Model icons

Hi all, Recently, it's trend to use icons or emoji before menu items and I like this idea because IMHO people orient better and more quickly when they see picture. What about to add this feature to native django? I thought the easiest way would be to add new Meta option to Model. The default

Re: Model icons

Yeah, I've tried to create templatetag like this: @register.simple_tag def get_module_icon(model, app): if app == 'auth': if model == 'Groups': return '' elif model == 'Users': return '' elif app == 'core': elif model == 'Generations':

Re: Model icons

I really like the idea to add just a simple 'icon' attribute. That's quite elegant solution. Thanks, Mark! 🙂 On Monday, February 20, 2023 at 2:33:43 PM UTC+1 Jacob Rief wrote: > I agree with Adam Johnson that adding HTML to the model class is a bit too > coupled. > But I like the idea of Mark N

Filtering chosen options

Hi, Is there a reason why there is a filter only at available options but not at chosen options in this multiple select widget ? I would appreciate filtering even chosen options. 🙂 Thanks. -- You received this message because you are subscribed to the Goo

Re: Filtering chosen options

tage, for final release around 2023-04-03. > > On Friday, 24 March 2023 at 03:20:41 UTC+1 Marty wrote: > >> Hi, >> >> Is there a reason why there is a filter only at available options but not >> at chosen options in this multiple select widget >> <https

Password reset link is not displayed by default

Hi, this is native django 4.2 code: *admin/login.html* ... {% csrf_token %} ... {% url '*admin_password_reset*' as password_reset_url %} {% if password_reset_url %} {% translate 'Forgotten your password or username?' %} {% endif %} ... ... *auth/urls.py:* ur

Re: Password reset link is not displayed by default

Hi, ah, I see. Okay, thanks for info and link. Marty On Monday, July 24, 2023 at 2:00:44 PM UTC+2 Adam Johnson wrote: > Hi! > > You've found the wrong mailing list for this post. This mailing list is > for discussing the development of Django itself, not for support usin

Re: FileStorage and folders

Alexey wrote: > I wonder, why is there no folder creation functions in Storage and > FileStorage classes? Because none of Django's features really required it. > I ask this not because I don't know how to create it mysef. I'm just > curios, why there are only one function for working with folder

Re: Adding signing (and signed cookies) to Django core

I'm obviously going to weigh in here, having authored the signed cookies app you mentioned below, but be aware I'm not a cryptographer, nor do I have any personal use for signed cookies at all. I can appreciate their value, but I'm not even using my own app in anything, so if there are problems wi

Re: Adding signing (and signed cookies) to Django core

On Thu, Sep 24, 2009 at 2:54 PM, Simon Willison wrote: > Hmm... I hadn't considered that. I was thinking that the unsigning > could be transparent, so by the time you access request.COOKIES['key'] > the value had already been unsigned (and if the signature failed the > cookie key just wouldn't be

Re: Adding signing (and signed cookies) to Django core

> Also, does the name of a cookie factor into the cookie length limits? > My reading of RFC 2109 says yes, but it'd be worth verifying, since it > would cut down on the usable value space. With your compressed base64 > stuff, that's not as big of a problem, but still something to look > into. Als

Re: Adding signing (and signed cookies) to Django core

On Thu, Sep 24, 2009 at 3:22 PM, Benjamin Slavin wrote: >> response.set_cookie('key', 'value', sign=True) >> - results in a Set-Cookie: key__Xsigned=value header > > Unfortunately, this approach won't work. > > A malicious client can just send "key" rather than "key__Xsigned" and > you'll never k

Re: Adding signing (and signed cookies) to Django core

On Fri, Sep 25, 2009 at 7:02 AM, Luke Plant wrote: > Suppose one part of an app signs an e-mail address for the purpose of > an account confirmation link sent in an e-mail.  The user won't be > able to forge the link unless they know HMAC(SECRET_KEY, email). > > However, suppose another part of t

Re: Adding signing (and signed cookies) to Django core

On Fri, Sep 25, 2009 at 9:26 AM, Simon Willison wrote: > The API would look something like this: > s = signed.sign('value', timestamp=True) v = signed.unsign(s, expire_after=24 * 60 * 60) > > A SignatureExpired exception would be raised if the signature was > older than the expire_after

