Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

me 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

Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

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

Joining the "Python 3 Statement"

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

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

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

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

he 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

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

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

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

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

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

gt; 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 s

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

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

> 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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

tring 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 >>&g

Re: [RFC] Python 3 and MySQL

icial 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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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:

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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,

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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:

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

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, "Pytho

Re: [RFC] Python 3 and MySQL

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

[RFC] Python 3 and MySQL

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

Re: Recommending a Python 3-compatible MySQL connector

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 >

Re: Recommending a Python 3-compatible MySQL connector

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>

Re: Recommending a Python 3-compatible MySQL connector

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:

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

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

en'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 Dja

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Recommending a Python 3-compatible MySQL connector

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

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

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

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

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

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

012 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: > f

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

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

Backporting some Python 3 support features to 1.4.x?

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

Re: Python 3: should we apply unicode_literals everywhere?

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.

Re: Python 3 str.format()

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

Re: Python 3 str.format()

lt, 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 beca

Re: Python 3 str.format()

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

Re: Python 3 str.format()

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

Python 3 str.format()

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

Re: Python 3: should we apply unicode_literals everywhere?

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

Re: Python 3: should we apply unicode_literals everywhere?

ng 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

Re: Python 3: should we apply unicode_literals everywhere?

gs"; 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

Re: Python 3: should we apply unicode_literals everywhere?

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

Re: Python 3: should we apply unicode_literals everywhere?

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

Re: Python 3: should we apply unicode_literals everywhere?

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

Re: Python 3: should we apply unicode_literals everywhere?

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 ch

Python 3: should we apply unicode_literals everywhere?

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

Re: Python 3 - style question

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.

Re: Python 3 - style question

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

Re: Python 3 - style question

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

Re: Python 3 - style question

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

Re: Python 3 - style question

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

Re: Python 3 - style question

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

Re: Python 3 - style question

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

Re: Python 3 - style question

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

Python 3 - style question

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

Re: Python 3 port status

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

Re: Python 3 port status

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

Re: Python 3 port status

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

Python 3: new coding guidelines

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

Re: Python 3 port - now available on GitHub

> 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

Re: Python 3 port - now available on GitHub

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

Re: Python 3 port - now available on GitHub

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

Re: Python 3 port - now available on GitHub

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

Re: Python 3 port - now available on GitHub

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

Re: Python 3 port - now available on GitHub

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 >

  1   2   3   4   >