Re: Joining the "Python 3 Statement"

2016-07-10 Thread Nick Timkovich
Regarding "forcing", the statement has a similar sentiment: "Third parties 
may offer paid support for our projects on old Python versions for longer 
than we support them ourselves. We won’t obstruct this, and it is a core 
principle of free and open source software that this is possible." If Blue 
Hat has a market for and chooses to develop Django 1.12 to run on their 
Python 2.8, that's fantastic. Just that you can't expect *free* support by 
the community beyond 2020.

Yes, the statement is status-quo for Django, but my motivation is more for 
this to expand the scope of said statement beyond the SciPy stack. Because 
this doesn't alter policy, I'm hoping for this as a smooth segue towards 
broader awareness/adoption.

On Sunday, July 10, 2016 at 1:18:56 PM UTC-4, Florian Apolloner wrote:
>
> On Sunday, July 10, 2016 at 3:22:47 PM UTC+2, Nick Sarbicki wrote:
>>
>> The problem with announcing way back is people outside of the sphere 
>> forget.
>>
>
> But then again those will not bother if Django is on Python3 or not. For 
> those it might be way more important if the default python is python3 on 
> their machines, or if a recent python is even available (looking at you 
> RHEL ;)).
>  
>
>> Even then (warning, dumb analogy coming), if I was asked to sign a 
>> petition to my government, I wouldn't refuse just because I'd already 
>> written to my MP about it. Speaking together has more power.
>>
>
> Yeah, given the current political situation I'd rather not continue that 
> argument -- lets leave politics out ;)
>  
>
>> My last job as an example had a huge pure python programme that is core 
>> to the business. My manager would try to justify upgrading to 3.x but it 
>> never caught on with the seniors. They would look at the stats and see most 
>> people still using 2.7, most libraries still working in 2.7, and see the 
>> current code still running in 2.7. There's never been anything big enough 
>> to convince them.
>>
>
> And those people are not convinced by a pledge either, so whats the point. 
> Then again, the decisions on companies often depend on other factors (ie 
> support on their machines etc…), and using python3 should be evaluated on a 
> project per project basis (and if a [non-binding]pledge is enough to shift 
> your managers, you probably have something else to worry about :D). 
>
> Even more to the point (and far worse in my mind) are the teaching 
>> websites like codecademy and learn python the hard way. They all still use 
>> python 2! And to justify it they quote employability and lack of 3.x 
>> uptake. Again if they were to have something bigger put in front of them to 
>> show how much of a dead end 2.7 is, it could push them to change.
>>
>
> Those people are quite aware that python3 is out there and ready, such a 
> statement is not going to help. It is probably quite a bit of work to 
> upgrade all those tutorials and they maybe do not see the gain in time vs 
> money or whatever…
>  
>
>> If that changes 3.x can get a big push forward. And that in the future 
>> can help Django.
>>
>
> And how exactly can that help Django?
>  
>
>> Realistically though, what is stopping us from signing? What negative 
>> outcome can it have?
>>
>
> Probably nothing, but Django in the past has never tried to convince 
> anyone or force anyone to do something (aside from the decisions we make 
> within our framework), and we do not feel the urge to force our view on 
> others -- nor sign a pledge for that matter. Our stance on Python 3 is 
> clear, we made our point, but we do not need or have to convince anyone 
> else.
>
> Cheers,
> Florian
>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/968d26e0-d792-4e0d-8bc7-b2173e850f30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-10 Thread Nick Sarbicki
>
> Not going to carry this on much more as I doubt I'll be convincing. And
while I, for the most part, agree that group pledges won't change the minds
of those locked to 2.7, I'm hopelessly optimistic about it :-).

And how exactly can that help Django?
>

I think anything which advances and promotes python3 will have direct knock
on effects for Django post 2.0. We all want to see the project thrive, and
if the language it's built on thrives as well that can only be a good thing.


Realistically though, what is stopping us from signing? What negative
>> outcome can it have?
>>
>
> Probably nothing, but Django in the past has never tried to convince
> anyone or force anyone to do something (aside from the decisions we make
> within our framework), and we do not feel the urge to force our view on
> others -- nor sign a pledge for that matter. Our stance on Python 3 is
> clear, we made our point, but we do not need or have to convince anyone
> else.
>

Again I think there's a difference in opinion here. I don't see it as
something we as a project need to convince people of. I see it as a
statement of intent. Django doesn't need to convince anyone, it just needs
to say "this is happening" (and if I had my way in this conversation,
publicly, more than once and in union with other projects...). The
convincing should be left to those using it.

Maybe it would have been better to not have an officially signed list. But
instead just a curated list of projects which have announced that they
won't support 2.7 at some date. Would have been easier and less political.

Nick.

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGuvt920HewnMjjzvn8kYdA8uNL%2BpsgQLxoqy81P9%2B6ro_3O%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-10 Thread ludovic coues
The 1.11 release note already tell clearly it will be the last version
of django supporting python2.

2016-07-10 16:17 GMT+02:00 Sam Willis :
> As far as I can tell the only place where Django's Python 2.x deprecation is 
> stated is here https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
>
> I think it should be more prominently stated in the docs, and as 1.11 is 
> supposedly the last to support 2.7 (according to the blog post) it may be 
> worth promoting it as such.
>
> Maybe there should be a pominant announcement about which version is the last 
> to support 2.7? Maybe in the release notes of 1.10?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/678cee6c-3df4-4715-b6af-3d20bf3f3822%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTZYGbQ-Hd91vS25QXMxJ0Xu-MxE%2BUfh1iDMBtf5oA0QMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-10 Thread Florian Apolloner
On Sunday, July 10, 2016 at 3:22:47 PM UTC+2, Nick Sarbicki wrote:
>
> The problem with announcing way back is people outside of the sphere 
> forget.
>

But then again those will not bother if Django is on Python3 or not. For 
those it might be way more important if the default python is python3 on 
their machines, or if a recent python is even available (looking at you 
RHEL ;)).
 

> Even then (warning, dumb analogy coming), if I was asked to sign a 
> petition to my government, I wouldn't refuse just because I'd already 
> written to my MP about it. Speaking together has more power.
>

Yeah, given the current political situation I'd rather not continue that 
argument -- lets leave politics out ;)
 

> My last job as an example had a huge pure python programme that is core to 
> the business. My manager would try to justify upgrading to 3.x but it never 
> caught on with the seniors. They would look at the stats and see most 
> people still using 2.7, most libraries still working in 2.7, and see the 
> current code still running in 2.7. There's never been anything big enough 
> to convince them.
>

And those people are not convinced by a pledge either, so whats the point. 
Then again, the decisions on companies often depend on other factors (ie 
support on their machines etc…), and using python3 should be evaluated on a 
project per project basis (and if a [non-binding]pledge is enough to shift 
your managers, you probably have something else to worry about :D). 

Even more to the point (and far worse in my mind) are the teaching websites 
> like codecademy and learn python the hard way. They all still use python 2! 
> And to justify it they quote employability and lack of 3.x uptake. Again if 
> they were to have something bigger put in front of them to show how much of 
> a dead end 2.7 is, it could push them to change.
>

Those people are quite aware that python3 is out there and ready, such a 
statement is not going to help. It is probably quite a bit of work to 
upgrade all those tutorials and they maybe do not see the gain in time vs 
money or whatever…
 

> If that changes 3.x can get a big push forward. And that in the future can 
> help Django.
>

And how exactly can that help Django?
 

> Realistically though, what is stopping us from signing? What negative 
> outcome can it have?
>

Probably nothing, but Django in the past has never tried to convince anyone 
or force anyone to do something (aside from the decisions we make within 
our framework), and we do not feel the urge to force our view on others -- 
nor sign a pledge for that matter. Our stance on Python 3 is clear, we made 
our point, but we do not need or have to convince anyone else.

Cheers,
Florian

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0da82dc7-c515-4e10-b0b9-c3cd873956e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-10 Thread Sam Willis
As far as I can tell the only place where Django's Python 2.x deprecation is 
stated is here https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

I think it should be more prominently stated in the docs, and as 1.11 is 
supposedly the last to support 2.7 (according to the blog post) it may be worth 
promoting it as such.

Maybe there should be a pominant announcement about which version is the last 
to support 2.7? Maybe in the release notes of 1.10?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/678cee6c-3df4-4715-b6af-3d20bf3f3822%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-10 Thread Nick Sarbicki
On my phone so excuse typos.

On Sun, 10 Jul 2016, 13:28 Florian Apolloner,  wrote:

>
>
> On Saturday, July 9, 2016 at 10:26:25 PM UTC+2, Nick Sarbicki wrote:
>>
>> I don't think this is a question of what it would do for Django. More
>> what Django could do for python.
>
>
> We already announced (way way back), that we are dropping support for
> Python 2 and outlined our plan. That is imo enough, being on a side like
> python3statement.github.io does not add any value to python.
>


The problem with announcing way back is people outside of the sphere
forget. Yes everyone working with Django should know. I know everyone in my
team is very aware of the deadline.

But those outside of Django forget how seriously this is being taken by the
community.

Even then (warning, dumb analogy coming), if I was asked to sign a petition
to my government, I wouldn't refuse just because I'd already written to my
MP about it. Speaking together has more power.

Again, no immediate benefit to Django, but there is one for python.



> The web and scientific communities are essentially the two biggest python
>> communities around. If they both joined together to say "2020 is the
>> deadline for us and everyone else" it could really push a lot of others to
>> see how serious the need to move is now.
>>
>
> Everyone seriously involved in Django (agencies, companies) etc are
> already aware of our plans and are hopefully preparing themselves, if not,
> there is little else we can do which would change their minds…
>

Again, in Django most definitely are. But outside of Django it's less clear.

My last job as an example had a huge pure python programme that is core to
the business. My manager would try to justify upgrading to 3.x but it never
caught on with the seniors. They would look at the stats and see most
people still using 2.7, most libraries still working in 2.7, and see the
current code still running in 2.7. There's never been anything big enough
to convince them.

It didn't run Django so Django announcing wouldn't have any impact. But if
all the major libraries announced then it might have.

Even more to the point (and far worse in my mind) are the teaching websites
like codecademy and learn python the hard way. They all still use python 2!
And to justify it they quote employability and lack of 3.x uptake. Again if
they were to have something bigger put in front of them to show how much of
a dead end 2.7 is, it could push them to change.

If that changes 3.x can get a big push forward. And that in the future can
help Django.

Realistically though, what is stopping us from signing? What negative
outcome can it have?

Nick.

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGuvt90S1oGxePdm14J-xAzT_mPmQE3dk5_F3SZubv_hRssfHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-10 Thread Florian Apolloner


On Saturday, July 9, 2016 at 10:26:25 PM UTC+2, Nick Sarbicki wrote:
>
> I don't think this is a question of what it would do for Django. More what 
> Django could do for python. 


We already announced (way way back), that we are dropping support for 
Python 2 and outlined our plan. That is imo enough, being on a side like 
python3statement.github.io does not add any value to python.

The web and scientific communities are essentially the two biggest python 
> communities around. If they both joined together to say "2020 is the 
> deadline for us and everyone else" it could really push a lot of others to 
> see how serious the need to move is now.
>

Everyone seriously involved in Django (agencies, companies) etc are already 
aware of our plans and are hopefully preparing themselves, if not, there is 
little else we can do which would change their minds…

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1f594455-aee2-4be5-9524-d6f262c1960d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-09 Thread Nick Sarbicki
Hi Aymeric,

I don't think this is a question of what it would do for Django. More what
Django could do for python.

The web and scientific communities are essentially the two biggest python
communities around. If they both joined together to say "2020 is the
deadline for us and everyone else" it could really push a lot of others to
see how serious the need to move is now.

Python could gain from the greater uptake of 3.x and further downstream
Django will benefit too. I don't find it smug. I think it's a reality check.

Nick.

On Sat, 9 Jul 2016, 07:51 Aymeric Augustin, <
aymeric.augus...@polytechnique.org> wrote:

> Hello Nick,
>
> This website was quickly discussed by a few team members some time ago. It
> wasn’t clear to us what joining this initiative would achieve for Django.
>
> At first sight, it would mostly allow those who run on Python 3 to feel a
> bit more smug and make those who are stuck on Python 2 a bit more
> frustrated.
>
> The web community seems to be ahead of the scientific community for moving
> to Python 3. By now most Django users should be aware that they have to
> figure out a plan to migrate to Python 3 (or JS, or Go, etc.) I don’t think
> the scientific community is there yet.
>
> (To be honest, I discovered recently that some high-profile members of the
> Django community are still advocating to start new projects on Python 2.
> I’m failing to rationalize why they give this advice, certainly because of
> my biais.)
>
> If we consider that we’ve reached a point where we no longer need to focus
> on raising awareness, I’d rather drive the migration to Python 3 with a
> stick than with a carrot. There’s plenty of cool stuff to advertise :-)
>
> --
> Aymeric.
>
> On 09 Jul 2016, at 04:03, Nick Timkovich <prometheus...@gmail.com> wrote:
>
> With the release of IPython 5.0 LTS, it was mentioned as also being the
> final Py2-compat release in the series with a reference to the "Python 3
> Statement" https://python3statement.github.io/ Some of the prose in it
> refers to just the Scientific Stack (Numpy, Scipy, MPL, et al.), but an
> issue popped up saying that it could be generalized if other projects were
> to join/"sign", e.g. Django.
> https://github.com/python3statement/python3statement.github.io/issues/21
>
> I'm not strongly advocating one way or the other, just thought I'd bring
> it up.
>
> Nick
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7E8B9E8B-D60E-48E4-BDB5-969BC4479EDF%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/7E8B9E8B-D60E-48E4-BDB5-969BC4479EDF%40polytechnique.org?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGuvt91Fw%2Bayc02jyW_-8hxj1_sekJvfkuUQsi0Ft566gyZ92w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Joining the "Python 3 Statement"

2016-07-09 Thread Aymeric Augustin
Hello Nick,

This website was quickly discussed by a few team members some time ago. It 
wasn’t clear to us what joining this initiative would achieve for Django.

At first sight, it would mostly allow those who run on Python 3 to feel a bit 
more smug and make those who are stuck on Python 2 a bit more frustrated.

The web community seems to be ahead of the scientific community for moving to 
Python 3. By now most Django users should be aware that they have to figure out 
a plan to migrate to Python 3 (or JS, or Go, etc.) I don’t think the scientific 
community is there yet.

(To be honest, I discovered recently that some high-profile members of the 
Django community are still advocating to start new projects on Python 2. I’m 
failing to rationalize why they give this advice, certainly because of my 
biais.)

If we consider that we’ve reached a point where we no longer need to focus on 
raising awareness, I’d rather drive the migration to Python 3 with a stick than 
with a carrot. There’s plenty of cool stuff to advertise :-)

-- 
Aymeric.

> On 09 Jul 2016, at 04:03, Nick Timkovich <prometheus...@gmail.com> wrote:
> 
> With the release of IPython 5.0 LTS, it was mentioned as also being the final 
> Py2-compat release in the series with a reference to the "Python 3 Statement" 
> https://python3statement.github.io/ Some of the prose in it refers to just 
> the Scientific Stack (Numpy, Scipy, MPL, et al.), but an issue popped up 
> saying that it could be generalized if other projects were to join/"sign", 
> e.g. Django. 
> https://github.com/python3statement/python3statement.github.io/issues/21
> 
> I'm not strongly advocating one way or the other, just thought I'd bring it 
> up.
> 
> Nick
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers 
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7E8B9E8B-D60E-48E4-BDB5-969BC4479EDF%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Joining the "Python 3 Statement"

2016-07-08 Thread Nick Timkovich
With the release of IPython 5.0 LTS, it was mentioned as also being the 
final Py2-compat release in the series with a reference to the "Python 3 
Statement" https://python3statement.github.io/ Some of the prose in it 
refers to just the Scientific Stack (Numpy, Scipy, MPL, et al.), but an 
issue popped up saying that it could be generalized if other projects were 
to join/"sign", e.g. Django. 
https://github.com/python3statement/python3statement.github.io/issues/21

I'm not strongly advocating one way or the other, just thought I'd bring it 
up.

Nick

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0460ab73-1059-49e9-be63-2716378fddca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-18 Thread Aymeric Augustin
Considering the information provided by Donald, it’s pretty clear to me that we 
should switch to rc as proposed by Tim.

-- 
Aymeric.