Re: Adding signing (and signed cookies) to Django core

On Fri, Sep 25, 2009 at 10:42 AM, Simon Willison wrote: > On Sep 25, 3:39 pm, Simon Willison wrote: >> While that makes sense for caching, I couldn't say if it makes sense >> for signatures or not - when we sign something, will we always know >> the point at which we want that signature to expir

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Mon, Oct 12, 2009 at 12:09 PM, Jeremy Dunck wrote: > Also, I bet Marty knows this area well from his book work. Actually, I didn't research much on the initialization process as a whole, if there indeed is such a beast. I started with what happens when Python actually encounters

Re: Call for feedback: django.utils.signed and signed cookies

nce the key can play double-duty. If there's a concern with collision with other keys, we could always prefix it with 'django_cookie_' or something before applying it, but I don't think that'd be a necessary step. -Marty -- You received this message because you are subscribed to

Loading Backends

even there. Unfortunately, I can't dedicate much of my own time at the moment to look into this, but I think it'd be worth doing before we start adding even more features with configurable backends in the future. -Marty -- You received this message because you are subscribed to the Google

Re: Loading Backends

On Mon, Dec 21, 2009 at 10:46 AM, Simon Willison wrote: > On Dec 21, 2:22 pm, Marty Alchin wrote: >> Looking over Simon's patch for signed cookies, I noticed that yet >> another feature needs to write its own "load a backend from a setting" >> function. >

Re: Porting Django to Python 3

2010/1/14 Łukasz Rekucki : > It is possible to write 3.x code that is backwards-compatible with > python 2.6+. There are some rough edges like, names of stdlib modules, > instance checks for strings and some introspection details. In my > opinion, it's pretty much the same as supporting old 2.x pyt

Re: Porting Django to Python 3

On Thu, Jan 14, 2010 at 2:32 PM, Karen Tracey wrote: > Martin's approach was single codebase where the 3.x version for execution is > generated by 2to3, not single source for execution across 2.x and 3.x.  Thus > I'm wondering if this difference is accounted for by 2to3?  If yes, then it > is not

DurationField update

umentation, but I'd appreciate any feedback or additions. It's also a good example of the ideas I've been having for type coercion, and it works in concert with my recent patch for #3982. I'd especially like feedback on this aspect of it, to see if this is a reasonable way to appr

Re: Field.contribute_to_class and contrib fields

has already been initialized within the context of that field. Currently I'm having to call it every time __get__ is called, which can't be a good thing. That's not a problem with the patch as is, of course, just a difficulty I'm having in getting it to work with other Field sub

Re: Field.contribute_to_class and contrib fields

its instantiating to a method on the field, which > can do extra initialisation. Hrm, very interesting. So the srid magic happens every time a new object is instantiated with __get__, as well as every time a new object is set directly, but never when just retrieving a previously cached object.

Re: django-values update

on them and hope to have them ready sometime next week. I'd also add documentation to this list. I know I wrote up a good bit on the Google Code wiki, but I don't think it would fit very well with Django's existing docs if it were taken verbatim. I don&

Re: django-values update

ent version of the app. I would definitely recommend that process to anyone else looking to write a contrib app for Django, as it makes it much easier for the eventual audience to try it out in real-world projects. I got suggestions and requests for things I never would've considered if I had

Re: Changing django.contrib.auth to make passwords optional

eant it, but it might be worth being clear on the subject, especially if the process gets documented for the sake of future authentication authors. I'm probably just splitting hairs though, so disregard as necessary. -Marty --~--~-~--~~~---~--~~ You received thi

Re: django-values update

the application, though, so that they can > safely write "from my_chosen_app_name import ..." And if I had done that from the start, I would've been forced to come up with a better (or at least, more original) package name than "values". Anybody got a time machine? -Mart

Re: Proposed Field API additions

to find them all, some other form of registration would probably be better. -Marty -- 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

Re: finding the source of "interesting" SQL queries

gs, **kwargs), self) So in short, we comment the SQL with the URI when it's available, and fall back to the (presumably more expensive to gather) traceback information when it's not. This is just the monkeypatch we're throwing in to solve our immediate problem, but it'd be

