Jeremy Dunck wrote:
> While I agree that choices is model-y,
+1. I actually thought that this (displaying CharField with choices as a
type="text") was an obvious bug :-).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gro
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> Adrian, correct me if I'm wrong, but the newforms-admin branch
> currently doesn't have arguments such as choices, editable, and other
> admin-related arguments removed from model fields, correct?
>
> Are they going to be removed? That's what I'm concern
Sorry Jacob, new post here --
http://groups.google.com/group/django-users/t/2bcc79251b693a05
On Apr 13, 12:59 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 4/12/07, sime <[EMAIL PROTECTED]> wrote:
>
> > I'm looking for a talented local programmer to help with a growing
> > workload, on
On 4/13/07, Honza Král <[EMAIL PROTECTED]> wrote:
> the queryset refactoring must (well, should) happen before aggregation
> support. After the refactoring, it should be relatively easy to put in
> the aggregations.
>
> see:
> http://code.djangoproject.com/ticket/3566
Ok; I've had a chance to loo
On 4/12/07, sime <[EMAIL PROTECTED]> wrote:
> I'm looking for a talented local programmer to help with a growing
> workload, on a regular contract basis. All projects in django :-)
In the future, please direct job ads to django-users. Django-dev is
used to discuss the development of Django itself
I have experience working remotely. I'm in southern USA.
Are you looking for fulltime or contract?
--B
sime wrote:
>I'm looking for a talented local programmer to help with a growing
>workload, on a regular contract basis. All projects in django :-)
>
>Or if you have experience working remotely
I'm looking for a talented local programmer to help with a growing
workload, on a regular contract basis. All projects in django :-)
Or if you have experience working remotely that could work too.
--~--~-~--~~~---~--~~
You received this message because you are su
Adrian, correct me if I'm wrong, but the newforms-admin branch
currently doesn't have arguments such as choices, editable, and other
admin-related arguments removed from model fields, correct?
Are they going to be removed? That's what I'm concerned about, not the
Admin class itself. I'm concerned
On 4/13/07, Honza Král <[EMAIL PROTECTED]> wrote:
> the queryset refactoring must (well, should) happen before aggregation
> support. After the refactoring, it should be relatively easy to put in
> the aggregations.
>
> see:
> http://code.djangoproject.com/ticket/3566
I didn't notice this ticket
On 4/13/07, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> I didn't see anything about aggregate support in
> VersionOneFeatures[1], are people still hung up about the syntax, or
> is anyone hacking on this? It's been mentioned a couple times since
> PyCon, but what's the status?
Many proposals have b
On 4/12/07, James Bennett <[EMAIL PROTECTED]> wrote:
> Since it doesn't seem to have come under the axe yet, I'd like to go
> ahead and suggest that 'choices' stay in the model -- we really ought
> to be turning that into a database-level constraint.
While I agree that choices is model-y, I don't
On 4/12/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The options that apply to the admin interface have been factored out
> as options to the admin class. Here's more information:
Since it doesn't seem to have come under the axe yet, I'd like to go
ahead and suggest that 'choices' stay in the
terrific, marked as a duplicate (which is horribly counter intuitive in trac)
~ Anders
On 4/12/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>
> There's already a ticket on this (3512) with a few patches and
> discussion. I would suggest marking your's as a duplicate.
>
> http://code.djangoproje
There's already a ticket on this (3512) with a few patches and
discussion. I would suggest marking your's as a duplicate.
http://code.djangoproject.com/ticket/3512
anders conbere wrote:
> ugh.. forgot to include a link to the ticket I made with my patch in it.
>
> http://code.djangoproject.com
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> Numerous arguments applicable to different fields.
>
> choices, radio_admin, editable, blank and several others.
>
> Some of them have absolutely nothing to do with the model/database
> itself, they exist purely for form/display-related purposes.
Hi jp,
the queryset refactoring must (well, should) happen before aggregation
support. After the refactoring, it should be relatively easy to put in
the aggregations.
see:
http://code.djangoproject.com/ticket/3566
http://groups.google.com/group/django-developers/browse_frm/thread/691da1d6e3b0661d/3e7aaad
I didn't see anything about aggregate support in
VersionOneFeatures[1], are people still hung up about the syntax, or
is anyone hacking on this? It's been mentioned a couple times since
PyCon, but what's the status?
[1] http://code.djangoproject.com/wiki/VersionOneFeatures
--~--~-~--~--
ugh.. forgot to include a link to the ticket I made with my patch in it.
http://code.djangoproject.com/ticket/4024
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
I noticed this today when writing some forms, and whipped up a quick
patch. It could probably use one or two more eyes to look at it. a) so
it doesn't get lost, b) to come up with some better variable names.
The problem is pretty simple, as_p, as_ul and as_table, don't include
an option to pass c
You can create a unicode string in Python like this:
Anymodel.name=u'España'
HTH,
Alex
On Apr 11, 9:06 am, "Saik" <[EMAIL PROTECTED]> wrote:
> Hi people,
>
> Im trying to use the serialize utils in
> django.core.serializers.xml_serialize and
> django.core.serializers.json, i dont have problems u
Numerous arguments applicable to different fields.
choices, radio_admin, editable, blank and several others.
Some of them have absolutely nothing to do with the model/database
itself, they exist purely for form/display-related purposes.
On Apr 12, 1:34 pm, "James Bennett" <[EMAIL PROTECTED]> wr
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> That doesn't make a whole lot of sense to me. I would think that with
> the newforms admin stuff it would be an ideal time to completely
> remove all display-related information from the models. It really just
> doesn't belong there.
What "display-relat
Alright, well now I'm even more confused.
The Admin class is being moved out of the model, but the display
information will remain on individual fields so that newforms can use
it via form_for_model() and form_for_fields()?
That doesn't make a whole lot of sense to me. I would think that with
th
I feel a bit ashamed. I came across a post about the newforms-admin
stuff and one of the prime goals is to move the admin information out
of the model.
Yay! I guess I will be writing my code with that in mind from here on
out.
On Apr 12, 12:50 pm, "jp" <[EMAIL PROTECTED]> wrote:
> Oh, in additio
Oh, in addition I was wondering what the 'right' way to do this would
be at the current time?
On Apr 12, 12:48 pm, "jp" <[EMAIL PROTECTED]> wrote:
> Today I needed to do something perhaps not entirely uncommon. I wanted
> to create a form that contained elements from both the User model as
> well
Today I needed to do something perhaps not entirely uncommon. I wanted
to create a form that contained elements from both the User model as
well as the UserProfile object I had attached to it.
At this point, I had an option. I could either define a completely
separate new form that had fields rel
> Hmm. Aren't objects with __del__ attributes rare in pure python, or
> is there some other way you're thinking the gc couldn't collect the
> cycle?
Well, you don't know how are they rare indeed. Though, weakrefs are
simple and safe.
--~--~-~--~~~---~--~~
You re
On Apr 6, 3:31 pm, "Jonas Maurus" <[EMAIL PROTECTED]> wrote:
>
> If it can be changed, I'd also like to see only one comment style: {#
> [text] #} with the {##}-notation supportingmultiple-linecomments. {%
> comment %} can either get continued support or be deprecated.
>
> I don't agree with the c
On 4/12/07, Christopher <[EMAIL PROTECTED]> wrote:
> File "C:\Python25\lib\site-packages\django\db\backends\postgresql
> \base.py", line 12, in
> raise ImproperlyConfigured, "Error loading psycopg module: %s" % e
> django.core.exceptions.ImproperlyConfigured: Error loading psycopg
> module:
On 4/12/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
>
> One thing - if you alias the top context at the top level, You'll end
> up with memory leak - there will be a circular reference. It can be
> avoided, if the context variable would hold a weakref.ref to the top
> context.
Hmm. Aren't objec
One thing - if you alias the top context at the top level, You'll end
up with memory leak - there will be a circular reference. It can be
avoided, if the context variable would hold a weakref.ref to the top
context.
On Apr 12, 5:04 pm, "Max Derkachev" <[EMAIL PROTECTED]> wrote:
> Well, you can al
Well, you can alias a top-level context in a context variable, and
then set the variable in that aliased context.
class AliasContextNode(template.Node):
def __init__(self, varname):
self.varname = varname
def render(self, context):
context[self.varname] = context.dicts[0]
hi,
as i read that pep, relative imports are not deprecated at all, they
just will require a new syntax in 2.8.
i advocate the use of relative imports, in cases like newforms as well
as in "user-space" apps, due to the possibility of name changes: sooner
or later, newforms will just be called for
On 4/12/07, Christopher <[EMAIL PROTECTED]> wrote:
First off - User queries (like this one) should be directed at
Django-users, not Django-developers. The developers list is for
discussion of the internal development of Django itself.
That said...
> I have no idea what has gone wrong but here i
I have no idea what has gone wrong but here is what I have.
Python 2.5
Django (latest from SVN)
Psycopg 2.0.5.1 (for Python 2.5)
PostgreSQL 8.2
Windows XP Professional
I am trying to run Manage.py syncdb and keep getting:
django.core.exceptions.ImproperlyConfigured: Error loading psycopg
module:
Hi,
The subject of this discussion should of course be "Relative or
absolute imports", sorry for the typo. The mentioned relative import
of util is just an example since other modules in newforms are
imported in a relative fashion too.
Thank,
Rudolph
--~--~-~--~~~-
Hi,
Some newforms modules contain some "relative" imports of the
newforms.util module. Is this intentional behavior or should we use
absolute imports? As far as I know absolute imports are preferred
because they are less likely to conflict with other modules. I think
relative imports are even dep
Yeah, I (briefly) considered that many people would probably want
their own set of message categories but didn't spend much time trying
to develop a solution because my patch works for what I need. A very
simple solution could be to define a choices tuple in settings.py with
a few default message
38 matches
Mail list logo
