Re: PUT and post data

2011-12-07 Thread Thibault Jouannic
Actually, I've been thinking about this issue, read again the bug report and current thread, and I'd like to re-open the discussion, if you don't mind. > request.POST is a > special-case for a request body submitted with the > "x-www-form-urlencoded" or "multipart/form-data" content types. This

Re: PUT and post data

2011-12-07 Thread Florian Apolloner
Hi, On Wednesday, December 7, 2011 9:33:52 AM UTC+1, Thibault Jouannic wrote: > So, don't you think the `request.POST` variable should be processed > for every request with the "x-www-form-urlencoded" content type, > whatever the http verb is? > That would be really odd imo and confusing as hell

Re: PUT and post data

2011-12-07 Thread Thibault Jouannic
Hi, > That would be really odd imo and confusing as hell if you find > PUT/DELETE/HEAD/OPTIONS/whatever data in request.POST If I'm not wrong, only the PUT method can specify POST like parameters. > put_data = QueryDict(self.raw_post_data, encoding=your_encoding) > not really hard if you ask

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

2011-12-07 Thread Vinay Sajip
On Dec 7, 5:14 am, "Joe & Anne Tennies" wrote: > So, I hg pull; hg update and reran the Python3 tests. The Egg import test > passes now. > > The attached patch fix makes the last 2 tests pass in both 2.7.2 and 3.2.1 > under postgres and sqlite. I'll be honest and say I don't

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

2011-12-07 Thread Vinay Sajip
On Dec 7, 5:53 am, Ian Clelland wrote: > On Tuesday, December 6, 2011, Ian Kelly wrote: > > itertools.izip_longest was added in Python 2.6, though, so a > > compatibility function is needed for Python 2.5. > > Ahh, that's a good catch. I'll have to make

Re: PUT and post data

2011-12-07 Thread Florian Apolloner
Hi, On Wednesday, December 7, 2011 11:09:38 AM UTC+1, Thibault Jouannic wrote: > > If I'm not wrong, only the PUT method can specify POST like > parameters. > Before writing my answer I did look on w3c and at least OPTIONS is allowed to have a body (can't tell you if it has to be a specific

Re: PUT and post data

2011-12-07 Thread Thibault Jouannic
Hi again, > Please add a patch to the tracker, since it always best if people with the > problem write it as they know what's missing. Done. https://github.com/django/django/pull/87 Hope I did everything right. I've read the submitting patches doc, but is a git pull request accepted?

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

2011-12-07 Thread Ian Clelland
On Wed, Dec 7, 2011 at 4:14 AM, Vinay Sajip wrote: > On Dec 7, 5:53 am, Ian Clelland wrote: > > On Tuesday, December 6, 2011, Ian Kelly wrote: > > > itertools.izip_longest was added in Python 2.6, though, so a > > >

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

2011-12-07 Thread Vinay Sajip
On Dec 7, 3:50 pm, Ian Clelland wrote: > I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a > drop-in replacement for MySQLdb. The biggest change is in the data > converters -- they have a different function signature from MySQLdb's. > > I have had to

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

2011-12-07 Thread Ian Clelland
On Wed, Dec 7, 2011 at 7:55 AM, Vinay Sajip wrote: > > On Dec 7, 3:50 pm, Ian Clelland wrote: > > I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a > > drop-in replacement for MySQLdb. The biggest change is in the data > >

Re: PUT and post data

2011-12-07 Thread Adrian Holovaty
On Wed, Dec 7, 2011 at 8:25 AM, Thibault Jouannic wrote: > I've read the submitting patches doc, but is a git pull request > accepted? For now, no. We'll be moving to GitHub in the near future, but currently we're using Subversion/Trac. Upload a patch via the ticket tracker

Re: PUT and post data

2011-12-07 Thread Carl Meyer
Fwiw, for the last number of months we've been telling people that pull requests are fine in lieu of uploaded patch, but the pull request still needs to be linked from a Trac ticket (so Trac remains the single source of truth). Carl -- Sent from my Android phone with K-9 Mail. Please excuse my

Re: Small problem with HttpResponseRedirect

2011-12-07 Thread Cal Leeming [Simplicity Media Ltd]
After reading all the comments, I now completely agree that Django is doing the right thing and it falls onto the user to do sanity checking. Always helps to have another set of eyes, so thank you to everyone who took time to post their thoughts! Cal On Tue, Dec 6, 2011 at 7:54 AM, Paul

Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Ian Clelland
Hi, all --- This is a proposal to add support in Django for PyMySQL[1] as an optional replacement for MySQLdb. I've been working with Vinay Sajip's Python 3-compatible branch; trying to get MySQL support working, and I have had a great deal of success, using PyMySQL as a back end, rather than

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Alex Gaynor
On Wed, Dec 7, 2011 at 3:38 PM, Ian Clelland wrote: > Hi, all --- > > This is a proposal to add support in Django for PyMySQL[1] as an optional > replacement for MySQLdb. > > I've been working with Vinay Sajip's Python 3-compatible branch; trying to > get MySQL support

Re: Django-nonrel patches