Re: finding the source of "interesting" SQL queries

' */']) On Wednesday, October 24, 2012 12:14:49 AM UTC-5, Àlex Pérez wrote: > > You are modifying the settings on runtime , that practise is not > recommended by django and personally i have had bad experience with that... > El 24/10/2012 00:26, "Marty Woodlee"

Re: finding the source of "interesting" SQL queries

something oriented towards that instead. It may take a while--priorities--but I'll post back here when I come up with something. Thanks! On Thursday, October 25, 2012 10:06:51 AM UTC-5, Anssi Kääriäinen wrote: > > On 25 loka, 17:52, Marty Woodlee wrote: > > Yeah, I don'

Re: Problem with ``Model.objects.create``

nk it should" gets confused with "X doesn't work the way it should" or even "X doesn't work." If you have a constructive argument for how you think it should work that can be implemented in a way that doesn't break compatibility with other people's code,

Re: Extending templates dynamically

ecides is appropriate. That said, if you have questions about using {% extends %} in this way, it's probably best to take it to django-users instead. -Marty -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this gr

Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

On Wed, Jun 4, 2008 at 1:21 PM, Aral Balkan <[EMAIL PROTECTED]> wrote: > Unfortunately, I don't think your ticketing system likes me. I'm > getting: 500 Internal Server Error (Submission rejected as potential > spam). Right on the new ticket screen, under the big heading labeled "Read this first"

One more issue with file storage

Hey all, I've been fairly quiet on the file storage front for a while, since it's basically done now, and is just waiting on the streaming upload ticket to hit trunk first. Since I got to that point, however, I've had two different people, working on two different storage backends, both approach

Re: RFC: Django 1.0 roadmap and timeline

I like it, but mainly that's because I'm not the "maybe" list, and I'm sure I can get it done in time. I do have one suggestion, though. On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > * "Maybe" features: things that *should* be in 1.0 and should be worked on > i

Re: RFC: Django 1.0 roadmap and timeline

On Thu, Jun 12, 2008 at 7:06 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > I think that this is a must-have: > > #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff Then you'll be glad to know that it's #3 the list of "Must-have features" in Jacob's email, just a bit below the portion you quoted. -Gul

Re: One more issue with file storage

On Fri, Jun 13, 2008 at 8:48 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I've been implementing a flexible file storage system for Django for > my own use (hacked in on top of the existing file field) and would be > happy to make this code available if you have any interest in it. I > hones

Re: Django community aggregator and non-English posts

This whole thing reminds me of something I've had rattling around in my head for a while, and maybe now's the time to bring it to the group. In addition to the language of blog posts, I've often had a hard time tracking down information from past conversations that have happened in the community.

Re: Django community aggregator and non-English posts

On Fri, Jun 13, 2008 at 1:23 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > There is existing multi-lingual aggregator http://djangosearch.com/ I didn't realize djangosearch broke articles down by language, complete with individual feeds! Looks like that's one problem down. Combine that with Jaco

Re: Djangochatter [WAS: Django community aggregator and non-English posts]

On Fri, Jun 13, 2008 at 1:23 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > Ugh, time. I have a bad habit of assuming I have more of that > resource available than I ultimately do. :) I'd definitely like to > help, but I don't think I could assume a driving role at this point. > (Chicago Djangonaut

Re: Djangochatter [WAS: Django community aggregator and non-English posts]

On Fri, Jun 13, 2008 at 1:38 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > Hey, it helps me segment my incoming mail. ;) It's always about *you* isn't it? ;) > Google Groups makes new mailing lists trivial. Although this may all > be moot if that djangosearch site pans out as useful. Well, I'd s

Re: Django 1.0 roadmap

On Mon, Jun 16, 2008 at 11:15 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > As requested, I've also added milestones for 1.0 alpha, beta, and > final (as well as a "post-1.0" catch-all). Triagers, feel free to use > these milestones thusly: > > * Any *feature* tickets related to the maybe lis

Re: Django 1.0 roadmap

On Mon, Jun 16, 2008 at 2:17 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Mon, Jun 16, 2008 at 12:43 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: >> * Leave them as they are, and just tell whoever commits #5361 to >> reference them in the commit message.

