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
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
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
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
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
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
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?
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
> > >
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
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
> >
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
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
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
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
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
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
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,
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
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.
>
>
>
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
-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
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
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'
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
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 =
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"
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
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 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
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
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
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
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:
>
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
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
35 matches
Mail list logo