2011-12-07 Thread Aymeric Augustin
On 3 déc. 2011, at 23:36, Jonas H. wrote: > On Jacob's suggestion in this thread [1] back in April, I split the diff > between Django trunk and Django-nonrel into logically separated patches. > > I uploaded most of them to the ticket tracker (a few things are still missing > but these are the

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Jannis Leidel
Ian, > This is a proposal to add support in Django for PyMySQL[1] as an optional > replacement for MySQLdb. > > I've been working with Vinay Sajip's Python 3-compatible branch; trying to > get MySQL support working, and I have had a great deal of success, using > PyMySQL as a back end,

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Ian Clelland
On Wed, Dec 7, 2011 at 12:48 PM, Alex Gaynor wrote: > It's a fine goal, though I'm not convinced this should necessarily ship > with Django given PyMySQL has relatively few users. Agreed; I just don't know of another way to support Python 3 and MySQL, without pushing the

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Alex Gaynor
On Wed, Dec 7, 2011 at 4:03 PM, Ian Clelland wrote: > > > On Wed, Dec 7, 2011 at 12:48 PM, Alex Gaynor wrote: > >> It's a fine goal, though I'm not convinced this should necessarily ship >> with Django given PyMySQL has relatively few users. > > >

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Ian Clelland
On Wed, Dec 7, 2011 at 12:56 PM, Jannis Leidel wrote: > > Ian, > > > This is a proposal to add support in Django for PyMySQL[1] as an > optional replacement for MySQLdb. > > > > I've been working with Vinay Sajip's Python 3-compatible branch; trying > to get MySQL support

Re: PUT and post data

2011-12-07 Thread Carl Meyer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2011 07:25 AM, Thibault Jouannic wrote: > https://github.com/django/django/pull/87 > > Hope I did everything right. > > I've read the submitting patches doc, but is a git pull request > accepted? Otherwise, Should I upload a patch in the

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Vinay Sajip
On Dec 7, 8:38 pm, Ian Clelland wrote: > > 3. Code speaks, I know -- what's the best way to share this? I've sent > Vinay a patch, but that's for his Py3k branch, and might not get the > audience that something like this needs. I'm doing it for Py3k support, but > ideally it

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Ian Clelland
On Wed, Dec 7, 2011 at 1:07 PM, Alex Gaynor wrote: > I'm saying database backends need badly to me refactored to split up these > two seperate concerns. > Agreed, then. Is there a ticket for this already? (I don't see anything in the DB component, looking for 'backend'

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Alex Gaynor
On Wed, Dec 7, 2011 at 5:17 PM, Ian Clelland wrote: > On Wed, Dec 7, 2011 at 1:07 PM, Alex Gaynor wrote: > >> I'm saying database backends need badly to me refactored to split up >> these two seperate concerns. >> > > Agreed, then. Is there a ticket

Re: Bug: When editing unique_togethers in a modelformset you can't reverse values

2011-12-07 Thread Russell Keith-Magee
On Wed, Dec 7, 2011 at 10:59 AM, Yo-Yo Ma wrote: > Take the following models: > > class Person(models.Model): >    name = models.CharField(_('Person'), max_length=255) > > class Production(models.Model): >    person = models.ForeignKey(Person) >    title =

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

2011-12-07 Thread Ian Clelland
Just finished a full suite test, with the PyMySQL adapter, and I'm down to 5 failures and 2 errors: Gory details: http://dpaste.com/hold/667992/ -- Regards, Ian Clelland -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: Bug: When editing unique_togethers in a modelformset you can't reverse values

2011-12-07 Thread Karen Tracey
On Wed, Dec 7, 2011 at 6:21 PM, Russell Keith-Magee wrote: > I don't consider it a bug > that Django exposes a database error in this case. > I didn't hear what sounded like a database error in this case. The original note says: Upon attempting to save, you'll receive

Re: Admin inlines and fieldsets

2011-12-07 Thread Imposter
This is exactly what I've been struggling with today! Specifically the ordering of a related object. More specifically the UserProfile created for User. Currently I seemingly have no control in integrating with the admin form and am stuck with my User extension as a stacked inline appended

Re: Bug: When editing unique_togethers in a modelformset you can't reverse values

2011-12-07 Thread Yo-Yo Ma
Re Russell: Pertaining to autocommit, I wrapped the view (my base view's dispatch method) in commit_on_success. I asked here (as opposed to opening a ticket) because I wasn't certain there was a way to fix this, but it just seemed too wrong to not at least bring to the table. After Karen's reply

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Vinay Sajip
On Dec 7, 8:38 pm, Ian Clelland wrote: > Thoughts? The Django test run using MySQLdb at https://github.com/vsajip/MySQL-for-Python-3 completed with 24 failures, 9 errors, so your PyMySQL results are better at 5 failures, 2 errors. I will dig in a little further into these

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Vinay Sajip
On Dec 7, 8:38 pm, Ian Clelland wrote: > Thoughts? A further update: of my 24 failures, 17 are in multiple_database, as are 3 failures. But I get the same errors with unpatched Django 2.x running with the standard 2.x MySQLdb adapter, so it might be something to do with my

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Ian Clelland
On Wed, Dec 7, 2011 at 9:59 PM, Vinay Sajip wrote: > On Dec 7, 8:38 pm, Ian Clelland wrote: > > > Thoughts? > > A further update: of my 24 failures, 17 are in multiple_database, as > are 3 failures. But I get the same errors with unpatched Django 2.x

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Vinay Sajip
On Dec 8, 6:46 am, Ian Clelland wrote: > There also seem to be a number of unicode-related errors there (mixed > collations; unrecognized characters) -- Could that be related to the lines > in your patched mysql/base.py: > >             if not PY3: >                

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Vinay Sajip
On Dec 8, 6:46 am, Ian Clelland wrote: > > use_unicode used to be unconditional on the database connection; now you've > removed it, but just for Python 3. > I looked into it a little further - the use_unicode flag is just used in the 2.x constructor to set default

Re: Adding Support for PyMySQL (for Python 3)

2011-12-07 Thread Vinay Sajip
On Dec 8, 6:46 am, Ian Clelland wrote: > > There also seem to be a number of unicode-related errors there (mixed > collations; unrecognized characters) -- Could that be related to the lines I'm also getting the same errors on 2.x with the 2.x adapter on unpatched Django - so