Re: Adding Support for PyMySQL (for Python 3)

[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 it might well be to do with my MySQL
installation (stock 5.1.58 for Ubuntu 64-bit).

It might be worth trying with my latest Django repo and my patched
MySQLdb on your installation, if you have the time and inclination...

BTW are you on IRC? If so, what nickname do you go by?

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: Adding Support for PyMySQL (for Python 3)

[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 converters to return unicode
instead of str. This would be implicitly always unicode in the 3.x
adapter.

I also looked further into one of the collation errors -
test_serialize_unicode. From what I can see, the query is converted to
utf-8 bytes and passed to MySQL, which returns the error. I can't see
where the Swedish collation it refers to comes from. Will continue to
investigate ...

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: Adding Support for PyMySQL (for Python 3)

[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:
>                 kwargs['use_unicode'] = True
>
> use_unicode used to be unconditional on the database connection; now you've
> removed it, but just for Python 3.

I removed it because the Python 3 adapter doesn't recognise the kwarg;
I thought it might be that under Python 3 it would be implicitly true.
Possibly I need to check the detail of where that value is used in the
2.x adapter and see what the 3.x adapter does in that area.

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: Adding Support for PyMySQL (for Python 3)

[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
> running with the standard 2.x MySQLdb adapter, so it might be
> something to do with my MySQL configuration.
>
>
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:
kwargs['use_unicode'] = True

use_unicode used to be unconditional on the database connection; now you've
removed it, but just for Python 3.



-- 
Regards,
Ian Clelland


-- 
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: Adding Support for PyMySQL (for Python 3)

[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 MySQL configuration.

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: Adding Support for PyMySQL (for Python 3)

[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 issues. Details at https://gist.github.com/1446201 - total run
time was 9737 secs, BTW, but that is quite possibly down to
differences between our machines.

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: Bug: When editing unique_togethers in a modelformset you can't reverse values

[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 I'm quite certain that, without the worst kind of
hacking imaginable, this is not fixable.

Re Karen: Thanks for clearing that up for me.

-- 
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: Admin inlines and fieldsets

[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 
to the bottom of the page, which is kind of a bummer because, for example, 
I've added middle name to the UserProfile but can't group it with the User 
first_name and last_name.  Unless of course I've completely missed 
something :P

Anyway, this has been a long-winded +1

-- 
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/-/QZIHicsafyMJ.
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: Bug: When editing unique_togethers in a modelformset you can't reverse values

[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 an error message stating,
"Production with this Person and Title already exists."

That sounds like pre-save validation refusing to attempt to save because it
believes an IntegrityError will be raised. I haven't checked the code but I
wouldn't be surprised if the unique validation works by checking for an
existing dupe among the other submitted/modified inlines and the db,
excluding just the pk of what it is currently attempting to verify will not
be a dupe with its new values. That approach would flag this direct swap
case as a validation error.

Whether that's a bug, I'm not convinced.

While it is true that the final state here won't violate the unique
together constraint, the intermediate state of getting there, given initial
state, WILLL violate the unique together constraint. There's no way (I
don't think, though I could be wrong) for the unique checking code to know
if current to final state is going to be done in a single transaction (nor
whether the DB in use is going to support deferring the constraint checking
to the end of the transaction). Seems to me safest thing for the unique
validation code to do is raise the validation error here.

Karen

-- 
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 - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[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" 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: Bug: When editing unique_togethers in a modelformset you can't reverse values

[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 = models.CharField(_('Title'), max_length=255)
>
>    class Meta:
>        unique_together = (('person', 'title'),)
>
>
> Create a Person named "Bob", then create a view with an inline model
> formset (I used the factory function) for the Production. Then, using
> the inline forms in the Production formset, add a couple of Production
> objects, one with the title "One", and one with the title "Two". After
> you save them, edit the title fields of "One" and "Two" to change the
> values to "Two" and "One", respectively. Upon attempting to save,
> you'll receive an error message stating, "Production with this Person
> and Title already exists."

Hi,

Two things:

Firstly, procedural -- if you've fairly certainly you've found a bug,
there's no need to start a thread on django-developers; just open a
ticket. The only reason to start a thread is if you've found something
that you're not sure is a bug, or if you're looking to start a design
discussion over the right way to address a bug.

Secondly (and this would have been my comment on a ticket if had been
created), this strikes me as something that should only be a problem
if you're in transaction autocommit mode. Saving an inline formset
isn't an atomic action, so the situation you describe is effectively
the analog of the following Python:

x = y
y = x

Which, of course, won't give you the result you expect; the database
error is just protecting you from the mistake. What you need to say
is:

x, y = y, x

The database equivalent of this line is to use a transaction. I
haven't tested this, but I'd be surprised if wrapping the inline
formset save in a transaction didn't address this issue (as long as
you're using a database that has real transactions -- MySQL InnoDB
doesn't count, due to its... interesting... interpretation of
constraint validation).

As long as this works under a transaction, I don't consider it a bug
that Django exposes a database error in this case. The overhead
involved in providing a workaround would be significant, and it's only
required for a very specific subset of cases.

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: Adding Support for PyMySQL (for Python 3)

[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 for this already? (I don't see anything in
> the DB component, looking for 'backend' anywhere in the
> summary/keywords/description, but I will allow that my trac-fu may be weak)
>
> I'm looking into what it would take to separate these concerns.
>
> --
> Regards,
> Ian Clelland
> 
>
> --
> 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.
>

No, there isn't a ticket for this.

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: Adding Support for PyMySQL (for Python 3)

[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' anywhere in the
summary/keywords/description, but I will allow that my trac-fu may be weak)

I'm looking into what it would take to separate these concerns.

-- 
Regards,
Ian Clelland


-- 
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: Adding Support for PyMySQL (for Python 3)

[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 would work just as well under Python 2.x. Should I set up a
> public repository somewhere, or just open a ticket and attach patches?
>
> Thoughts? Flames?

Ian,

I have a clone of Dāvis' repo which supports MySQLdb on Python 3:

https://github.com/vsajip/MySQL-for-Python-3

(forked from https://github.com/davispuh/MySQL-for-Python-3)

I mentioned in a message to you that I couldn't use it because it used
str.format rather than % formatting, but actually that was easy enough
to patch. I didn't have to make the Django changes called for in your
patch, and the test suite is running now with the MySQLdb backend. I
got some warnings for utf-8 bytestrings as fixtures were loaded, but
it's run the first 275 or so tests without errors or failures so I'm
going to let it run to see how far it gets. I will push my changes to
the above repo soon.

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: PUT and post data

[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 closed ticket, or
> open a new one?

Oh, just noticed this question. Generally it's best to err on the side
of opening a new ticket when a previous one has been closed, unless it's
exactly the same issue and the closing was simply in error. In this
case, it's not the same thing, as we're adding documentation of the
current behavior, not adding request.PUT as the previous ticket requested.

Thanks for the documentation patch!

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7f4KIACgkQ8W4rlRKtE2f6TACgqQGglLk4rpiMF+lkhnfQwKLs
dMYAnjuGZG8i/aLVltQxlcCtoJU+/Cu1
=QStu
-END PGP SIGNATURE-

-- 
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: Adding Support for PyMySQL (for Python 3)

[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 working, and I have had a great deal of success, using
> PyMySQL as a back end, rather than MySQLdb.
> >
> > MySQLdb does not support Python3, and I haven't seen any indication
> online that it will be supporting Python3 any time soon.
>
> That's not entirely true actually, I talked to Andy Dustman (MySQLdb's
> author earlier this year while researching the bits needed for porting) and
> he mentioned that several people ported it over the Python 3:
>
> -
> http://sourceforge.net/projects/mysql-python/forums/forum/70460/topic/3831691
> - https://github.com/davispuh/MySQL-for-Python-3
>
> Quoting him from his private reply: "I use 1.2.3 regularly with Django, so
> if there's serious interest in a Python 3 version, I'll try to find the
> time and energy to work on it again."
>
> As to which of those unofficial ports is the "correct" one, I can't help.
> But it would certainly be helpful to get in touch with Andy before
> dismissing MySQLdb altogether.
>
>
That's great to hear, that there's still at least some motivation to move
that project forward.

My goal has been to help Vinay out with his Python 3 drive, by debugging
the MySQL backend, and dropping this adapter in has been a way to at least
get the rest of the backend code exercised.


> > PyMySQL is a pure python implementation of PEP 249 for MySQL, and
> supports Python 2.4 - 3.2, and MySQL 4.1 and higher. It is nearly a
> plug-in-replacement for MySQLdb  (although there are a few compatibility
> issues that I have tried to take care of in Django backend code)
> >
> > My approach so far has been to patch django/db/backends/mysql:
> >- Try to import MySQLdb, and then MySQLdb.converters and
> MySQLdb.constants.
> >- If that fails, try to import pymysql, and pymysql.converters and
> pymysql.constants
> >- Whichever succeeds, set a module-level variable 'backend' to
> indicate the backend that we are using.
> >
> >- Patch the data-type conversions appropriately, depending on the
> backend that was used.
> >
> > So far, that's it -- and I'm down to just a couple of unit test
> failures, but those may even be Python3 issues; I haven't tracked them all
> down yet.
> >
> > My questions, then:
> >
> > 1. Is PyMySQL appropriate for django-core, in the opinion of the core
> devs? There isn't another stable Python 3-compatible mysql adapter, as far
> as I know, and I don't think Django could move to Python 3 support without
> at least the currently-supported databases.
>
> I think it's better to ask whether it's appropriate to switch the backend
> library while doing the Python version jump. In my opinion it's not given
> the stability MySQLdb has shown over the years. At least I'm not seeing
> reasons to get rid of it.
>

Well, it sounds like moving Django to Python 3, even with MySQLdb support,
would necessitate a simultaneous upgrade in MySQLdb anyway -- if there's no
official version right now that support both 2 and 3, then we would have to
upgrade both at the same time. Appreciated, though, that MySQLdb has a
longer history, but it would still be at least some new code.

And I wasn't trying to get rid of it, rather to support both of them at the
same time, given that they have the same interface, and only a few internal
differences, which can be smoothed over in module initialization.


>
> > 2. Is this the right approach? I know that in the past, we have had
> multiple backends for PostgreSQL, in different modules under
> django.db.backends, but in this case, the modules are almost 100%
> compatible, except for the module names themselves, and the calling
> conventions for the data conversions. It feels more like the situation with
> JSON libraries, where we just load whichever one is available, and present
> the same outward api to the developer.
>
> IMO it's not, database backends vary in the way to speak to the database,
> so if -- and only if it's really needed to introduce another backend for
> MySQL -- it should be independent from the current one.
>
> > 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 would work just as well under Python 2.x. Should I set up a
> public repository somewhere, or just open a ticket and attach patches?
>
> I asked Martin von Löwis who maintains the Py3K branch in Django official
> SVN repo to review Vinay's changes and merge them, as long as you manage to
> get patches in line with their work I think we're fine.
>

Jannis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To 

Re: Adding Support for PyMySQL (for Python 3)

[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.
>
>
> Agreed; I just don't know of another way to support Python 3 and MySQL,
> without pushing the MySQLdb developers to add support. (This is the Python
> 3 upgrade catch-22, and I'm looking for a way out of it).
>
>
>>  However, the approach is the wrong one, django database backends should
>> be really split up between the parts that are database specific, and the
>> parts that are driver specific,
>
>
> Do you mean to say that putting support for two drivers in
> django.db.backends.mysql is wrong, or that the django backends need to be
> refactored?
>
> I had started off by writing a new backend, mysql_pymysql (in the spirit
> of postgres_psycopg2), but there is so much overlap that it didn't make
> sense to me to have to duplicate all of the code in a separate module, when
> most of what I was doing was just changing the imports at the top of
> base.py and introspection.py.
>
> I would be happy putting this out as a separate backend, which just
> imported all of its functionality (and future bug fixes) from
> django.db.backends.mysql, but I can't even import the django backend
> modules in an environment which doesn't have MySQLdb installed -- say, any
> Python 3 environment.
>
> I'll think some more on it, but if you have any architectural suggestions,
> I'm very open to them.
>
>
>> that way someone can write an external driver that uses, say, the
>> postgresql spcific stuff but make it run on the 500 other postgresql
>> drivers.
>>
>> Alex
>>
>>
> Ian
>
>
>
> --
> Regards,
> Ian Clelland
> 
>
>  --
> 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.
>

I'm saying database backends need badly to me refactored to split up these
two seperate concerns.

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: Adding Support for PyMySQL (for Python 3)

[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 MySQLdb developers to add support. (This is the Python
3 upgrade catch-22, and I'm looking for a way out of it).


>  However, the approach is the wrong one, django database backends should
> be really split up between the parts that are database specific, and the
> parts that are driver specific,


Do you mean to say that putting support for two drivers in
django.db.backends.mysql is wrong, or that the django backends need to be
refactored?

I had started off by writing a new backend, mysql_pymysql (in the spirit of
postgres_psycopg2), but there is so much overlap that it didn't make sense
to me to have to duplicate all of the code in a separate module, when most
of what I was doing was just changing the imports at the top of base.py and
introspection.py.

I would be happy putting this out as a separate backend, which just
imported all of its functionality (and future bug fixes) from
django.db.backends.mysql, but I can't even import the django backend
modules in an environment which doesn't have MySQLdb installed -- say, any
Python 3 environment.

I'll think some more on it, but if you have any architectural suggestions,
I'm very open to them.


> that way someone can write an external driver that uses, say, the
> postgresql spcific stuff but make it run on the 500 other postgresql
> drivers.
>
> Alex
>
>
Ian



-- 
Regards,
Ian Clelland


-- 
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: Adding Support for PyMySQL (for Python 3)

[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, rather than MySQLdb.
> 
> MySQLdb does not support Python3, and I haven't seen any indication online 
> that it will be supporting Python3 any time soon. 

That's not entirely true actually, I talked to Andy Dustman (MySQLdb's author 
earlier this year while researching the bits needed for porting) and he 
mentioned that several people ported it over the Python 3:

- http://sourceforge.net/projects/mysql-python/forums/forum/70460/topic/3831691
- https://github.com/davispuh/MySQL-for-Python-3

Quoting him from his private reply: "I use 1.2.3 regularly with Django, so if 
there's serious interest in a Python 3 version, I'll try to find the time and 
energy to work on it again."

As to which of those unofficial ports is the "correct" one, I can't help. But 
it would certainly be helpful to get in touch with Andy before dismissing 
MySQLdb altogether.

> PyMySQL is a pure python implementation of PEP 249 for MySQL, and supports 
> Python 2.4 - 3.2, and MySQL 4.1 and higher. It is nearly a 
> plug-in-replacement for MySQLdb  (although there are a few compatibility 
> issues that I have tried to take care of in Django backend code)
> 
> My approach so far has been to patch django/db/backends/mysql:
>- Try to import MySQLdb, and then MySQLdb.converters and MySQLdb.constants.
>- If that fails, try to import pymysql, and pymysql.converters and 
> pymysql.constants
>- Whichever succeeds, set a module-level variable 'backend' to indicate 
> the backend that we are using.
> 
>- Patch the data-type conversions appropriately, depending on the backend 
> that was used.
> 
> So far, that's it -- and I'm down to just a couple of unit test failures, but 
> those may even be Python3 issues; I haven't tracked them all down yet.
> 
> My questions, then:
> 
> 1. Is PyMySQL appropriate for django-core, in the opinion of the core devs? 
> There isn't another stable Python 3-compatible mysql adapter, as far as I 
> know, and I don't think Django could move to Python 3 support without at 
> least the currently-supported databases.

I think it's better to ask whether it's appropriate to switch the backend 
library while doing the Python version jump. In my opinion it's not given the 
stability MySQLdb has shown over the years. At least I'm not seeing reasons to 
get rid of it.

> 2. Is this the right approach? I know that in the past, we have had multiple 
> backends for PostgreSQL, in different modules under django.db.backends, but 
> in this case, the modules are almost 100% compatible, except for the module 
> names themselves, and the calling conventions for the data conversions. It 
> feels more like the situation with JSON libraries, where we just load 
> whichever one is available, and present the same outward api to the developer.

IMO it's not, database backends vary in the way to speak to the database, so if 
-- and only if it's really needed to introduce another backend for MySQL -- it 
should be independent from the current one.

> 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 
> would work just as well under Python 2.x. Should I set up a public repository 
> somewhere, or just open a ticket and attach patches?

I asked Martin von Löwis who maintains the Py3K branch in Django official SVN 
repo to review Vinay's changes and merge them, as long as you manage to get 
patches in line with their work I think we're fine.

Jannis

-- 
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: Django-nonrel patches

[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 most important changes):

Hi Jonas,

I just came across your patches while I was triaging the "unreviewed" queue. 
Unfortunately, I found it difficult to assess them, since they don't include 
tests or docs.

Generally, all changes should come with tests. If you're adding new features — 
for instance "Support for non-integer primary keys" sounds an interesting one — 
those should be documented too.

That would help people who aren't familiar with django-nonrel (like me) to 
review your patches, and in particular to understand their consequences.

That said, I believe NoSQL support in a very interesting experiment for 
Django's ORM, and I really hope we can move forward with these tickets!

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: Adding Support for PyMySQL (for Python 3)

[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 working, and I have had a great deal of success, using
> PyMySQL as a back end, rather than MySQLdb.
>
> MySQLdb does not support Python3, and I haven't seen any indication online
> that it will be supporting Python3 any time soon.
>
> PyMySQL is a pure python implementation of PEP 249 for MySQL, and supports
> Python 2.4 - 3.2, and MySQL 4.1 and higher. It is nearly a
> plug-in-replacement for MySQLdb  (although there are a few compatibility
> issues that I have tried to take care of in Django backend code)
>
> My approach so far has been to patch django/db/backends/mysql:
>- Try to import MySQLdb, and then MySQLdb.converters and
> MySQLdb.constants.
>- If that fails, try to import pymysql, and pymysql.converters and
> pymysql.constants
>- Whichever succeeds, set a module-level variable 'backend' to indicate
> the backend that we are using.
>
>- Patch the data-type conversions appropriately, depending on the
> backend that was used.
>
> So far, that's it -- and I'm down to just a couple of unit test failures,
> but those may even be Python3 issues; I haven't tracked them all down yet.
>
> My questions, then:
>
> 1. Is PyMySQL appropriate for django-core, in the opinion of the core
> devs? There isn't another stable Python 3-compatible mysql adapter, as far
> as I know, and I don't think Django could move to Python 3 support without
> at least the currently-supported databases.
>
> 2. Is this the right approach? I know that in the past, we have had
> multiple backends for PostgreSQL, in different modules under
> django.db.backends, but in this case, the modules are almost 100%
> compatible, except for the module names themselves, and the calling
> conventions for the data conversions. It feels more like the situation with
> JSON libraries, where we just load whichever one is available, and present
> the same outward api to the developer.
>
> 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 would work just as well under Python 2.x. Should I set up a
> public repository somewhere, or just open a ticket and attach patches?
>
> Thoughts? Flames?
>
> Regards,
> Ian Clelland
> 
>
>
> [1] Original at https://github.com/petehunt/PyMySQL, my patches for
> better Python 3 support at https://github.com/clelland/PyMySQL
>
>  --
> 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.
>

It's a fine goal, though I'm not convinced this should necessarily ship
with Django given PyMySQL has relatively few users.  However, the approach
is the wrong one, django database backends should be really split up
between the parts that are database specific, and the parts that are driver
specific, that way someone can write an external driver that uses, say, the
postgresql spcific stuff but make it run on the 500 other postgresql
drivers.

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.

Adding Support for PyMySQL (for Python 3)

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

MySQLdb does not support Python3, and I haven't seen any indication online
that it will be supporting Python3 any time soon.

PyMySQL is a pure python implementation of PEP 249 for MySQL, and supports
Python 2.4 - 3.2, and MySQL 4.1 and higher. It is nearly a
plug-in-replacement for MySQLdb  (although there are a few compatibility
issues that I have tried to take care of in Django backend code)

My approach so far has been to patch django/db/backends/mysql:
   - Try to import MySQLdb, and then MySQLdb.converters and
MySQLdb.constants.
   - If that fails, try to import pymysql, and pymysql.converters and
pymysql.constants
   - Whichever succeeds, set a module-level variable 'backend' to indicate
the backend that we are using.

   - Patch the data-type conversions appropriately, depending on the
backend that was used.

So far, that's it -- and I'm down to just a couple of unit test failures,
but those may even be Python3 issues; I haven't tracked them all down yet.

My questions, then:

1. Is PyMySQL appropriate for django-core, in the opinion of the core devs?
There isn't another stable Python 3-compatible mysql adapter, as far as I
know, and I don't think Django could move to Python 3 support without at
least the currently-supported databases.

2. Is this the right approach? I know that in the past, we have had
multiple backends for PostgreSQL, in different modules under
django.db.backends, but in this case, the modules are almost 100%
compatible, except for the module names themselves, and the calling
conventions for the data conversions. It feels more like the situation with
JSON libraries, where we just load whichever one is available, and present
the same outward api to the developer.

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 would work just as well under Python 2.x. Should I set up a
public repository somewhere, or just open a ticket and attach patches?

Thoughts? Flames?

Regards,
Ian Clelland



[1] Original at https://github.com/petehunt/PyMySQL, my patches for better
Python 3 support at https://github.com/clelland/PyMySQL

-- 
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: Small problem with HttpResponseRedirect

[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 McMillan  wrote:

> As Ian said, Django does the right thing here according to my tests
> too, and generates the absolute URIs required by RFC 2616. If you've
> figured out some way to actually get location headers that are
> noncompliant, that would be a bug, but the handling of // is correct.
>
> -Paul
>
> --
> 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: PUT and post data

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

Adrian Holovaty  wrote:

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 (code.djangoproject.com).

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: PUT and post data

[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 (code.djangoproject.com).

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 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[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
> > converters -- they have a different function signature from MySQLdb's.
> >
> > I have had to make a couple of patches to the library, which I hope to
> get
> > applied upstream, otherwise it's working pretty well, so far.
>
> By "library" I assume you're referring to PyMySQL. Is there a repo I
> can clone, so I can start testing with MySQL?
>

There is now :)

https://clell...@github.com/clelland/PyMySQL.git

It needs some supporting code in backends/mysql/base.py -- I'll start
another discussion thread for those issues. (i.e. Do we support pymysql in
the mysql backend, or do we create a mysql_pymysql, akin to
postgres_psycopg2?)

>
> > I'm down to four failures and one error now -- I'll post back once those
> > are done, with a set of patches, hopefully.
>
> Great - thanks!
>
> 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.
>
>


-- 
Regards,
Ian Clelland


-- 
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 - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[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 make a couple of patches to the library, which I hope to get
> applied upstream, otherwise it's working pretty well, so far.

By "library" I assume you're referring to PyMySQL. Is there a repo I
can clone, so I can start testing with MySQL?

> I'm down to four failures and one error now -- I'll post back once those
> are done, with a set of patches, hopefully.

Great - thanks!

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 - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[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
> > > compatibility function is needed for Python 2.5.
> >
> > Ahh, that's a good catch. I'll have to make use of your solution, then.
> >
>
> I've already pulled Ian Kelly's changes from his BitBucket repo. Which
> MySQL driver are you using for Python 3? I started looking at
>
> git://github.com/davispuh/MySQL-for-Python-3.git
>
> but it appears to expect queries formatted with {} rather than %s, so
> it doesn't seem that I can use it.
>

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 make a couple of patches to the library, which I hope to get
applied upstream, otherwise it's working pretty well, so far.

I'm down to four failures and one error now -- I'll post back once those
are done, with a set of patches, hopefully.

Ian


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


-- 
Regards,
Ian Clelland


-- 
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: PUT and post data

[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? Otherwise, Should I upload a patch in the closed ticket, or
open a new one?

Regards,
Thibault J

-- 
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: PUT and post data

[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 contenttype, but 
I doubt that).

Well, fix is not that simple, since you have to handle the multipart/
> form-data case, (which is the default encoding used in test client):
>

Agreed, I was mostly referring to  your curl example which shouldn't issue 
multipart I guess ;)

I can work with that. My main concern is the lack of clarity in the
> documentation. 
>
+1 one, it would be good to know when what is filled (as people seem to 
appear to have problems with the current form).
 
 

> Then, maybe a variable named something like FORM_DATA would be less
> error prone?
>
Right, but that would make the distinction between GET and POST disappear, 
or at least I would expect GET params to be in it if I submitted a form etc…
Either way, since form-data is usually not the common way for stuff like 
this people might ask why there is no JSON_DATA etc…

Anyway, I think that discussion should be summarized
> somewhere in the documentation, to prevent any further WTF?! effect.


Please add a patch to the tracker, since it always best if people with the 
problem write it as they know what's missing. 
 

-- 
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/-/Tagzx6tF-K4J.
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 - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[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 use of your solution, then.
>

I've already pulled Ian Kelly's changes from his BitBucket repo. Which
MySQL driver are you using for Python 3? I started looking at

git://github.com/davispuh/MySQL-for-Python-3.git

but it appears to expect queries formatted with {} rather than %s, so
it doesn't seem that I can use it.

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 - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

[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 know why, so
> please figure out why and explain it to me. I think it's because psycopg2
> won't run upper on something that's not a unicode in python 3, but it needs
> to be a bytestring later to have the "buffer interface" implemented.

I think that part about "upper" is probably right - it doesn't make
sense to run "upper" on anything other than text.

Part of it is just bugs in my conversion - if you look at some of the
other test methods in the same test case, it appears that I applied
b() in some places when I shouldn't have.

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: PUT and post data

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

Well, fix is not that simple, since you have to handle the multipart/
form-data case, (which is the default encoding used in test client):

def
get_put_data(request):
content_type =
request.META.get('CONTENT_TYPE')
if
content_type.startswith('multipart'):
parser = MultiPartParser(request.META,
StringIO(request.raw_post_data), [], request.encoding) #nowhere in
docs.djangoproject.com
post, files =
parser.parse()
 
else:
post =
QueryDict(request.raw_post_data)
return post

I can work with that. My main concern is the lack of clarity in the
documentation. The testing doc asserts that « Client.put() [...] Acts
just like Client.post() except with the PUT request method. » When I
used Client.put in my tests, I was very surprised to find an empty
request.POST. Checked request.PUT ? Nope ! I had to browse a few
threads and bug reports to understand what was happening. Then, I had
to browse django's code to write the method above.

> Stuffing it into POST is a no go, adding an extra PUT/OPTIONS/ http verb allows entitity body> is something we don't like either. Given
> that the fix in Client code is a oneliner I think it's not really an issue.

Then, maybe a variable named something like FORM_DATA would be less
error prone? Anyway, I think that discussion should be summarized
somewhere in the documentation, to prevent any further WTF?! effect.

Regards,
Thibault J.

-- 
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: PUT and post data

[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 if you find 
PUT/DELETE/HEAD/OPTIONS/whatever data in request.POST
 

> But in the case of an urlencoded request, why would django
>
> make PUT requests' processing harder, forcing the user to parse the
> querystring by himself (which is not really well documented, as far as
> I know)?
>

put_data = QueryDict(self.raw_post_data, encoding=your_encoding)
not really hard if you ask me.
 

> If there is a valid explanation, I would be happy to hear it.
> Otherwise, I could provide a patch to solve the issue. Let me know.
>
Stuffing it into POST is a no go, adding an extra PUT/OPTIONS/ is something we don't like either. Given 
that the fix in Client code is a oneliner I think it's not really an issue.

Cheers,
Florian 

-- 
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/-/2HMtmOujeKkJ.
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: PUT and post data

[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 is
> common for POST because these content types are used by web browsers to
> submit HTML forms.

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? Even if form urlencoded web services are
not common, it is still the easiest way to send a request to a web
server.

Here's a few examples.

1) Using curl http://pastie.org/2979317

2) Using httplib2 http://pastie.org/2979319

I understand that browsers should not send PUT requests, and I agree
that if the requests comes as json or xml, the parsing is up to the
developer. But in the case of an urlencoded request, why would django
make PUT requests' processing harder, forcing the user to parse the
querystring by himself (which is not really well documented, as far as
I know)?

If there is a valid explanation, I would be happy to hear it.
Otherwise, I could provide a patch to solve the issue. Let me know.

Regards,
Thibault J

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