Re: Joining the "Python 3 Statement"

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

Re: Joining the "Python 3 Statement"

utcome 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

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 https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ >

Re: Joining the "Python 3 Statement"

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

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 be

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. > > > We already announced

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"

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 r

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 a

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

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 candid

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

ate 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

> On Nov 17, 2015, at 12:00 PM, Tim Graham 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.g

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? >> https://github.com/django/django/pull/5676 >>

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

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 t

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'

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 thi

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

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 issues, th

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

Re: [RFC] Python 3 and MySQL

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

Re: [RFC] Python 3 and MySQL

I find what cause this problem. I usually use strict mode. In my my.cnf: sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES After commenting out this line: mysql> CREATE INDEX `admin_views_prepopulatedpostlargeslug_f52cfca0` ON `admin_views_prepopulatedpostlargeslug` (`slug`); Query OK, 0 ro

Re: [RFC] Python 3 and MySQL

Maybe, this difference is come from MySQL version. I use MySQL 5.6.20 (Homebrew). mysql> show create table admin_views_prepopulatedpostlargeslug\G *** 1. row *** Table: admin_views_prepopulatedpostlargeslug Create Table: CREATE TABLE `admin_vi

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

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

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 er

Re: [RFC] Python 3 and MySQL

ble 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

Re: [RFC] Python 3 and MySQL

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

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 django-developers+unsubsc

Re: [RFC] Python 3 and MySQL

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

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 &

Re: [RFC] Python 3 and MySQL

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

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: /var/lib/jenkins/workspace/django-selenium/database/mysql/python/python3.2/tests/.env/lib/python3.2/site-packages/_mysql.cpython

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

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 unsu

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 qui

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

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 Githu

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 thi

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 m

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

Re: [RFC] Python 3 and MySQL

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 pu

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

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

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

Re: Recommending a Python 3-compatible MySQL connector

On Thu, Jan 23, 2014 at 2:51 PM, Daniel Sears 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 for the

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 >> >> > Also actively developed by @geertjanvdk at Oracle so he may

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 can't tell if he chose > the GPL to ma

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 >>> >>> https://pypi.python.org/pypi/mysql-connector-python/1.0.9 >> >> T

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 missing! > > Unfor

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 the best of my und

Re: Recommending a Python 3-compatible MySQL connector

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

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 slippin

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

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

Re: Recommending a Python 3-compatible MySQL connector

On 5 mai 2013, at 21:15, Ian Clelland 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.djangoprojec

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 whe

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

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

Given the positive replies, I'll commit this patch (with suitable docs). Thank you all for your feedback. -- 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

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

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.

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

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

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

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

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

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 Autho

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

On 24/08/12 22:47, claudep wrote: One more reason not to adopt too quickly this syntax is missing support from gettext. http://savannah.gnu.org/bugs/?30854 Right. That makes up my mind then. I can't afford to be without gettext support. Until gettext supports the newer format, and until

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 efficie

Re: Python 3 str.format()

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

Re: Python 3 str.format()

n 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

Re: Python 3 str.format()

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

Re: Python 3 str.format()

Hi Daniel, On 08/24/2012 09:56 AM, Daniel Swarbrick wrote: > 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 Pytho

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

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 https://groups.google.com/d/msg

Re: Python 3: should we apply unicode_literals everywhere?

ge 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). Worki

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 lon

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 move at this point. However I >> believe it deserves a publi

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 seems like the Right Thing To Do. Of c

Re: Python 3: should we apply unicode_literals everywhere?

Hi Aymeric, I prefer the eventual resulting consistency of option 2 and less gotchas when coding; thanks for asking. On 21/08/2012 06:46, Aymeric Augustin wrote: Hello, The first steps of porting Django to Python 3 was to switch on unicode_literals, as explained here [1]. This change was

Re: Python 3: should we apply unicode_literals everywhere?

On 21 elo, 13:46, Aymeric Augustin 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 a

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

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. https://gith

Re: Python 3 - style question

t do that until a significant part of the Django ecosystem has itself migrated to Python 3. Anyway, I'm not working on the documentation at this time. I'm only keeping API docs in sync with the code. This will be easier to discuss when the port is finished, and we have a better view of its c

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 removed. > > On 11 August 2012 06:10, Łukasz

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: > How about wrapping those 3 lines of code into a

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 Rekucki -- You received t

Re: Python 3 - style question

I think Option 2 is better, for the reasons you state. 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 emai

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 ex

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/

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 -- yes. Jo(sephin)e Publ

Re: Python 3 - style question

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

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

Re: Python 3 port status

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

  1   2   3   4   >