I'm now tuning my project at work and resolve_variable shows up
alarmingly high in profiled data. I'm thus very eager to look at this
fix and will try it this Monday or Tuesday and will try to fix any
unicode problems.
> Examples would be lovely; that particularly patch proceeded the
> unicode me
Sorry for not replying for past 2 days, Google caught a bounce from my
mail host and stopped to send new mails :-(
I just saw that Adrian has now commited the "response" part so unified
patch is not needed anymore. I'll update "request" patch for new lines
count (and try to fix code styling issue
kmh wrote:
>Or we could have an update() method that took multiple arguments like
>the constructor.If two fields do depend on each other for validity
>then it makes sense that you can't set them separately.
>
>
This makes sense. However setting several fields at once is only one of
the pro
Maniac wrote:
>The concept of always keeping object in a correct state is indeed very
>nice but makes some practicle cases really harder.
>
>
I want to share an experience working with Delphi's VCL (library of
visual components) where this thing was solved in a very con
Adrian Holovaty wrote:
>* Specifically, validation happens on Model.__init__() and
>Model.__setattr(),
>
Ouch... Last time this was discussed this was considered bad thing (I
may be mistaken) because this doesn't allow any intermediate non-valid
state for an object which nonetheless may be usef
Russell Keith-Magee wrote:
>How about putting all the essential configuration items at the top of
>the generated settings.py, with an obvious 'border' that marks
>'optional, but possibly useful configuration options below this line';
>e.g.,
>
This looks reasonable to me... In fact I don't know if
Adrian Holovaty wrote:
>So the question is, do we give the generated settings.py file all the
>possible settings, or does it continue to have just the settings that
>are commonly changed? I really could go either way on this.
>
>
It's good that current settings.py looks small. This adds to the
limodou wrote:
>please see another thread to see what I really want, what I want not
>just READ but WRITE and SAVING.
>
>
This is exactly what I meant. You can use your own config format, read
it, write it and save it. Settings.py would just import its data for the
rest of the Django.
--~--~
limodou wrote:
>I'v summited a ticket http://code.djangoproject.com/ticket/1337 for this.
>
>What do you think about?
>
>
You can store settings in any format right now and use settings.py as a
parser:
from my_parser import my_parse
values=my_parse('my_config.ini')
locals().up
Maniac wrote:
The recent message from Luke Plant on generic views call syntax got me
thinking. Now one should pass a model's queryset into a generic view.
This means that urlconf should import all models used in generic views
which would become an annoying boilerplate if you use
The recent message from Luke Plant on generic views call syntax got me
thinking. Now one should pass a model's queryset into a generic view.
This means that urlconf should import all models used in generic views
which would become an annoying boilerplate if you use them extensively.
Another u
Adrian Holovaty wrote:
So what did we decide to change from the current proposal at
http://code.djangoproject.com/wiki/DescriptorFields ? I got lost. :)
The best I can conclude is that the only difference with this page is
that people don't like the ".all()" thing and want Manager to behave
Russell Keith-Magee wrote:
From my context, Article.objects() constructs a basic query that knows
how to return all object instances of type Article, which can then be
filtered to produce more complex query objects. The idea that there is
a single basic query which everyone should use doesn't r
Joseph Kocherhans wrote:
http://code.djangoproject.com/wiki/ModelInheritance
This is still really rough. I hope I didn't leave too much out. Let
the arguing commence ;-)
If the last bit ("Change the current usage of subclassing") is only
about removing inherited attributes why not do it th
Jacob Kaplan-Moss wrote:
If I ask for places, give me a list of places and don't bother
looking up restaurants. So:: ``place_instance.description`` should
raise an ``AttributeError`` regardless if weather or not it is
actually a restaurant.
Why? This is not how duck typing works all ov
Joseph Kocherhans wrote:
Have you started on this yet maniac?
Not yet. And actually can't predict when I'll be able to :-(. So feel
free to implement the idea if you like. Please post here a ticket number
to track the thing.
Adrian Holovaty wrote:
p = Poll(pub_date=request.POST.get('pub_date'),
question=request.POST.get('question'),
num_votes=request.POST.get('num_votes'))
Some automation is needed for this. Currently automatic manipulators can
deal with copy of POST dict themselves.
Adrian Holovaty wrote:
Looks like a good solution to me. I kind of liked Max's idea of
"app('django.contrib.admin')", but maybe YAGNI on that. Let's do the
dictionary thing, assuming it's cool with Jacob as well.
I hope I'm not late yet...
I kinda don't like all proposed solutions for they
Jeroen Ruigrok van der Werven wrote:
Makes sense given the recent push for making the Django core UTF8.
No, recent push is to make Django core Unicode (arrays of 2-byte
normalized characters). Django now is in UTF-8 (Unicode encoded to be
passed as single-byte strings) and this is the exact
hugo wrote:
Looks like a typo: DEFAULT_ENCODING there is actually DEFAULT_CHARSET?
Yep. Fixed it. But you could have fixed that yourself, it's a wiki ;-)
Will do next time. I didn't have much experience with public wikis and
thought I need some special authorisation to correct someth
hugo wrote:
I think that Django should support(use only) python unicode strings.
http://code.djangoproject.com/wiki/UnicodeInDjango
Looks like a typo: DEFAULT_ENCODING there is actually DEFAULT_CHARSET?
Adrian Holovaty wrote:
I like this a lot! SimpleContext is good...Other thoughts?
I'd say BaseContext. It's now just a base class for other actually
useful contexts.
Adrian Holovaty wrote:
You can get started, if you're willing to use the magic-removal branch. :)
The event system is in that branch, in django.dispatch.
Ok. I'll get to it as soon as I could kill some more lines from ToDo on
my desktop :-)
Maniac wrote:
- auth app using event system hooks to the save event for models
- auth middleware populates request.user and also keeps the user for
itself in some warm private place
- on model's save it looks in its Meta for fields that should be
populated and does it
Wait, there&#
Adrian Holovaty wrote:
I don't see a need to add this functionality for use beyond the scope
of the admin site.
Well... I can recall more than one request in django-users :-). And this
feature is pretty commonplace...
The auto_now options aren't coupled to a request,
so they're a special c
Joseph Kocherhans wrote:
Create a ForeignKey field that references
django.contrib.auth.models.User or whatever. This field cannot be
editable=False, or the manipulator will skip over it when you save the
object. Exclude the field from your admin screens using the fields
attribute of the new inn
Luke Plant wrote:
This is important:
http://www.w3.org/2001/tag/doc/whenToUseGet-20030709.html#i18n
There is a note in that text saying that when encoding is unknown
browsers may use the encoding that was used for outputting the form.
Which they really do.
But as I understod Hugo's note
hugo wrote:
http://code.djangoproject.com/wiki/UnicodeInDjango
It mentions that HTTPResponse should do unicode -> DEFAULT_ENCODING. I
think that HTTPRequest should do backward translation. Or am I missing
something why it shouldn't?
Ivan Fedorov wrote:
I think now is good time to do this work. We already have many backward
incompatibitilies in magic-removal branch. So I'm think that we can add
one more.
You mean total unicodization? As far as I understand it's not
incompatibilities that hold this change but complexity.
Ivan Fedorov wrote:
I think that Django should support(use only) python unicode strings.
For example, at this time django can't capitalize russian strings, when
site charset is utf-8...
There is a patch fixing this bug in
http://code.djangoproject.com/ticket/924 waiting for... something? :
Adrian Holovaty wrote:
I've been wanting to make the "core" and "auth" models optional for
installation, effectively removing the "django-admin.py init" command
and requiring people to install "core" and "auth" explicitly.
I'd say I'm against it. I don't know of any stats but my feeling is t
Robert Wittams wrote:
reporter.articles
reporter.articles.filter(headline__startswith='This').order_by('headline')
reporter.articles.add(headline="John's second story",
pub_date=datetime(2005, 7, 29))
?
The only objection I can think of is that such property notation implies
the notion th
hugo wrote:
2) I really, really dislike the
Person.objects.get_list(Person.q.first_name == 'Adrian')
+1
Adrian Holovaty wrote:
http://code.djangoproject.com/wiki/RemovingTheMagic
Please comment here rather than on the wiki.
My concern is not about removing the magic, but you described a change
to using connection and cursors that I'm concerned about.
Right now Django has some problems with
Jacob Kaplan-Moss wrote:
* The fix solves the visibility problems, solves naming issues, and
makes importing crystal clear. Inheritance is quite unrelated to this
as are mixins.
Jacob, sorry for misunderstading... I've reread Adrians original
proposal but still can'r get it. Could you exp
James Bennett wrote:
Any way of implementing this is going to require you to specify
*somewhere* which GET parameters are relevant to caching a particular
view, and it'd be hard to implement that directly in the view syntax
(since not everyone will be using caching). The proposed decorator
does
James Bennett wrote:
Except it's a decorator, so it's right there with your view code.
But still you have to blindly copy strings from code to decorator
parameters.
Jacob Kaplan-Moss wrote:
This sounds like the right idea to me: explicitly state which GET
params invalidate the cache.
So when the view's code change during development one should alsways
remember to update this invalidators list. Not very DRY :-(
jws wrote:
My ticket was closed - http://code.djangoproject.com/ticket/470
I'd like to clarify the reasoning, since I think it pertains to a
larger issue. My understanding of Adrian's comment is that there
currently is no infrastructure in Django to escape special characters
in strings in a wa
Amit Upadhyay wrote:
Consider http://code.djangoproject.com/ticket/398 for example.
It looks like a good idea to me, patch is there, so is some discussion
and suggestions, but activities ended 3 months back and from ticket
there seems to be no idea if its being considered or what.
But publi
Simon Willison wrote:
The other one is database table names. I would argue that since these
are almost /never/ directly exposed in Django itself, they should be
left as singular as well (just the name of the model class casted to
lower case. If we wanted to be really radical we could leave
This email from Beorn:
Beorn wrote:
Ruby's more extensive skeleton isn't all bad: Ruby generates a lot of
empty directories that actually "sell" the notion that this is a
framework that can grow with you and has best practices for testing,
documentation, using AJAX, logging, staging, where to
Simon Willison wrote:
a = request.GET.as_int('a')
Looks like I will be the one breaking the party :-)
I don't like this idea for two reasons.
The first is simple: it makes code ugly and much less readable. I had
this experience with Delphi where you have always do something like
Table.Fie
hugo wrote:
They are done in new_admin. No need to do the work twice :-) - As soon
as new_admin hits trunk, the admin is much more complete with regard to
translation.
Cool!
BTW: If you are interested in translation work, join django-I18N, as
that's the place where translation discussions
There are a whole lot of strings in core/formfields.py that aren't
translated with _(). Is there some reason why it's not done or it should
be done?
I probably will make it anyway for my project and I wonder if a patch
with this would be desired?
Bill de hÓra wrote:
* Change django-admin.py so that the various commands that act on apps
-- such as sql, install and sqlreset -- take the *full app name* (e.g.
"myproject.polls") instead of the name of the Python module that holds
the models. This would have the following subtle side effect:
Eugene Lazutkin wrote:
Care to share these reasons or provide a link to reasons you support?
Unfortunately all this client-server separation is a marriage of
convenience, which is mostly created by network speed. Trust me: as network
speed grows, client-server separation will be less defined.
Adrian Holovaty wrote:
I've been using XMLHttpRequest for years now. My chicagocrime.org
site, powered by Django, uses Ajax in several places
(chicagocrime.org/map, for one). Django made this very easy. Yet I
still can't fathom what "Ajax support" at the server-side-framework
level *means*.
Adrian Holovaty wrote:
I see two solutions:
- generate new session key when processing request immediately if there
is no cookie
I don't see this as a viable solution, because that would require a
database hit for every request that doesn't have a session -- which
isn't good for performa
Hello!
I recently discovered some annoyances in sessions middleware which I'd
like to fix. But first I prefer to here from you if this is desirable.
1. Session key is generated on save, not on creation.
This means that Django may expose the working and usable session to the
user which nonet
Jacob Kaplan-Moss wrote:
Server error page: http://toys.jacobian.org/django/500.html
This one is fantastic! I hope now I will use those 'raise str(myvar)'
lookups mush less.
Jacob Kaplan-Moss wrote:
So, any objections to starting a 1.0 bug-fix-only release branch?
No objection but a concern...
Some time ago I filed a ticket
(http://code.djangoproject.com/ticket/570/) about FormWrapper not
working for ForeignKey fields. It's rather basic functionality and I
co
Nebojša Đorđević - nesh wrote:
3 IIRC, same as Serbian.
There are 3 declensions but actually different forms of declension are
more (including nouns, adjectives etc).
Three forms, special cases for numbers ending in 1 and 2, 3, 4,
except those ending in 1[1-4]
In Russian it's slightly
Robert Wittams wrote:
It would of course be another option. But not a particularly good one.
It means that when you change the template, someone has to merge the
changes into all the other languages. You will almost certainly end up
with your logic out of sync in different templates.
Nightmare.
Robert Wittams wrote:
See new-admin branch or ticket #598. It just needs to be applied to trunk.
Great!
Also, be aware that you can extend a template whose name is in a variable.
Funny :-). Thanks for showing this!
Hi!
Django's template system encourages extension of base templates as a
mechanism of template reuse. However simple functionality for inclusion
templates is still needed. Here's the example.
I have a web application for manipulating images. It has a central
interface part (one Django view)
Robert Wittams wrote:
This is fixed in the new-admin branch. I've forgotten how this actually
worked in the admin before (as you say, it looks for the wrong member),
but it works for all ForeignKey fields ( in both admin and user views)
in that branch.
Robert, is there any estimated time whe
Jacob Kaplan-Moss wrote:
However, please note that there are two of us with commit privileges,
and almost 200 open tickets; please be patient!
Thank you for clarification!
Hi!
I'm a little confused about practices of working with Trac in Django
community and decided to ask here.
First, some history:
Some time ago I made a patch for ticket 440
(http://code.djangoproject.com/ticket/440) introducing a new config
parameter for default charset. This parameter was
59 matches
Mail list logo
