Gary Wilson wrote:
Jacob Kaplan-Moss wrote:
> On 12/24/06 11:15 PM, Gary Wilson wrote:
> > Well, the two tickets are different functionality. I could create a
> > single patch for both, the only thing was that in the patch for #3180 I
> > added an "Updating objects&qu
code and tests attached, requesting eyes...
http://code.djangoproject.com/ticket/2756
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develope
Russell Keith-Magee wrote:
I just tested this on SQLite, and it fails with:
OperationalError: no such column: false
Ok, I added a new patch [1] that uses where 0=1 instead of where false.
This seems to work with postgresql, mysql, and sqlite.
[1]
http://code.djangoproject.com/attachment/ticke
Ok, after getting sidetracked by update() and update_or_create(), back
to the topic of the OP. Here are some options:
1) Add a get_or_none() method that returns None if object does not
exist.
2) Add a get_or_default() method that accepts a "default" keyword
argument, the value of which gets r
James Bennett wrote:
> Unfortunately, I don't really have a good proposal for how to handle
> this, except maybe to further break down the Widget API to include
> 'as_html' and 'as_xhtml'. Any ideas?
I still think that all these "strategies" do not belong in the BaseForm
class. Using a strategy
I like the ideas Joseph.
While we are naming backends, let's also use the backend name to key
the backend information in the session data (see [1]) so that different
backends can be used for different areas of your site.
Maybe something like the value of session['_auth_user_backend']
becoming a
Adrian Holovaty wrote:
Hello all,
I'd really like to streamline the way we interact with our ticket system, Trac.
We've fallen behind on managing tickets, which is not only frustrating
to contributors but a hindrance to Django's growth, as solid
contributions are made but eventually get lost i
I got signed up yesterday. A coworker and I plan on showing up wed.
night and staying through the 2nd day of sprints. Will be my first
PyCon and first sprint, can't wait!
I assume the sprint will be focusing on stomping as many bugs as
super-humanly possible?
--~--~-~--~~
FYI, this is being talked about too:
http://trac.edgewall.org/ticket/153
http://trac.edgewall.org/ticket/1459
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send e
On Dec 24 2006, 9:35 pm, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
On 12/24/06 4:50 PM, Gary Wilson wrote:
>> I have created a ticket for this too and have attached some code:
>>http://code.djangoproject.com/ticket/3182
> Documentation and tests attached too now.Hm
Patch attached with documentation fixes, requesting review.
http://code.djangoproject.com/ticket/685
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to
http://code.djangoproject.com/ticket/3134
Bringing discussion to the list...
I would also say that all the date based generic views should have the
same behavior, but I'm not sure if that should be making all the date
based views take an order_by parameter, or to just make archive_year
act like
Russell Keith-Magee wrote:
On 1/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Trac's non-feature of not automatically sending changes to the reporter
> (which follows from not requiring a valid reporter email) doesn't help
> here, either.
I'd always wondered about this.. er... featur
patch attached and tested, requesting review.
http://code.djangoproject.com/ticket/3259
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develo
Robert Myers wrote:
> Only one tiny remark, the closed tickets use to show up with a
> strike-through, possibly a missing css param?
Oops, Robert beat me to it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Djan
Jacob Kaplan-Moss wrote:
> I'm about to roll out an upgrade to our Trac installation on
> code.djangoproject.com. We're adding a few features to make our internal
> management of ticket workflow better (some of you many have the thread about
> this on django-developers over the past week or so).
On Jan 18, 11:31 am, telenieko <[EMAIL PROTECTED]> wrote:
Maybe the WikiStart could be locked down so newcomers don't get confused? It
does not need to be changed that much ;)
Or at least set some guidelines for it. It seems to get more cluttered
by the day. I would like to see some of those
[EMAIL PROTECTED] wrote:
Many of these have working patches and are ready to go, but I'm
wondering if we want to proliferate the number of field types? I think
that adding too many of these is just adding clutter ( e.g.
EthernetAdress vs. IPAddress vs. CIDR etc ) and especially since a
CharField
Michael Radziej wrote:
Jeremy Dunck wrote:
> Michael, I see that ticket was closed as invalid because it needed to
> pass tests.
>
> If I understand the triage process correctly, it should have been
> marked accepted, but with has_patch=1 and patch_needs_improvement=1.
Yeah, your're basically r
simonbun wrote:
If editable=False is specified in the model, then I personally would
expect it not to show up in the form_from_model form either.
On the other hand, I'm not so sure that the need to differentiate the
editable option between the admin contrib and plain form_from_model is
so gener
James Bennett wrote:
> Joseph and I were kicking around some ideas over lunch today, and one
> thing that seemed like a good idea was moving back to the old-school
> 'admin as Meta attribute'. Under this scheme, django.contrib.admin
> would define a default class for model administration.
This so
SmileyChris wrote:
> On Jan 19, 2:29 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > > (At least, I cannot reopen from closed/invalid)
> > Very interesting - it looks like that action is being hidden from
> > non-authenticated users... I'll investigate.
>
> How's the investigation going? I'm
On Jan 24, 11:03 am, "vfoley" <[EMAIL PROTECTED]> wrote:
> one thing that bugs me about URL patterns is that you can specify a
> prefix only for the view functions to call, not for the URLs to match.
[snip]
> urls.py:
> urlpatterns = patterns('', prefix_url='project/',
> (r'^view/(?P\d+)/$', 'mypr
On Jan 20, 10:00 am, "Joseph Perla" <[EMAIL PROTECTED]> wrote:
> Have you already decided on a simple, fast, non-deprecated, standard way of
> extending the User model?
This has been talked about a few times, but nothing concrete yet. I
think one of the more popular ideas was to create a user in
On Jan 24, 2:50 pm, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote:
> Really nice work, congratulations! ;)
Yes, good work everyone! It at least appears that there is more
activity in the ticket system now ;)
--~--~-~--~~~---~--~~
You received this message becau
"For models with file fields (FileField/ImageField etc.) save() is
called twice on manipulator form submission"
Possibly causing duplicate objects to be created in the database.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
link for the lazy:
http://code.djangoproject.com/ticket/639
--~--~-~--~~~---~--~~
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 unsub
see http://code.djangoproject.com/ticket/3012
--~--~-~--~~~---~--~~
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 th
a shiny new title.
--~--~-~--~~~---~--~~
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 [EM
On Feb 2, 5:29 pm, "Daniel" <[EMAIL PROTECTED]> wrote:
> I would like to implement this as an extension of the existing auth
> code. Is there any interest in a trunk patch to achieve this? If so,
> any suggestions on best practices?
I would suggest taking a look at ticket #3011 (and its attache
On Feb 2, 3:13 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote:
> * A test case that tries to demonstrate it isn't a dupe of #2076 and trying
> to justify a reopen.
FYI, there are a couple other tickets needing reopening too:
http://code.djangoproject.com/query?status=closed&keywords=%7Ereopen&
On Jan 30, 8:37 pm, Vadim Macagon <[EMAIL PROTECTED]> wrote:
> A two line change to BoundField will do the trick, I can submit a patch
> if desired.
I would suggest filing a ticket so that your suggestion and patch
don't get forgotten.
http://code.djangoproject.com/simpleticket
--~--~-
On Jan 30, 9:36 am, "noahz" <[EMAIL PROTECTED]> wrote:
> I ran into the same issue recently, and I got to thinking... Are
> validators going to go away when manipulators do?
I believe they are going away, in favor of creating custom subclasses
of Field and using its clean() method to validate.
>
On Jan 31, 3:23 am, "Honza Král" <[EMAIL PROTECTED]> wrote:
> the ticket has been accepted I am only waiting for decision on whether
> to prepend an empty choice ("", "--") or any suggestion on other
> ways of doing that...
In /django/db/models/fields/__init__.py, line 20 there is
# The value
On Jan 26, 1:41 pm, "J" <[EMAIL PROTECTED]> wrote:
> I am trying to wrap my head around the server firepower I would need to
> pull this latter idea off.
The following might give you some idea:
http://wiki.rubyonrails.com/rails/pages/Framework+Performance
http://www.jacobian.org/writing/2005/dec/
On Feb 3, 5:04 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Filtering with javascript isn't too much needed, but the edit_inline
> with javascript is a cool thing I want to see in django that doesn't
> break backward compatibility. As I said, I can make this improvement
> on the django ad
On Jan 26, 11:04 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 1/26/07, medhat <[EMAIL PROTECTED]> wrote:
> > So many times I send messages to the group, but my message does not
> > appear at all, or it might appear a day or two after I actually send
> > it, which of course makes it appear
On Feb 1, 1:34 pm, "Sebastien Armand [Pink]" <[EMAIL PROTECTED]> wrote:
> Hi everyone,
Welcome!
> I'm not used to contribute to free softwares and don't really know how to!
> But I've had to change a part of Django for personnal use: I wanted a model
> field like CharField(choices=...) to become
On Jan 30, 8:21 am, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote:
> 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,
On Jan 31, 7:58 pm, "Joseph Perla" <[EMAIL PROTECTED]> wrote:
> Along the lines of get_or_create(), does it make sense to implement a
> get_or_set() function for quick caches?
For the sake of discussion, there is a ticket with similar goals, but
only for QuerySets:
#5 - Add a cache=NUM_SECONDS ar
On Feb 8, 10:22 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> I'd like to see more inline documentation of the code. Some .py files
> have this but some don't. Just an overview of what the file does, how
> things are organized, maybe some concrete examples via doctests.
> Something for the avera
On Feb 8, 5:28 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> # set the current line number to 3
> line_number = 3
>
> But this kind of stupidity is exactly what documentation metrics reward.
I 100% agree that comments such as these are worthless.
> Thats not to say that document
On Feb 8, 5:35 pm, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> Should I file a bug to eventually use hashlib for >= Python 2.5?
> Should I provide a patch which attempts to import hashlib and use it
> if available, but otherwise falls back on md5/sha1?
Yes, file a bug so the idea is not forgotten.
I have opened a ticket about it:
#3463 - EmptyQuerySet's iterator() method does not return a generator
http://code.djangoproject.com/ticket/3463
Please review.
Thanks,
Gary
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
google ate "[4394]" off of my subject
--~--~-~--~~~---~--~~
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
On Jan 29, 4:25 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> b = Blog.objects.get(id=1)
> for entry in b.entry_set.all():
> entry.blog is b # True
So what if the blog with id=1 changes in between accesses? What if I
had
b = Blog.objects.get(id=1)
[ I do some other things
On Feb 8, 10:12 pm, Vadim Macagon <[EMAIL PROTECTED]> wrote:
> Gary Wilson wrote:
> > google ate "[4394]" off of my subject
>
> Err, no it didn't.
Only in the web display I guess, which is what I use.
--~--~-~--~~~---~--~~
Y
On Feb 8, 9:27 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Tell us where we need more comments.
This is possibly one:
http://code.djangoproject.com/ticket/2256
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gro
On Feb 8, 9:27 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> It's not like there has been a conscious effort to _not_ comment code
> - if there is an area that is lacking inline documentation, its
> because whoever checked the code in thought it _was_ obvious (at the
> time, at least). Po
On Feb 8, 10:57 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> (although it might be an idea to have a 'code cleanup' category for
> reporting inline comments and bad/inefficient coding idioms).
+1
--~--~-~--~~~---~--~~
You received this message because y
On Feb 6, 3:47 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Any ideas on how to proceed and diagnose this would be greatly
> appreciated.
You would probably have a better chance for a response by posting your
issue in the django-users group:
http://groups.google.com/group/django-users
-
On Feb 8, 11:10 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Does anyone else have any thoughts on this?
Oh, and I forgot to mention that there is a similar ticket wanting the
same thing for select_related:
Ticket #17 - Metasystem optimization: Share select_related in memory
http://code.d
On Feb 10, 3:36 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Do we need an "enhancement" resolution, or some other way of saying
> "some day, maybe"? The benefit of this is keeping the very low priority
> stuff out of the queue of things needing attention. Then we can point
> enthusiastic b
On Feb 12, 9:01 am, "RonnyPfannschmidt" <[EMAIL PROTECTED]>
wrote:
> in some case the only way to do it right is a replacement (like using
> a mail as username)
You would probably be interested in ticket 3011, which aims to make
the auth User model replaceable. There is even a patch to get you
s
Added fix and regression tests, could someone please review.
http://code.djangoproject.com/ticket/3465
Gary
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send em
As an example, ticket 3123 was re-opened and the stage remained ready
for checkin. I think it would be better if the stage was reset to
unreviewed when the ticket gets reopened. Thoughts?
Gary
--~--~-~--~~~---~--~~
You received this message because you are subs
On Feb 14, 8:54 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> I'm wondering if maybe get should raise an error with a name like
> "MultipleValueError" rather than "AssertionError" when multiple values
> are found...
+1
--~--~-~--~~~---~--~~
You received this mess
On Feb 14, 8:54 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> I'm wondering if maybe get should raise an error with a name like
> "MultipleValueError" rather than "AssertionError" when multiple values
> are found...
Ticket and patch created:
http://code.djangoproject.com/ticket/3511
--~--~-
What's the plan for 0.96? I know of a few patches that are waiting
for post-0.96 to break backwards compatibility. Jacob mentioned a
release coming in a week or so in his Moving towards Django 1.0 post,
but that was now 5 weeks ago. Since PyCon is next week, is the plan
to use that sprint time
On Feb 17, 3:58 pm, "Honza Král" <[EMAIL PROTECTED]> wrote:
> On 2/17/07, oggie rob <[EMAIL PROTECTED]> wrote:
> > > I find it useful to have the {% for %} tag syntax extended so that one
> > > can write:
> > > {% for a,b in L %} meaning the obvious thing
>
> +1
+1
The {{ x.0 }} syntax is simply
On Feb 19, 8:49 pm, "juampa" <[EMAIL PROTECTED]> wrote:
> I have noticed the following situation and I suspect it may be a
> problem:
Juan, could you please open a ticket about this problem.
http://code.djangoproject.com/simpleticket
Thanks,
Gary
--~--~-~--~~~---~--
On Mar 1, 7:10 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I've tried several times to attach files of a sample project and sql
> dump to Ticket #3613 several times, and trac keeps throwing an
> error does one need special permissions to do this? ( I'm using
> firefox. )
What's the
On Mar 2, 6:38 pm, "Simon G." <[EMAIL PROTECTED]> wrote:
> Can you drop by code.djangoproject.com and create a ticket for this,
> so we don't lose trac (sorry) of it.
Actually, we already have one:
http://code.djangoproject.com/ticket/3579
I have also referenced this thread in the ticket so that
On Mar 2, 7:38 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> If you think this really should work and you can reproduce it, you
> should consider reporting this problem to the Trac team.
Could you attach the file here? I could try my luck and open a ticket
with the Trac project if it fail
On Mar 2, 10:24 pm, "Simon G." <[EMAIL PROTECTED]> wrote:
> I thought #3579 was more of a generic thing, but well spotted Gary!
Yes, I just changed the title to, what I think, better convey the
intention of poster of the ticket.
--~--~-~--~~~---~--~~
You received
reposting what I put in this ticket: http://code.djangoproject.com/ticket/3626
put note on the "Create New Ticket" page about how to format code
A good percentage of the tickets that come in are not using {{{}}}s in
their ticket descriptions to format. Could we please add a note about
this in th
On Mar 8, 10:09 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-03-08 at 04:09 -0800, Simon G. wrote:
> > Good Evening Djuggernauts,
>
> > I've spent some time looking over the email related tickets in Trac,
> > and think I've got them sorted out a bit. I'm hoping to spur some
> >
On Mar 8, 10:09 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I haven't read the patches closely, but my immediate concern is whether
> we are duplicating too much of Python's existing mail framework and just
> wrapping it. That would be bad design. I have no opinion on this yet.
Speaking o
Jure Čuhalev wrote:
> I was receiving same error. The problem happened when I tried to
> upload a file that was gzipped. After attaching plain-text patch it
> worked. I have a session with my name inside trac.
>
> Hope this helps in debugging.
The problem is with Trac:
http://trac.edgewall.org/
Jeremy Dunck wrote:
> Do people think it's worth doing?
Have you seen the (accepted) object-level caching summer of code project?
http://code.google.com/soc/django/appinfo.html?csaid=EFBF229544BAC5D0
--~--~-~--~~~---~--~~
You received this message because you are
Kevin wrote:
> The generic views use RequestContext (was DjangoContext) and that
> requires request.user be set.
RequestContext doesn't necessarily require request.user to be set.
RequestContext just runs through all the TEMPLATE_CONTEXT_PROCESSORS,
which includes django.core.context_processors.a
Rock wrote:
> Finally, I agree that the name get_aggregate(s) kinda sux but I still
> haven't come up with anything better.
Sending to list this time, sorry Rock...
Throwing these into the mix:
Inventory.objects.aggregate(['AVG','MIN','MAX'],'quantity')
Inventory.objects.calculate(['AVG','MIN',
I like the idea of shorter comment syntax. The current way is just too
ugly and inhibiting.
{! Comment !} -- Similar to HTML comment.
{# Comment #} -- Similar to Python comment.
Since Django templates use Python-ish language in the {}'s, I say {# #}
is better.
I see a striking resemblance...
I think it would be nice to have the authentication backend
configurable per app instead of project-wide. This way, I could use an
LDAP backend for the app that my users use, and use the builtin backend
for the admin app.
--~--~-~--~~~---~--~~
You received this m
Should contrib app tests go in that particular contrib app's directory
as opposed to the global tests directory?
Should we make Django's test runner look for and run all "tests"
packages/modules within the Django tree? Or maybe just those in
django.contrib?
Gary
--~--~-~--~~---
Man, I really need to remember to always use email when posting to these
django lists. Too many of my web posts never show up. And here I
thought the internets was a truck I could just dump stuff on.
Malcolm Tredinnick wrote:
> On Sat, 2007-05-19 at 00:16 -0500, Gary Wilson wrote:
>>
I would like to request comments/suggestions about a few patches I have
submitted recently for the newforms library that solve some issues that
I encountered during the development of some newforms.
#3718 - newforms.Form.clean should have access to field errors [1]
#3896 - pass value to field spe
Malcolm Tredinnick wrote:
>> #3718 - newforms.Form.clean should have access to field errors [1]
>
> I'm not sure what this really gains. Fixing the second part of #3896
> means that all the necessary information is in cleaned_data. I'm -0 on
> this, because I feel it's pretty pointless, merely pr
Craig wrote:
> I have noticed that when using the admin site (which is really nice,
> by the way), the date and time fields have a nice js widget to fill in
> the current date and time, but it uses localtime, not UTC time. Our
> database we store all time fields in UTC, and having the web page us
[EMAIL PROTECTED] wrote:
> I don't want to attempt to pollute Django's beautiful template library
> namespace with garbage, but I do see a legitimate value for a
> linebreaksli template filter.
A more general solution might be to have a linebreakstag filter that
takes arguments:
{{ mytext|lineb
Getting back into the swing of things...
Paul Collier wrote:
>> If I update o1 in some other part of the
>> code, what assumptions are made about qs?
> Hmm, yeah... I haven't focused enough attention on .cache_set() yet,
> heheh. I was definitely just going to implement (1) first, and then
> worr
Tai Lee wrote:
> I've been using my own messages in sessions for a while now and every
> message i send is either "good", "bad", or neutral (neither good nor
> bad). these three states are very generic and cover every type of
> message i need to send. at present i display good messages in green,
>
Russell Keith-Magee wrote:
> Any feedback (especially objections to committing) would be
> appreciated.
First, great work! I think all the kiddies will like it. Won't be long
before Django has a Scriptaculous widget set, I bet :)
Are we fine with having two ways to add media?
The two methods
Ben Ford wrote:
> Peter,
> I ran into this problem when I was bringing the multi-db branch up to date
> and was so busy I forgot to tell anyone! (My bad) I fixed it, but it was on
> another machine. It's a pretty simple change, but the exact diff escapes me
> at the moment! Is there a ticket on th
Brian Harring wrote:
> On Wed, Jul 11, 2007 at 09:38:54AM -0500, Deryck Hodge wrote:
>> For example:
>>
>> mkdir repos
>> cd repos
>> bzr init
>> svn co http://code.djangoproject.com/svn/django/trunk/ django_trunk
>> bzr add django_trunk
>> bzr commit
>>
>> Then you can bzr branch from there to ha
James Bennett wrote:
> On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> I'm biased, because I have an immediate need for this in a project,
>> but this seems general and useful enough for inclusion in QuerySet.
>
> Implementing the check in __nonzero__ and having people test by doing
> '
Mario Gonzalez wrote:
>After I saw your link I read the FAQ and there's something caught
> my attention: "have added all features that we feel are necessary to
> earn a 1.0". Are those "features" the open tickets?
No, not all of the open tickets anyway. There will _always_ be open
tickets n
Czubakabra wrote:
> Hi,
> Include tag is vulnerable to directory traversal:
>
> {% include "/etc/passwd" %}
It's a bug and not intended behavior. I've opened a ticket and have
attached a patch.
http://code.djangoproject.com/ticket/4952
Gary
--~--~-~--~~~---~--~--
SmileyChris wrote:
> On Jul 22, 6:21 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> It's a bug and not intended behavior. I've opened a ticket and have
>> attached a patch.
>>
>> http://code.djangoproject.com/ticket/4952
>
> I've pu
SmileyChris wrote:
> On Jul 23, 3:53 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> SmileyChris wrote:
>> I think the patch looks good. Can someone please confirm that the
>> latest patch works ok on Windows.
>
> I guess you mean apart from me? ;)
You would
SmileyChris wrote:
> PS: I can't patch your diffs because they don't use the format which
> TortoiseSVN accepts and the win32 build of patch falls over on it too.
> How are you making them?
I'm making my diffs with Bazaar, using "bzr diff". My unix patch seems
to handle them ok. Sorry about th
Adrian recently corrected some of my docstring additions [1][2], and I
am posting this to the list so that we can get an official stance on the
matter. I also suggest we add the decision to the "Coding style"
section of the "Contributing" documentation for consistency of future
patches, since
On Jul 27, 12:47 pm, Sebastian Macias <[EMAIL PROTECTED]>
wrote:
> I just added it to the wiki:
>
> http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyApp...
I don't think you meant to have the exact same directory structure for
a django project as you did for 3rd party apps, did y
I brought the patch back in sync with trunk, and would like to make a
call for some eyes, as this is a big, mostly boring, patch. I don't
want to let this one get 6 months out of date again :)
Thanks,
Gary
--~--~-~--~~~---~--~~
You received this message because y
Jacob Kaplan-Moss wrote:
> Seems that making the change outright would annoy a whole host of
> people... IIRC, we'd decided to deprecate max_length and issue
> warnings... does that sound right?
The patch actually still keeps maxlength around, raising an error only
if both max_length and maxlengt
Russell Keith-Magee wrote:
> #3297 - FileField/ImageField for newforms
> http://code.djangoproject.com/ticket/3297
+1
> #4001 - saving m2m fields on newforms with commit=False
> http://code.djangoproject.com/ticket/4001
-1
The save_m2m() seems a bit weird to me too. Sometimes it's there,
some
James Bennett wrote:
> Let's just do:
>
> 1. Autoescape on by default.
> 2. Autoescape is turned off by the {% autoescape off %}
> 3. Autoescape happens irregardless of what the template's source file
> or source string happened to be named.
Is it done yet?
--~--~-~--~~~
Jacob Kaplan-Moss wrote:
> On 7/30/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> That sounds like the best thing to do -- I don't see a huge need to
>> deprecate maxlength immediately, or even issue warnings about it. The
>> change gets a +1 from me.
>
> I'd say that making maxlength issue a
Adrian Holovaty wrote:
> This is a nice, clean approach -- good work! The patch is looking
> good. Go ahead and check it in at your leisure.
Checked in as http://code.djangoproject.com/changeset/5803
--~--~-~--~~~---~--~~
You received this message because you are
Ash wrote:
> What would be the point in opening a ticket when this clearly broken
> behavior gets marked as 'wontfix'?
>
> http://code.djangoproject.com/ticket/4981
I believe SmileyChris meant that a ticket should be opened about
updating the documentation.
> The documents for Django newforms s
101 - 200 of 286 matches
Mail list logo