> On 18 nov. 2015, at 01:26, Tim Graham <timogra...@gmail.com> wrote:
> 
> Thanks Donald, updating setuptools was the factor I missed, not Python 2 vs. 
> 3.
> 
> On Tuesday, November 17, 2015 at 5:06:59 PM UTC-5, Donald Stufft wrote:
> 
>> On Nov 17, 2015, at 12:00 PM, Tim Graham <timog...@gmail.com > 
>> wrote:
>> 
>> There was a small hiccup with the 1.9 release candidate yesterday. Unless 
>> there is some other conflating factor that I missed, generating release 
>> packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
>> Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
>> release must have been the first release candidate to be generated using 
>> Python 3, and this broke the download page because 
>> django.utils.version.get_version() (which the website uses) returns "c1" for 
>> the file name instead of "rc1". I put in a (perhaps temporary) fix to 
>> correct this: https://github.com/django/djangoproject.com/pull/547 
>> <https://github.com/django/djangoproject.com/pull/547>
>> 
>> Do you think it's correct to make the change in Django itself? 
>> https://github.com/django/django/pull/5676 
>> <https://github.com/django/django/pull/5676> -- I didn't track down the 
>> reason why this changed in Python.
>> While get_version() isn't a public API, it's widely used according to GitHub 
>> search.
>> 
> 
> Whoever generated the tarballs is probably using a version of setuptools 
> older than 8.0 in their Python 2 environment and a version of setuptools 
> newer than 8.0 in their Python 3 environment.
> 
> 
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-developers 
> <http://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/e02a697f-36c4-4604-b484-1907919a6a54%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/e02a697f-36c4-4604-b484-1907919a6a54%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/72652A2A-292E-4303-ACCE-8BB1104196B0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Tim Graham
Thanks Donald, updating setuptools was the factor I missed, not Python 2 
vs. 3.

On Tuesday, November 17, 2015 at 5:06:59 PM UTC-5, Donald Stufft wrote:
>
>
> On Nov 17, 2015, at 12:00 PM, Tim Graham <timog...@gmail.com > 
> wrote:
>
> There was a small hiccup with the 1.9 release candidate yesterday. Unless 
> there is some other conflating factor that I missed, generating release 
> packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
> Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
> release must have been the first release candidate to be generated using 
> Python 3, and this broke the download page because 
> django.utils.version.get_version() (which the website uses) returns "c1" 
> for the file name instead of "rc1". I put in a (perhaps temporary) fix to 
> correct this: https://github.com/django/djangoproject.com/pull/547
>
> Do you think it's correct to make the change in Django itself? 
> https://github.com/django/django/pull/5676 -- I didn't track down the 
> reason why this changed in Python.
> While get_version() isn't a public API, it's widely used according to 
> GitHub search.
>
>
> Whoever generated the tarballs is probably using a version of setuptools 
> older than 8.0 in their Python 2 environment and a version of setuptools 
> newer than 8.0 in their Python 3 environment.
>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/e02a697f-36c4-4604-b484-1907919a6a54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Donald Stufft

> On Nov 17, 2015, at 12:00 PM, Tim Graham <timogra...@gmail.com> wrote:
> 
> There was a small hiccup with the 1.9 release candidate yesterday. Unless 
> there is some other conflating factor that I missed, generating release 
> packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
> Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
> release must have been the first release candidate to be generated using 
> Python 3, and this broke the download page because 
> django.utils.version.get_version() (which the website uses) returns "c1" for 
> the file name instead of "rc1". I put in a (perhaps temporary) fix to correct 
> this: https://github.com/django/djangoproject.com/pull/547 
> <https://github.com/django/djangoproject.com/pull/547>
> 
> Do you think it's correct to make the change in Django itself? 
> https://github.com/django/django/pull/5676 
> <https://github.com/django/django/pull/5676> -- I didn't track down the 
> reason why this changed in Python.
> While get_version() isn't a public API, it's widely used according to GitHub 
> search.
> 

Whoever generated the tarballs is probably using a version of setuptools older 
than 8.0 in their Python 2 environment and a version of setuptools newer than 
8.0 in their Python 3 environment.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/F8D9E8C5-852C-4BDF-A8E9-C3D91CFA7972%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Donald Stufft

> On Nov 17, 2015, at 3:03 PM, Aymeric Augustin 
>  wrote:
> 
> On 17 nov. 2015, at 18:00, Tim Graham  > wrote:
> 
>> Do you think it's correct to make the change in Django itself? 
>> https://github.com/django/django/pull/5676 
>>  -- I didn't track down the 
>> reason why this changed in Python.
> 
> 
> 
> Per PEP 386, the standard scheme is ‘c’, although ‘rc’ is acceptable as well.

PEP 386 has been superseded by PEP 440 which recommends “rc” because almost 
everyone was using “rc” and not “c”. It didn’t seem reasonable to have a 
decision which was solely bike shedding (it can handle rc as easily as it can 
handle c) to favor an option that flew in the face of what most projects were 
doing.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/D79091CB-743C-4D96-8CAF-29718BDA61D9%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Aymeric Augustin
On 17 nov. 2015, at 18:00, Tim Graham <timogra...@gmail.com> wrote:

> Do you think it's correct to make the change in Django itself? 
> https://github.com/django/django/pull/5676 
> <https://github.com/django/django/pull/5676> -- I didn't track down the 
> reason why this changed in Python.



Per PEP 386, the standard scheme is ‘c’, although ‘rc’ is acceptable as well.

> Pre-releases can use a for "alpha", b for "beta" and c for "release 
> candidate". rc is an alternative notation for "release candidate" that is 
> added to make the version scheme compatible with Python's own version scheme. 
> rc sorts after c.

We can take this opportunity to change the naming scheme to what Python 3 
generates by default. We just have to be careful not to generate releases with 
Python 2 from now on. I suggest to add something in the release checklist 
(assuming you still follow it when making releases, perhaps you know it by 
heart by now).

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/34D2A435-48DA-47E2-A86F-FE5BF351%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Tim Graham
There was a small hiccup with the 1.9 release candidate yesterday. Unless 
there is some other conflating factor that I missed, generating release 
packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
release must have been the first release candidate to be generated using 
Python 3, and this broke the download page because 
django.utils.version.get_version() (which the website uses) returns "c1" 
for the file name instead of "rc1". I put in a (perhaps temporary) fix to 
correct this: https://github.com/django/djangoproject.com/pull/547

Do you think it's correct to make the change in Django itself? 
https://github.com/django/django/pull/5676 -- I didn't track down the 
reason why this changed in Python.
While get_version() isn't a public API, it's widely used according to 
GitHub search.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/8a7f8f47-6a43-4a02-a0f5-f64461cefadf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-11-04 Thread Collin Anderson
I started the ball rolling on getting mysqlclient packaged in Debian/Ubuntu.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768096

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/382ac68c-e992-4b1f-b50c-917057036e04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Tim Graham
Test failures are fixed with mysqlclient 1.3.3. I believe we can now move 
the discussion of the implementation of this to the 
ticket: https://code.djangoproject.com/ticket/23446

There are some tickets about pymysql (below), but I have some reservations 
about officially supporting more than one MySQL connector since our 
buildbot would presumably need to test all of them.

https://code.djangoproject.com/ticket/20542
https://code.djangoproject.com/ticket/22391

On Tuesday, September 9, 2014 3:32:47 PM UTC-4, Corey Farwell wrote:
>
> It is a valid concern. That said, I'd rather the documentation recommend a 
> GPL, Python 3+2, working MySQL connector over a GPL, Python 2, partially 
> broken MySQL connector.
>
> On Tuesday, September 9, 2014 3:21:08 PM UTC-4, Daniel Sears wrote:
>>
>> Aside from the technical issues, there are the licensing issues. The 
>> Django community strongly prefers BSD-style licensing and both mysqldb and 
>> MySQL Connector/Python use GPL licenses. For an e-mail thread which 
>> addresses these GPL issues, see
>>
>>
>> https://groups.google.com/forum/#!msg/django-developers/8r_RVmUe5ys/09lCwJl-L1kJ
>>
>> PyMySQL does appear to have a BSD-like license.
>>
>> --Dan
>>
>>
>> On Tuesday, September 9, 2014 8:26:37 AM UTC-7, Naoki INADA wrote:
>>>
>>> I've fixed them and released mysqlclient 1.3.3.
>>> https://pypi.python.org/pypi/mysqlclient
>>>
>>> On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>>>>
>>>> I've fixed `%(xxx)s` style formatting.
>>>>
>>>> I have not changed error switch:
>>>> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
>>>> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>>>>
>>>> I'll investigate the problem, but I can't promise any date for fixing 
>>>> it.
>>>>
>>>>
>>>> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>>>>>
>>>>> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timog...@gmail.com> 
>>>>>> wrote: 
>>>>>> > We'd need mysqlclient to support Python 3.2 (or drop official 
>>>>>> support for 
>>>>>> > MySQL/Python 3.2): 
>>>>>>
>>>>>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>>>>>> many Unicode API has 
>>>>>> been changed and deprecated.  It also introduce unicode literal. 
>>>>>> Supporting Python 3.2 will make code messy. 
>>>>>>
>>>>>> I want to drop Python 3.2 support since I believe most Python 3 users 
>>>>>> are aggressive enough 
>>>>>> to go forward. 
>>>>>>
>>>>>> How Python 3.2 important for you? 
>>>>>>
>>>>>
>>>>> I think we could live with MySQL not supporting Python 3.2. 
>>>>>
>>>>> > Python 2.7 test failures: 
>>>>>> > 
>>>>>> > 
>>>>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>>>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>>>>> > 
>>>>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>>>>  
>>>>>>
>>>>>> > 
>>>>>> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>>>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>>>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>>>>
>>>>>
>>>>> Thanks Tim for testing. These errors seem to all have the same origin, 
>>>>> null inserts into not-null columns generate OperationalError instead of 
>>>>> IntegrityError.
>>>>>  
>>>>>
>>>>>> > Python 3.4 test failures: 
>>>>>> > 
>>>>>> > 
>>>>>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>>>>>> > 
>>>>>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>>>>>> > 
>>>>>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>>>>>  
>>>&g

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Corey Farwell
It is a valid concern. That said, I'd rather the documentation recommend a 
GPL, Python 3+2, working MySQL connector over a GPL, Python 2, partially 
broken MySQL connector.

On Tuesday, September 9, 2014 3:21:08 PM UTC-4, Daniel Sears wrote:
>
> Aside from the technical issues, there are the licensing issues. The 
> Django community strongly prefers BSD-style licensing and both mysqldb and 
> MySQL Connector/Python use GPL licenses. For an e-mail thread which 
> addresses these GPL issues, see
>
>
> https://groups.google.com/forum/#!msg/django-developers/8r_RVmUe5ys/09lCwJl-L1kJ
>
> PyMySQL does appear to have a BSD-like license.
>
> --Dan
>
>
> On Tuesday, September 9, 2014 8:26:37 AM UTC-7, Naoki INADA wrote:
>>
>> I've fixed them and released mysqlclient 1.3.3.
>> https://pypi.python.org/pypi/mysqlclient
>>
>> On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>>>
>>> I've fixed `%(xxx)s` style formatting.
>>>
>>> I have not changed error switch:
>>> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
>>> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>>>
>>> I'll investigate the problem, but I can't promise any date for fixing it.
>>>
>>>
>>> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>>>>
>>>> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>>>>
>>>>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timog...@gmail.com> 
>>>>> wrote: 
>>>>> > We'd need mysqlclient to support Python 3.2 (or drop official 
>>>>> support for 
>>>>> > MySQL/Python 3.2): 
>>>>>
>>>>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>>>>> many Unicode API has 
>>>>> been changed and deprecated.  It also introduce unicode literal. 
>>>>> Supporting Python 3.2 will make code messy. 
>>>>>
>>>>> I want to drop Python 3.2 support since I believe most Python 3 users 
>>>>> are aggressive enough 
>>>>> to go forward. 
>>>>>
>>>>> How Python 3.2 important for you? 
>>>>>
>>>>
>>>> I think we could live with MySQL not supporting Python 3.2. 
>>>>
>>>> > Python 2.7 test failures: 
>>>>> > 
>>>>> > 
>>>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>>>> > 
>>>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>>>  
>>>>>
>>>>> > 
>>>>> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>>>
>>>>
>>>> Thanks Tim for testing. These errors seem to all have the same origin, 
>>>> null inserts into not-null columns generate OperationalError instead of 
>>>> IntegrityError.
>>>>  
>>>>
>>>>> > Python 3.4 test failures: 
>>>>> > 
>>>>> > 
>>>>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>>>>> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>>>>> > 
>>>>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>>>>  
>>>>>
>>>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>>>> > 
>>>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>>>  
>>>>>
>>>>> > 
>>>>> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>>> > raw_query.tests.RawQueryTests.test_pyformat_params 
>>>>>
>>>>>
>>>> In addition of the above issue, it seems that pyformat isn't supported 
>>>> for Python3. Something around these lines:
>>>> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
>>>> {"val1": value_1, "val2": value_2})
>>>>
>>>> I've created issues on the mysqlclient bug tracker.
>>>> https://github.com/PyMySQL/mysqlclient-python/issues/3
>>>> https://github.com/PyMySQL/mysqlclient-python/issues/4
>>>>
>>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a6bb5190-eebf-466c-b0d7-0c592ce7c6bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Daniel Sears
Aside from the technical issues, there are the licensing issues. The Django 
community strongly prefers BSD-style licensing and both mysqldb and MySQL 
Connector/Python use GPL licenses. For an e-mail thread which addresses 
these GPL issues, see

https://groups.google.com/forum/#!msg/django-developers/8r_RVmUe5ys/09lCwJl-L1kJ

PyMySQL does appear to have a BSD-like license.

--Dan


On Tuesday, September 9, 2014 8:26:37 AM UTC-7, Naoki INADA wrote:
>
> I've fixed them and released mysqlclient 1.3.3.
> https://pypi.python.org/pypi/mysqlclient
>
> On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>>
>> I've fixed `%(xxx)s` style formatting.
>>
>> I have not changed error switch:
>> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
>> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>>
>> I'll investigate the problem, but I can't promise any date for fixing it.
>>
>>
>> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>>>
>>> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>>>
>>>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timog...@gmail.com> 
>>>> wrote: 
>>>> > We'd need mysqlclient to support Python 3.2 (or drop official support 
>>>> for 
>>>> > MySQL/Python 3.2): 
>>>>
>>>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>>>> many Unicode API has 
>>>> been changed and deprecated.  It also introduce unicode literal. 
>>>> Supporting Python 3.2 will make code messy. 
>>>>
>>>> I want to drop Python 3.2 support since I believe most Python 3 users 
>>>> are aggressive enough 
>>>> to go forward. 
>>>>
>>>> How Python 3.2 important for you? 
>>>>
>>>
>>> I think we could live with MySQL not supporting Python 3.2. 
>>>
>>> > Python 2.7 test failures: 
>>>> > 
>>>> > 
>>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>>> > 
>>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>>  
>>>>
>>>> > 
>>>> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>>
>>>
>>> Thanks Tim for testing. These errors seem to all have the same origin, 
>>> null inserts into not-null columns generate OperationalError instead of 
>>> IntegrityError.
>>>  
>>>
>>>> > Python 3.4 test failures: 
>>>> > 
>>>> > 
>>>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>>>> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>>>> > 
>>>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>>>  
>>>>
>>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>>> > 
>>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>>  
>>>>
>>>> > 
>>>> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>> > raw_query.tests.RawQueryTests.test_pyformat_params 
>>>>
>>>>
>>> In addition of the above issue, it seems that pyformat isn't supported 
>>> for Python3. Something around these lines:
>>> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
>>> {"val1": value_1, "val2": value_2})
>>>
>>> I've created issues on the mysqlclient bug tracker.
>>> https://github.com/PyMySQL/mysqlclient-python/issues/3
>>> https://github.com/PyMySQL/mysqlclient-python/issues/4
>>>
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ed5e0901-c632-4c47-9aa4-72ea54f0a97c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Naoki INADA
I've fixed them and released mysqlclient 1.3.3.
https://pypi.python.org/pypi/mysqlclient

