Re: Python 3
Guido strongly recommends you try to rely on the 2to3 conversion tool to generate the Python 3000 version for a while to come, or suffer having to maintain two code bases. So "porting" should ideally be fixing the 2to3 tool, or tweaking the Python 2.x version of Django so that the tool can do its job... Ideally :-| --~--~-~--~~~---~--~~ 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 Week in Review -- ATTN: Adrian Holovaty
Great work, Clint! These updates are going to be a lifesaver! --~--~-~--~~~---~--~~ 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
On Feb 1, 4:16 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > Ivan Sagalaev: > > > Michael Radziej wrote: > >> d) make the database wrapper accept both unicode and bytestrings in > >> the models, but always pass unicode strings to the database backend. Sounds like a reasonable proposal. You may even consider logging deprectation messages in the case of bytestrings appearing in models (but be careful not to create a flood of these). --~--~-~--~~~---~--~~ 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
On Jan 28, 2:02 pm, "ak" <[EMAIL PROTECTED]> wrote:
> Bjorn, if you read my first messages and specially my patch #3370, you
> find that I made a suggestion that if the guys want to move to unicode
> they better drop all native encodings support and so does my patch.
You mean require all I/O edge/boundary points to convert to/from
Python unicode strings? (We'll of course need to support non-UTF
character encodings in databases, files, the web, etc.)
> Then people started to answer me that this is wrong. And at the moment
> noone is able to explain the whole thing and answer my quesions:
> 1. how do they want to support templates and python code (views/
> scripts) in native encodings if django itself would be all in unicode.
> The only way i see is to encode/decode everything at programmer's end
> and this means for me no native encodings support at all.
Support for Unicode strings (u"") in code is described in PEP-263,
e.g.,
#!/usr/bin/python
# -*- coding: -*-
Unfortunately it's not implemented yet (AFAIK), so you can't just have
unescaped literals:
s = u"encoded text goes here" # doesn't work yet; pending
PEP-263
An alternative for literals in code is to surround them with unicode()
and specify the appropriate encoding:
s = unicode("encoded text goes here", "encoding name")
An even better way is to externalize all strings in .po files and use
gettext, which has some support for returning unicode strings.
I guess templates could have their character encoding identified
either through a similar mechanism, through a global settings
variable, or just use the system default encoding.
> 2. how do they want to support legacy databases if db connection speaks
> unicode
I'm not sure I can follow you. How to configure a database adapter
depends on the database and adapter you're using. Some can accept
unicode strings; for those that don't I guess you'll need a wrapper of
some sort.
Rgds,
Bjorn
--~--~-~--~~~---~--~~
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: QuerySet's __repr__
Malcolm Tredinnick wrote: [...] This seems like a reasonable idea, although I'm not sure if __repr__ is the right place for it or not (and that's something that doesn't interfere with the implementation anyway, so I'm not going to worry much). In principle __repr__ should be the right place (according to how Python defines __repr__), but I understand there could be compatibility issues. I would suggest/prefer holding off trying to get this perfect until the QuerySet rewrite is done (something I am doing). As part of that rewrite, QuerySets will contain a slightly more abstract version of the SQL being constructed -- the SQL string itself will be formed as part of the __str__ method. This removes a bunch of the hackery needed to join queries together and provides some manipulation possibilities we don't have now. The upshot of this for your work is that it will probably be easier to extract a serialised form of the query itself. I'm not sure how much easier/harder it will be to print it out as a Python statement like the above in all cases, but some form of serialisation that will be easy to dynamically reconstruct should be possible. Waiting will probably be better as we (at least I :) won't have to create backwards compatible constructors to QuerySets serialized the old way, which could be non-trivial. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
QuerySet's __repr__
Hi,
I would like to be able to serialize QuerySets for use as "canned"
queries etc, and looking at QuerySet it's currently delegating __repr__
to its data. I was wondering what the feeling would be to change this
to actually return a Python expression that would evaluate to the value
of the QuerySet, for use in serializing etc. E.g.,
>>> a = MyModel.objects.filter(status=3).distinct()[:3]
>>> a_str = repr(a)
>>> a_str
MyModel.objects.filter(status=3).distinct()[:3]
>>> b = eval(a_str)
>>> b
MyModel.objects.filter(status=3).distinct()[:3]
The object b would now be a clone of a. I haven't found a way to
replicate it using filter() and exclude(), but can do it using
complex_filter(), e.g.,
>>> b
QuerySet(model=MyModel).complex_filter( QAnd( Q(), Q(status=3)
)).distinct()
For some reason there's always an empty Q() as the first element of
_filter.
I've attached a tentative patch for django.db.models.query.py for this.
Index: query.py
===
--- query.py(revision 5323)
+++ query.py(working copy)
@@ -94,7 +94,19 @@
def __repr__(self):
-return repr(self._get_data())
+# goal is that self == eval(repr(self))
+model= self.model and "model=%s" % self.model.__name__ or
""
+filters = ".complex_filter( %s )" % repr(self._filters)
+order_by = self._order_by and ".order_by(%s)" %
repr(self._order_by) or ""
+distinct = self._distinct and ".distinct()" or ""
+if self._offset or self._limit:
+start = self._offset or 0
+end = self._limit and self._limit+start or 0
+slice = "[%s:%s]" % (start or "", end or "")
+else:
+slice = ""
+# TODO: support _select_related, _select, _where, _params,
_tables
+return
"QuerySet(%(model)s)%(filters)s%(order_by)s%(distinct)s%(slice)s" %
locals()
def __len__(self):
return len(self._get_data())
@@ -592,6 +604,9 @@
return QAnd(*(self.args+(other,)))
else:
raise TypeError, other
+
+def __repr__(self):
+return 'QAnd(%s)' % (", ".join([ repr(arg) for arg in
self.args ]),)
class QOr(QOperator):
"Encapsulates a combined query that uses 'OR'."
@@ -607,6 +622,9 @@
else:
raise TypeError, other
+def __repr__(self):
+return 'QOr(%s)' % (", ".join([ repr(arg) for arg in self.args
]),)
+
class Q(object):
"Encapsulates queries as objects that can be combined logically."
def __init__(self, **kwargs):
@@ -621,6 +639,9 @@
def get_sql(self, opts):
return parse_lookup(self.kwargs.items(), opts)
+def __repr__(self):
+return 'Q(%s)' % (", ".join([ "%s=%s" % (arg,repr(val)) for
arg,val in self.kwargs.items() ]),)
+
class QNot(Q):
"Encapsulates NOT (...) queries as objects"
def __init__(self, q):
@@ -632,6 +653,9 @@
where2 = ['(NOT (%s))' % " AND ".join(where)]
return joins, where2, params
+def __repr__(self):
+return 'QNot(%s)' % repr(self.q)
+
def get_where_clause(lookup_type, table_prefix, field_name, value):
if table_prefix.endswith('.'):
table_prefix = backend.quote_name(table_prefix[:-1])+'.'
--~--~-~--~~~---~--~~
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: Branch Merges?
Although the http://code.djangoproject.com/wiki/ActiveBranches is better than what we had before, it can still be easier and more clear how to participate. Something like this might work better: generic-auth - Allow for ACL's, role-based systems, and current model-level permissions * Owner: Joseph Kocherhans * Looking for developers * How to participate: 1. Read http://code.djangoproject.com/wiki/GenericAuthorization 2. svn co http://code.djangoproject.com/svn/django/branches/multiple-db-support 3. Coordinate with Joseph Kocherhans to figure out where help is needed multiple-db-support - Add support for multiple database connections * Owner: J. Pellerin * Looking for testers * How to participate: 1. Read http://code.djangoproject.com/wiki/MultipleDatabaseSupport 2. svn co http://code.djangoproject.com/svn/django/branches/multiple-db-support 3. Try it out with your application 4. Report problems to XXX --~--~-~--~~~---~--~~ 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: Branch Merges?
Why not have both a "branch per month" and all branches featured prominently on the home page? --~--~-~--~~~---~--~~ 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: limit_choices_to does not limit list_filter in admin interface
I'd love to see this as well. An alternative is to only show values that are actually in use for the field in the list_filter. This would further reduce the clutter of filters. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Cannot search ForeignKeys that can be null?
Given these two example models and sample data:
class Venue(models.Model):
title = models.CharField("title")
class Event(models.Model):
title = models.CharField("title")
venue = models.ForeignKey(Venue, null=True, blank=True)
class Admin:
search_fields = ('title', 'venue__title',)
>>> whitehouse = Venue.objects.create(title="Whitehouse")
>>> staffmeeting = Event.objects.create(title="Staff meeting",
venue=whitehouse)
>>> onlinemeeting = Event.objects.create(title="Online meeting")
Searching events for "meeting" in the admin interface finds
staffmeeting but not onlinemeeting. Adding list_select_related to the
admin options didn't change anything. Is this a bug or am I missing
something?
We're using r4571.
Rgds,
Bjorn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
James Bennett wrote: > On 8/22/06, Karl Guertin <[EMAIL PROTECTED]> wrote: > > http://www.sqlalchemy.org/docs/adv_datamapping.myt > > Some of these examples deal with rather exotic use cases that, I > think, are close to the edge of what ORM can reasonably do before the > abstraction starts leaking. > > The "map multiple tables to an object", for example, really feels like > something that'd be better handled by a view at the database level. Yes, a lot of things would be better handled at the database level, e.g., inheritance, views, more advanced validation, but it would break database independence. I guess there's more than a few people running MySQL/PostgreSQL as their production and development database, but SQLite (:memory:) as their testing database. > It's something to think about though; if you've got ideas for concrete > implementations that would satisfy relatively common use cases, please > do submit tickets for them. It's unfortunately beyond me. These things are presumably quite hard to get right, and that's why I use a framework. What's a bit dangerous is that I do feel a bit let down if the framework oversold itself in this respect when I 3 months down-the-road discover it couldn't do what I need (thus the rants about "it's all marketing"). To me, what Django got right is a coherent set of core components that work well and feel right together, and that's extremely important. They're not individually "best of breed", but they don't feel as frankensteinish together as some of the other frameworks' components. This is also, btw, what Ruby on Rails got right initially; over time the components improved, and they're now really good. All we need is involvement of experts for each of the tricky components :( I'll add another thing to the wish-list for the framework: database schema/data migration. Rgds, Bjorn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Graham Dumpleton about mod_python
I do remember posting a comment on the Django docs site about mod_python and mpm-worker crashes a while ago, but I cannot find it on the Django site anymore. In any case, we were using mod_python 3.1.3-3. I'm happy to hear it's been fixed in 3.2.8. Unfortunately, even Debian unstable is still at 3.2.7, so I think a warning about this is necessary. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
In China GB18030 is required to be used by law, any most sites just assume the browser uses that as the default, so they don't even specify a character encoding. Your likely setup for international web sites is to have Unicode in the database (since databases have special support for it and it is a good base encoding), but to serve up different encodings wherever UTF-8 proves problematic (for technical or legal reasons). Hopefully, over time, there'll be less and less resistance to using UTF-8. Rgds, Bjorn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Model inheritance redux
Alan Green wrote: > Sure. In this case you would need a discriminator attribute on Place. [...] > I'd be pleased to see Django require discriminator attributes on > superclasses, and then automagically retrieve the correct subclasses > at the correct times. It seems to work well enough in ORMs such as > Hibernate. However, I think I could happily live with Malcolm's > proposal too, even if it means writing code like the above every > now-and-then. Yes, I'm worried that needing polymorphism is the common case, and if it's not blatantly obvious how to do it, people are going to get frustrated, especially if they're used to it working in other ORMs. They're attracted to Python and Django for certain characteristics, and it'll be a bit of a let-down, that's all. So, I understand the technical challenges, and that the design is the most generic and optimized possible, and many people will appreciate this as well. All I'm saying this Alan's descriptor solution better be a Best Practice side note in the docs if it's not an option of the framework itself :) Rgds, Bjorn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Model inheritance redux
Okay, I've got one more question. If we're not going to support
querying for an object's real type, it becomes quite cumbersome to do
anything polymorphically, which kind-of is the point of
object-orientation.
For example, to use the same URI spec & view for all the subtypes.
OPTION 1: lots of if-then-else's
def detail_view(id):
place = Place.objects.get(id)
if place.isinstance(Place): model_name = 'Place'
elif place.isinstance(Restaurant): model_name = 'Restaurant'
...
return render_to_response("templates/place_%s.html" % model_name,
place)
OPTION 2: embed the type in the URI
def detail_view(model_name, id):
... # or map to a different view altogether
Neither seem like very good solutions to me. Am I missing something?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Email address as username
Hi, We'd like to use the email address as the username, but @'s not allowed in usernames. I was just wondering if there's a reason why usernames are restricted to alphanumeric characters only? We could, of course, just store the email address with @'s substituted with some other alphanumeric character instead, but that's a bit hacky. Rgds, Bjorn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Model inheritance redux
Just a question; how does this compare pros and cons with single-table inheritance, used in Rails? See: http://twelvelabs.com/singletable/index.html Rgds, Bjorn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Manipulators going away?
Adrian Holovaty wrote: > You're right -- models will gain validation, and there will be a > helper function/method that returns a data structure that encapsulates > form validation/redisplay (like a Manipulator currently does). That'll > be replacing the current "automatic" manipulators, which I've never > really liked; they were originally intended for use only by the admin > site, not by end users, which explains the problems such as "Why does > file upload not work for the automatic manipulators" and "How can I > use edit inline with the automatic manipulators." Sounds cool. I also thought manipulators were a strange abstraction. Any timeline? :) Would this also take care of the issue I'm having right now that stand-alone validators (not defined inside of a manipulator) only has access to the form data, not the the actual object? I'm trying to detect and prevent cyclic relationships between objects linked together using ForeignKeys, so I need to make sure the object being changed isn't already part of some other list of objects. Rgds, Bjorn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Unicodification of Django
Jacob Kaplan-Moss wrote: > On Jun 28, 2006, at 8:08 AM, Gábor Farkas wrote: > > let's imagine for a second that the unicode-django patch is done and > > available (it's not, but let's imagine it is) > > > > would there be a chance to get it applied? > > Obviously that would depend on the quality of the patch and the > ramifications of its application, but I'd think it's pretty likely > the answer is "yes". What if the patch required everything to be Unicode, meaning: * all programmers would have to become aware of Unicode to some extent * all code would suffer the (minior) performance penalty of encoding and decoding all text If we're not willing to make those two trade-offs, we'll have to support both Unicode and bytestrings, and then we're potentially in a whole different kind of hell that I've seen many systems go. Unicode is a all-or-nothing thing. Rgds, Bjorn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
