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
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 un
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 ma
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
On Jan 28, 4:03 am, "ak" <[EMAIL PROTECTED]> wrote:
> After some thoughts I came to the following conclusion: if you guys
> want to keep support of legacy charsets in fact you don't have to
> force model objects too be unicoded. Firstly, they are passed to
> templates and filters and we can't mix
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 (a
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 Que
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: Jose
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-
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 Goo
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 = ('
GinTon wrote:
> I have seen that for web applications is best far using a ODBMS:
>
> 1- Objects in an OODBMS can store an arbitrary number of atomic types
> as well as other objects. The fact that an OODBMS is better suited to
> handling complex,interrelated data than an RDBMS means that an OODBMS
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 leakin
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 a
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
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 suc
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
Joseph & Malcom, thanks for the comments. Just wanted to make sure I
could stand my ground in the face of Rails-istas :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gr
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 ch
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
"
I was wondering if anyone has made a field for managing hierarchical
data in Django?
For example, a TreeField that manages "parent" relationships and gives
the model parent and children object managers:
class Category(model.Model):
tree = TreeField()
>>> a = Category()
>>> b = Categor
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'v
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 o
I submitted a ticket about this (I believe) 2 weeks ago:
http://code.djangoproject.com/ticket/1658
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
Could you make it available as a patch against the latest magic-removal
branch?
--~--~-~--~~~---~--~~
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@googl
Hi all,
Is there any work underway to implement more than two-levels of inline
editing in the admin interface? I.e., Company/ Department/ Team/
Person in one interface?
I see this talk about 'new-admin' so I'd thought I'd ask.
Rgds,
-- Bjorn
26 matches
Mail list logo