On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>
> I've fixed `%(xxx)s` style formatting.
>
> I have not changed error switch:
> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>
> I'll investigate the problem, but I can't promise any date for fixing it.
>
>
> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>>
>> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>>
>>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timog...@gmail.com> wrote: 
>>> > We'd need mysqlclient to support Python 3.2 (or drop official support 
>>> for 
>>> > MySQL/Python 3.2): 
>>>
>>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>>> many Unicode API has 
>>> been changed and deprecated.  It also introduce unicode literal. 
>>> Supporting Python 3.2 will make code messy. 
>>>
>>> I want to drop Python 3.2 support since I believe most Python 3 users 
>>> are aggressive enough 
>>> to go forward. 
>>>
>>> How Python 3.2 important for you? 
>>>
>>
>> I think we could live with MySQL not supporting Python 3.2. 
>>
>> > Python 2.7 test failures: 
>>> > 
>>> > 
>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>> > 
>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>  
>>>
>>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>
>>
>> Thanks Tim for testing. These errors seem to all have the same origin, 
>> null inserts into not-null columns generate OperationalError instead of 
>> IntegrityError.
>>  
>>
>>> > Python 3.4 test failures: 
>>> > 
>>> > 
>>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>>> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>>> > 
>>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>>  
>>>
>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>> > 
>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>  
>>>
>>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>> > raw_query.tests.RawQueryTests.test_pyformat_params 
>>>
>>>
>> In addition of the above issue, it seems that pyformat isn't supported 
>> for Python3. Something around these lines:
>> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
>> {"val1": value_1, "val2": value_2})
>>
>> I've created issues on the mysqlclient bug tracker.
>> https://github.com/PyMySQL/mysqlclient-python/issues/3
>> https://github.com/PyMySQL/mysqlclient-python/issues/4
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35badf29-051c-44af-9938-607ed2a7d1ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Florian Apolloner
Python 2.7.3 and MySQL_python-1.2.5-cp27-none-linux_x86_64.whl

On Tuesday, September 9, 2014 10:41:40 AM UTC+2, Naoki INADA wrote:
>
> I run django tests using MySQL-python 1.2.5 (aka, MySQLdb1) and Python 
> 2.7.8. 
> So it means django doesn't work with MySQL with MySQL-python. 
>
> $ python -V 
> Python 2.7.8 
> (mysql2)[inada-n@MBA:~] 
> $ pip list 
> MySQL-python (1.2.5) 
> pip (1.5.6) 
> setuptools (3.6) 
> wsgiref (0.1.2) 
>
> On Tue, Sep 9, 2014 at 5:18 PM, Florian Apolloner  > wrote: 
> > On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote: 
> >> 
> >> Failed to install index for admin_views.PrePopulatedPostLargeSlug 
> >> model: (1071, 'Specified key was too long; max key length is 767 
> bytes') 
> > 
> > 
> > Welcome to the wonderful world to mysql, afaik this is a warning and not 
> an 
> > error; so your database driver might convert that incorrectly. 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "Django developers" group. 
> > To unsubscribe from this topic, visit 
> > 
> https://groups.google.com/d/topic/django-developers/n-TI8mBcegE/unsubscribe. 
>
> > To unsubscribe from this group and all its topics, send an email to 
> > django-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/4bd04867-0f32-4db2-85b3-41671f92aecc%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> INADA Naoki   
>

-- 
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/e4a2365f-625b-4154-8e5f-dda3a206ec33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Florian Apolloner
http://djangoci.com/ disagrees with you :) Would have to check the specific 
mysqldb version. 

-- 
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/01a5f888-75c2-4315-9ad0-e52359b215de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread INADA Naoki
I run django tests using MySQL-python 1.2.5 (aka, MySQLdb1) and Python 2.7.8.
So it means django doesn't work with MySQL with MySQL-python.

$ python -V
Python 2.7.8
(mysql2)[inada-n@MBA:~]
$ pip list
MySQL-python (1.2.5)
pip (1.5.6)
setuptools (3.6)
wsgiref (0.1.2)

On Tue, Sep 9, 2014 at 5:18 PM, Florian Apolloner  wrote:
> On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote:
>>
>> Failed to install index for admin_views.PrePopulatedPostLargeSlug
>> model: (1071, 'Specified key was too long; max key length is 767 bytes')
>
>
> Welcome to the wonderful world to mysql, afaik this is a warning and not an
> error; so your database driver might convert that incorrectly.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/n-TI8mBcegE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/4bd04867-0f32-4db2-85b3-41671f92aecc%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
INADA Naoki  

-- 
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/CAEfz%2BTxL4E8jYSBrF4jh1H2QTKncQXNAF9uZGJTOshCXf1BxXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Florian Apolloner
On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote:
>
> Failed to install index for admin_views.PrePopulatedPostLargeSlug 
> model: (1071, 'Specified key was too long; max key length is 767 bytes')
>

Welcome to the wonderful world to mysql, afaik this is a warning and not an 
error; so your database driver might convert that incorrectly. 

-- 
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/4bd04867-0f32-4db2-85b3-41671f92aecc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Naoki INADA
I can't run django test.

Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Failed to install index for admin_views.PrePopulatedPostLargeSlug 
model: (1071, 'Specified key was too long; max key length is 767 bytes')

I use 1.7 tag on git repository.


On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>
> I've fixed `%(xxx)s` style formatting.
>
> I have not changed error switch:
> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>
> I'll investigate the problem, but I can't promise any date for fixing it.
>
>
> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>>
>> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>>
>>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timog...@gmail.com> wrote: 
>>> > We'd need mysqlclient to support Python 3.2 (or drop official support 
>>> for 
>>> > MySQL/Python 3.2): 
>>>
>>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>>> many Unicode API has 
>>> been changed and deprecated.  It also introduce unicode literal. 
>>> Supporting Python 3.2 will make code messy. 
>>>
>>> I want to drop Python 3.2 support since I believe most Python 3 users 
>>> are aggressive enough 
>>> to go forward. 
>>>
>>> How Python 3.2 important for you? 
>>>
>>
>> I think we could live with MySQL not supporting Python 3.2. 
>>
>> > Python 2.7 test failures: 
>>> > 
>>> > 
>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>> > 
>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>  
>>>
>>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>
>>
>> Thanks Tim for testing. These errors seem to all have the same origin, 
>> null inserts into not-null columns generate OperationalError instead of 
>> IntegrityError.
>>  
>>
>>> > Python 3.4 test failures: 
>>> > 
>>> > 
>>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>>> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>>> > 
>>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>>  
>>>
>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>> > 
>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>  
>>>
>>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>> > raw_query.tests.RawQueryTests.test_pyformat_params 
>>>
>>>
>> In addition of the above issue, it seems that pyformat isn't supported 
>> for Python3. Something around these lines:
>> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
>> {"val1": value_1, "val2": value_2})
>>
>> I've created issues on the mysqlclient bug tracker.
>> https://github.com/PyMySQL/mysqlclient-python/issues/3
>> https://github.com/PyMySQL/mysqlclient-python/issues/4
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c160599a-13b2-445d-a0a0-6e9cea4be953%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Naoki INADA
I've fixed `%(xxx)s` style formatting.

I have not changed error switch:
https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180

I'll investigate the problem, but I can't promise any date for fixing it.


On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>
> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>
>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timog...@gmail.com> wrote: 
>> > We'd need mysqlclient to support Python 3.2 (or drop official support 
>> for 
>> > MySQL/Python 3.2): 
>>
>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>> many Unicode API has 
>> been changed and deprecated.  It also introduce unicode literal. 
>> Supporting Python 3.2 will make code messy. 
>>
>> I want to drop Python 3.2 support since I believe most Python 3 users 
>> are aggressive enough 
>> to go forward. 
>>
>> How Python 3.2 important for you? 
>>
>
> I think we could live with MySQL not supporting Python 3.2. 
>
> > Python 2.7 test failures: 
>> > 
>> > 
>> > custom_pk.tests.CustomPKTests.test_required_pk 
>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>> > 
>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>  
>>
>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>
>
> Thanks Tim for testing. These errors seem to all have the same origin, 
> null inserts into not-null columns generate OperationalError instead of 
> IntegrityError.
>  
>
>> > Python 3.4 test failures: 
>> > 
>> > 
>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>> > 
>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>  
>>
>> > custom_pk.tests.CustomPKTests.test_required_pk 
>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>> > 
>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>  
>>
>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>> > model_fields.tests.BooleanFieldTests.test_null_default 
>> > raw_query.tests.RawQueryTests.test_pyformat_params 
>>
>>
> In addition of the above issue, it seems that pyformat isn't supported for 
> Python3. Something around these lines:
> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
> {"val1": value_1, "val2": value_2})
>
> I've created issues on the mysqlclient bug tracker.
> https://github.com/PyMySQL/mysqlclient-python/issues/3
> https://github.com/PyMySQL/mysqlclient-python/issues/4
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3f29471a-c174-4985-8018-881f866edaa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Collin Anderson
I also don't need python 3.2 support (or even python 3.3 support for that 
matter)

-- 
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/36b57267-d451-4c89-a2e4-9ee6302743eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Tim Graham
I don't think it'd be a problem, but I don't use MySQL or Python 3.2 on a 
regular basis.

On Monday, September 8, 2014 11:19:56 AM UTC-4, Naoki INADA wrote:
>
> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timog...@gmail.com 
> > wrote: 
> > We'd need mysqlclient to support Python 3.2 (or drop official support 
> for 
> > MySQL/Python 3.2): 
>
> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
> many Unicode API has 
> been changed and deprecated.  It also introduce unicode literal. 
> Supporting Python 3.2 will make code messy. 
>
> I want to drop Python 3.2 support since I believe most Python 3 users 
> are aggressive enough 
> to go forward. 
>
> How Python 3.2 important for you? 
>
> > 
> > django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb 
> module: 
> > 
> /var/lib/jenkins/workspace/django-selenium/database/mysql/python/python3.2/tests/.env/lib/python3.2/site-packages/_
> mysql.cpython-32mu.so: 
> > undefined symbol: PyUnicode_AsUTF8 
> > 
> > 
> > Python 2.7 test failures: 
> > 
> > 
> > custom_pk.tests.CustomPKTests.test_required_pk 
> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
> > 
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>  
>
> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
> > model_fields.tests.BooleanFieldTests.test_null_default 
> > 
> > 
> > Python 3.4 test failures: 
> > 
> > 
> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
> > 
> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator 
>
> > custom_pk.tests.CustomPKTests.test_required_pk 
> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
> > 
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>  
>
> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
> > model_fields.tests.BooleanFieldTests.test_null_default 
> > raw_query.tests.RawQueryTests.test_pyformat_params 
> > 
> > 
> > Let me know if you need tracebacks, but I assume you'll need to run the 
> > tests  yourself in our to fix the issues. 
> > 
> > On Monday, September 8, 2014 9:38:22 AM UTC-4, Collin Anderson wrote: 
> >> 
> >> It's great to see us moving forward on this. Thanks to Naoki for all of 
> >> the work on this! 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "Django developers" group. 
> > To unsubscribe from this topic, visit 
> > 
> https://groups.google.com/d/topic/django-developers/n-TI8mBcegE/unsubscribe. 
>
> > To unsubscribe from this group and all its topics, send an email to 
> > django-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/fcc06c58-a366-4996-9b57-6412d93c6483%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> INADA Naoki  <songof...@gmail.com > 
>

-- 
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/3adcf424-c70d-4d7f-b5f7-c2b640aab07c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread INADA Naoki
On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham <timogra...@gmail.com> wrote:
> We'd need mysqlclient to support Python 3.2 (or drop official support for
> MySQL/Python 3.2):

Python 3.3 introduces PEP 393 (Flexible String Representation) and
many Unicode API has
been changed and deprecated.  It also introduce unicode literal.
Supporting Python 3.2 will make code messy.

I want to drop Python 3.2 support since I believe most Python 3 users
are aggressive enough
to go forward.

How Python 3.2 important for you?

>
> django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module:
> /var/lib/jenkins/workspace/django-selenium/database/mysql/python/python3.2/tests/.env/lib/python3.2/site-packages/_mysql.cpython-32mu.so:
> undefined symbol: PyUnicode_AsUTF8
>
>
> Python 2.7 test failures:
>
>
> custom_pk.tests.CustomPKTests.test_required_pk
> fixtures.tests.FixtureLoadingTests.test_loaddata_error_message
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params
> get_or_create.tests.UpdateOrCreateTests.test_integrity
> model_fields.tests.BooleanFieldTests.test_null_default
>
>
> Python 3.4 test failures:
>
>
> backends.tests.BackendTestCase.test_cursor_execute_with_pyformat
> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat
> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
> custom_pk.tests.CustomPKTests.test_required_pk
> fixtures.tests.FixtureLoadingTests.test_loaddata_error_message
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params
> get_or_create.tests.UpdateOrCreateTests.test_integrity
> model_fields.tests.BooleanFieldTests.test_null_default
> raw_query.tests.RawQueryTests.test_pyformat_params
>
>
> Let me know if you need tracebacks, but I assume you'll need to run the
> tests  yourself in our to fix the issues.
>
> On Monday, September 8, 2014 9:38:22 AM UTC-4, Collin Anderson wrote:
>>
>> It's great to see us moving forward on this. Thanks to Naoki for all of
>> the work on this!
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/n-TI8mBcegE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/fcc06c58-a366-4996-9b57-6412d93c6483%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
INADA Naoki  <songofaca...@gmail.com>

-- 
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/CAEfz%2BTyReVRdQFdr_v%2BsS4BXrX1XCAJm2Wj30AO0Qk5fNBOSaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Tim Graham
We'd need mysqlclient to support Python 3.2 (or drop official support for 
MySQL/Python 3.2):

django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module: 
/var/lib/jenkins/workspace/django-selenium/database/mysql/python/python3.2/tests/.env/lib/python3.2/site-packages/_mysql.cpython-32mu.so:
 undefined symbol: PyUnicode_AsUTF8


Python 2.7 test failures:


custom_pk.tests.CustomPKTests.test_required_pk
fixtures.tests.FixtureLoadingTests.test_loaddata_error_message
generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params
get_or_create.tests.UpdateOrCreateTests.test_integrity
model_fields.tests.BooleanFieldTests.test_null_default


Python 3.4 test failures:


backends.tests.BackendTestCase.test_cursor_execute_with_pyformat
backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat
backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
custom_pk.tests.CustomPKTests.test_required_pk
fixtures.tests.FixtureLoadingTests.test_loaddata_error_message
generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params
get_or_create.tests.UpdateOrCreateTests.test_integrity
model_fields.tests.BooleanFieldTests.test_null_default
raw_query.tests.RawQueryTests.test_pyformat_params


Let me know if you need tracebacks, but I assume you'll need to run the 
tests  yourself in our to fix the issues.

On Monday, September 8, 2014 9:38:22 AM UTC-4, Collin Anderson wrote:
>
> It's great to see us moving forward on this. Thanks to Naoki for all of 
> the work on 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/fcc06c58-a366-4996-9b57-6412d93c6483%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Collin Anderson
It's great to see us moving forward on this. Thanks to Naoki for all of the 
work on 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/c14af6ba-8b93-49e9-bc49-64e8142f4be5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Tim Graham
I'll test mysqlclient-python on my staging CI server today.

