Re: Dynamic choices for newforms?
+1
Aside from putting choices in __init__, my other current workaround is
to use Python's property feature:
class PhysicianChoices:
def _physicians(self):
return [(e.id, e.name) for e in \
Physician.objects.order_by('lastName','firstName') if
e.active]
choices = property(_physicians)
--
Jeff Bauer
Rubicon, Inc.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Dynamic choices for newforms?
I'm working on porting an app over to newforms as a learning exercise, and running into what I'm sure will be a pretty common pattern: wanting to populate the choices for a ChoiceField from a QuerySet. This is easy enough to do, except that the QuerySet only gets evaluated once per server process (when the file containing the form gets imported), so any change to the data it's building from won't be reflected. It feels slightly hackish to try to do this in, say, the form's __init__; any chance of getting ChoiceField to check whether the 'choices' argument is a callable and do the right thing? Then it'd just be a matter of defining a function which generates the choice list. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: specifying newforms-admin options
On Sun, Jan 21, 2007 at 12:24:54PM -0600, Adrian Holovaty wrote:
> On 1/20/07, Honza Kr?l <[EMAIL PROTECTED]> wrote:
> > why not create a function to do that for you..
> > urls.py is after all a python module, so you could just introduce a function
> >
> > urlpatterns = admin_urls_for_model(
> > MyModel,
> > field_list=[ 'field' ],
> > exclude_actions=[ admin.EDIT ],
> > perms_required={
> > admin.EDIT : 'can_change_MyModel',
> > admin.LIST : 'something_else'
> > }
> > )
>
> I must not have explained this correctly. In the newforms-admin
> branch, all of those options are specified in a class, ModelAdmin. The
> goal here is to figure out how those classes interact with the
> URLconf. There's no need to pass dictionaries around -- all of that
> configuration is in the class.
>
> Something like this is what I had in mind:
>
> """
> from myapp.models import PollAdmin, ChoiceAdmin
>
> urlpatterns = patterns('',
> (r'^admin/', include('django.contrib.admin.urls'), {'models':
> (PollAdmin, ChoiceAdmin)})
> )
> """
>
> The problem here is that each time you add an admin interface to a
> model, you have to remember to add it to your URLconf. Maybe there can
> be a helper function that looks for all Admin classes, as long as you
> save them in a file called admin.py within the app, but that's kind of
> magic.
What if we made the admin app scan all installed applications in its
urls.py file for admin classes in models or admin modules?
Currently we have this in django.contrib.admin.urls:
# Model-specific admin pages.
('^([^/]+)/([^/]+)/(?:(.+)/)?$',
'django.contrib.admin.views.main.model_admin_view'),
This pulls us out of urlconf into a view to decide what the real view
is. Instead we could continue adding to urlpatterns for any admin
classes we find.
# This is pseudo-python
def find_admin_urlpatterns:
for app in settings.INSTALLED_APPS:
if app.admin:
urlpatterns += app.admin.urlpatterns
else:
for model in app.models:
if model.Admin:
urlpatterns += model.Admin.urlpatterns
With this method we could support the old style of Admin class in
models and whatever new way we want for extending the ModelAdmin class
using admin.py in each app.
Nate
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
newforms: accessing help_text in a template
Hi,
Currently to access help_text for a field in a template I have to do this:
{{ form..field.help_text }}
would be nicer if I could just do this:
{{ form..help_text }}
A two line change to BoundField will do the trick, I can submit a patch
if desired.
-+ enlight +-
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Django Builbot (was: dbsync for mysql lacks...)
On 31/01/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > Hi Matthew > > On 1/30/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > I run the django pybot. It wouldn't be difficult to add other backends > > to the tests and is something I've been considering for a while. As > > for python versions, pybot only tests 2.5 and trunk > > . Testing against 2.3 and 2.4 would have to be done on another buildbot. > > At least on debian is not hard to have python 2.3, 2.4 and 2.5 > available on the same box (simply call /usr/bin/python2.X), also > different versions of postgresql can be run side by side (not for > mysql). Maybe a single BuildSet could be created that creates a bunch > of Builds with the different combinations of python+backend. As far as > a slave has the three versions of python and the different backends it > could run the tests. (note that for postgresql there are two > backends!), Anyway there's always virtualization if you need true > isolation and/or different mysql server versions. > > Sure you have far more knowledge of buildbot than me, so any comments > are really appreciated! > The Django buildbot slave is currently running inside a Solaris 10 zone so it is virtualized...kind of. Let me clarify that testing python 2.3 and 2.4 would require a separate buildbot master than pybots unless you can talk the pybots maintainer into running 2.3 and 2.4 tests as well. Why don't you join the pybots mailing list and ask? > > I'm fairly busy for the next 2 weeks but I can look at it after that > > and hopefully add postgresql and mysql backends on top sqlite that is > > being tested already. > > That would be nice, then the only thing left would be the different > versions of python. For which, as you say, those would need to run on > a different buildbot (buildd.djangoproject.com ?) > > Cheers, > Marc. > > PS: I can host a slave and/or the master for the different > python/backends buildbot if you wish. > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Builbot (was: dbsync for mysql lacks...)
On 31/01/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Marc Fargas Esteve: > > That sounds interesting. (Did I mention that it should run python > > versions 2.3, 2.4 and 2.5? ;-) > > As Matthew said this could be done with separate buildbots or slaves > running different jobs. > > > I wouldn't mind doing this on my own computer if it's so easy ;-) > It depends on how Matthew's buildbot works, normally if you have svn > and the required dependencies it just requires a few files and the > buildbot package, the hard work is at the master which, at the most > part, has already been done by Matthew (get the source, set a project, > test it...) > I don't control the pybots master just the slave that does the django builds. The master is responsible for telling the slaves what to build. For pybots it triggers a build whenever any of the python developers commit changes to either the python 2.5 maintenance branch or 2.6 trunk. So only those python versions are available to test against on pybots. Take a look at my build slave test scripts at: http://pybots.googlecode.com/svn/trunk/slave/flanagan-sparc/ and the pybot master config at: http://pybots.googlecode.com/svn/trunk/master/community.cfg Adding more backends would just be a matter of creating a Django-mysql.sh, Django-postgresql.sh, etc scripts to run each backend test as distinct stages. > Then you can make your computer be a new "slave" that received build > jobs from the "master", then the master decides when your slave has to > do things. > > > Perhaps you can pre-build such a thing ready to download for > > everybody who is interested? It's probably easier than building a > > shared buildbot with proper authentication etc. Don't make any > > complicated patch-auto-selection, let the user prepare the source, > > and the buildbot runs the testsuite with all backends and the python > > versions. > > For that to be done the user would need all the different python > versions and backends (with the required database servers) to run it. > A user can already run the tests with one python version and database > or more if he/she has them. But it's not an easy thing to package, > that's why buildbot was written! > > > This could be used to test the trunk with each checkin (or daily), > > or to test all the patches in stage "Ready for checkin". And I'd > > love to have this for triage. > > Buildbot was written for that, the svn repository can tell the > buildbot when a new checking has been done and start a new bunch of > jobs against it. Having this in place the part of taking patches from > trac is not so hard, the problem is to identify which is the correct > patch to test. > > > Michael > Marc > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Bill de hOra wrote: > Yep; it's a problem on the way back in. Python won't let you interpolate > encoded bytestrings and unicode; you have to state the encoding. Ivan - > could the db encoding be declared in settings.py? This is what #952 is about. Though it doesn't convert things for DB on Django side, it declares Django's data encoding to DB instead so it can convert. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django ORM bug when your app has a model named "ContentType"?
I'm getting a weird bug here and this is what I've deduced... I've got a "Page" model and a "Content" model. Content has a FK to Page. I also have a "ContentType" model and Content has a FK to ContentType. This is where I tell it if the content is text or other media content. The problem comes when I use Content.objects to pull data... This works: Content.objects.filter(page__number=11020) But this doesn't: Content.objects.select_related().filter(page__number=11020) When I view the SQL, the one with selected_related includes invalid tables in the SELECT clause, namely: '`page_contenttype6`.`id`', '`page_contenttype6`.`name`', Even though it already has the real tables: '`page_contenttype`.`id`', '`page_contenttype`.`name`', When I look in the django_content_type table, the row with id=6 is: | 6 | content type | contenttypes | contenttype | This seems like too much of a coincidence. The row for the "ContentType" content type is this: | 10 | content type | page | contenttype | How can I help further debug this? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Ivan Sagalaev wrote: > Michael Radziej wrote: >> >> I don't see a problem with the generic views since they pass bytestrings >> to the database wrapper, this gets as bytestrings to MySQLdb, and for >> bytestrings the charset attribute is not used at all. > > Umm... This is the exact problem with byte strings: that they require > knowledge of a charset somewhere. Yep; it's a problem on the way back in. Python won't let you interpolate encoded bytestrings and unicode; you have to state the encoding. Ivan - could the db encoding be declared in settings.py? cheers Bill --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: A question related to URLConf, Reverse URL, etc...
Well, I went ahead and created a patch for this. It is in ticket 3402
(http://code.djangoproject.com/ticket/3402)
--
Thanks,
Medhat
On Jan 26, 12:18 pm, "medhat" <[EMAIL PROTECTED]> wrote:
> the url should behttp://www.example.com/categories/x/
>
> --
> Medhat
>
> On Jan 26, 12:12 pm, "medhat" <[EMAIL PROTECTED]> wrote:
>
> > Here is even a better idea...
>
> > in your urls.py when you "from django.conf.urls.defaults import *" this
> > will import 'stem' in addition to the usual things. In any url pattern,
> > if you add {'param_name':stem} to the extra options, your view will get
> > a keyword argumant called 'param_name' and will have the value of the
> > part of the url that matched *before* going into that urls.py file.
>
> > example:
>
> > --- urls.py ---
>
> > from django.conf.urls.defaults import *
>
> > urlpatterns = patterns('',
> > (r'^categories/', include('apps.tags.urls')),
> > )
>
> > --- apps/tags/urls.py ---
>
> > from django.conf.urls.defaults import *
>
> > urlpatterns = patterns('apps.tags.views',
> > (r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
> > )
>
> > ---
>
> > In that case the urlhttp://www.example.com/tags/x/willcall
> > apps.tags.views.tag_list and pass it the request object and two keyword
> > parameters: tag = 'x' and stem = /categories/
>
> > I already have a patch that does this. I don't have unit tests or
> > documentation yet. But if this looks like a patch that would be
> > accepted, I can definitely work on the tests and documentation.
>
> > --
> > Thanks,
> > Medhat
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Comments requested on two serializer related fixes
Russell Keith-Magee wrote: > I hadn't considered that approach. I'm not a big fan of the > half-complete object instance, though. So do I :-). I merely bring this up to remind that it kinda works but may be it should be removed in favor of a more clean way. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django Builbot (was: dbsync for mysql lacks...)
[note: maybe this message appears twice as I sent it with the wrong reply-to and google-groups likes to reject it, if so, sorry ;) ] Hi Matthew On 1/30/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > I run the django pybot. It wouldn't be difficult to add other backends > to the tests and is something I've been considering for a while. As > for python versions, pybot only tests 2.5 and trunk > . Testing against 2.3 and 2.4 would have to be done on another buildbot. At least on debian is not hard to have python 2.3, 2.4 and 2.5 available on the same box (simply call /usr/bin/python2.X), also different versions of postgresql can be run side by side (not for mysql). Maybe a single BuildSet could be created that creates a bunch of Builds with the different combinations of python+backend. As far as a slave has the three versions of python and the different backends it could run the tests. (note that for postgresql there are two backends!), Anyway there's always virtualization if you need true isolation and/or different mysql server versions. Sure you have far more knowledge of buildbot than me, so any comments are really appreciated! > I'm fairly busy for the next 2 weeks but I can look at it after that > and hopefully add postgresql and mysql backends on top sqlite that is > being tested already. That would be nice, then the only thing left would be the different versions of python. For which, as you say, those would need to run on a different buildbot (buildd.djangoproject.com ?) Oh, and congratulations for the django pybot ;) Cheers, Marc. PS: I can host a slave and/or the master for the different python/backends buildbot if you wish. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Builbot (was: dbsync for mysql lacks...)
On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > Marc Fargas Esteve: > That sounds interesting. (Did I mention that it should run python > versions 2.3, 2.4 and 2.5? ;-) As Matthew said this could be done with separate buildbots or slaves running different jobs. > I wouldn't mind doing this on my own computer if it's so easy ;-) It depends on how Matthew's buildbot works, normally if you have svn and the required dependencies it just requires a few files and the buildbot package, the hard work is at the master which, at the most part, has already been done by Matthew (get the source, set a project, test it...) Then you can make your computer be a new "slave" that received build jobs from the "master", then the master decides when your slave has to do things. > Perhaps you can pre-build such a thing ready to download for > everybody who is interested? It's probably easier than building a > shared buildbot with proper authentication etc. Don't make any > complicated patch-auto-selection, let the user prepare the source, > and the buildbot runs the testsuite with all backends and the python > versions. For that to be done the user would need all the different python versions and backends (with the required database servers) to run it. A user can already run the tests with one python version and database or more if he/she has them. But it's not an easy thing to package, that's why buildbot was written! > This could be used to test the trunk with each checkin (or daily), > or to test all the patches in stage "Ready for checkin". And I'd > love to have this for triage. Buildbot was written for that, the svn repository can tell the buildbot when a new checking has been done and start a new bunch of jobs against it. Having this in place the part of taking patches from trac is not so hard, the problem is to identify which is the correct patch to test. > Michael Marc --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Builbot (was: dbsync for mysql lacks...)
Marc Fargas Esteve: > On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > [..] >> I'm now dreaming of a test service that would automatically run the >> testsuite for a given patch (or multiple patches) with all supported >> database backends ... > > Also thought about that, getting up a buildbot for testing the SVN is > not hard (it's already done on pybots), running the testsuite for a > given patch has a big danger: One could upload a malicious patch just > to f**k the buildbot. Some way would be needed to tell the buildbot > that a patch is to be tested, then it only has to download the patch > from a ticket and start a Build jobs. That sounds interesting. (Did I mention that it should run python versions 2.3, 2.4 and 2.5? ;-) I wouldn't mind doing this on my own computer if it's so easy ;-) > I could setup the buildbot for testing if it seems to make sense (most > of the work is already done on pybots, only playing with all the > possible combinations is needed). Perhaps you can pre-build such a thing ready to download for everybody who is interested? It's probably easier than building a shared buildbot with proper authentication etc. Don't make any complicated patch-auto-selection, let the user prepare the source, and the buildbot runs the testsuite with all backends and the python versions. This could be used to test the trunk with each checkin (or daily), or to test all the patches in stage "Ready for checkin". And I'd love to have this for triage. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django Builbot (was: dbsync for mysql lacks...)
Hi, inline On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: [..] > I'm now dreaming of a test service that would automatically run the > testsuite for a given patch (or multiple patches) with all supported > database backends ... Also thought about that, getting up a buildbot for testing the SVN is not hard (it's already done on pybots), running the testsuite for a given patch has a big danger: One could upload a malicious patch just to f**k the buildbot. Some way would be needed to tell the buildbot that a patch is to be tested, then it only has to download the patch from a ticket and start a Build jobs. If the core's around here would like to get up a buildbot that runs the testsuite on the various python versions, and various backends it can be done! (at least on debian.. :P). And if some security measure is provided patches on TRAC could also be tested without trouble maybe a textfield on the ticket telling which patches to check (as some tickets have lots of patches) to be set by a triage member. I could setup the buildbot for testing if it seems to make sense (most of the work is already done on pybots, only playing with all the possible combinations is needed). > Michael Marc --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Critical ticket: can cause data loss
2007/1/30, Russell Keith-Magee <[EMAIL PROTECTED]>: > > On 1/30/07, David Larlet <[EMAIL PROTECTED]> wrote: > > I'm +1 on this option. Before making decision what about at least add > > a warning message on the documentation page? > > This is kind of the point. Which documentation page? Generic relations > exist, but they aren't documented - specifically because they're not > really ready for prime time yet (at the very least, they don't have > any representation in the admin view). Here is the documentation page: http://www.djangoproject.com/documentation/models/generic_relations/ Cheers, David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Michael Radziej wrote:
> I thank you for all your patience with me. I was completely off-track. I
> read all the mails again, and everything is starting to make sense now.
Then I hope not to confuse you (and everyone else) with my answer :-)
> First, contrary to my former opinion, #3370 is a bug in the newforms
> module, as it is passing unicode to the database API which is not ripe
> for it and will break as soon as you leave ASCII.
I wouldn't call it a bug. Newforms are intended to work in unicode. They
don't play nice with db backends now but it's a question what should be
changed: newforms to supply byte strings or db backends to accept unicode.
> I see three ways to fix the problem in #3370:
>
> a) newforms stops passing unicode strings to the Database API and uses
> bytestrings.
>
> b) the database wrapper in Django sets connection.charset (but needs to
> translate the charset name since the databases don't understand all
> charset name variants, see ticket #952 here). This is the approach of
> the patches in tickets #1356 and #3370.
>
> c) the database wrapper in Djago must check whether it gets unicode. In
> this case, it needs to encode it into a bytestring.
I believe option a) and b) together will do the work.
Now we have all these confusing bugs because db backends receive two
kind of inputs: unicode from newforms and byte strings from oldforms (a
majority of existing code I think). Newforms are now "guilty" of
introducing unicode into party so I think it's better to keep all the
conversions there.
Option b) is needed because a db backend should know in which
single-byte encoding it receives data. The great advantage of unicode is
that you shouldn't supply a text's language alongside, it's encoded
right there. But with byte strings it's necessary.
Option c) scares me :-). Because the need in working with byte strings
(and hence in options a) and b)) remains but also introduces an ability
to accept but not to issue unicode objects also. I don't think people
would thank us for this :-)
> With all three variants, what encoding should be used? We currently
> issue (without #952) a 'set name utf8' at the beginning of each
> connection, so the database server expects to receive utf8. So,
> shouldn't we currently always use utf8 encoding, regardless of what is
> in settings.DEFAULT_CHARSET?
No we shouldn't. In fact this was never working properly, #952 is an old
bug. It kinda works most of the time because the default value of
DEFAULT_CHARSET is 'utf-8' and most apps don't change it. But if they do
and actually work with non utf-8 data then when fed into database
declared as utf-8 they will break because an arbitrary single-byte
encoding is not well-formed utf-8.
Databases react differently: Postgres complains that it's not utf-8 and
refuses to accept garbage (I love Postgres :-) ). MySQL, at least some
versions, just won't check the encoding and store data as a byte array.
Sorting and case insensitivity won't work but at least you can SELECT
everything back unchanged which supports the notion that it "works" :-).
Actually this means that #3370 is safe to include because it's
MySQL-only, doesn't affect byte strings at all because of MySQL's
liberal interface and actually fixes a bug when it receives unicode from
newforms. I'm against it only because it creates this incomprehensible
mess of conventions and edge cases neutralizing each other... #952 is
just a more general way of doing things.
> Well, the current patch in #3370 (I still ignore __repr__) only changes
> the charset attribute of a connection, and this attribute is used only
> to encode unicode strings when sending data to the database, or to
> decode bytestrings received from the database when MySQLdb is configured
> to produce unicode ('use_unicode').
BTW I'm -1 on switching backends to unicode right now because:
1. We should manually decode/encode for backends that can't do it (say,
psycopg1)
2. We immediately get __str__'s returning unicode objects which will
open a can of worms of confusions (and flame wars :-) ).
> I don't see a problem with the generic views since they pass bytestrings
> to the database wrapper, this gets as bytestrings to MySQLdb, and for
> bytestrings the charset attribute is not used at all.
Umm... This is the exact problem with byte strings: that they require
knowledge of a charset somewhere.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