Django book seeking Tech Reviewer

Hey all, First, I apologize for posting this on django-dev, since I know it's not development *of* Django, but I didn't want to add to the noise on django-users, and most of the people I'm hoping to reach are frequent readers of this list. No need to flame, I got it. As most of you are no doubt

Re: Call for testing: streaming uploads (#2070)

On Thu, Jun 26, 2008 at 3:14 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Hi folks -- > > As far as I'm concerned, #2070, adding large streaming uploads, is > done. I'd like to get some public kicking-of-the-tires before I push > the change to trunk (which won't happen before Tuesday: I'm

Re: More secure user password reset

On Fri, Jun 27, 2008 at 8:31 PM, Simon Willison <[EMAIL PROTECTED]> wrote: > I've got code for this lying round which I'd be happy to donate if > people agree this is the right approach. I personally much prefer this approach. I've worked in a couple communities where personal attacks were quite

Re: Community representation, or, #django user "Magus-" needs to go far away

On Wed, Jul 2, 2008 at 12:55 AM, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > actually this debate belongs on django-users (which is why I put in > my 2 paise) - I think if taken there we can get a real measure of the > pros of his help against the cons of his curtness at times (I > wouldn't cal

Re: Ticket #7591: Authenticate By Email Support

On Wed, Jul 2, 2008 at 1:24 PM, Paul Kenjora <[EMAIL PROTECTED]> wrote: > Reasons why an alternate backend or view is not good: > 3. Maintaining my own back end, means others are doing the same, again poor > re-use. Not if you: 1. Write it well 2. Distribute it freely 3. Make its presence known

Re: Ticket #7591: Authenticate By Email Support

On Wed, Jul 2, 2008 at 2:56 PM, George Vilches <[EMAIL PROTECTED]> wrote: > On Jul 2, 2008, at 1:24 PM, Paul Kenjora wrote: > >> I understand the resistance but you've got demand, you've got a >> willing developer, and you've got a clean fix that significantly >> improves the adaptability of the f

Re: UploadedFile API changes (was: Is it UploadedFile.chunks() or .chunk() ?)

On Thu, Jul 3, 2008 at 12:22 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I just talked about this with Mike on IRC; I think chunk() is > non-obvious and we're gonna change it to chunks(). Hopefully nobody's > written so much code in the last week to be pissed. > > Also, we're going to chang

Re: UploadedFile in cleaned_data

On Thu, Jul 10, 2008 at 4:46 AM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > I've seen already two people highly confused with this thing. After > successful validation of a form with file upload > form.cleaned_data['fieldname'] contains an instance of a wrapper -- > newforms.fields.UploadedFile. P

Re: Will oldforms completely go after 1.0?

On Thu, Jul 10, 2008 at 12:35 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > It'll be a badge of honor/experience. "I used Django back when forms > was called newforms!" Yeah, and everybody at DjangoCon can have a little icon on their name badges that indicates how many backwards-incompatible c

Re: One more issue with file storage

On Thu, Jul 10, 2008 at 2:52 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Sorry for the late reply. I meant to look at this awhile ago but it > slipped off my plate for a bit. Looking at the latest patch > (filestorage.16.diff) it does look like a similar approach the main > differences comi

Re: Test Suite on a mac

On Thu, Jul 10, 2008 at 3:23 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote: > So I'm a linux user, but I have a MBP. I was playing with the django test > suite a while back, and some test failed on my mac but would succeed on any > of my linux machines. After discovering the django buildbot, I thoug

Re: Add a helper function in UploadedFile's API for writing files on disk?

On Fri, Jul 11, 2008 at 4:14 AM, Julien Phalip <[EMAIL PROTECTED]> wrote: > Not sure if we're talking about the same thing here. What I ask is if > it'd be a good idea to have a generic method for UploadedFile which > lets copy/move the file to where ever you want. These method would > have to be

Re: API change in set_cookie for 1.0?

On Tue, Jul 15, 2008 at 7:49 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > I was using HttpResponse.set_cookie for the first time and annoyed > that expires has to be a properly-formatted string. > > Why not take a datetime and do the formatting in the function? > > Obviously this is a breaking ch

Re: Last call for 1.0 alpha

On Mon, Jul 21, 2008 at 11:37 AM, Tom Tobin <[EMAIL PROTECTED]> wrote: > Gah, I really haven't had time to do the > move-code-out-of-__init__-modules dance. I'm fairly certain that > it'll be completely backwards compatible (via re-importing back into > __init__), though, so I'm not too worried;

Model method decorators

On Thu, Jul 24, 2008 at 9:54 AM, zvoase <[EMAIL PROTECTED]> wrote: > Developers, > I've just looked at the latest revision (r8068) for Django and there > are a couple of things I'd like to suggest. I've already replied to part of this email, but I'd like to take a minute to also reply to the othe

Re: Denormalisation, magic, and is it really that useful?

On Mon, Sep 22, 2008 at 4:03 PM, Andrew Godwin <[EMAIL PROTECTED]> wrote: > So, I'd love people's opinions about where I should take this - to a > dark corner and hide it, to a separate app like django-extensions (which > involves keeping the horrid hacks in there), into a separate app but > with

Re: Denormalisation, magic, and is it really that useful?

On Tue, Sep 23, 2008 at 8:44 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > This appears to be a proposal to re-implement triggers inside Django. I suppose it is. But then, perhaps triggers were a re-implementation of application-based denormalization. ... The chicken? The egg? The world may never

Python 2.6 abstract base classes

Looking over the new things in Python 2.6, I wonder if there are plans to inherit from any of the new abstract base classes in Django. It looks (to me) like it could be backwards-compatible, using an import like so: try: from collections import Sequence except ImportError: # Fallback for

Re: Python 2.6 abstract base classes

On Fri, Oct 3, 2008 at 7:34 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Trendy might be superficially appealing, but I personally felt 2.6 would > have been just as useful without the ABC backport. Actually, I don't find it particularly appealing myself. The PEP specifically states that it isn'

Re: Python 2.6 abstract base classes

On Fri, Oct 3, 2008 at 9:48 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Think "interfaces". Given that you wrote the file storage stuff and are > no doubt aware that we still have lots of fuzzy issues where something > may or may not be able to be used where a Python file object is used, >

Re: Python 2.6 abstract base classes

On Fri, Oct 3, 2008 at 10:39 PM, Eduardo O. Padoan <[EMAIL PROTECTED]> wrote: > IIRC, the file-ABCs are in the new `io` library. Ah, indeed. I was looking for something called "File" or similar, not IOBase. :) -Gul --~--~-~--~~~---~--~~ You received this message

Re: Lazy-loading model fields

I won't pretend to know the whole story here, but I will take issue with some of your points. I'll leave others to people who have history on the subject. On Tue, Oct 14, 2008 at 3:14 AM, Jesse Young <[EMAIL PROTECTED]> wrote: > * If you split them out, you have to manually create one model every

Re: Lazy-loading model fields

On Tue, Oct 14, 2008 at 12:34 PM, Jesse Young <[EMAIL PROTECTED]> wrote: > A LazyTextField that manages a dynamic model behind the scenes sounds > like a neat idea. That would certainly make the Django side of this > easier to manage. (But of course I have a slight bias towards code > that exists

Re: Final(ish) 1.1 feature list

The biggest issue is that we can't edit anything. There's no "Edit Page" button, and when I manually add "?action=edit" to the URL, it gives me an editor form, but upon submission, I see the culprit: 403 Forbidden (WIKI_ADMIN privileges are required to perform this operation). Any hope of getting

Re: Final(ish) 1.1 feature list

]> wrote: > On Tue, Nov 25, 2008 at 10:34 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: >> >> The biggest issue is that we can't edit anything. There's no "Edit >> Page" button, and when I manually add "?action=edit" to the URL, it >

Re: Final(ish) 1.1 feature list

Thanks, guys. All that just to delete a question mark from my name after signed cookies. :) -Gul On Tue, Nov 25, 2008 at 12:04 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 25, 2008 at 11:02 AM, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: >> Ok, the page is now editable. >

Re: Custom Fields API Cleanup

On Tue, Dec 16, 2008 at 1:03 PM, Jacob Kaplan-Moss wrote: > This seems like a good idea to me, and an easy one to implement; I'm > all for it. Are there any backwards-compatibility concerns here? It > doesn't look like it -- we're just talking about adding a new hook to > SubFieldBase, right? My

Re: Custom Fields API Cleanup

On Tue, Dec 16, 2008 at 2:02 PM, David Cramer wrote: > Could we just use a lazy proxy for the value value? When it's executed, it > could then just call the get_value_from_db method (or whatever). I expect that the lazy approach is what most people would really want, so I'd be fine with that. I

Signed Cookies Status

In light of the upcoming feature completion deadline for Django 1.1, I'd like to take a few minutes to mention where the signed cookies application stands right now and some of my thoughts about its inclusion in django.contrib. The code itself is done. I made a few minor updates to it last week to

Unicode filenames

While working again with files for model validation, I realized (and confirmed with Russ, Honza and Alex in IRC) that the tests put in as a fix for #6009[1] don't actually prove all the behavior that ticket refers to. They prove that Unicode filenames come through fine from uploads, but that test

Re: Unicode filenames

On Thu, Jan 15, 2009 at 10:33 AM, Marty Alchin wrote: > While working again with files for model validation, I realized (and > confirmed with Russ, Honza and Alex in IRC) that the tests put in as a > fix for #6009[1] don't actually prove all the behavior that ticket > refers to

Re: Model-validation: call for discussions

I haven't been following everything, but I do have a couple comments to make here. On Fri, Jan 23, 2009 at 8:04 AM, mrts wrote: > works both for forms and models with the proposed approach (all_values > is model_instance.__dict__.copy() in model field validation case). One thing to consider is

Re: reason for missing readline() in uploaded files?

I suppose I should probably weigh in over here. For those who don't know, I worked on much of Django's file handling, refactoring FileField, adding storage options and standardizing the File interface across models, forms, storage and uploads. If there are methods missing, I'm almost certainly the

Re: MarkupField

I haven't looked too much at the patch, so I can't comment much on the implementation yet, but reading your description and the ticket, I'd to offer some thoughts, based on some of my own thoughts I've had on this in the past. First, I don't think you actually addressed the question mentioned in

Re: Non-primary key AutoField

On Sat, Feb 28, 2009 at 11:27 PM, NewSpire wrote: > First, this restriction is not there in the database.  Auto-increment > fields do not have to be primary keys.  Imposing this restriction > could cause a problem when trying to use legacy tables in a Django > environment.  Is there a compelling

Re: (Discussion) Ticket 9986: CACHE_BACKEND argument name doesn't match code

On Mon, Mar 30, 2009 at 1:25 PM, Kurt Grandis wrote: > cull_interval or cull_period would absolutely be the most accurate > description in terms of the algorithm's operation. My contention is that > parameter name would be confusing to all but those who have seen the actual > underlying culling a

Re: Bug or feature: pre_save used on FileField/ImageField doesn't work as in Django 1.0.2

On Thu, Apr 2, 2009 at 11:45 AM, Karen Tracey wrote: > I think it's a bug, and I'm pretty sure it was introduced by r9766.  The > setting of the actual file name that will be used (which pulls in the > upload_to path and possibly tacks on some underscores if the uploaded name > conflicts with al

Re: Bug or feature: pre_save used on FileField/ImageField doesn't work as in Django 1.0.2

On Mon, Apr 6, 2009 at 1:16 PM, Karen Tracey wrote: > We cannot know for sure what the file name is until it is saved to disk, as > the save operation may tack on underscores when handling race conditions. > Thus we cannot delay file save to a field pre_save routine and report the > guaranteed co

Re: Django 1.1 update

On Thu, May 7, 2009 at 6:43 AM, Jacob Kaplan-Moss wrote: > Once this is done we'll be down to blockers for 1.1; many of us at the > sprint are focusing on these. More help will be appreciated! I just wanted to add a note here that may have some impact on which tickets get punted vs. fixed in 1.1

Re: Django 1.1 update

On Thu, May 7, 2009 at 8:34 AM, Jacob Kaplan-Moss wrote: > Ugh, I really hate not being able to just assign files to fields. It > just feels hacky and wrong to call instance.file_field.save(). It'll > also break a bunch of code folks have written over the last few > months. I know, no backwards-c

Re: r9766-related issues

nt in with too little thought on the subject (entirely my fault, not passing blame), and I don't want to make that same mistake twice. It's not a regression in and of itself, but the feature is broken, all the same. > (Marty also mentioned at one point he had some other ideas on how

Re: r9766-related issues

On Thu, May 7, 2009 at 12:05 PM, Armin Ronacher wrote: > I'm working with Alex on that right now here in Prague.  We have some > branches on github related to that.  Basically the idea is to start > with getting rid of some of the over engineering in the abstract base > classes and make sure the

Re: r9766-related issues

On Thu, May 7, 2009 at 3:43 PM, Armin Ronacher wrote: > On May 7, 5:37 pm, Karen Tracey wrote: >> #10249: can't create consistent MRO (method resolution order) when assigning >> a File to a FileField. > This is fixed. I was reading over the patch Alex mentioned in IRC (yay for DjangoBot's logge

Re: Posting to the wrong list (was: Re: Need Django Developer urgent)

On Fri, May 8, 2009 at 7:05 AM, Jacob Kaplan-Moss wrote: > """ > Discussion group for Django developers. This group is used for > discussion of developing Django itself, not user questions; Please use > django-users for issues regarding using the framework, questions for > the Django user communi

Re: r9766-related issues

On Mon, May 11, 2009 at 8:45 AM, Armin Ronacher wrote: > All bugs are fixed now except for #10788.  Now the problem with > closing that one is that this one requires a design descision.  I > updated the ticket accordingly for jacob or anyone else to decide on > it.  My personal opinion is that I

Re: DurationField, request for help and comments

Okay, I'm finally back around looking into this situation, and I have to say I'm not thrilled with the direction it's currently headed. I've never liked the "1h 30m 10s" syntax in any situation I've ever encountered it, and I highly doubt that it will be meaningful to much of anyone. That's person

Re: DurationField, request for help and comments

On Tue, May 26, 2009 at 2:16 PM, Jerome Leclanche wrote: > Right now, removing months and years is a matter of removing two lines > from the patch. I didn't want to write a patch just to get told "it's > lacking months/years!"; I'm also in favour of dropping it and > following Python's style; but

Re: Template Caching

I won't speak to most of this, since Russ and Jacob have said it all, but I do want to respond to one point. On Thu, Aug 6, 2009 at 3:55 AM, Russell Keith-Magee wrote: >> By simply checking that the template has a ``render`` method in >> ``get_template``, we get the added benefit of allowing user

Re: Field.contribute_to_class and contrib fields

en't figured out a way around that one yet. -Marty --~--~-~--~~~---~--~~ 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

Re: Field.contribute_to_class and contrib fields

On 5/18/07, Robert Coup <[EMAIL PROTECTED]> wrote: > What about having a _first_set attribute on the proxy object that only > allows laziness for the first time the value is set (ie. when it is set > from the DB row)? Then any later set()s get live validation and coercion > to geos objects. I sub

django-values -> django-policy?

Django-values has had a long and rocky road thus far, with its name not being the least of its problems. I finally put it to the masses in a recent blog post, and I got back the simplest word I'm amazed I didn't think of: policy. Organizations are very familiar with the idea of policies and proced

newforms-admin "plugins"

In working with my recent contrib saga, I've been looking a bit into newforms-admin, since it's going to be merged someday, and it looks like it would give me some better options. However, one thing I was hoping for doesn't seem to be there. For my policy work, I'd like to be able to add in a sep

Re: newforms-admin "plugins"

On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Aren't you asking the wrong question here? The real issue seems to be > "how is admin going to handle arbitrary Field classes that it doesn't > otherwise know about?" Well, I'm not worried about Field classes. DurationField, for instance

Re: django-values -> django-policy?

On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > My understanding of the module is that it doesn't enforce rules and > procedures and that is certainly what I think of policy as being,too. Your understanding is correct. It doesn't do any enforcement of any rules, but simply provides va

Re: newforms-admin "plugins"

On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > It seems that "extra" things on a model in whatever form they may take > are either instance-specific, in which case they are Field sub-classes > -- for database-backed data -- or methods, or they are model-specific > (e.g. django-values'

  1   2   3   4   >