On Monday, September 8, 2014 3:08:41 AM UTC-4, Claude Paroz wrote:
>
> Le lundi 8 septembre 2014 08:33:39 UTC+2, Naoki INADA a écrit :
>>
>>
>> On Monday, September 8, 2014 2:04:26 PM UTC+9, Naoki INADA wrote:
>>>
>>> > 
>>> > Naoki, 
>>> > 
>>> > Are you aware of performance benchmarks comparing your MySQLdb1 fork 
>>> and 
>>> > mysql-connector-python? 
>>>
>>
>> I've posted quick benchmark:
>> https://github.com/methane/mysql-driver-benchmarks
>>
>> Most heavy part of MySQL Driver is parsing packet.
>> There are (number of columsn) descripter packet and (number of columns * 
>> number of rows) result packet in query response.
>>
>> On PyPy, packet parsing is faster after JIT warmup.
>> MySQL-Connector/Python reads from socket packet by packed.  It makes many 
>> system call.
>> PyMySQL uses buffering for faster receiving.
>>
>
> Great, 8-9x difference in favor of the C implementation (which might be 
> expected). That's a clear sign for me that we should continue using 
> primarily the C version. That doesn't mean we shouldn't make efforts to 
> support at least one Python-only driver (as asked in #12500).
>
> > About your fork, do you plan to maintain it in the middle/long term? I 
>> saw 
>> > that issues were not enabled on your Github repo. Is it on purpose? 
>> What's 
>> > the plan about bug tracking of your fork? 
>> > 
>>
>> Thanks for pointing it out.  I've enabled github issue. 
>>
>> I'll maintain mysqlclient-python until MySQLdb1 development is restarted. 
>> Since I hope MySQLdb1 and mysqlclient-python merged someday (like 
>> setuptools and distribute were merged), 
>> I don't want to implement new feature. 
>> 'maintain' means bugfix, support new Python, new libmysqlclient and 
>> new OS, etc... 
>>
>
> That makes sense.
> Tim, Florian, would it be possible to switch to that fork on the CI server 
> (both for Python 2 and 3) for MySQL?
> Then of course, if all goes well, we would need to update our 
> documentation.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f617f1f-26db-4b9d-af85-b1b834bd6832%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Collin Anderson
Ohh wow. I also just noticed CyMySQL, which is a fork of PyMySQL with 
optional C speedups. It seems like a good idea in theory, though it appears 
to have diverged from PyMySQL a bit.

-- 
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/2bdbbcc8-488b-4e82-b8b4-3a99954a704a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Claude Paroz
Le lundi 8 septembre 2014 08:33:39 UTC+2, Naoki INADA a écrit :
>
>
> On Monday, September 8, 2014 2:04:26 PM UTC+9, Naoki INADA wrote:
>>
>> > 
>> > Naoki, 
>> > 
>> > Are you aware of performance benchmarks comparing your MySQLdb1 fork 
>> and 
>> > mysql-connector-python? 
>>
>
> I've posted quick benchmark:
> https://github.com/methane/mysql-driver-benchmarks
>
> Most heavy part of MySQL Driver is parsing packet.
> There are (number of columsn) descripter packet and (number of columns * 
> number of rows) result packet in query response.
>
> On PyPy, packet parsing is faster after JIT warmup.
> MySQL-Connector/Python reads from socket packet by packed.  It makes many 
> system call.
> PyMySQL uses buffering for faster receiving.
>

Great, 8-9x difference in favor of the C implementation (which might be 
expected). That's a clear sign for me that we should continue using 
primarily the C version. That doesn't mean we shouldn't make efforts to 
support at least one Python-only driver (as asked in #12500).

> About your fork, do you plan to maintain it in the middle/long term? I 
> saw 
> > that issues were not enabled on your Github repo. Is it on purpose? 
> What's 
> > the plan about bug tracking of your fork? 
> > 
>
> Thanks for pointing it out.  I've enabled github issue. 
>
> I'll maintain mysqlclient-python until MySQLdb1 development is restarted. 
> Since I hope MySQLdb1 and mysqlclient-python merged someday (like 
> setuptools and distribute were merged), 
> I don't want to implement new feature. 
> 'maintain' means bugfix, support new Python, new libmysqlclient and 
> new OS, etc... 
>

That makes sense.
Tim, Florian, would it be possible to switch to that fork on the CI server 
(both for Python 2 and 3) for MySQL?
Then of course, if all goes well, we would need to update our documentation.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7487c9c9-0b46-4e84-8203-7841ab0b0bba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-08 Thread Naoki INADA

On Monday, September 8, 2014 2:04:26 PM UTC+9, Naoki INADA wrote:
>
> > 
> > Naoki, 
> > 
> > Are you aware of performance benchmarks comparing your MySQLdb1 fork and 
> > mysql-connector-python? 
>
> I'll show you some numbers.  But I'm not have time for now. 
>

I've posted quick benchmark:
https://github.com/methane/mysql-driver-benchmarks

Most heavy part of MySQL Driver is parsing packet.
There are (number of columsn) descripter packet and (number of columns * 
number of rows) result packet in query response.

On PyPy, packet parsing is faster after JIT warmup.
MySQL-Connector/Python reads from socket packet by packed.  It makes many 
system call.
PyMySQL uses buffering for faster receiving.

-- 
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/86510ef0-f470-47c6-a137-44caf6e87373%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-07 Thread INADA Naoki
>
> Naoki,
>
> Are you aware of performance benchmarks comparing your MySQLdb1 fork and
> mysql-connector-python?

I'll show you some numbers.  But I'm not have time for now.

>
> About your fork, do you plan to maintain it in the middle/long term? I saw
> that issues were not enabled on your Github repo. Is it on purpose? What's
> the plan about bug tracking of your fork?
>

Thanks for pointing it out.  I've enabled github issue.

I'll maintain mysqlclient-python until MySQLdb1 development is restarted.
Since I hope MySQLdb1 and mysqlclient-python merged someday (like
setuptools and distribute were merged),
I don't want to implement new feature.
'maintain' means bugfix, support new Python, new libmysqlclient and
new OS, etc...

-- 
INADA Naoki  

-- 
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/CAEfz%2BTz1DiprvtgeB-ByRcEHZRsLwZF_vOZqoGN-QPY42DMTbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-07 Thread Collin Anderson
I'm warming up to mysqlclient. I assume it has better performance or is 
more correct than pymysql? Is there any hope to getting the package 
included in debian/ubuntu?

-- 
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/18d3bdd9-6fae-4df9-98dc-0377d894fff7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-07 Thread Corey Farwell
Claude, it looks like Naoki opened up Issues on the repository.

Coincidentally, I just opened a Django Ticket related to this: 
https://code.djangoproject.com/ticket/23446 I had not seen this thread 
until Tim Graham pointed it out. See that ticket for my views on the 
matter. tldr: recommending mysqldb1 is a documentation bug as it is a 
broken library.


On Sunday, September 7, 2014 3:43:19 PM UTC-4, Claude Paroz wrote:
>
> On Thursday, August 14, 2014 3:01:07 PM UTC+2, Naoki INADA wrote:
>>
>>
>> MySQL-Connector/Python was not so popular (as far as I know).
>> But 1.2.2 GA was released recently.  It looks nice to me. It may be 
>> popular if Django recommend it.
>> It's repository was moved from launchpad to github. 
>> https://github.com/oracle/mysql-connector-python 
>> 
>>
>> Although it looks nice to me, there are 2 drawbacks.
>>
>> * They don't put package to PyPI. `--allow-external 
>> mysql-connector-python` option is required for `pip install`.
>> * Although repository was moved to Github, bug database is still bit 
>> unfriendly (http://bugs.mysql.com/ ).
>>
>>
>> I think if Oracle will be more familiar with OSS community (accepting 
>> pull requests, using Travis-CI, etc...),
>> It can replace PyMySQL. Because it's development is more active than us.
>>
>
> Naoki,
>
> Are you aware of performance benchmarks comparing your MySQLdb1 fork and 
> mysql-connector-python?
>
> About your fork, do you plan to maintain it in the middle/long term? I saw 
> that issues were not enabled on your Github repo. Is it on purpose? What's 
> the plan about bug tracking of your fork?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4cd9eea7-5f9c-4a57-840f-eb30d581e470%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-09-07 Thread Claude Paroz
On Thursday, August 14, 2014 3:01:07 PM UTC+2, Naoki INADA wrote:
>
>
> MySQL-Connector/Python was not so popular (as far as I know).
> But 1.2.2 GA was released recently.  It looks nice to me. It may be 
> popular if Django recommend it.
> It's repository was moved from launchpad to github. 
> https://github.com/oracle/mysql-connector-python 
> 
>
> Although it looks nice to me, there are 2 drawbacks.
>
> * They don't put package to PyPI. `--allow-external 
> mysql-connector-python` option is required for `pip install`.
> * Although repository was moved to Github, bug database is still bit 
> unfriendly (http://bugs.mysql.com/ ).
>
>
> I think if Oracle will be more familiar with OSS community (accepting pull 
> requests, using Travis-CI, etc...),
> It can replace PyMySQL. Because it's development is more active than us.
>

Naoki,

Are you aware of performance benchmarks comparing your MySQLdb1 fork and 
mysql-connector-python?

About your fork, do you plan to maintain it in the middle/long term? I saw 
that issues were not enabled on your Github repo. Is it on purpose? What's 
the plan about bug tracking of your fork?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ca6afdc5-a5f2-43e4-a0e8-c7755e916276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-08-14 Thread Naoki INADA

On Wednesday, August 13, 2014 1:41:22 AM UTC+9, Tim Graham wrote:
>
> I'd like see some community consensus on the best solution for a MySQL 
> adapter rather than than have more than one build for MySQL.
>
> I don't know the MySQL ecosystem very well. Naoki, is there no interest 
> from MySQLdb in your Python 3 compatibility changes? On the PyPI page it 
> says, 
> "Python-3.0 will be supported in a future release." but it's been like that 
> for several years so who knows if it's actually going to happen.
>

I've sent pull request to MySQLdb that support Python 3. 
(https://github.com/farcepest/MySQLdb1/pull/62 )
But project owner (Andy) doesn't have time to review PRs for now.

MySQLdb is the most popular MySQL driver for long years. But it's Andy's 
personal project and development speed is
slowed down for these years. (https://github.com/farcepest )

I hope Andy make MySQLdb as community based project.
But I have not proposed it to him, because I'm afraid my poor English say 
something rude.

So I've released my fork (including windows wheel) as mysqlclient.
I'll maintain it until Andy will be back active.


PyMySQL is also popular MySQL driver because it's pure Python and works 
well with gevent.
PyMySQL was also inactive for few years. But it switched to new maintainer 
(Marcel).
https://groups.google.com/forum/#!topic/pymysql-users/hrIYyeGMQwY

After switching, I'm also active committer of PyMySQL.
We've released PyMySQL 0.6 as stable release supporting Python 3.


MySQL-Connector/Python was not so popular (as far as I know).
But 1.2.2 GA was released recently.  It looks nice to me. It may be popular 
if Django recommend it.
It's repository was moved from launchpad to 
github. https://github.com/oracle/mysql-connector-python

Although it looks nice to me, there are 2 drawbacks.

* They don't put package to PyPI. `--allow-external mysql-connector-python` 
option is required for `pip install`.
* Although repository was moved to Github, bug database is still bit 
unfriendly (http://bugs.mysql.com/ ).


I think if Oracle will be more familiar with OSS community (accepting pull 
requests, using Travis-CI, etc...),
It can replace PyMySQL. Because it's development is more active than us.
 

>
> I think we could at least consider a change from the (somewhat random?) 
> Python 3 fork of MySQLdb we are using for the Python 3 bulids.
>
> On Friday, June 6, 2014 12:44:12 PM UTC-4, Collin Anderson wrote:
>>
>> While we're on the topic, I'd like to propose (also?) supporting the 
>> pure-python, MySQLdb-compatible pymysql, which INADA Naoki (methane) has 
>> also put a lot of work into. 
>>
>> pymysql is pure-python, so it's really easy to get up-and running on Mac 
>> OS X and in other environments, because you don't need the mysql header 
>> files around. Just pip install pymysql, and you're good to go.
>>
>> https://code.djangoproject.com/ticket/22391
>>
>> Tim says on the ticket: "One question I have is how we are going to 
>> ensure that it doesn't break if we merge it to core. Do we need another 
>> MySQL build to the Jenkins matrix?"
>>
>>

-- 
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/aa5e3c01-9aab-449c-b1c8-defde73065dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-08-12 Thread Tim Graham
I'd like see some community consensus on the best solution for a MySQL 
adapter rather than than have more than one build for MySQL.

I don't know the MySQL ecosystem very well. Naoki, is there no interest 
from MySQLdb in your Python 3 compatibility changes? On the PyPI page it says, 
"Python-3.0 will be supported in a future release." but it's been like that 
for several years so who knows if it's actually going to happen.

I think we could at least consider a change from the (somewhat random?) 
Python 3 fork of MySQLdb we are using for the Python 3 bulids.

On Friday, June 6, 2014 12:44:12 PM UTC-4, Collin Anderson wrote:
>
> While we're on the topic, I'd like to propose (also?) supporting the 
> pure-python, MySQLdb-compatible pymysql, which INADA Naoki (methane) has 
> also put a lot of work into. 
>
> pymysql is pure-python, so it's really easy to get up-and running on Mac 
> OS X and in other environments, because you don't need the mysql header 
> files around. Just pip install pymysql, and you're good to go.
>
> https://code.djangoproject.com/ticket/22391
>
> Tim says on the ticket: "One question I have is how we are going to ensure 
> that it doesn't break if we merge it to core. Do we need another MySQL 
> build to the Jenkins matrix?"
>
>

-- 
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/52e8bf42-28fa-4f3b-a654-74965d517852%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [RFC] Python 3 and MySQL

2014-06-06 Thread Collin Anderson
While we're on the topic, I'd like to propose (also?) supporting the 
pure-python, MySQLdb-compatible pymysql, which INADA Naoki (methane) has 
also put a lot of work into. 

pymysql is pure-python, so it's really easy to get up-and running on Mac OS 
X and in other environments, because you don't need the mysql header files 
around. Just pip install pymysql, and you're good to go.

https://code.djangoproject.com/ticket/22391

Tim says on the ticket: "One question I have is how we are going to ensure 
that it doesn't break if we merge it to core. Do we need another MySQL 
build to the Jenkins matrix?"

-- 
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/260d5b5e-47e3-4432-848f-b3fe58db1a7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[RFC] Python 3 and MySQL

2014-06-03 Thread Naoki INADA
Hi, folks.

I believe most popular MySQL driver for Python is MySQL-python (MySQLdb).
http://py3readiness.org/ shows MySQL-python is the 4th popular package that 
does not support Python 3.

I've forked MySQL-python because I want to move Python 3 completely ASAP.

https://pypi.python.org/pypi/mysqlclient
https://github.com/PyMySQL/mysqlclient-python


https://docs.djangoproject.com/en/dev/ref/databases/#mysql-db-api-drivers
references MySQL-for-Python3 as Python 3 port but it doesn't support binary 
and
it has not maintained for a long time.

So I propose replacing MySQL-for-Python3 with my fork.


MySQL-Connector/Python 1.2.2 (GA) has been released recently (not updated 
PyPI, but you
can download it from http://dev.mysql.com/downloads/connector/python/ ). It 
also support
Python 3 and Django.
One option for moving to Python 3 is recommend MySQL Connector/Python and 
doesn't
support MySQL-python nor mysqlclient.

https://code.djangoproject.com/ticket/12500
https://code.djangoproject.com/ticket/22732

But parsing MySQL packets with pure CPython is slow. Quick benchmark shows
MySQL Connector/Python is 5x slower than mysqlclient.

https://gist.github.com/methane/90ec97dda7fa9c7c4ef1

-- 
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/e4c85c41-1a4b-42e5-8673-39e19bbc6d79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Recommending a Python 3-compatible MySQL connector

2014-01-23 Thread Aymeric Augustin
2014/1/23 Daniel Sears 

> I know the core issue of GPL remains. But since this discussion began
> Oracle has extended their driver to include their own 
> Django
> back-end.
> Does this create enough separation to get us out of the GPL bind?


In the original discussion, I missed that MySQLdb is also released under
the GPL. See https://pypi.python.org/pypi/MySQL-python.

Considering the current state of the MySQL ecosystem, I'm +0 for switching
to Oracle's connector. I used to be -1.

You can use this email to ignore things I've said on this topic in the past.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mVDr_1On5eL%3DSwWw%3DN%2Bhniqzegbvcipb0mx8gdCRb5OWg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Recommending a Python 3-compatible MySQL connector

2014-01-23 Thread Russell Keith-Magee
On Thu, Jan 23, 2014 at 2:51 PM, Daniel Sears <daniel.se...@gmail.com>wrote:

> I want to follow up on the issue of a Python 3 connector for MySQL.
>
> Oracle has developed an open source Python driver for 
> MySQL<http://dev.mysql.com/doc/connector-python/en/index.html>
> :
>
>
>- PEP 249-compliant
>    - pure Python
>- supports Python 3
>- very simple installation:
>pip install mysql-connector
>- better support for asyncio than a C 
> driver<https://www.devbliss.com/en/reviving-the-snake/>
>- stable
>   - actively developed and supported by Oracle
>   - will likely track emerging MySQL features (in line with Oracle's
>   other drivers, e.g. Java, PHP, ...)
>
> I submitted a documentation 
> patch<https://docs.djangoproject.com/en/dev/ref/databases/#mysql-db-api-drivers>
>  for
> this a few months ago, but then I saw this closed 
> ticket<https://code.djangoproject.com/ticket/21226>.
> So I want to revisit this issue in the hopes of getting a clarifying
> policy. Without that I should probably back out the patch.
>
> I know the core issue of GPL remains. But since this discussion began
> Oracle has extended their driver to include their own 
> <http://dev.mysql.com/doc/refman/5.6/en/connector-python-django-backend.html>Django
> back-end<http://dev.mysql.com/doc/refman/5.6/en/connector-python-django-backend.html>.
> Does this create enough separation to get us out of the GPL bind?
>

The existence of a Django backend in MySQL Connector/Python doesn't change
anything. The code is still released under the GPL, and the GPL has been
specifically constructed to prevent people from "getting out of it".

The issue is that the GPL is at odds with the type of community that the
Django project has tried to foster. Django has been released under the
terms of the BSD license specifically because we want to allow commercial
activities without also requiring the release of source code.

If we recommended MySQL Connector/Python backend, anyone who chose to use
that backend would need to release that project under the terms of the GPL
- which means releasing source code.

This may be acceptable on a per project basis, and users are free to use
Connector/Python in their own projects if they want -- but I don't think
Django as a project should be encouraging this by documenting it as an
option.

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/CAJxq848Wo4p1aDrPigBtgzH%2BFTkdMua2VH9%2BqChdCpFtDjin_g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Recommending a Python 3-compatible MySQL connector

2014-01-23 Thread Daniel Sears
I want to follow up on the issue of a Python 3 connector for MySQL.

Oracle has developed an open source Python driver for 
MySQL<http://dev.mysql.com/doc/connector-python/en/index.html>
:


   - PEP 249-compliant
   - pure Python
   - supports Python 3
   - very simple installation:
   pip install mysql-connector 
   - better support for asyncio than a C 
driver<https://www.devbliss.com/en/reviving-the-snake/>
   - stable
  - actively developed and supported by Oracle
  - will likely track emerging MySQL features (in line with Oracle's 
  other drivers, e.g. Java, PHP, ...)
   
I submitted a documentation 
patch<https://docs.djangoproject.com/en/dev/ref/databases/#mysql-db-api-drivers>
 for 
this a few months ago, but then I saw this closed 
ticket<https://code.djangoproject.com/ticket/21226>. 
So I want to revisit this issue in the hopes of getting a clarifying 
policy. Without that I should probably back out the patch.

I know the core issue of GPL remains. But since this discussion began 
Oracle has extended their driver to include their own 
<http://dev.mysql.com/doc/refman/5.6/en/connector-python-django-backend.html>Django
 
back-end<http://dev.mysql.com/doc/refman/5.6/en/connector-python-django-backend.html>.
 
Does this create enough separation to get us out of the GPL bind?

--Dan

On Wednesday, June 5, 2013 9:11:11 AM UTC-7, Jacob Kaplan-Moss wrote:
>
> I've reached out to a lawyer friend to see if he can give us some 
> guidance. Until then, let's avoid making a recommendation either way. 
>
> Jacob 
>
> On Wed, Jun 5, 2013 at 10:01 AM, Aymeric Augustin 
> <aymeric@polytechnique.org > wrote: 
> > 2013/5/10 Aymeric Augustin <aymeric@polytechnique.org > 
>
> >> 
> >> > 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. 
> > 
> > 
> > I got an answer today. The license will not be changed. I was asked not 
> to 
> > publish our discussion. 
> > 
> > Specifically, MySQL Connector/Python is released under GNU GPLv2 with 
> FOSS 
> > exception. 
> > 
> > The FOSS exception only applies to redistributing MySQL 
> Connector/Python, 
> > which we don't intend to do anyway. 
> > 
> > 
> > To sum up, the scenario I'm worried about is the following. A company 
> > develops a product based on Django + MySQL and distributes it to its 
> > customers. Currently, the product can be distributed under any license. 
> If 
> > we switch to MySQL Connector/Python in Django, then the product must be 
> > licensed under the GPLv2 or a compatible license. Once again I'm not a 
> > lawyer and I may be wrong, I don't know where the line lies exactly, but 
> > that could create a legal trap for some users of Django. 
> > 
> > I don't want to add a warning along the lines of "be careful, if you use 
> > MySQL, the licensing terms change!" in our docs. I'm not even sure how 
> to 
> > write it without falling into FUD. 
> > 
> > So at this point I see two solutions: 
> > - a core dev (not me!) feels sufficiently confident that this isn't an 
> issue 
> > to add such a backend to Django itself. That's Oracle's theory, as far 
> as I 
> > understand. 
> > - someone writes an external MySQL Connector/Python backend, probably 
> based 
> > on the MyQSLdb backend. That keeps the licensing issue outside of 
> Django. 
> > 
> > I'm leaving this here, if someone wants to take over, the ground is 
> yours! 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > Visit this group at 
> http://groups.google.com/group/django-developers?hl=en. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d84939dd-3428-44d0-ac0a-74aaff8140ff%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Oracle users -- which first, Python 3 or Oracle 12?

2013-07-10 Thread Shai Berger
Hi Oracle users,

As you may be aware, Oracle 12 was released last month, and Django 1.6 
declares Python 3 fully supported. As you may also be aware, Django currently 
cannot be tested with Oracle 12 [1] or with earlier Oracle under Python 3 [2], 
so these two must be declared unsupported for the time being. I am working on 
both, but either will take some time for me to provide a reasonable solution.

So my question to the Django/Oracle community is -- which would you prefer to 
work first? My instinct (and input from people around me) is that Oracle12 is 
more important, but any input is welcome.

Also, of course, help wanted.

For Python3 the problem appears to be in cx_Oracle -- so to help, you should 
probably be a C programmer.

For Oracle12, for me, the main obstacle is a testing environment. While I'm 
working on that, any patches and/or help testing would be much appreciated.

Thanks,
Shai.

[1] https://code.djangoproject.com/ticket/20707
[2] https://code.djangoproject.com/ticket/20725

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




Re: Recommending a Python 3-compatible MySQL connector

2013-06-05 Thread Jacob Kaplan-Moss
I've reached out to a lawyer friend to see if he can give us some
guidance. Until then, let's avoid making a recommendation either way.

Jacob

On Wed, Jun 5, 2013 at 10:01 AM, Aymeric Augustin
 wrote:
> 2013/5/10 Aymeric Augustin 
>>
>> > 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.
>
>
> I got an answer today. The license will not be changed. I was asked not to
> publish our discussion.
>
> Specifically, MySQL Connector/Python is released under GNU GPLv2 with FOSS
> exception.
>
> The FOSS exception only applies to redistributing MySQL Connector/Python,
> which we don't intend to do anyway.
>
>
> To sum up, the scenario I'm worried about is the following. A company
> develops a product based on Django + MySQL and distributes it to its
> customers. Currently, the product can be distributed under any license. If
> we switch to MySQL Connector/Python in Django, then the product must be
> licensed under the GPLv2 or a compatible license. Once again I'm not a
> lawyer and I may be wrong, I don't know where the line lies exactly, but
> that could create a legal trap for some users of Django.
>
> I don't want to add a warning along the lines of "be careful, if you use
> MySQL, the licensing terms change!" in our docs. I'm not even sure how to
> write it without falling into FUD.
>
> So at this point I see two solutions:
> - a core dev (not me!) feels sufficiently confident that this isn't an issue
> to add such a backend to Django itself. That's Oracle's theory, as far as I
> understand.
> - someone writes an external MySQL Connector/Python backend, probably based
> on the MyQSLdb backend. That keeps the licensing issue outside of Django.
>
> I'm leaving this here, if someone wants to take over, the ground is yours!
>
> --
> 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.
>
>

-- 
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-06-05 Thread Aymeric Augustin
2013/5/10 Aymeric Augustin 

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


I got an answer today. The license will not be changed. I was asked not to
publish our discussion.

Specifically, MySQL Connector/Python is released under GNU GPLv2 with FOSS
exception.

The FOSS exception only applies to redistributing MySQL Connector/Python,
which we don't intend to do anyway.


To sum up, the scenario I'm worried about is the following. A company
develops a product based on Django + MySQL and distributes it to its
customers. Currently, the product can be distributed under any license. If
we switch to MySQL Connector/Python in Django, then the product must be
licensed under the GPLv2 or a compatible license. Once again I'm not a
lawyer and I may be wrong, I don't know where the line lies exactly, but
that could create a legal trap for some users of Django.

I don't want to add a warning along the lines of "be careful, if you use
MySQL, the licensing terms change!" in our docs. I'm not even sure how to
write it without falling into FUD.

So at this point I see two solutions:
- a core dev (not me!) feels sufficiently confident that this isn't an
issue to add such a backend to Django itself. That's Oracle's theory, as
far as I understand.
- someone writes an external MySQL Connector/Python backend, probably based
on the MyQSLdb backend. That keeps the licensing issue outside of Django.

I'm leaving this here, if someone wants to take over, the ground is yours!

-- 
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 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: 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
<aymeric.augus...@polytechnique.org> 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.




Re: Recommending a Python 3-compatible MySQL connector

2013-05-09 Thread Travis Jensen

Thanks, Aymeric. I grabbed the latest Django code and things worked like a 
charm.

Now, I have a decision to make: Stay on the Django/Python 3 bleeding edge 
or back off to Python 2.7.  My project's timeline says I won't release 
until after Django 1.6 (even with some slop for slipping releases), but it 
still feels dicey. On the other hand, on a brand new project, I'd prefer to 
be looking at Python's future rather than sticking in its past. :)

tj

On Wednesday, May 8, 2013 5:26:41 AM UTC-6, Aymeric Augustin wrote:
>
> On 7 mai 2013, at 08:34, Aymeric Augustin 
> <aymeric@polytechnique.org> 
> wrote:
>
> These problems look fairly easy. I plan to work on them.
>
>
> I just updated the pull request and everything works except BinaryField:
> https://code.djangoproject.com/ticket/20025#comment:5
>
> Something forces the output to be a string, either in the MySQL connector 
> or in the converters registered by Django.
>
> I would appreciate some help on this.
>
> Here's how to setup the MySQL connector with python 3.3:
>
> $ pyvenv-3.3 mysql-py33
> $ . mysql-py33/bin/activate
> $ curl http://python-distribute.org/distribute_setup.py | python
> $ git clone https://github.com/clelland/MySQL-for-Python-3
> $ cd MySQL-for-Python-3
> $ python setup.py install
>
> Then run model_fields tests.
>
> -- 
> 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-08 Thread Aymeric Augustin
On 7 mai 2013, at 08:34, Aymeric Augustin <aymeric.augus...@polytechnique.org> 
wrote:

> These problems look fairly easy. I plan to work on them.


I just updated the pull request and everything works except BinaryField:
https://code.djangoproject.com/ticket/20025#comment:5

Something forces the output to be a string, either in the MySQL connector or in 
the converters registered by Django.

I would appreciate some help on this.

Here's how to setup the MySQL connector with python 3.3:

$ pyvenv-3.3 mysql-py33
$ . mysql-py33/bin/activate
$ curl http://python-distribute.org/distribute_setup.py | python
$ git clone https://github.com/clelland/MySQL-for-Python-3
$ cd MySQL-for-Python-3
$ python setup.py install

Then run model_fields tests.

-- 
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-07 Thread Aymeric Augustin
On 6 mai 2013, at 23:38, Travis Jensen <travis.jen...@gmail.com> wrote:

> On Sunday, May 5, 2013 2:46:43 PM UTC-6, Aymeric Augustin wrote:
> On 5 mai 2013, at 21:15, Ian Clelland <clel...@gmail.com> wrote: 
> 
> > I don't object at all -- as long as the code it still passing tests, that 
> > is :) 
> 
> 
> So, given that the tests aren't passing, what does that mean?  I've played 
> around with removing that flag, but it just leads to "TypeError: 
> 'OperationalError' object does not support indexing".  I spent the day 
> playing with PyMySQL and MySQL-for-Python-3, and neither look like any work 
> is being done on them.

I've reached roughly the same point.

> Is Django, Python 3 and MySQL going to become non-supported? 


These problems look fairly easy. I plan to work on them.

The only question is whether they should be fixed in the MySQL connector or in 
Django.

-- 
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-06 Thread Travis Jensen

On Sunday, May 5, 2013 2:46:43 PM UTC-6, Aymeric Augustin wrote:
>
> On 5 mai 2013, at 21:15, Ian Clelland <clel...@gmail.com > 
> wrote: 
>
> > I don't object at all -- as long as the code it still passing tests, 
> that is :) 
>
>
So, given that the tests aren't passing, what does that mean?  I've played 
around with removing that flag, but it just leads to "TypeError: 
'OperationalError' object does not support indexing".  I spent the day 
playing with PyMySQL and MySQL-for-Python-3, and neither look like any work 
is being done on them.

Is Django, Python 3 and MySQL going to become non-supported? 

tj

-- 
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-05 Thread Aymeric Augustin
On 5 mai 2013, at 21:15, Ian Clelland <clell...@gmail.com> wrote:

> I don't object at all -- as long as the code it still passing tests, that is 
> :)

I just installed your version of MySQL-for-Python-3 on the CI server.

We'll have the results of the test runs in a few hours:
http://ci.djangoproject.com/job/Django/database=mysql,python=python3.2/
http://ci.djangoproject.com/job/Django/database=mysql,python=python3.3/
http://ci.djangoproject.com/job/Django/database=mysql_gis,python=python3.2/
http://ci.djangoproject.com/job/Django/database=mysql_gis,python=python3.3/
(There URLs return a 404 until the first build.)

-- 
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-05 Thread Ian Clelland
> So, unless someone has a better idea, or Ian objects, I'm going to link to
> his fork <https://github.com/clelland/MySQL-for-Python-3>.


I don't object at all -- as long as the code it still passing tests, that
is :) It was originally developed as a proof of concept when python 3
support was bring added for Django 1.5, and I haven't touched the code
since that was released.

I'll take a look and see if any work is going to be required to bring it in
line with 1.6.

Ian

>
> Trac ticket: https://code.djangoproject.com/ticket/20025
> Pull request: https://github.com/django/django/pull/1044
>
> Any objections?
>
> --
> Aymeric.
>
>

-- 
Regards,
Ian Clelland
<clell...@gmail.com>

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




Recommending a Python 3-compatible MySQL connector

2013-05-05 Thread Aymeric Augustin
Hello,

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.

Moist: https://github.com/farcepest/moist
- port by Andy, the maintainer of MySQLdb
- I don't think it works yet and development has stalled

PyMySQL: http://www.pymysql.org/
- pure-Python connector
- it doesn't appear to be widely used
- support for Python 3 looks a bit sketchy, eg. "run the build-py3k.sh 
script"
- it requires some modifications to the Django database backend, see 
https://github.com/clelland/django-mysql-pymysql
Related thread: 
https://groups.google.com/d/msg/django-developers/elQlGVnJ5b4/eoIZQ4kG-uIJ

MySQL-for-Python-3: https://github.com/davispuh/MySQL-for-Python-3 / 
https://github.com/clelland/MySQL-for-Python-3
- independent ports, there's a bit of fragmentation and no clear winner 
but at least they build upon MySQLdb's proven codebase.

So, unless someone has a better idea, or Ian objects, I'm going to link to his 
fork <https://github.com/clelland/MySQL-for-Python-3>.

Trac ticket: https://code.djangoproject.com/ticket/20025
Pull request: https://github.com/django/django/pull/1044

Any objections?

-- 
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: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Luke Plant
On 06/09/12 19:09, Aymeric Augustin wrote:

> Now we have two alternatives:
> 1) tell them to roll their own compat or wait until they can target 1.5
> + 1.6 — quite a downer,
> 2) add some forwards compatibility tools to 1.4.
> 
> We generally don't add features to minor releases, but there's a
> precedent (csrf_noop), and the patch is as harmless as they come (see
> attachment).
> 
> What do you think?

This was something I was going to bring up myself, since it is a major
obstacle to re-usable django apps actually providing Python 3
compatibility. I'm +1 on adding forwards compatibility to 1.4.X,
assuming a safe patch.

Luke

-- 
"In your presence there is fullness of joy; at your right hand are
pleasures forevermore" Psalm 16:11

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

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



Re: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Andrew Godwin
I'm definitely +1 on this - I have a few codebases I want to start
converting but also want to keep running on 1.4, and the patch looks
sensible to me. There is precedent for this, and even if there wasn't, this
is a nice way to get the migration cycle started.

Andrew

On Thu, Sep 6, 2012 at 3:05 PM, Donald Stufft <donald.stu...@gmail.com>wrote:

>  Just as an additional aside, the apps can also depend on the actual six
> library itself instead of Django's embedded version (It could be an
> optional dependency on Django < 1.5). The major things I think would be
> anything Django specific that don't come from six.
>
> On Thursday, September 6, 2012 at 2:09 PM, Aymeric Augustin wrote:
>
> Hello,
>
> Several people have started porting their apps for Python 3, but they're
> running into trouble when they try to support both Django 1.4 and
> master. They end up with regrettable patterns such as:
>
> try:
> from django.utils.six import PY3
> except ImportError:
> PY3 = False
>
> Authors of pluggable apps generally chose to support the current and the
> previous version of Django. Thus their users can alternatively upgrade
> Django and their apps, which makes upgrades less scary.
>
> Now we have two alternatives:
> 1) tell them to roll their own compat or wait until they can target 1.5 +
> 1.6 — quite a downer,
> 2) add some forwards compatibility tools to 1.4.
>
> We generally don't add features to minor releases, but there's a precedent
> (csrf_noop), and the patch is as harmless as they come (see attachment).
>
> What do you think?
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
> Attachments:
>  - python3-forwards-compat-for-django-14.diff
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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



Re: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Donald Stufft
Just as an additional aside, the apps can also depend on the actual six library 
itself instead of Django's embedded version (It could be an optional dependency 
on Django < 1.5). The major things I think would be anything Django specific 
that don't come from six.


On Thursday, September 6, 2012 at 2:09 PM, Aymeric Augustin wrote:

> Hello,
>  
> Several people have started porting their apps for Python 3, but they're 
> running into trouble when they try to support both Django 1.4 and master. 
> They end up with regrettable patterns such as:  
>  
> try:
> from django.utils.six import PY3
> except ImportError:
> PY3 = False
>  
> Authors of pluggable apps generally chose to support the current and the 
> previous version of Django. Thus their users can alternatively upgrade Django 
> and their apps, which makes upgrades less scary.  
>  
> Now we have two alternatives:
> 1) tell them to roll their own compat or wait until they can target 1.5 + 1.6 
> — quite a downer,
> 2) add some forwards compatibility tools to 1.4.
>  
> We generally don't add features to minor releases, but there's a precedent 
> (csrf_noop), and the patch is as harmless as they come (see attachment).
>  
> What do you think?  
>  
> --  
> Aymeric.
> --  
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>  
> Attachments:  
> - python3-forwards-compat-for-django-14.diff
>  


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



Re: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Mark Lavin
Hi,

I am one such author and I wanted to share my experience. I have ported my 
code and test suites for 3 applications to run on Django 1.3-1.5dev and 
Python 2.6, 2.7 and 3.2 (1.5dev only).
Those are https://github.com/mlavin/django-responsive, 
https://github.com/mlavin/django-ad-code and 
https://github.com/mlavin/django-scribbler. There are fairly new apps and 
don't
have many users/active deployments and so made good candidates for this 
work.

For the most part these were fairly easy to port. Adding unicode_literals 
everywhere was most of the work. There were a few places where I needed to 
make use of django.utils.six.
The largest pain point was trying to follow the recommendation for models 
__str__/__unicode__ in 
https://docs.djangoproject.com/en/dev/topics/python3/#str-and-unicode-methods
If you are trying to support Django 1.4 then you can't really use this 
recommendation without backporting the decorator because of the way it was 
written to be no-op for
Python 3 rather than Python 2. I understand why this decision was made and 
in the long run it is the right decision. For now I think app maintainers 
will have a bit of pain without
some of these features being backported to a 1.4.X release. You do have the 
option of using the hack you referenced (which I am doing) or a similar 
conditional import 
along with conditional __str__/__unicode__ which this decorator was meant 
to avoid. It's certainly not hard to do but it feels dirty.

My work now has been focused on getting the tests to pass and now they do. 
Another piece will be to actually deploy a project using one of these app.
I'll be continuing to do this work while at DjangoCon and I'll happily 
chime in any other stumbling blocks I run into while I port some other 
larger applications.

Best,

Mark

On Thursday, September 6, 2012 2:10:18 PM UTC-4, Aymeric Augustin wrote:
>
> Hello,
>
> Several people have started porting their apps for Python 3, but they're 
> running into trouble when they try to support both Django 1.4 and 
> master. They end up with regrettable patterns such as:
>
> try:
> from django.utils.six import PY3
> except ImportError:
> PY3 = False
>
> Authors of pluggable apps generally chose to support the current and the 
> previous version of Django. Thus their users can alternatively upgrade 
> Django and their apps, which makes upgrades less scary.
>
> Now we have two alternatives:
> 1) tell them to roll their own compat or wait until they can target 1.5 + 
> 1.6 — quite a downer,
> 2) add some forwards compatibility tools to 1.4.
>  
> We generally don't add features to minor releases, but there's a precedent 
> (csrf_noop), and the patch is as harmless as they come (see attachment).
>
> What do you think?
>  
> -- 
> Aymeric.
>  

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



Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Aymeric Augustin
Hello,

Several people have started porting their apps for Python 3, but they're
running into trouble when they try to support both Django 1.4 and
master. They end up with regrettable patterns such as:

try:
from django.utils.six import PY3
except ImportError:
PY3 = False

Authors of pluggable apps generally chose to support the current and the
previous version of Django. Thus their users can alternatively upgrade
Django and their apps, which makes upgrades less scary.

Now we have two alternatives:
1) tell them to roll their own compat or wait until they can target 1.5 +
1.6 — quite a downer,
2) add some forwards compatibility tools to 1.4.

We generally don't add features to minor releases, but there's a precedent
(csrf_noop), and the patch is as harmless as they come (see attachment).

What do you think?

-- 
Aymeric.

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



python3-forwards-compat-for-django-14.diff
Description: Binary data


Re: Python 3: should we apply unicode_literals everywhere?

2012-08-30 Thread Felipe Prenholato
Here at PDG (Brazil) we are migrating our software to Djang 1.4 and already
using unicode_literals. I can count in my fingers places that I needed to
use 'b' for byte code string (most on settings.py).

In my experience, maintain byte code strings isn't that hard and we should
than go to option 2.

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2012/8/24 Vinay Sajip 

> I would also prefer Option 2, as the places where str('...') are needed
> are not all that many.
>
> Regards,
>
> Vinay Sajip
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/WLtnInRyKyAJ.
>
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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



Re: Python 3 str.format()

2012-08-24 Thread claudep

Le vendredi 24 août 2012 19:11:49 UTC+2, Ian a écrit :

> Until the Python developers announce an actual timeline for removal 
> (if they ever do), I can't see any reason for Django to be concerned 
> about which formatting approach to use, apart from the immediate 
> concerns of style and efficiency. 
>

One more reason not to adopt too quickly this syntax is missing support 
from gettext.

http://savannah.gnu.org/bugs/?30854

Claude

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



Re: Python 3 str.format()

2012-08-24 Thread Alex Ogier
> Until the Python developers announce an actual timeline for removal
> (if they ever do), I can't see any reason for Django to be concerned
> about which formatting approach to use, apart from the immediate
> concerns of style and efficiency.

I don't think Python will ever remove %-style formatting, even in a
hypothetical "Python 4," because there are a lot of APIs (including
Django's) that expose it. Guido mentions the logging package, but
there are also a lot of third party packages that take %-style
template strings as arguments to formatting functions. As a result,
the %-style syntax will have to stick around until most of these
packages convert over, and if the latest Python 3 documentation has
even stopped recommending str.format() as a better alternative then I
expect it to stick around for good.

Best,
Alex

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



Re: Python 3 str.format()

2012-08-24 Thread Ian Kelly
On Fri, Aug 24, 2012 at 10:30 AM, Daniel Swarbrick
<daniel.swarbr...@gmail.com> wrote:
> On 24 August 2012 18:12, Carl Meyer <c...@oddbird.net> wrote:
>> Can you link to where in the current docs it specifies that %-formatting
>> is deprecated and/or will be removed? I can't even find, on a cursory
>> search, where it says the new .format() style should be preferred.
>
> It's not easy to find - I've only found the mention of the impending
> deprecation in the Python 3.0 "What's New" docs -
> http://docs.python.org/release/3.0/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting
>
> However, I can't find followup references to that in the Python 3.1
> docs. Maybe the decision was rescinded? Personally I didn't really see
> anything majorly wrong with the %-style formatting. Being a C
> developer myself, it was nice to have some common ground and not have
> to go hunting for format string specifications.
>
> This section http://docs.python.org/library/stdtypes.html#str.format
> states "This method of string formatting is the new standard in Python
> 3, and should be preferred to the % formatting described in String
> Formatting Operations in new code."
>
> I just thought that if the %-style formatting is indeed earmarked for
> removal, maybe we should start using the new format sooner rather than
> later.

This post by Guido is informative on the subject, even though it's
nearly three years old now:

http://mail.python.org/pipermail/python-dev/2009-September/092399.html

The 3.2 docs specifically say, "As the new String Formatting syntax is
more flexible and handles tuples and dictionaries naturally, it is
recommended for new code. However, there are no current plans to
deprecate printf-style formatting."  The 3.3 docs no longer have this
quote, but they also indicate nothing about planned deprecation or
removal.

Until the Python developers announce an actual timeline for removal
(if they ever do), I can't see any reason for Django to be concerned
about which formatting approach to use, apart from the immediate
concerns of style and efficiency.

Cheers,
Ian

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



Re: Python 3 str.format()

2012-08-24 Thread Daniel Swarbrick
On 24 August 2012 18:12, Carl Meyer <c...@oddbird.net> wrote:
> Can you link to where in the current docs it specifies that %-formatting
> is deprecated and/or will be removed? I can't even find, on a cursory
> search, where it says the new .format() style should be preferred.

It's not easy to find - I've only found the mention of the impending
deprecation in the Python 3.0 "What's New" docs -
http://docs.python.org/release/3.0/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting

However, I can't find followup references to that in the Python 3.1
docs. Maybe the decision was rescinded? Personally I didn't really see
anything majorly wrong with the %-style formatting. Being a C
developer myself, it was nice to have some common ground and not have
to go hunting for format string specifications.

This section http://docs.python.org/library/stdtypes.html#str.format
states "This method of string formatting is the new standard in Python
3, and should be preferred to the % formatting described in String
Formatting Operations in new code."

I just thought that if the %-style formatting is indeed earmarked for
removal, maybe we should start using the new format sooner rather than
later.

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



Python 3 str.format()

2012-08-24 Thread Daniel Swarbrick
Hi folks,

Apologies in advance if this topic has already been raised. I don't believe 
I've seen it on the list since I've been subscribed.

Since Django 1.5 has set the minimum version of Python at 2.6, and in 
conjunction with the push to make Django more Python 3 compatible, should 
we slowly start migrating to the new format string [1] syntax? The Python 
docs state that it is the new standard in Python 3, and should be preferred 
to the old %-style formatting. The %-style was supposed to be deprecated in 
Python 3.1. Whilst I'm a little vague on whether it's been officially 
deprecated yet, it is slated to be removed from Python altogether at some 
point.

The new str.format() method is supported by Python 2.6 onwards.

1: http://docs.python.org/library/string.html#format-string-syntax

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



Re: Python 3: should we apply unicode_literals everywhere?

2012-08-24 Thread Vinay Sajip
I would also prefer Option 2, as the places where str('...') are needed are 
not all that many.

Regards,

Vinay Sajip

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



Re: Python 3: should we apply unicode_literals everywhere?

2012-08-22 Thread Aymeric Augustin
> 2012/8/22 VernonCole <vernondc...@gmail.com>:
>
> On Tuesday, August 21, 2012 4:03:57 PM UTC-6, DrMeers wrote:
>>
>> It's a shame we couldn't skip straight to Python 3.3 and take
>> advantage of PEP414...
>
> That seems to me (in my dark status as a lurker here) to be a brilliant
> idea.


Well, this point is moot as far as Django is concerned: we already
went through the effort of removing the `u` prefixes!

However I'd like to explain why this PEP is at odds with the porting
philosophy I've applied to Django, and why I would have vetoed taking
advantage of it.

I believe that aiming for a Python 2 codebase with Python 3
compatibility hacks is a counter-productive way to port a project. You
end up with all the drawbacks of Python 2 (including the legacy `u`
prefixes) and none of the advantages Python 3 (especially the sane
string handling).

Working to write Python 3 code, with legacy compatibility for Python
2, is much more rewarding. Of course it takes more effort, but the
results are much cleaner and much more maintainable. It's really about
looking towards the future or towards the past.

I understand the reasons why PEP 414 was proposed and why it was
accepted. It makes sense for legacy software that is minimally
maintained. I hope nobody puts Django in this category!

-- 
Aymeric.

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



Re: Python 3: should we apply unicode_literals everywhere?

2012-08-22 Thread Mikhail Korobov
Python 3.2 is a default python in Ububtu 12.04 LTS so I think Python 3.2 
support is pretty important. 

And what are the gains of having "u" prefixes all over the codebase? This 
makes the codebase less Python3-like. With PEP414-based code there must be 
explicit "b" and explicit "u" prefixes all over the code; the sweet 
unprefixed variant will be reserved for "naive strings" which are rarely 
useful. With unicode_literals explicit "b" prefix is needed if byte strings 
and explicit "str(foo)" call is needed for "native strings"; unicode 
strings are implicit and default in both Python 2.x code and Python 3.x 
code. This is more porting work but I think it is more rewarding because it 
leads to a cleaner code.

среда, 22 августа 2012 г., 21:06:37 UTC+6 пользователь VernonCole написал:
>
> That seems to me (in my dark status as a lurker here) to be a brilliant 
> idea. 
> It is already established practice to say something like: "version 1.n of 
> django requires 2.m or later of Python".
> The practice then would change to: "version 1.n of django requires 2.m of 
> Python or 3.3 or later".
> I see from reading the text of PEP414 that there is an import hook 
> available to make this feature also work in Python 3.2.
> Would there be any advantage to requiring support for older versions of 
> Python 3?  I can't think of any.
> Python 3.3 will be an established thing long before a django version using 
> it gains production status. We developers can use hooks and beta versions.
> --
> Vernon Cole
>
> On Tuesday, August 21, 2012 4:03:57 PM UTC-6, DrMeers wrote:
>>
>> It's a shame we couldn't skip straight to Python 3.3 and take 
>> advantage of PEP414... 
>>
>> On 22 August 2012 07:32, Adrian Holovaty <adr...@holovaty.com> wrote: 
>> > On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin 
>> > <aymeric@polytechnique.org> wrote: 
>> >> In my opinion, option (2) is a logical move at this point. However I 
>> >> believe it deserves a public discussion (or at least an explanation). 
>> >> What do you think? 
>> > 
>> > I prefer option 2 as well, because it seems like the Right Thing To 
>> > Do. Of course, there's no rush to do everything -- we can just nibble 
>> > off bits here and there. 
>> > 
>> > I'll have some free time soon and would be happy to help out migrating 
>> > code. (Relatively) mindless refactoring like this is one of my 
>> > favorite things to do. :-) 
>> > 
>> > Adrian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "Django developers" group. 
>> > To post to this group, send email to django-d...@googlegroups.com. 
>> > To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com. 
>> > For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en. 
>> > 
>>
>

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



Re: Python 3: should we apply unicode_literals everywhere?

2012-08-22 Thread VernonCole
That seems to me (in my dark status as a lurker here) to be a brilliant 
idea. 
It is already established practice to say something like: "version 1.n of 
django requires 2.m or later of Python".
The practice then would change to: "version 1.n of django requires 2.m of 
Python or 3.3 or later".
I see from reading the text of PEP414 that there is an import hook 
available to make this feature also work in Python 3.2.
Would there be any advantage to requiring support for older versions of 
Python 3?  I can't think of any.
Python 3.3 will be an established thing long before a django version using 
it gains production status. We developers can use hooks and beta versions.
--
Vernon Cole

On Tuesday, August 21, 2012 4:03:57 PM UTC-6, DrMeers wrote:
>
> It's a shame we couldn't skip straight to Python 3.3 and take 
> advantage of PEP414... 
>
> On 22 August 2012 07:32, Adrian Holovaty <adr...@holovaty.com> 
> wrote: 
> > On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin 
> > <aymeric@polytechnique.org > wrote: 
> >> In my opinion, option (2) is a logical move at this point. However I 
> >> believe it deserves a public discussion (or at least an explanation). 
> >> What do you think? 
> > 
> > I prefer option 2 as well, because it seems like the Right Thing To 
> > Do. Of course, there's no rush to do everything -- we can just nibble 
> > off bits here and there. 
> > 
> > I'll have some free time soon and would be happy to help out migrating 
> > code. (Relatively) mindless refactoring like this is one of my 
> > favorite things to do. :-) 
> > 
> > Adrian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers" group. 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> django-develop...@googlegroups.com . 
> > For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en. 
> > 
>

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



Re: Python 3: should we apply unicode_literals everywhere?

2012-08-21 Thread Simon Meers
It's a shame we couldn't skip straight to Python 3.3 and take
advantage of PEP414...

On 22 August 2012 07:32, Adrian Holovaty  wrote:
> On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin
>  wrote:
>> In my opinion, option (2) is a logical move at this point. However I
>> believe it deserves a public discussion (or at least an explanation).
>> What do you think?
>
> I prefer option 2 as well, because it seems like the Right Thing To
> Do. Of course, there's no rush to do everything -- we can just nibble
> off bits here and there.
>
> I'll have some free time soon and would be happy to help out migrating
> code. (Relatively) mindless refactoring like this is one of my
> favorite things to do. :-)
>
> Adrian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>

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



Re: Python 3: should we apply unicode_literals everywhere?

2012-08-21 Thread Adrian Holovaty
On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin
 wrote:
> In my opinion, option (2) is a logical move at this point. However I
> believe it deserves a public discussion (or at least an explanation).
> What do you think?

I prefer option 2 as well, because it seems like the Right Thing To
Do. Of course, there's no rush to do everything -- we can just nibble
off bits here and there.

I'll have some free time soon and would be happy to help out migrating
code. (Relatively) mindless refactoring like this is one of my
favorite things to do. :-)

Adrian

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



Re: Python 3: should we apply unicode_literals everywhere?

2012-08-21 Thread Anssi Kääriäinen
On 21 elo, 13:46, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> The first steps of porting Django to Python 3 was to switch on
> unicode_literals, as explained here [1]. This change was discussed in
> ticket #18269 [2] and committed in changeset 4a103086d5 [3].
>
> This changeset added `from __future__ import unicode_literals` only
> where necessary, ie. in modules that contained explicit unicode
> literals. This choice absolutely makes sense. Switching
> unicode_literals on everywhere in Django would have resulted in tons
> of b"" prefixes and/or in an incredible number of changes. Both
> options were unrealistic.
>
> However, it has an unfortunate side effect. In master, some modules
> have unicode_literals and others don't. I find myself constantly
> checking which mode is in effect.
>
> So we have two options at this point.
>
> (1) The status quo
>
>     Pros:
>         - less work in the short term
>         - avoiding the cons of solution (2)
>
>     Cons:
>         - check-top-of-file syndrom
>         - different behavior in Python 2 and Python 3 in some modules
>         - different behavior between some modules and others (eg.
> moving code isn't safe)
>         - cognitive overhead
>
> (2) Progressively turn unicode_literals on throughout the codebase. If
> we do it in small steps, it becomes easier to ensure that the change
> from str literals to unicode literals doesn't result in regressions on
> Python 2. That's how we handled the entire Python 3 port and it worked
> well — several regressions were quickly caught and fixed.
>
>     Pros:
>         - consistent codebase, easier to maintain in the long term
>         - avoiding the cons of solution (1)
>
>     Cons:
>         - "native strings" have to be expressed as str("...") in
> modules that need them
>         - more changes, higher risk of regressions on Python 2
>
> In my opinion, option (2) is a logical move at this point. However I
> believe it deserves a public discussion (or at least an explanation).
> What do you think?
>
> Best regards,

I did some benchmark runs some time ago, and it seems the
unicode_literals caused a small performance regression in many
queryset related benchmarks. The only one I have available is this:
http://users.tkk.fi/~akaariai/djbench/queryannotate.html

I remembered doing the benchmarks when reading this post, and thought
to mention this. The regression is small and I don't have any ideas
how to solve them. It might be it is just a testing artefact. So, this
is in no way a complaint against unicode_literals, just something I
though to share.

BTW if there happens to be some unused hardware available I could
automate such benchmarks as above. The hardware needs to be dedicated,
and a virtual machine will not do. Benchmarking on shared/virtual
machine will lead to inaccurate results. However the performance of
the HW isn't important at all, actually an older machine might be
better for this purpose...

For the actual question: I vote we move every non-empty file to
unicode_literals. If we use smaller steps we can bisect breakages
easier.

 - Anssi

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



Python 3: should we apply unicode_literals everywhere?

2012-08-21 Thread Aymeric Augustin
Hello,

The first steps of porting Django to Python 3 was to switch on
unicode_literals, as explained here [1]. This change was discussed in
ticket #18269 [2] and committed in changeset 4a103086d5 [3].

This changeset added `from __future__ import unicode_literals` only
where necessary, ie. in modules that contained explicit unicode
literals. This choice absolutely makes sense. Switching
unicode_literals on everywhere in Django would have resulted in tons
of b"" prefixes and/or in an incredible number of changes. Both
options were unrealistic.

However, it has an unfortunate side effect. In master, some modules
have unicode_literals and others don't. I find myself constantly
checking which mode is in effect.

So we have two options at this point.

(1) The status quo

Pros:
- less work in the short term
- avoiding the cons of solution (2)

Cons:
- check-top-of-file syndrom
- different behavior in Python 2 and Python 3 in some modules
- different behavior between some modules and others (eg.
moving code isn't safe)
- cognitive overhead

(2) Progressively turn unicode_literals on throughout the codebase. If
we do it in small steps, it becomes easier to ensure that the change
from str literals to unicode literals doesn't result in regressions on
Python 2. That's how we handled the entire Python 3 port and it worked
well — several regressions were quickly caught and fixed.

Pros:
- consistent codebase, easier to maintain in the long term
- avoiding the cons of solution (1)

Cons:
- "native strings" have to be expressed as str("...") in
modules that need them
- more changes, higher risk of regressions on Python 2

In my opinion, option (2) is a logical move at this point. However I
believe it deserves a public discussion (or at least an explanation).
What do you think?

Best regards,

-- 
Aymeric.


[1] https://docs.djangoproject.com/en/dev/topics/python3/#unicode-literals
[2] https://code.djangoproject.com/ticket/18269
[3] 
https://github.com/django/django/commit/4a103086d5c67fa4fcc53c106c9fdf644c742dd8

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



Re: Python 3 - style question

2012-08-11 Thread Aymeric Augustin
On 11 août 2012, at 11:00, Aymeric Augustin wrote:
> Thanks for all your answers. A decorator will indeed be the cleanest solution.

Given the large number of existing __unicode__ methods (66 in django, 375 in 
the tests) I've written a custom 2to3 fixer to perform the transformation.

https://github.com/aaugustin/django/commits/py3-2to3

To try it, checkout the branch and run:
$ django2to3.py django tests
(assuming django/bin is on your path).
 
Do you think the Django distribution include include this fixer? It could be 
useful to developers porting pluggable apps, but I can't vouch for its quality 
— it's the first time I touch 2to3. Should I just put in extras/ with some 
basic instructions?

Best regards,

-- 
Aymeric.

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



Re: Python 3 - style question

2012-08-10 Thread Alex Gaynor
On Fri, Aug 10, 2012 at 3:45 PM, Simon Meers  wrote:

> > On 10 August 2012 18:56, Vinay Sajip  wrote:
> >> I think Option 2 is better, for the reasons you state.
>
> +1. And it's not too entangled to be easily stripped out if/when
> Python 2 support is removed.
>
> On 11 August 2012 06:10, Łukasz Rekucki  wrote:
> > How about wrapping those 3 lines of code into a class decorator
> > (preferably named more explicit then StrAndUnicode) ? That would be at
> > least a little DRY.
>
> +1. It won't mess with the inheritance hierarchy, and is explicit
> enough (depending on the name), whilst encapsulating the boilerplate
> elegantly. @python2_unicode_compatible?
>
> (Though, @-syntax class decorators are only available from 2.6+, but
> I'm guessing we won't be able to drop 2.5 support at the same time as
> picking up 3. I guess we could just tidy up when we do.)
>
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
Trunk is 2.6+, so we're fine on that score.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

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



Re: Python 3 - style question

2012-08-10 Thread Simon Meers
> On 10 August 2012 18:56, Vinay Sajip  wrote:
>> I think Option 2 is better, for the reasons you state.

+1. And it's not too entangled to be easily stripped out if/when
Python 2 support is removed.

On 11 August 2012 06:10, Łukasz Rekucki  wrote:
> How about wrapping those 3 lines of code into a class decorator
> (preferably named more explicit then StrAndUnicode) ? That would be at
> least a little DRY.

+1. It won't mess with the inheritance hierarchy, and is explicit
enough (depending on the name), whilst encapsulating the boilerplate
elegantly. @python2_unicode_compatible?

(Though, @-syntax class decorators are only available from 2.6+, but
I'm guessing we won't be able to drop 2.5 support at the same time as
picking up 3. I guess we could just tidy up when we do.)

Simon

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



Re: Python 3 - style question

2012-08-10 Thread Łukasz Rekucki
On 10 August 2012 18:56, Vinay Sajip  wrote:
> I think Option 2 is better, for the reasons you state.
>

How about wrapping those 3 lines of code into a class decorator
(preferably named more explicit then StrAndUnicode) ? That would be at
least a little DRY.

-- 
Łukasz Rekucki

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



Re: Python 3 - style question

2012-08-10 Thread claudep
Le vendredi 10 août 2012 05:28:42 UTC+2, Daniel Sokolowski a écrit :
>
> I prefer Proposal 2 out of the list, and regarding Russell's point I 
> believe that the tutorial ought to promote Python 3 and be written from 
> that perspective with Python 2 exceptions -  because exactly of Django's 
> importance in the Python landscape. 
>
> Thanks and good day. 
>

It may depend if we can provide a reliable Python 3 experience in Django 
1.5, with all supported DB backends. This is not yet defined. Until now, 
we've targeted "experimental" Python 3 support in 1.5, meaning that Python 
2 would still be the safest choice for greater stability. Then we would 
have a complete release to prove Python 3 reliability. Until then, the docs 
would still mainly target Python 2.

Claude

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



Re: Python 3 - style question

2012-08-09 Thread Daniel Sokolowski
I prefer Proposal 2 out of the list, and regarding Russell's point I 
believe that the tutorial ought to promote Python 3 and be written from 
that perspective with Python 2 exceptions -  because exactly of Django's 
importance in the Python landscape.


Thanks and good day.

On 09/08/2012 19:35, Russell Keith-Magee wrote:

On Fri, Aug 10, 2012 at 4:58 AM, charettes <charett...@gmail.com> wrote:

I think this will only be an issue for django application maintainers.

IMHO, projects target a specific version of python and won't have to provide
python 2-3 compatibility. Am I wrong?

Yes and no.

On the one hand -- yes. Jo(sephin)e Public is here to write some code,
and it's going to be for their own purposes, which means they've
already picked a Python version, and so making their code
cross-version isn't important.

However, on the other hand, if you're "doing it right™", *every* app
is a reusable app, and teaching best practices is important. Like it
or not, Django is a major part of the Python ecosystem, and a lot of
people look at us as an example of what best practices look like.

My suggestion would be to look at a fifth option. Lets remember that
this is a training exercise, and for many of our user base, this is
their first exposure to Python. If we overload complexity in the
basics, they're going to come to the conclusion that Python is nasty
and horrible.

So - let's write the initial tutorials targeting a specific version,
but provide hints/directions indicating that there is a bigger picture
to consider:

  a) There should also be an aside at the start of section 1 of the
tutorial quickly explaining the Python version landscape to those that
aren't familiar with it, and explaining how the tutorial will handle
this landscape.

  b) Write the docs as Py2, with "Py3 admonition" whenever there's a
difference between the two. I haven't done a full audit of the
tutorial, but there shouldn't be *too* many of these.

  c) Add a new tutorial section indicating how to write cross-version
Python. For that document, I agree that Aymeric's option 2 looks
attractive, because it's the version that is the easiest to clean up
when the time comes to deprecate Py2 (although I wouldn't complain if
we packaged a pre-canned version of the lambda function in
django.utils)

Over time, we could change the primacy of the docs from Py2 native
(with Py3 warnings) to Py3 native (with Py2 warnings), until we
finally deprecate Py2.

In the interest of keeping the tutorial clear, I *might* be convinced
to drop step (b) entirely. This would mean we still have a Py2
tutorial, but with a couple of clear pointers towards best practices
(one indicating that there is a bigger picture to consider, and one
showing how to paint that picture). However, that would leave native
Py3-only users high and dry, which isn't exactly ideal.

Yours,
Russ Magee %-)




--
Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
Office: 613-817-6833
Fax: 613-817-5340
Toll Free: 1-855-5DANOLS
Kingston, ON K7L 1H3, Canada


Notice of Confidentiality:
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review re-transmission dissemination or other use of or taking of any action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you received this in error please contact the 
sender immediately by return electronic transmission and then immediately 
delete this transmission including all attachments without copying distributing 
or disclosing same.

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



Re: Python 3 - style question

2012-08-09 Thread Russell Keith-Magee
On Fri, Aug 10, 2012 at 4:58 AM, charettes  wrote:
> I think this will only be an issue for django application maintainers.
>
> IMHO, projects target a specific version of python and won't have to provide
> python 2-3 compatibility. Am I wrong?

Yes and no.

On the one hand -- yes. Jo(sephin)e Public is here to write some code,
and it's going to be for their own purposes, which means they've
already picked a Python version, and so making their code
cross-version isn't important.

However, on the other hand, if you're "doing it right™", *every* app
is a reusable app, and teaching best practices is important. Like it
or not, Django is a major part of the Python ecosystem, and a lot of
people look at us as an example of what best practices look like.

My suggestion would be to look at a fifth option. Lets remember that
this is a training exercise, and for many of our user base, this is
their first exposure to Python. If we overload complexity in the
basics, they're going to come to the conclusion that Python is nasty
and horrible.

So - let's write the initial tutorials targeting a specific version,
but provide hints/directions indicating that there is a bigger picture
to consider:

 a) There should also be an aside at the start of section 1 of the
tutorial quickly explaining the Python version landscape to those that
aren't familiar with it, and explaining how the tutorial will handle
this landscape.

 b) Write the docs as Py2, with "Py3 admonition" whenever there's a
difference between the two. I haven't done a full audit of the
tutorial, but there shouldn't be *too* many of these.

 c) Add a new tutorial section indicating how to write cross-version
Python. For that document, I agree that Aymeric's option 2 looks
attractive, because it's the version that is the easiest to clean up
when the time comes to deprecate Py2 (although I wouldn't complain if
we packaged a pre-canned version of the lambda function in
django.utils)

Over time, we could change the primacy of the docs from Py2 native
(with Py3 warnings) to Py3 native (with Py2 warnings), until we
finally deprecate Py2.

In the interest of keeping the tutorial clear, I *might* be convinced
to drop step (b) entirely. This would mean we still have a Py2
tutorial, but with a couple of clear pointers towards best practices
(one indicating that there is a bigger picture to consider, and one
showing how to paint that picture). However, that would leave native
Py3-only users high and dry, which isn't exactly ideal.

Yours,
Russ Magee %-)

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



Re: Python 3 - style question

2012-08-09 Thread charettes
I think this will only be an issue for django application maintainers.

IMHO, projects target a specific version of python and won't have to 
provide python 2-3 compatibility. Am I wrong?

Le jeudi 9 août 2012 16:36:12 UTC-4, Aymeric Augustin a écrit :
>
> Hello, 
>
> One of the first lessons in the tutorial is to define a __unicode__ 
> method. In Python 3, __unicode__ is replaced by __str__ (and __str__ by 
> __bytes__, but that method won't be needed in general). 
>
> Writing these methods in a way works on both Python 2 and 3 proves 
> surprisingly messy. I'd like some feedback before choosing a technique, 
> applying it to Django, and documenting it. 
>
> Here are a few proposals. Which one do you prefer? Do you have better 
> ideas? 
>
>
> * Proposal 1 — the very explicit way 
>   + explicit 
>   + no runtime overhead 
>   - not DRY 
>   - much boilerplate code 
>
> from __future__ import unicode_literals 
> from django.utils import six 
>
> class MyClass(object): 
> if six.PY3: 
> def __str__(self): 
> return "text ..." 
> else: 
> def __str__(self): 
> return self.__unicode__().encode('utf-8') 
> def __unicode__(self): 
> return "text ..." 
>
>
> * Proposal 2 — the Python 3 way 
>   + explicit 
>   + no runtime overhead 
>   - 3 lines of boilerplate code 
>
> from __future__ import unicode_literals 
> from django.utils import six 
>
> class MyClass(object): 
> def __str__(self): 
> return "text ..." 
> if not six.PY3: 
> __unicode__ = __str__ 
> __str__ = lambda self: self.__unicode__().encode('utf-8') 
>
>
> * Proposal 3 — the magic mixin 
>   + no boilerplate code 
>   - not explicit 
>   - requires writing a __unicode__ method which was removed in Python 3: 
> this is non-educational for Python 2 programmers learning Python 3 and 
> complete nonsense for Python 3 programmers who have never been exposed to 
> Python 2. 
>
> from __future__ import unicode_literals 
> from django.utils.encoding import StrAndUnicode 
>
> class MyClass(StrAndUnicode, object): 
> def __unicode__(self): 
> return "text ..." 
>
>
> * Proposal 4 — the non-unicode way 
>   - on Python 2, __unicode__ performs an unnecessary encode / decode 
>   - on Python 2, __unicode__ will fail if the system encoding isn't utf-8 
> (which may happen for a variety of reasons) 
>
> from __future__ import unicode_literals 
> from django.utils import six 
>
> class MyClass(object): 
> def __str__(self): 
> result = "text ..." 
> if six.PY3: 
> result = result.encode('utf-8') 
> return result 
>
>
> At this point I tend to prefer the version 2, because it's explicit, short 
> and in line with our goal to write Python 3 code that also works on Python 
> 2. What about you? 
>
> Best regards, 
>
> -- 
> Aymeric. 
>

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



Python 3 - style question

2012-08-09 Thread Aymeric Augustin
Hello,

One of the first lessons in the tutorial is to define a __unicode__ method. In 
Python 3, __unicode__ is replaced by __str__ (and __str__ by __bytes__, but 
that method won't be needed in general).

Writing these methods in a way works on both Python 2 and 3 proves surprisingly 
messy. I'd like some feedback before choosing a technique, applying it to 
Django, and documenting it.

Here are a few proposals. Which one do you prefer? Do you have better ideas?


* Proposal 1 — the very explicit way
  + explicit
  + no runtime overhead
  - not DRY
  - much boilerplate code

from __future__ import unicode_literals
from django.utils import six

class MyClass(object):
if six.PY3:
def __str__(self):
return "text ..."
else:
def __str__(self):
return self.__unicode__().encode('utf-8')
def __unicode__(self):
return "text ..."


* Proposal 2 — the Python 3 way
  + explicit
  + no runtime overhead
  - 3 lines of boilerplate code

from __future__ import unicode_literals
from django.utils import six

class MyClass(object):
def __str__(self):
return "text ..."
if not six.PY3:
__unicode__ = __str__
__str__ = lambda self: self.__unicode__().encode('utf-8')


* Proposal 3 — the magic mixin
  + no boilerplate code
  - not explicit
  - requires writing a __unicode__ method which was removed in Python 3: this 
is non-educational for Python 2 programmers learning Python 3 and complete 
nonsense for Python 3 programmers who have never been exposed to Python 2.

from __future__ import unicode_literals
from django.utils.encoding import StrAndUnicode

class MyClass(StrAndUnicode, object):
def __unicode__(self):
return "text ..."


* Proposal 4 — the non-unicode way
  - on Python 2, __unicode__ performs an unnecessary encode / decode
  - on Python 2, __unicode__ will fail if the system encoding isn't utf-8 
(which may happen for a variety of reasons)

from __future__ import unicode_literals
from django.utils import six

class MyClass(object):
def __str__(self):
result = "text ..."
if six.PY3:
result = result.encode('utf-8')
return result


At this point I tend to prefer the version 2, because it's explicit, short and 
in line with our goal to write Python 3 code that also works on Python 2. What 
about you?

Best regards,

-- 
Aymeric.

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



Re: Python 3 port status

2012-07-24 Thread Vinay Sajip
On Jul 24, 7:37 pm, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:

> Since Django's test suite isn't exhaustive, we focus on code review rather 
> than passing tests to validate the
> changes. That's why we're doing them step by step rather than in a huge 
> merge. We're coordinating this effort
> on the #django-dev IRC channel.

Sure. The test results are just one metric, which one might class as
"necessary but not sufficient". There are numerous places where things
IMO aren't done correctly in the main Django repo: for example, using
BytesIO in some places where StringIO should be used, and using b
prefixes a little too liberally (for example, if you use a b prefix
for a class name when constructing a type, it will fail on Python
3.x).

If you think it would be helpful for me to be available on #django-
dev, I can try to do that more often.

> Of course, I'm frequently looking at your branch to see how you've resolved 
> the various problems. It would be
> very useful to view the entire diff between your branch and master. 
> Unfortunately I couldn't figure out how to do
> this on GitHub. The "Files changed" tab 
> onhttps://github.com/vsajip/django/compare/django3shows a lot of
> differences in AUTHORS that I wouldn't expect to find there. Any idea?

I've not intentionally made any changes to AUTHORS. I started working
with Git the way one is supposed to, but I've found that for some
reason, every time I do a merge with master, the same conflicts keep
coming up again and again, even if they were resolved in previous
merges; this makes it hard for me to use Git to keep my branch
synchronised with changes in the upstream repo. I mentioned this to
Claude a while ago, but I haven't been able to find out why I have so
much trouble. (I've tried both fast-forward and no fast-forward
options when merging). Possibly something went wrong in one of my
merges, but AFAIK the AUTHORS file should be identical. I actually
keep 3 repos around: django-upstream, which I never touch but just
pull from the main Django repo, then my repo which I use to publish my
changes, and another Mercurial repo which I use for help with merging
due to the aforementioned problems with Git merging.

I just checked: if I run meld to compare django-upstream and my Django
repo, I see no changes in the top-level directory other than in
setup.py (which IIRC are changes Martin von Löwis made a long while
ago to patch sysconfig in 2.7 / 3.2).

I've found in the past that diff UIs are not completely reliable due
to how they parse line endings (by which I mean Windows/Mac/Linux).
Also, the diff is pretty big, so it may push the diff-determining code
into less well tested areas. So I use meld, which hasn't let me
down :-)

Regards,

Vinay Sajip

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



Re: Python 3 port status

2012-07-24 Thread Aymeric Augustin
On 24 juil. 2012, at 19:43, Vinay Sajip wrote:

> Since the update of Django to use Benjamin Peterson's six package for
> single code-base compatibility, I've updated my port [1] to do
> likewise.
> [1] https://github.com/vsajip/django

Hi Vinay,

Since Django's test suite isn't exhaustive, we focus on code review rather than 
passing tests to validate the changes. That's why we're doing them step by step 
rather than in a huge merge. We're coordinating this effort on the #django-dev 
IRC channel.

Of course, I'm frequently looking at your branch to see how you've resolved the 
various problems. It would be very useful to view the entire diff between your 
branch and master. Unfortunately I couldn't figure out how to do this on 
GitHub. The "Files changed" tab on 
https://github.com/vsajip/django/compare/django3 shows a lot of differences in 
AUTHORS that I wouldn't expect to find there. Any idea?

Thanks,

-- 
Aymeric.

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



Re: Python 3 port status

2012-07-24 Thread Vinay Sajip
Since the update of Django to use Benjamin Peterson's six package for
single code-base compatibility, I've updated my port [1] to do
likewise. All tests pass [2] with the SQLite backend on Ubuntu Linux
(64-bit). I added to the small section at the end of six.py [3] of
additional customisations for Django's use. Some of these additions
may be removable in due course if appropriate changes are made to
Django. The additions are IMO uncontroversial - mostly, they are to
support uniform access for APIs which return lists on 2.x and
iterators on 3.x.

BTW, many tests fail if six's default StringIO is used on 2.x (this is
StringIO.StringIO). However, cStringIO.StringIO works in those cases.
I've tackled this by using

from django.utils.six.moves import StringIO

wherever possible, but

from django.utils.six import StringIO

where necessary. The former resolves to StringIO.StringIO on 2.x,
while the latter resolves to cStringIO.StringIO. On 3.x, both resolve
to io.StringIO and there are no failures due to StringIO usage.

I'm currently unable to test with other backends, but will try to
resolve any port-related problems which are fed back to me via the
GitHub issue tracker on the repo [4]. Note that my changes are in the
django3 branch, and not the master branch.

Regards,

Vinay Sajip

[1] https://github.com/vsajip/django
[2] https://gist.github.com/1373553
[3] https://github.com/vsajip/django/blob/django3/django/utils/six.py#L356
[4] https://github.com/vsajip/django/issues/new

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



Python 3: new coding guidelines

2012-07-22 Thread Aymeric Augustin
Hello,

The core team decided to implement Python 3 support with a single codebase, 
unicode_literals, and six. (I don't think we ever announced it.)

I've just pushed a series of changes that make Django's code base more 
compatible with Python 3. They are the first steps of a long path. The syntax 
errors are fixed but nothing's working yet.

>From now on, and until we deprecate Python 2, we must write code that's 
>compatible with both Python 2 and Python 3. The requirements are explained 
>here:

https://docs.djangoproject.com/en/dev/topics/python3/

This applies to the core team, but also to anyone submitting patches.

Thanks!

-- 
Aymeric.

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



Re: Python 3 port - now available on GitHub

2012-05-28 Thread Vinay Sajip

> The izip_longest definition was removed from itercompat in revision
> b60b45a2a565 (which is fine, since it was only there for Python 2.5
> compatibility), but it means that the places that imported it need to
> be changed to import it directly from py3 instead.

Right, and I fixed that a couple of days ago. Anssi has kindly posted
feedback to the GitHub issue tracker on my repo, so I'm following up
there.

Regards,

Vinay Sajip

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



Re: Python 3 port - now available on GitHub

2012-05-28 Thread Vinay Sajip

On May 28, 8:24 pm, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:
> Is there any workaround for this? I need to install psycopg2 and cx-
> oracle under python 3 to run the tests, and virtualenv is the only way
> I know how to do this. However, this issue is causing a lot of noise
> in the results, making testing the py3-branch somewhat hard.

Just get a recent version of virtualenv.py and run that. For example,

https://raw.github.com/pypa/virtualenv/1.7.1.2/virtualenv.py

(I've not specifically tested this exact version, but IIRC I only had
the problem with my distro's version, which was a little out of date).

It's a self contained script, so just downloading it and running it
should allow you to create a working virtual environment.

Thanks for your input so far.

Regards,

Vinay Sajip

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



Re: Python 3 port - now available on GitHub

2012-05-28 Thread Ian Kelly
On Sat, May 26, 2012 at 4:31 AM, Vinay Sajip  wrote:
> Anssi,
>
> Thanks very much for the feedback.
>
>> Both Oracle and MySQL fail to run because of this error (on both 2.7
>> and 3.2):
>>   File "/home/akaariai/Programming/django/tests/django/db/backends/
>> mysql/compiler.py", line 2, in 
>>     from django.utils.itercompat import izip_longest
>> ImportError: cannot import name izip_longest
>
> I will investigate this.

The izip_longest definition was removed from itercompat in revision
b60b45a2a565 (which is fine, since it was only there for Python 2.5
compatibility), but it means that the places that imported it need to
be changed to import it directly from py3 instead.

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



Re: Python 3 port - now available on GitHub

2012-05-28 Thread Anssi Kääriäinen
On May 26, 1:31 pm, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> There are problems with some virtualenv versions, see this open
> virtualenv issue:
>
> https://github.com/pypa/virtualenv/issues/194
>
> The problem with importing tokenize.py in your traceback implies you
> might be running into this issue.

Is there any workaround for this? I need to install psycopg2 and cx-
oracle under python 3 to run the tests, and virtualenv is the only way
I know how to do this. However, this issue is causing a lot of noise
in the results, making testing the py3-branch somewhat hard.

 - Anssi

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



Re: Python 3 port - now available on GitHub

2012-05-27 Thread Kok Hoor Chew
Hi Vinay / anyone interested in the Python 3 port,

   I am a real newbie, so I seek forgiveness if what I did is stupid, but as I 
wanted to test out Vinay Sajip's django3 from git based on an existing project, 
I tried to install psycopg2 (Is this wise?)

I found following error when trying to browse to the admin site of my django 
app:

  File 
".../venv//lib/python3.2/site-packages/django/db/backends/postgresql_psycopg2/base.py",
 line 8, in 
from django.db import utils
ImportError: cannot import name utils

And therefore I changed line 8 of the aforementioned code to:

from django.db.utils import *

It then works. Is this ok?

The pip freeze of my virtual env shows:

Django==1.5.dev20120527102728
distribute==0.6.24
psycopg2==2.4.5
wsgiref==0.1.2

Thanks.

Regards,
Kok Hoor

On May 25, 2012, at 5:51 PM, Vinay Sajip wrote:

> The single codebase port of Django to Python 3 is now available on
> GitHub [1]. Recent core changes have been merged, and the test results
> are available at [2].
> 
> Summary:
> 
> 2.7.2: Ran 4734 tests in 540.793s - OK (skipped=112, expected
> failures=3)
> 3.2.2: Ran 4688 tests in 524.807s - OK (skipped=120, expected
> failures=2, unexpected successes=1)
> 
> Recent tests only cover the SQLite backend and were run on Linux. Help
> with testing other DB backends (and the GIS functionality) would be
> much appreciated!
> 
> Regards,
> 
> Vinay Sajip
> 
> [1] https://github.com/vsajip/django/tree/django3
> [2] https://gist.github.com/1373553
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

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



Re: Python 3 port - now available on GitHub

2012-05-26 Thread Vinay Sajip
Anssi,

Thanks very much for the feedback.

> Both Oracle and MySQL fail to run because of this error (on both 2.7
> and 3.2):
>   File "/home/akaariai/Programming/django/tests/django/db/backends/
> mysql/compiler.py", line 2, in 
>     from django.utils.itercompat import izip_longest
> ImportError: cannot import name izip_longest

I will investigate this.

> I get the following error when running the tests on any database on my
> setup (Ubuntu 12.04, Python 3.2):
> Traceback (most recent call last):
>   File "/home/akaariai/Programming/django/tests/regressiontests/
> test_runner/tests.py", line 197, in
> test_option_name_and_value_separated
>     self.assertNoOutput(err)
>   File "/home/akaariai/Programming/django/tests/regressiontests/
> admin_scripts/tests.py", line 164, in assertNoOutput
>     self.assertEqual(len(stream), 0, "Stream should be empty: actually
> contains '%s'" % stream)
> AssertionError: 335 != 0 : Stream should be empty: actually contains
> 'b'\'import warnings\' failed; traceback:\nTraceback (most recent call
> last):\n  File "/home/akaariai/Programming/python3/lib/python3.2/
> warnings.py", line 6, in \n    import linecache\n  File "/home/
> akaariai/Programming/python3/lib/python3.2/linecache.py", line 10, in
> \n    import tokenize\nImportError: No module named tokenize
> \n''
>
> I used this to install my setup:
> # sudo apt-get install python3 python3-dev virtualenv
> # virtualenv -p python3 --distribute python3
> # source python3/bin/activate
> # pip install psycopg2
> # run tests...
>
> Am I missing some dependency?

There are problems with some virtualenv versions, see this open
virtualenv issue:

https://github.com/pypa/virtualenv/issues/194

The problem with importing tokenize.py in your traceback implies you
might be running into this issue.

> PostgreSQL seems fine on 2.7 for the reduced test set ran
> (introspection transactions inspectdb fixtures queries extra_regress
> prefetch_related test_runner aggregation_regress). On 3.2 I get this
> additional error:
> Traceback (most recent call last):
>   File "/home/akaariai/Programming/django/tests/django/test/utils.py",
> line 203, in inner
>     return test_func(*args, **kwargs)
>   File "/home/akaariai/Programming/django/tests/modeltests/
> prefetch_related/tests.py", line 378, in test_child_link_prefetch
>     self.assertIn('authorwithage', connection.queries[-1]
> ['sql'].lower())
>   File "/usr/lib/python3.2/unittest/case.py", line 889, in assertIn
>     if member not in container:
> TypeError: Type str doesn't support the buffer API

I'll investigate this too.

I've enabled the issue tracker in the port's GitHub repo [1]
- feel free to add any further findings there.

Regards,

Vinay Sajip

[1] https://github.com/vsajip/django

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



  1   2   3   4   >