Re: Enhanced debug output colors: django code is green, user code is red.
I'm not sure about the exact colors, but the visual distinction is a big plus in my book. One possible place to document it would be in the information regarding the TEMPLATE_DEBUG setting here: http://docs.djangoproject.com/en/dev/ref/settings/#template-debug - Gabriel On Nov 2, 2:03 pm, Dougal Matthews wrote: > 2009/11/2 Yuri Baburov > > > > > > > > > Hi All, > > > Since you are discussing and applying different features, > > > I think it's time to ask what do you think of the subj. > > > It's athttp://code.djangoproject.com/ticket/11834 > > > It adds some helpful color beauty to django 500 output. > > > Sample pictures are here: > >http://code.djangoproject.com/attachment/ticket/11834/11834.pngand > >http://code.djangoproject.com/attachment/ticket/11834/11834_2.png > > > I'm not a designer, so feedback is highly appreciated > > I really like this, I always scan the traceback looking for items with with > .virtualenv in the path so I can ignore them - its bugged me for a while. > This is clearly a better solution. > > I'm no designer either but I perhapsit could do with a bit of attention from > one, I'm not that keen on the red (pink?) and green mix. > > Also, documentation will be needed so users know what the colours mean but > I'm not sure where in the docs. I can't see anything on the current error > page. > > Dougal --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
phone2numeric doesn't convert "Q" or "Z"
1. Is there a reason Django's phone2numeric method doesn't work for the letters Q or Z? I realize that those two letters are the ones that share four letters to a number instead of the standard three, but that's no reason to leave them out. Most modern phones include the full alphabet on their keys and it's silly not to let people convert those two letters. If there's no reason, I'd be happy to submit a patch since it's such an easy fix. 2. I was also wondering if there's a reason that the dictionary of numbers/letters used in that function is in such a seemingly random order... is there some brilliant logic behind it? The source for the function I'm referring to is here: http://code.djangoproject.com/browser/django/trunk/django/utils/text.py#L158 Thanks! - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: phone2numeric doesn't convert "Q" or "Z"
I've opened a ticket and submitted a patch that fixes this strange oversight: http://code.djangoproject.com/ticket/12613 Thanks! - Gabriel On Jan 14, 5:05 am, Harro wrote: > hmm that's indeed weird. The regex excludes those as well > specifically. > The Q and Z should be added or a comment should be added to the code > explaining the reason for leaving them out. > > On Jan 14, 11:23 am, Gabriel Hurley wrote: > > > > > 1. Is there a reason Django's phone2numeric method doesn't work for > > the letters Q or Z? I realize that those two letters are the ones that > > share four letters to a number instead of the standard three, but > > that's no reason to leave them out. Most modern phones include the > > full alphabet on their keys and it's silly not to let people convert > > those two letters. > > > If there's no reason, I'd be happy to submit a patch since it's such > > an easy fix. > > > 2. I was also wondering if there's a reason that the dictionary of > > numbers/letters used in that function is in such a seemingly random > > order... is there some brilliant logic behind it? > > > The source for the function I'm referring to is here: > > >http://code.djangoproject.com/browser/django/trunk/django/utils/text > > > Thanks! > > > - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Status of #1480: "Don't Set TIME_ZONE [...]"
Having been bitten by issue #1480 personally, I'm wondering what the status of this ticket really is? Trac indicates it needs a better patch and better docs, but there's no information about what changes are needed. If someone will give me some guidance, I'd be happy to wrap this one up and see it ship in 1.2... See the ticket here: http://code.djangoproject.com/ticket/1480 Thanks! - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Status of #1480: "Don't Set TIME_ZONE [...]"
Great! I thought those modifications by "Anonymous" looked funny... Thanks! - Gabriel On Feb 25, 11:25 pm, Russell Keith-Magee wrote: > On Fri, Feb 26, 2010 at 8:55 AM, Gabriel Hurley wrote: > > Having been bitten by issue #1480 personally, I'm wondering what the > > status of this ticket really is? Trac indicates it needs a better > > patch and better docs, but there's no information about what changes > > are needed. > > > If someone will give me some guidance, I'd be happy to wrap this one > > up and see it ship in 1.2... > > In this case, I think it's just a matter of spam that hasn't been > cleaned up properly. Looking at the history, the 'better patch, needs > docs, needs tests' flags were all set by an anonymous user, and some > (but not all) of those flags were reverted very soon after. > > The ticket hasn't been committed because the ticket hasn't ever been > promoted it to ready for checkin, and it's never been put up for > consideration on a milestone. > > From a quick look at the patch, it looks fine; I've marked it ready for > checkin. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding a new convenience filter 'contains_any'
The Django Developers list for discussion of the development of Django itself. Please ask questions related to using Django on django-users, not here. Just to point you in the right general direction, the allowed query terms are defined in django.db.models.sql.constants the and then the SQL is filled in via each backend's DatabaseWrapper class. - Gabriel On Mar 4, 11:56 am, aditya wrote: > I would like to add a new filter for models to my django build that > can be used as follows: > > tags = ['tag1','tag2','tag3''tagn'] > i = Image.objects.filter(tags__contains_any=tags) > > Essentially, instead of passing a string, I pass a list and get a set > of valid objects that match *any* of the items in the list. I'm a loss > for where to look for the relevant code, thoughI'm trying to find > where the 'contains' filter has been implemented, so that I can take a > look at how its written. Currently I'm looking at db.models.query and > db.models.query_utils. Where should I be looking? > > Thanks for any help you all can provide! > > Aditya -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding a new convenience filter 'contains_any'
I guess it depends whether he wants his new filter added to core, or just for his project... That's why I gave him a starting point, just in case ;-) - Gabriel On Mar 4, 1:12 pm, Jerome Leclanche wrote: > On Thu, Mar 4, 2010 at 11:05 PM, Gabriel Hurley wrote: > > The Django Developers list for discussion of the development of Django > > itself. Please ask questions related to using Django on django-users, > > not here. > > This looks very django-development-related to me. Having hacked-about > a __band filter to django for my app, I'm interested what a more > proper way to do it would be. > > J. Leclanche / Adys -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Would a "Feedback" triage stage be helpful?
I've read through the history on this group about triage process and I have an idea I'd like to offer gently: When I'm looking for tickets to work on, I often wish there was a triage stage between "accepted" and "ready for checkin". On other trackers the "feedback" triage stage is for this purpose. It lets people who have worked on a ticket indicate it's ready for others to look at and approve, and tickets can be bounced back out of the feedback stage if problems are found. Filtering by "has_patch", "needs_better_patch", "needs_documentation" and "owner" gets you partway there, but the flags and ownership are not always set consistently... Owner, particularly, is frequently forgotten about. I could see it helping the core devs, too, since they'd have to spend less time sifting through "accepted" tickets looking for things that might be ok to escalate to "ready for checkin". Thoughts? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Would a "Feedback" triage stage be helpful?
I'm certainly not discouraged and I appreciate the reply. The crowdsourced/trust-based system is more what I had in mind; my suggestion was trying to shoehorn that thought into the existing tracker. Given that I love organization and would love to help decrease the entropy in Trac, maybe you can just provide a little personal insight on which of the following you find more helpful: 1. Community members aggressively marking "needs better patch" so that anything that has a patch and doesn't have "needs better patch" is more likely to *actually* be good. 2. Community members leaving comments on tickets with good patches to say that they seem ready. Also, how important is the "owner" status of tickets? It seems silly to take ownership of a ticket that someone else has done all the work for... but if that means a completed fix is more likely to get noticed and checked in then maybe that's the right thing to do? Your thoughts on the matter really are interesting to me. The "contributing to Django" docs tell the "how it's supposed to work" but it's helpful to hear the "how it actually works" first-hand. Thanks! - Gabriel On Mar 6, 3:56 am, Russell Keith-Magee wrote: > On Sat, Mar 6, 2010 at 9:40 AM, Gabriel Hurley wrote: > > I've read through the history on this group about triage process and I > > have an idea I'd like to offer gently: > > Thanks for the suggestion, Gabriel. We're always interested in > considered feedback and suggestions. Don't let what I'm about to say > discourage you :-) > > > When I'm looking for tickets to work on, I often wish there was a > > triage stage between "accepted" and "ready for checkin". On other > > trackers the "feedback" triage stage is for this purpose. It lets > > people who have worked on a ticket indicate it's ready for others to > > look at and approve, and tickets can be bounced back out of the > > feedback stage if problems are found. > > > Filtering by "has_patch", "needs_better_patch", "needs_documentation" > > and "owner" gets you partway there, but the flags and ownership are > > not always set consistently... Owner, particularly, is frequently > > forgotten about. > > The issue here is that introducing another flag doesn't help in this case. > > 'needs-better-patch' already covers a lot of the ground of a > 'feedback' state. However, rather than assuming that a patch will be > bad, it assumes the patch will be good, and provides a way for > triagers or the core team to pass back feedback that a patch isn't > ready. > > Also, as you've noted, the existing flags and states are already > inconsistently applied -- adding another state or flag just adds more > complication, and more ways that a ticket can be incorrectly > configured. > > This is all part of the devil's bargain we've made with Trac. We've > left our Trac instance open. The upside is that anyone can help, and a > new user doesn't need permission to start pitching in. The downside is > that anyone can help, and someone "helping" isn't forced to learn the > rules first. > > The net result is that Trac is a great way of putting a name to > specific problems. It's a passable way of organizing the todo list for > a release. It has sufficient fidelity to draw tickets to the attention > of the core (the ready for checkin flag). There's a lot of noise, but > the only effective way to eliminate that noise is to apply human grey > matter to the problem. I'm not convinced adding or changing the Trac > states that are available will improve matters significantly. > > If we were to make any big changes in this area, I suspect it would be > to move away from Trac altogether. Looking right outside the box, > there might be space for a tool that provides better integration with > the crowdsourced approach to ticket handling that we are using. > > To elaborate a little -- Trac provides access to all, but treats all > contributors as equals. We allow anyone to triage, but the opinion of > the triage team matters more than the general community, and the > opinion of the core team matters more than the triage team, and the > opinion of the BDFLs trump everything. A random community member > should be able to provide feedback saying that they think a patch is > ready, and if they make a habit of marking patches that are > subsequently accepted, the 'value' of their feedback should improve. > That said - if a large group of low-trust individuals say a patch is > ready, that patch should also surface for c
Re: truncate filter
Wow, that's a seriously old ticket! Decision needed for sure. Wim, if you want to open a ticket for the docs but don't feel like (or don't know how to) write a docs patch I'm happy to do so. I agree that the current solution isn't clear enough. Just let me know what number the ticket is. - Gabriel On Mar 6, 6:18 am, Jerome Leclanche wrote: > http://groups.google.com/group/django-developers/browse_thread/thread...http://code.djangoproject.com/ticket/5025 > > The proper solution would be a truncate filter, unfortunately, the > ticket is still sitting on "Design decision needed". (Could someone > PLEASE just take a design decision already) > > J. Leclanche / Adys > > > > On Sat, Mar 6, 2010 at 4:05 PM, Wim Feijen wrote: > > Hello, > > > Truncatewords is in Django, but I've been missing the (for me) more > > obvious "truncate"-filter, which truncates to a specified amount of > > letters, which is really important to me for formatting purposes. > > > After some thorough looking on Google, I found out that I didn't need > > to write the filter myself, slice can do the same trick. I didn't get > > that from the official Django filter documentation, so my first > > question is: > > 1. Can we update the filter docs, so > > a) slice shows an extra example of slicing a string; and > > b) truncate_words refers to slice for truncating by letters, to give > > readers a helpful hint. > > These might sound trivial, but I am pretty sure that I am not the only > > one misunderstanding. > > > 2. As I understand it, there are several cases where slice fails, > > because of unicode characters? What would be the proper solution to > > that, and can we include that in django trunk as well? > > > Thanks for making Django better and better and better! > > > Wim > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
You seem to be missing the point of the code you reference above. You should probably read up on the "Sites" framework that ships with Django: http://docs.djangoproject.com/en/dev/ref/contrib/sites/ All the best, - Gabriel On Mar 12, 1:39 pm, aditya wrote: > Description > = > This page of the Django documentation shows how to use the 'Sites' > framework to get the domain of the current site: > > http://docs.djangoproject.com/en/dev/ref/contrib/sites/ > > I've noticed that 'domain = Site.objects.get_current().domain' is > becoming a common idiom in Django. Most recently I've seen it being > used in django-disqus as a way to get the url of the current site > (Disqus tracks comments by associating each comment with a specific > url). I'm also seeing it being used for RSS feeds and for mailers. > > The trouble is, there is no straightforward way to configure the name > and domain of a site. > Currently, Django uses "example.com" for both the domain and the > name. The only way to change that is to wade into the actual > database. I'd like to propose adding two optional variables to > settings.py: > > SITE_DOMAIN and > SITE_NAME. > > If either of these are defined, they will override "example.com" when > the new site is created. > > Implementation > > > This is quite easy to implement. In the create_default_site function, > add these 5 lines: > > from django.conf import settings > try: def_domain = settings.SITE_DOMAIN > except: def_domain = "example.com" > try: def_name = settings.SITE_NAME > except: def_name = "example.com" > > and then create the new site using: > s = Site(domain=def_domain, name=def_name) > > I hope this is the correct place to post this! I wanted to hear what > other people thought of this proposal. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
"domain = Site.objects.get_current().domain" The "Site" model in that code comes from the django.contrib.sites.models, part of the Sites framework I mentioned above. This is not some bizarre buried database mishap; this is the app developer taking advantage of a contrib app that is included in Django. You complain "The trouble is, there is no straightforward way to configure the name and domain of a site" but if you actually *include* django.contrib.sites in your INSTALLED_APPS you'd see that it's EASILY configurable using the Django admin, and that it in fact offers you some very useful features if you want to publish similar content on multiple domains. As of Django's 1.0 release the Sites framework is supported as an *optional* component, allowing developers to take advantage of it in their apps without requiring that everyone use contrib.sites. This is accomplished using the RequestSite object. You can read about that here: http://docs.djangoproject.com/en/dev/ref/contrib/sites/#requestsite-objects However, if you're in the habit of using 3rd-party apps that take advantage of the Sites framework, I strongly suggest you simply *add* "django.contrib.sites" to your INSTALLED_APPS in settings. Then you can edit it via the Django admin, the Django shell, or by whatever method you choose. Adding another setting in place of the actual contrib.sites app would be a *different* solution to the problem solved by RequestSite, but I don't see that it offers any real advantages. Please read the docs I linked you to carefully. It really does explain everything you need to know to understand why your proposal is off- base. Again: http://docs.djangoproject.com/en/dev/ref/contrib/sites/ All the best, - Gabriel On Mar 12, 6:56 pm, aditya wrote: > Could you be more specific? I'm not sure what you mean. > Aditya > > On Mar 12, 5:26 pm, Gabriel Hurley wrote: > > > > > You seem to be missing the point of the code you reference above. You > > should probably read up on the "Sites" framework that ships with > > Django: > > >http://docs.djangoproject.com/en/dev/ref/contrib/sites/ > > > All the best, > > > - Gabriel > > > On Mar 12, 1:39 pm, aditya wrote: > > > > Description > > > = > > > This page of the Django documentation shows how to use the 'Sites' > > > framework to get the domain of the current site: > > > >http://docs.djangoproject.com/en/dev/ref/contrib/sites/ > > > > I've noticed that 'domain = Site.objects.get_current().domain' is > > > becoming a common idiom in Django. Most recently I've seen it being > > > used in django-disqus as a way to get the url of the current site > > > (Disqus tracks comments by associating each comment with a specific > > > url). I'm also seeing it being used for RSS feeds and for mailers. > > > > The trouble is, there is no straightforward way to configure the name > > > and domain of a site. > > > Currently, Django uses "example.com" for both the domain and the > > > name. The only way to change that is to wade into the actual > > > database. I'd like to propose adding two optional variables to > > > settings.py: > > > > SITE_DOMAIN and > > > SITE_NAME. > > > > If either of these are defined, they will override "example.com" when > > > the new site is created. > > > > Implementation > > > > > > > This is quite easy to implement. In the create_default_site function, > > > add these 5 lines: > > > > from django.conf import settings > > > try: def_domain = settings.SITE_DOMAIN > > > except: def_domain = "example.com" > > > try: def_name = settings.SITE_NAME > > > except: def_name = "example.com" > > > > and then create the new site using: > > > s = Site(domain=def_domain, name=def_name) > > > > I hope this is the correct place to post this! I wanted to hear what > > > other people thought of this proposal. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
I'm not arguing that the proposal is inherently bad, just that it was being proposed without understanding the existing solution. Personally, I use a custom model that inherits from Site to manage my sites, so it's not like I'm thrilled with the current system either. I would actually be +0 on adding this as a feature for some future released, particularly if it was simple, and Site.get_current()- compatible. Getting some feedback from the core devs would be great, but they've definitely got more important things on their minds with the 1.2 deadlines looming. (the ticket list is shrinking fast, though! Keep up the great work!) All the best, - Gabriel On Mar 13, 5:41 am, Will Hardy wrote: > > Does this proposal add any functionality that fixtures do not already > > provide? > > Convenience. It moves the definition of the site away from the > database, and away from fixtures files and into the settings. > Personally, I am yet to need multiple sites for a single database, and > would much prefer being able to set the domain using settings files > (eg host="localhost:8000" for my settings/local.py on my dev, > host="production.com.au" for settings/__init__.py etc). > > For my needs, being able to define the domain in the settings is much > more powerful and convenient than storing it in the database and an > initial_data fixture isn't going to be able to play very cleanly with > my settings configuration. > > Just adding my +1 vote for a standard, > Site.objects.get_current()-compatible way to set the domain name in > django.conf.settings. Bonus points if no site table is created and no > ModelAdmin turns up in admin on auto_discover. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket #13115: Grouping multiple fields into one form-row div
Hey folks, I was looking through the recent tickets and saw #13115 [1], which looked interesting. It got closed by ramiro (whose judgment I normally trust) as a "worksforme", but I don't think he quite got what the OP wanted. I thought I'd bring it up on here to see if it was worth reopening the ticket as a possible future feature-addition. Basically, the OP wants to be able to take various fields which have some logical relation to each other and group their widgets into the same "form-row" div. The result would be similar to how a datetime widget is rendered, except that he could define these sets of grouped widgets himself. Obviously this is neither simple, nor going to happen before 1.3 at least. But it seems like something I'd use if it existed. So is the ticket worth reopening? All the best, - Gabriel [1] http://code.djangoproject.com/ticket/13115 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #13115: Grouping multiple fields into one form-row div
Wow, I read that section three times this morning (and who knows how many times in the past), and I still managed to miss that about wrapping fields inside of fieldsets in tuples. My apologies! I'd almost say it could use a docs patch to make that feature more obvious since it's now eluded several developers multiple times. Sorry for wasting time, and as usual, ramiro was right! Thanks! - Gabriel On Mar 14, 4:09 pm, Florian Apolloner wrote: > Can you tell us what the difference to fieldsets would be (as ramiro > already pointed > out:http://docs.djangoproject.com/en/1.1/ref/contrib/admin/#django.contri... > > Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: logialogin_required does not check User.is_active
The docs have this to say about is_active: "This doesn’t control whether or not the user can log in. Nothing in the authentication path checks the is_active flag, so if you want to reject a login based on is_active being False, it is up to you to check that in your own login view. However, permission checking using the methods like has_perm() does check this flag and will always return False for inactive users." http://docs.djangoproject.com/en/1.1/topics/auth/#django.contrib.auth.models.User.is_active So, if we're to believe the docs, this isn't a bug but a design decision. All the best, - Gabriel On Mar 16, 1:53 pm, Sean Brant wrote: > A co-worker of mine noticed this bug > todayhttp://code.djangoproject.com/ticket/13125. > Should it be marked for 1.2 or punt it until after the release > candidate? It looks to be a bug so it could probably go in at anytime. > Let me know your thoughts. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket 13023: Admin inlines, max_num, and extra
I couldn't help notice that #13023 was mentioned in Russ' latest 1.2 status update as a ticket that "will require some significant design work". Since I've accepted that ticket I'd love to get some feedback from folks. The ticket: http://code.djangoproject.com/ticket/13023 The ticket was opened because the new javascript "Add Another" functionality for admin inlines caused a useful (though possibly unintended) feature to be removed: when setting extra to 0 you could display existing inlines without allowing any new ones to be created. The new javascript made this impossible because the "Add Another" button was controlled by max_num, and ignored a value of 0. When I tracked back through the code, I realized there was a more fundamental problem: the javascript ignored a value of 0 because max_num has a default value of 0, and all the code using it had taken to equating max_num = 0 with being "off". So you can't actually have a maximum of 0. It's not possible. My patch for the ticket restored the desired behavior for admin inlines, but I'll admit it was a bit of a hack and didn't address the larger problem. I wasn't sure the larger problem was appropriate to fix in the 1.2 timeframe. So what is the appropriate course here? Should the default value and behavior of max_num be changed? Does the entire feature need to be re- evaluated? Are there other issues involved that I'm missing entirely? I'm happy to work on the ticket (and have a reasonable grasp on that area of the codebase), but I need some direction. Thanks so much! - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: logialogin_required does not check User.is_active
I linked to the 1.1 docs there, but the 1.2 docs add: "However, the AuthenticationForm used by the login() view does perform this check, as do the permission-checking methods such as has_perm() and the authentication in the Django admin." So in this instance, if using the built-in django login view is your only method of logging in to your site you would be safe. I'll admit the whole business of not checking is_active seems a little odd to me, but I also haven't looked to see what discussion there was around the original decision. I'd hope it would make more sense if I did look back in the archives. I'm no expert on this one. Just thought I'd point out the fact that the docs do discuss the subject of that bug ticket. - Gabriel On Mar 16, 3:12 pm, mattd wrote: > if it's a design decision, it's a silly one imo. why should i have to > work around django's ever-so-convenient "login_required" decorator to > prevent a deactivated user from viewing a page they're no longer > allowed to view? a deactivated user *shouldn't even be allowed to be > be logged in*, but there's no way (that i know of) the purge the > session data for a given user on deactivation, and i can't just email > them to politely ask them to log out. > > On Mar 16, 4:48 pm, Gabriel Hurley wrote: > > > > > The docs have this to say about is_active: > > > "This doesn’t control whether or not the user can log in. Nothing in > > the authentication path checks the is_active flag, so if you want to > > reject a login based on is_active being False, it is up to you to > > check that in your own login view. However, permission checking using > > the methods like has_perm() does check this flag and will always > > return False for inactive users." > > >http://docs.djangoproject.com/en/1.1/topics/auth/#django.contrib.auth... > > > So, if we're to believe the docs, this isn't a bug but a design > > decision. > > > All the best, > > > - Gabriel > > > On Mar 16, 1:53 pm, Sean Brant wrote: > > > > A co-worker of mine noticed this bug > > > todayhttp://code.djangoproject.com/ticket/13125. > > > Should it be marked for 1.2 or punt it until after the release > > > candidate? It looks to be a bug so it could probably go in at anytime. > > > Let me know your thoughts. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket 13023: Admin inlines, max_num, and extra
Thanks for the IRC log, Ivan. That offers some perspective. Ideally a complete solution would have the following characteristics: 1. Makes behavior consistent with or without Javascript enabled. I personally would argue against any solution that caused extra and max_num to have different effects with and without JS. 2. Preserves existing behaviors from 1.1 for both extra and max_num. If those behaviors become "features" instead of "unintended side- effects" that's cool, but IMHO removing those behaviors doesn't benefit Django overall. Even if it means codifying the "feature" into something more like readonly that is no longer tied to max_num and extra. 3. Clarifies the meaning of max_num = 0. Currently max_num being 0 has a very odd behavior, and while it would be somewhat silly to create an Admin that had inlines but said the maximum number was 0, it seems equally strange that if I deliberately set max_num to 0 that it is, in fact, ignored. I guess in a sense, I really see three separate but related issues here. Anyhow, that's where I'm at with it. I'd love to hear from some of the core devs, since they've already given it some thought, and will make the ultimate decision about any changes that take place. - Gabriel On Mar 16, 7:56 pm, Iván Raskovsky wrote: > Hi Gabriel, here's a follow up after I asked in django-dev if I should file > the ticket:http://botland.oebfare.com/logger/django-dev/2010/3/4/1/ > Unfortunately I can't find my original conversation. > > One thing that might be important to take into consideration is that without > the patch users without JS enabled can't add any new inlines, so if the > patch is rejected, we should be fixing that instead. > > For what is worth, IMHO documented or not this was a behavior I'm sure I > wasn't the only one taking advantage of, and would very much like to see in > 1.2 so I can update my 1.1 projects and take advantage of all the new > features without breaking the actual functionality. > > I'd like to take the opportunity and thank you for this patch and another > one in a ticket I filed. Thanks, > Iván > > > > On Tue, Mar 16, 2010 at 8:10 PM, Gabriel Hurley wrote: > > I couldn't help notice that #13023 was mentioned in Russ' latest 1.2 > > status update as a ticket that "will require some significant design > > work". Since I've accepted that ticket I'd love to get some feedback > > from folks. > > > The ticket:http://code.djangoproject.com/ticket/13023 > > > The ticket was opened because the new javascript "Add Another" > > functionality for admin inlines caused a useful (though possibly > > unintended) feature to be removed: when setting extra to 0 you could > > display existing inlines without allowing any new ones to be created. > > The new javascript made this impossible because the "Add Another" > > button was controlled by max_num, and ignored a value of 0. > > > When I tracked back through the code, I realized there was a more > > fundamental problem: the javascript ignored a value of 0 because > > max_num has a default value of 0, and all the code using it had taken > > to equating max_num = 0 with being "off". So you can't actually have a > > maximum of 0. It's not possible. > > > My patch for the ticket restored the desired behavior for admin > > inlines, but I'll admit it was a bit of a hack and didn't address the > > larger problem. I wasn't sure the larger problem was appropriate to > > fix in the 1.2 timeframe. > > > So what is the appropriate course here? Should the default value and > > behavior of max_num be changed? Does the entire feature need to be re- > > evaluated? Are there other issues involved that I'm missing entirely? > > > I'm happy to work on the ticket (and have a reasonable grasp on that > > area of the codebase), but I need some direction. > > > Thanks so much! > > > - Gabriel > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > i...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket 13023: Admin inlines, max_num, and extra
There are two possible solutions, as I see it: 1. Change the default value of max_num from 0 to -1. That's a pretty standard solution to indicating an "off" value for something with a range of [0, ∞]. That way when max_num and extra are *both* explicitly set to 0, the "Add Another" link could be removed. For the vast majority of people who *don't* explicitly set max_num to 0, it would be functionally identical to the current status of things in 1.2-beta. It would also bring the javascript-enabled and noscript behaviors closer into line with each other. Even better it means that the behavior of extra is completely untouched. This solution would also mean that max_num = 0 (which should be a valid value even if it's not a common usage) is no longer ignored. Obviously the docs and tests would be updated in conjunction with all that. 2. Create a readonly attribute for inlines as a completely new feature. This would default to False, and setting it to True would cause the desired behavior of preventing new inlines from being created. It would override both extra and max_num. This solution would be more explicit (as compared to the setting both max_num and extra to 0), but I feel it doesn't address the deeper issue around max_num. I guess it ultimately comes down to wether you view this as a bug or a feature. It has aspects of both. Calling it a "new" feature isn't quite right because it already exists in 1.1, it just wasn't intentional. If this is determined to be a feature, I'll open a new bug ticket about max_num because I do think that should be corrected. But it doesn't absolutely have to be corrected in connection with this ticket. Feedback? - Gabriel On Mar 16, 8:31 pm, Gabriel Hurley wrote: > Thanks for the IRC log, Ivan. That offers some perspective. > > Ideally a complete solution would have the following characteristics: > > 1. Makes behavior consistent with or without Javascript enabled. I > personally would argue against any solution that caused extra and > max_num to have different effects with and without JS. > > 2. Preserves existing behaviors from 1.1 for both extra and max_num. > If those behaviors become "features" instead of "unintended side- > effects" that's cool, but IMHO removing those behaviors doesn't > benefit Django overall. Even if it means codifying the "feature" into > something more like readonly that is no longer tied to max_num and > extra. > > 3. Clarifies the meaning of max_num = 0. Currently max_num being 0 has > a very odd behavior, and while it would be somewhat silly to create an > Admin that had inlines but said the maximum number was 0, it seems > equally strange that if I deliberately set max_num to 0 that it is, in > fact, ignored. > > I guess in a sense, I really see three separate but related issues > here. Anyhow, that's where I'm at with it. I'd love to hear from some > of the core devs, since they've already given it some thought, and > will make the ultimate decision about any changes that take place. > > - Gabriel > > On Mar 16, 7:56 pm, Iván Raskovsky wrote: > > > > > Hi Gabriel, here's a follow up after I asked in django-dev if I should file > > the ticket:http://botland.oebfare.com/logger/django-dev/2010/3/4/1/ > > Unfortunately I can't find my original conversation. > > > One thing that might be important to take into consideration is that without > > the patch users without JS enabled can't add any new inlines, so if the > > patch is rejected, we should be fixing that instead. > > > For what is worth, IMHO documented or not this was a behavior I'm sure I > > wasn't the only one taking advantage of, and would very much like to see in > > 1.2 so I can update my 1.1 projects and take advantage of all the new > > features without breaking the actual functionality. > > > I'd like to take the opportunity and thank you for this patch and another > > one in a ticket I filed. Thanks, > > Iván > > > On Tue, Mar 16, 2010 at 8:10 PM, Gabriel Hurley wrote: > > > I couldn't help notice that #13023 was mentioned in Russ' latest 1.2 > > > status update as a ticket that "will require some significant design > > > work". Since I've accepted that ticket I'd love to get some feedback > > > from folks. > > > > The ticket:http://code.djangoproject.com/ticket/13023 > > > > The ticket was opened because the new javascript "Add Another" > > > functionality for admin inlines caused a useful (though possibly > > > unintended) feature to be removed: when setting extra to 0 you could > > > disp
Re: Ticket 13023: Admin inlines, max_num, and extra
Thanks for a great reply Russ. I agree 100% about interpretation 3 being the most useful and beneficial. The first concern about the original use case is something I'd considered, but I don't think it can be helped without creating an ugly hack (like my original patch on the ticket). The change should be noted in the docs, but thankfully it's an incredibly easy fix for anyone who wants to keep using that "feature". I think we both agree about the second concern. All existing inlines should be displayed. Since max_num and extra have no actual DB constraints backing them up, I've always seen them as display guidelines. With that, I'll get to work on a proper solution over the weekend (code changes, docs, and tests) and will have it done with time to spare for 1.2. Thanks so much! - Gabriel On Mar 18, 7:45 pm, Russell Keith-Magee wrote: > Hi Gabriel > > Sorry for taking so long to get back to you on this. I certainly > appreciate the effort you've put into the analysis. > > On Fri, Mar 19, 2010 at 6:03 AM, Gabriel Hurley wrote: > > There are two possible solutions, as I see it: > > > 1. Change the default value of max_num from 0 to -1. That's a pretty > > standard solution to indicating an "off" value for something with a > > range of [0, ∞]. That way when max_num and extra are *both* explicitly > > set to 0, the "Add Another" link could be removed. For the vast > > majority of people who *don't* explicitly set max_num to 0, it would > > be functionally identical to the current status of things in 1.2-beta. > > It would also bring the javascript-enabled and noscript behaviors > > closer into line with each other. Even better it means that the > > behavior of extra is completely untouched. This solution would also > > mean that max_num = 0 (which should be a valid value even if it's not > > a common usage) is no longer ignored. Obviously the docs and tests > > would be updated in conjunction with all that. > > This seems like the better approach, although I would use None rather > than -1 as a more Pythonic alternative i.e., "max_num = None" says > "there is no max number"; max_num=0 says "there is a maximum of 0". > > However, I can see two downsides. > > Firstly, the original use case that raised this problem (i.e., someone > that wants to show exactly 2 inlines, with no extras allowed) will > require code changes. I'm not convinced this is a show-stopper, but it > is something that we should mention in the release notes as an edge > case backwards incompatibility if you were relying on one particular > interpretation of the docs. > > Secondly -- and more concerning -- what happens if you set max_num = X > (where X is any non-null value), and you already have > X inlines? For > example, if you have 4 inline related objects, and you set max_num = > 2, what happens to the extra 2 objects? > > This is actually already a problem with 1.1, but if we're going to > start getting esoteric on the interpretation of max_num, it's doubly > important we get this right. > > So, is the interpretation of max_num: > 1) Only display max_num inlines > 2) Always display all inlines, but only allow max_num inlines to be > saved (and raise a validation error for the remainder) > 3) Don't allow extra inlines to be added past the limit of max_num; > if a form already has more than max_num inlines, allow them to remain, > but prevent any extra inlines being added. > > The current implementation (1) is clearly wrong, if only because it's > possible to display an object and *not* see all the inlines. > > Whether (2) or (3) is the right response depends on whether we > consider the ModelAdmin to be a validation condition or a display > guideline. (2) enforces ModelAdmin as a validation condition; (3) > treats it as display guidelines. My initial response is that (3) is > correct (since you could easily add other related objects > programatically, or using a different form), but I'm willing to be > convinced otherwise. > > The interpretation here also reflects back on the original problem. In > the original problem, B had a FK on A, so A allowed inline B's in the > admin. B was a complex object, so not all the fields of B were > displayed in the inline. The inlines on A were made available as a > convenience to edit the most notable properties of B. If you wanted to > add a new B, you used the full admin interface for B, and set the FK > to point to a specific instance of A. As a consequence of this, you > can't add new B's via the inline -- but you also don't know a prioiri > how many B's will actually be th
Re: Ticket 13023: Admin inlines, max_num, and extra
I've added an all-new patch to #13023 that encompasses everything discussed in this thread. It makes max_num default to None instead of 0. This makes the meaning of max_num clearer as per Russ above, and makes the behavior of the dynamic "Add Another" admin inline link fall into line with the no- script behavior. Explicitly setting both max_num and extra to 0 achieves the functionality desired by the OP of the ticket. The patch passes the complete test suite. A handful of new tests were added to prevent future regression. Only three existing tests needed real updating, though many others had a hard-coded value of 0 for the max_num default. The tests all passed even with that hard-coded value, but just for completeness I changed them all to None (the new default). Lastly, the patch also updates the docs for all mentions of max_num. Please test and review, but at this point the patch should be complete! On Mar 18, 8:05 pm, Gabriel Hurley wrote: > Thanks for a great reply Russ. I agree 100% about interpretation 3 > being the most useful and beneficial. > > The first concern about the original use case is something I'd > considered, but I don't think it can be helped without creating an > ugly hack (like my original patch on the ticket). The change should be > noted in the docs, but thankfully it's an incredibly easy fix for > anyone who wants to keep using that "feature". > > I think we both agree about the second concern. All existing inlines > should be displayed. Since max_num and extra have no actual DB > constraints backing them up, I've always seen them as display > guidelines. > > With that, I'll get to work on a proper solution over the weekend > (code changes, docs, and tests) and will have it done with time to > spare for 1.2. > > Thanks so much! > > - Gabriel > > On Mar 18, 7:45 pm, Russell Keith-Magee > wrote: > > > > > Hi Gabriel > > > Sorry for taking so long to get back to you on this. I certainly > > appreciate the effort you've put into the analysis. > > > On Fri, Mar 19, 2010 at 6:03 AM, Gabriel Hurley wrote: > > > There are two possible solutions, as I see it: > > > > 1. Change the default value of max_num from 0 to -1. That's a pretty > > > standard solution to indicating an "off" value for something with a > > > range of [0, ∞]. That way when max_num and extra are *both* explicitly > > > set to 0, the "Add Another" link could be removed. For the vast > > > majority of people who *don't* explicitly set max_num to 0, it would > > > be functionally identical to the current status of things in 1.2-beta. > > > It would also bring the javascript-enabled and noscript behaviors > > > closer into line with each other. Even better it means that the > > > behavior of extra is completely untouched. This solution would also > > > mean that max_num = 0 (which should be a valid value even if it's not > > > a common usage) is no longer ignored. Obviously the docs and tests > > > would be updated in conjunction with all that. > > > This seems like the better approach, although I would use None rather > > than -1 as a more Pythonic alternative i.e., "max_num = None" says > > "there is no max number"; max_num=0 says "there is a maximum of 0". > > > However, I can see two downsides. > > > Firstly, the original use case that raised this problem (i.e., someone > > that wants to show exactly 2 inlines, with no extras allowed) will > > require code changes. I'm not convinced this is a show-stopper, but it > > is something that we should mention in the release notes as an edge > > case backwards incompatibility if you were relying on one particular > > interpretation of the docs. > > > Secondly -- and more concerning -- what happens if you set max_num = X > > (where X is any non-null value), and you already have > X inlines? For > > example, if you have 4 inline related objects, and you set max_num = > > 2, what happens to the extra 2 objects? > > > This is actually already a problem with 1.1, but if we're going to > > start getting esoteric on the interpretation of max_num, it's doubly > > important we get this right. > > > So, is the interpretation of max_num: > > 1) Only display max_num inlines > > 2) Always display all inlines, but only allow max_num inlines to be > > saved (and raise a validation error for the remainder) > > 3) Don't allow extra inlines to be added past the limit of max_num; > > if a form already has more than max_num inlines, allow them to remain,
Re: High Level Discussion about the Future of Django
If you haven't already, take a read through the "internals" section of the docs. It covers a number of the questions you've asked about deprecation, what can be changed in minor (1.x) releases, etc. http://docs.djangoproject.com/en/dev/internals/ They were definitely interesting for me. Being a long-time django user but only recently a contributor, I'd imagine any truly breaking changes would have to be targeted for 2.0, which really is just a "someday" right now from all I've gathered. Also, scattered throughout the wiki section of the docs are numerous high-level ideas for future releases. They're hard to find, but they're in there. Most of the high-level stuff I'd personally like to see has already been brought up in GSOC proposals and wiki pages, so I can't add much to that discussion right now. But hey, that's a good thing, right? It means I like where Django's (probably) headed! Once 1.2 gets released, I think we'll all be a lot happier, right? (by the way, congrats to the core devs on knocking out the last ORM ticket that was open against 1.2 today! That's awesome!) All the best, - Gabriel On Apr 4, 8:02 pm, orokusaki wrote: > This is a bit abstract, but I'd like to bring up this idea, and > firstly let me say that I don't intend to waste the time of the major > contributors (unless you want to join in of course). I mostly want to > get an idea of what some of the contributors/feature proposers out > there are thinking of, in a sort of fly by the seat of your pants way. > > Through reading some of the ideas/problems on this group (including my > own) I've noticed that some tend to be A) too far in the future, B) > too abstract, C) (very important) Backwards incompatible, D) (very > important) Too much architecture changes. The discussions tend to turn > from macro to micro very quickly because of some of the existing > constraints. > > 2 thoughts came to mind: > > 1) What if every major element could be re-factored for better > extensibility (and perhaps speed as well) without regard for the > backwards compatibility. > 2) Imagine the progress that could be made if the existing code base > was able to be re-factored in one week (impossible of course, but > hypothetically speaking), knowing everything that the developers know > now. > > I know neither of those is possible at the moment, but take those two > ideas (rules) in mind, and talk about what you'd add / change / make > better / etc. > > Perhaps this is way more 2.0 than even 1.3, but I wanted to get a very > early look through foggy goggles into the future so that I can come up > with ideas. I've been bombarding Russell K M with questions, thoughts, > etc that are just very poorly timed with 1.2 Beta and all, and I want > to step back and really prepare for next time. > > 2 related questions for anyone who cares to answer: > > 1) Is anything allowed to become non-backwards compatible during a .x > release? (ie, from 1.2 to 1.3 or 1.4) > 2) When will 2.0 development begin? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Application to update the Test Suite
Maybe it's an overly simplistic question, but: what makes the tests slow currently? It's not simply the volume of them. It's more than possible for Python to race through hundreds of tests per second under the right conditions. Some of Django's test modules obviously zip along, but others seem to take a rather long time to complete individual tests. Has anyone identified which tests are the slowest and what is making them so slow? Is it the length of the tests? The parsing? The fixtures that are loaded? The data generated in the test itself? Without knowing what gives the current test suite its performance characteristics aren't we all just guessing at how a rewrite of it will compare? Perhaps a good test would be to take one test module and convert it from doc tests to unit tests and profile the before and after versions to see how they compare. While the micro-scale may not ultimately compare to the macro, it would at least be a starting benchmark. I don't have any answers here, but that's what occurs to me about performance... All the best, - Gabriel On Apr 9, 12:51 pm, Paul McMillan wrote: > I've revised the proposal, but am inlining more complete answers. > > > If someone needs to fix a bug, they will essentially need to > > write the test twice; once for the old framework, and once for the > > new. Do you have any suggestions on what we should be doing to > > mitigate this complexity? > > Unfortunately some mismatch seems inevitable for major changes like > the proposed one. I will include comments indicating where > corresponding test code in the previous branches can be found to help > with this problem. If the test code is a completely new chunk of code, > it will be written in the unittest style which should not be too hard > to add to the old test suite. Many of the bits of code that are > currently doctests are fairly well vetted by now, and so should > hopefully have few changes necessary for backports. If it's just a > minor couple line testing change, that shouldn't be too hard to make > into a doctest if that's more appropriate. Better ideas are, of course > welcome. > > > We have a buildbot currently in development; if you're have the > > resources to contribute, it would be good if these could be integrated > > permanently into the build farm. > > That might be possible. I was intending to pull up vmware instances on > my development machine, but we should discuss how best I could > contribute to that. > > > The #python IRC channel needs to think about the problem a little more. > > I figured that was probably the case, given that you included that > aspect in the project suggestion... > > > While this project is *very* appealing from a project point of view -- > > we get the benefit of individually failing and isolated tests -- but > > the risk of test runtime blowouts is huge. Any suggestions on how to > > tackle this problem (and speed up test runs in general) would be > > almost as valuable as the doctest->unittest conversion itself. > > This is a bit of a sticky problem. I'll be thinking about it between > now and when the project (potentially) starts, but my first thoughts > are as follows: > > We know that the existing doctests work when run sequentially. There > may be bugs that are revealed as they're run individually, but to a > first order, we know that some tests can safely be run sequentially > without the setup/teardown each time. Since we're worried that this > process is going to greatly inflate runtime, why not investigate > options that let us avoid it where appropriate? Specifically, why not > structure things such that we can lump tests together into groups that > can safely be run sequentially, but also allow a "full" test run that > runs each tested item individually as is currently the case for > unittests? > > There are a couple problems with this approach. The first is that > there are now 2 different ways to "pass the tests" - the quick run and > the full run. Developers will still have to run the "full" run > sometimes, negating at least some time saved. On the other hand, the > proposed "quick" run doesn't provide LESS coverage than the existing > doctests, so it might be good enough, particularly for tests which are > currently in the regression test category. Unfortunately, it's > probably not broadly appropriate for a majority of existing unit > tests. We could make the "quick" option the standard for unit tests, > with the "full" option reserved for assistance in bug hunting when > there's an identified error. > > It needs more concerted thought, but I'd be interested in feedback. > Maybe it's a terrible idea. This subject should probably have a > dedicated thread here for better exposure and more specific > discussion. Hopefully others have good ideas. > > In any case, I should do some profiling work as I'm doing the > conversion to identify particularly inefficient areas and clean them > up. This is part of the advantage of doing it by hand ra
Re: GSoC Proposal: Web Unifying Markup (templating) Language, or WUML
To be honest, my biggest question is "is this really about Django?"
It seems like this proposal could have gone to anybody, or it could be
a standalone app.
I also would like to know if you have examples of other successful
implementations of such a system that incorporate HTML, CSS, *and* JS
into one. Striking out into this territory and finding it's a much
larger job than expected just means the code branch is more likely to
die.
I'm particularly concerned about your discussion of javascript being
included. Though Django has chosen jQuery for its admin there is no
such requirement for the rest of any Django site's codebase. Writing a
meta-language for javascript that is framework-agnostic (or framework-
independent) is going to be extremely hard.
You talk about extensibility, but don't give any examples of how this
system would *actually* be extended.
How do you propose for your parser to determine the difference between
this new WUML markup and non-escaped similar-looking markup in legacy
templates? Backwards compatibility is not a simple issue here.
Adding dependencies on more external Python libraries also doesn't sit
well with me. I don't want to have to install SASS and SHPAML
libraries, nor do I want to be reliant upon the development directions
of those projects.
This proposal is certainly ambitious. I'll give you that.
All the best,
- Gabriel
On Apr 9, 11:14 am, nubela wrote:
> Proposal Title
> --
>
> Web Unifying Markup (templating) Language, or WUML
>
> Background
> --
>
> As a freelance developer having built entire platforms of Django, I
> find the most time consuming part of web development to be the front
> end development. Essentially, Javascript, HTML, and CSS. Of course
> there are tools that might help. For example, SASS for CSS, JQuery for
> Javascript, and recently, an exciting new library known as the SHPAML
> surfaced that is pretty similar to HAML, but more pythonic, and
> definitely more transparent. (http://shpaml.webfactional.com/)
>
> However, what does not change is that these components are still
> distinct. Everytime I have to modify a property of an element, I'd
> still have to go to my CSS file, or SASS file. Same goes to JS, or
> HTML.
>
> But thats not all, if we were to use SHPAML and SASS, every time we
> have to test the interface, we have to manually compile, or have a 3rd
> party script to compile all the relevant files back into its HTML/CSS/
> JS components. And that means before every F5, we have to run a mini
> script. It gets annoying after a while.
>
> This is when I hope WUML can come in.
>
> Essentially, I hope to have a unified templating language that will
> coexists with template tags of Django, whereby I can streamline my
> development into a pythonic element-centric experience. But its better
> to demonstrate with examples.
>
> Examples
>
>
> html
> body
> div#header
> | this is some verbose text inside this div
> + background-color: {{ backgroundcolor }}
> + pointer: cursor
> ^ alert("true");
> ^ this.hide();
>
> will be compiled into
>
> > A HTML FILE
>
>
>
> this is some verbose text inside this div
>
>
>
> > A CSS FILE
>
> html body div#header {
> background-color: #FFF;
> pointer: cursor;
>
> }
> > A JS FILE (using JQuery)
>
> $(document).ready({function(){
> $("div#header").live("click",function() {
> alert("true");
> this.hide(); //hide here has to be defined in another js file.
> });
>
> });
>
> Arguments against WUML (or why it is helpful)
> -
>
> Some people might argue that this defeats the purpose of abstraction
> of different components into its respective components. JS/HTML/CSS
> existed distinctly for a reason. While I agree strongly with this
> point, but I hope to point out that WUML is not replacing any of those
> components.
>
> Here are some reasons why WUML might be interesting:
>
> 1) A javascript coder, a HTML writer, and a CSS scriptor, can still
> work on their individual files, no one is stopping them. What WUML
> does is, it provides a shorthand in an element-centric manner to
> various of these components in a pythonic sense. The 3 different
> people can now instead of working on 3 different files, they can work
> on the same code, and view distinctly what are the relevant details to
> each element they should take note of. Besides, with the state of the
> art revision control any decent programmer should use these days,
> merging will make this much easier.
>
> 2) WUML is s much shorter.
>
> 3) WUML is pythonic, at least syntatically-wise.
>
> 4) WUML will greatly boost any frontend developer's lead time.
>
> Implementation Details
> --
>
> In a gist, I will basically be merging the best components of JS/CSS/
> HTML, and providing a markup syntax for them in a pythonic fashion.
>
> Details:
>
> - Architecture: The WUML layer will live atop the 2 main com
Re: Process discussion: reboot
Before I even say anything: I think the core team does a great job, they're as fair as humanly possible in their decisions, and Django's stability is amazing. My disclaimer out of the way, I'd like to share my own experience of being a new contributor just to add another perspective. I only started submitting patches during the 1.2 release cycle, so I'm still a relative newbie. In 4 months I've learned *a lot* about Django's process and the history of thought behind many of the issues in both the codebase and the development process. But that knowledge wasn't easy to come by. I read the contributing docs twice before I even opened my first ticket. Twice more before I submitted a single patch. When I finally did submit my first patch, I was terrified of getting it wrong and having it rejected. I'd seen it happen on other tickets. It wasn't until I got *more involved* and started keeping up with the trac timeline--watching the ebb and flow of tickets--that I started to understand how the tone on trac had a reason. Until you get that perspective, it's hard to know what's right or wrong, and easy to take things personally. The core devs can seem imposing or scary simply because you don't know them. Even after reading the contributing docs and all the internals several times, there was still a large portion of knowledge that I found only existed outside those docs. Spending hours reading through this list's history and through the #django-dev IRC logs have answered a lot more of my questions. While it might seem obvious to say "go add that information to the docs" the truth is that a lot of what new contributors need to learn is subjective, and may not belong in official documentation. I did find that the ambiguity of ticket statuses in trac made it hard to dive right in and understand what was going on. But that's been discussed at length. When someone has an idea for a solution there, I'll be the first to jump in and work on it. If anything, my point is that getting started as a Django contributor *can* be difficult, and the core team just being aware of that fact is a good thing. That said, I have no sympathy for the malcontents. I would really rather have seen 1.2 get released than 80+ messages on these two threads. If complaints were patches, we'd be halfway to 1.3 by now. Divisiveness and ill-willed argument is stifling to creativity and progress. I hope this post doesn't contribute to it. I'll close with Benjamin Franklin: "We must hang together or assuredly we shall hang separately." - Gabriel On Apr 19, 7:19 am, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to try to reboot the discussion that's been going on about > Django's development process. > > I'm finding the current thread incredibly demoralizing: there's a > bunch of frustration being expressed, and I hear that, but I'm having > trouble finding any concrete suggestions. Instead, the thread has > devolved into just going around in circles on the same small handful > of issues. > > So: here's your chance. You have suggestions about Django's > development process? Make them. I'm listening. > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Low-Hanging Fruit
I just want to second this suggestion from Russell: On Apr 19, 8:11 am, Russell Keith-Magee wrote: > Lastly, pick anything to do with documentation. This isn't a coding > problem, obviously, but writing up a documentation patch to clarify > some issue will help you get to know Django's Sphinx markup > extensions, and it's good practice for when you submit a bigger ticket > that does requires documentation Even beyond that, taking on documentation tickets will take you into a broad range of areas and have you digging into the codebase to figure out what the correct documentation ought to be. It's a great way to find out what you weren't aware that you didn't know. (that's kind of like preparing for the unexpected...) - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
Brilliant! Absolutely brilliant! - Gabriel On Apr 19, 4:23 pm, Bitrot McGee wrote: > Q: When will Django finally have every feature I want? > A: "Ambition has its disappointments to sour us, but never the good > fortune to satisfy us." > > Q: What the fuck is taking so long? > A: "As we enjoy great advantages from the inventions of others, we > should be glad of an opportunity to serve others by any invention of > ours; and this we should do freely and generously." > > Q: Should certain Trac fields only be editable by commiters? > A: "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > > -- > > I hope this attempt to lighten the mood isn't too distracting. > > To the core team: your efforts are so, so appreciated. Benjamin > Franklin (et al.) know that you have a lot of other things you could > be doing, and that working on Django is too often thankless. Thank > you! You all deserve many, many IRL ponies. A herd of ponies. > > To everyone: I'd like to close with a quote by Richard Penn: "We must, > indeed, all hang together, or assuredly we shall all be forced to use > Rails separately." Please keep that in mind. It seems relevant for > some reason. > > ~Bitrot > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
That's awesome. I'll definitely add to that when I have some time tonight. On Apr 20, 2:49 pm, Robert Coup wrote: > On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss wrote: > > I like this a lot. Especially the "your next steps" part - it makes it > > very obvious what the next thing interested parties should do is. > > > Could you start a wiki page with this stuff? Until we figure out how > > to get it more visible, it could at least serve as a sort of FAQ about > > what different ticket actions mean. Starting it on the wiki means > > folks can pitch in and help get the wording good. > > Tada...http://code.djangoproject.com/wiki/TicketChangeHelp > > Most of it is empty - please help fill it in! > > > > > In the meantime, I'll look into how to get it into Trac somehow. > > I can write you a trac extension/patch - just didn't want to spend the > time on it if nobody was keen. May be as simple as customising the > email template, but we don't want it to send out stuff whenever > someone is added to the CC list, etc. > > Rob :) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
That sounds like a great idea! Even having been at this for a few months I'd watch it just to see how somebody else handles things. On Apr 20, 10:55 am, Alex Gaynor wrote: > On Tue, Apr 20, 2010 at 1:36 PM, Bmheight wrote: > > +1 to Stephen Crosbys' proposal, although I think this would be a bit > > difficult to perform as the Framework evolves and the documentation on this > > would be a bit outdated as time goes on (And have to yet again maintain > > another Document to keep up to date). > > It it still none the less a good idea in my opinion. > > > On Tue, Apr 20, 2010 at 9:43 AM, Stephen Crosby > > wrote: > > >> What could be very helpful here is some education for would-be Django > >> developers. The tutorial format has worked so well for educating new Django > >> users, why not apply it also to Django developers also? After the 1.2 > >> release, why don't we come up with a Django developers tutorial that walks > >> us through the process of solving issues and working on Django. The goal of > >> this would be to help would-be developers understand the Django development > >> process by getting their hands dirty with a real issue. > >> It could begin with a short explanation of the process, go through finding > >> a real (old) example issue in Trac (already solved), it could run down what > >> type of Trac activity is helpful and what is not. Then the tutorial could > >> instruct the reader to checkout an old revision of Django (with the > >> unsolved > >> issue) and how to reproduce the issue. > >> We could show the reader how to apply a bad patch (attached by some > >> less-informed Trac user), then how to run the test suite and notice that > >> some tests fail. Some instruction on how to politely note that fact on Trac > >> might be in order as well as how the patch was rewritten in order to pass > >> the tests. > >> Another bit on proper documentation, some notes on quality, where to get > >> help, what types of issues need discussion on this list would be great and > >> I'm sure there's more that could be included with this type of tutorial. > > >> On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss > >> wrote: > > >>> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley wrote: > >>> > When I finally did submit my first patch, I was terrified of getting > >>> > it wrong and having it rejected. I'd seen it happen on other tickets. > >>> > It wasn't until I got *more involved* and started keeping up with the > >>> > trac timeline--watching the ebb and flow of tickets--that I started to > >>> > understand how the tone on trac had a reason. Until you get that > >>> > perspective, it's hard to know what's right or wrong, and easy to take > >>> > things personally. The core devs can seem imposing or scary simply > >>> > because you don't know them. > > >>> This is *really* good feedback, and thank you very much for it. > > >>> Clearly scaring people isn't our intent, but if that's the result... > >>> well, we're doing something wrong. I really don't want people to be > >>> scared off, and I'm hearing from you and a few others that that's > >>> already happening. > > >>> I don't think I need to enumerate why the tone on a ticket tracker > >>> tends towards the terse -- lack of time, repetition, yadayada -- but > >>> regardless I don't like our process being scary. > > >>> > If anything, my point is that getting started as a Django contributor > >>> > *can* be difficult, and the core team just being aware of that fact is > >>> > a good thing. > > >>> I hear you loud and clear, and I'd love any suggestions you might have > >>> about how we might improve in this area. > > >>> Jacob > > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "Django developers" group. > >>> To post to this group, send email to django-develop...@googlegroups.com. > >>> To unsubscribe from this group, send email to > >>> django-developers+unsubscr...@googlegroups.com. > >>> For more options, visit this group at > >>>http://groups.google.com/group/django-developers?hl=en. > > >> -- > >> Stephen Crosby > >> Web Developer > >> lithostech.com > > >> -- > >
Re: Process discussion: reboot
I just built something in a similar vein as this for my team's internal use. Amusingly, I used Django's inspectdb feature to directly interface with Redmine's database and provide a separate front-end. The data feeds into a javascript graphing library. The ability to visualize languishing issues, activity over time, etc. is really pretty awesome. I've got no experience hacking at Trac particularly, but I can at least speak to how useful having that kind of resource can be. - Gabriel On Apr 20, 2:46 pm, Jeremy Dunck wrote: > On Mon, Apr 19, 2010 at 9:19 AM, Jacob Kaplan-Moss wrote: > > ... > > > So: here's your chance. You have suggestions about Django's > > development process? Make them. I'm listening. > > I have a perception that there are some phases of the ticket lifecycle > where things get stuck -- I think that if you look at this > diagram:http://docs.djangoproject.com/en/dev/_images/djangotickets.png > there is a pretty clear flow, and people are encouraged to pitch in > where ever they feel it might help. > > But in practice, it seems that some of the edges become queues, and > some tickets sit in that queue for a long time -- either because the > next step for that ticket isn't obvious, or because there's a shortage > of triage attention on that particular ticket. > > Earlier in the other thread, someone claimed there were hundreds of > patches ready (but ignored), while the response was "no, those tickets > aren't actually ready" -- the issue was a recognition of procedure, in > that case. Even so, the perception of ignored tickets is part of the > problem-- whether tickets are actually ignored or not, the perception > still would discourage contribution. > > I'd like to highlight tickets that have sat in each queue for a period > of time -- a summary of min, max, mean time in queue (over time), and > a detail view to sort tickets by age in queue, etc. > > I know this isn't well-supported by Trac, but Joseph pointed me at the > XML RPC API--- the pieces are there. I never worked on it; generally, > I felt that the triagers are doing what they can and if anything, my > time would be better spent fixing bugs or triaging. > > But this debate has been at least partially about responsiveness and > the perception of inclusion. > > Triagers, commiters, off-put contributors, do you think this sort of > view would help the workflow and understanding of the ticket status? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: managing javascript and css resources
I like the idea of having these "bundles" or "stacks" for media. Just
thinking out loud here, if there were a compression engine in play
that could do concatenation as well as minification you could have a
useful syntax for ordered combinations of scripts similar to how
ModelAdmin's fieldsets work (using a dictionary of nested tuples).
A quick example:
scripts = {
"head": (
"media/js/script_to_be_loaded_first.js",
),
"tail": (
"media/js/script_that_shouldn't_be_concatenated.js", ("media/
js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
)
}
That would give you the benefit of automated concatenation while
somewhat alleviating the problem Kevin Howerton pointed out about it
best being done by hand.
That's my thought for the moment.
- Gabriel
On Apr 21, 9:18 am, Owen Nelson wrote:
> I've been thinking about this ever since I learned that django's admin
> was going to be using jQuery, but I admit I didn't really consider it
> that important until recently (building sites against 1.2-beta).
>
> I know now is not a fantastic time to be talking about features, but
> this is something I'd enjoy working on (personally), and I am just
> hoping to get a little feedback regarding the design, and how it might
> fit in with everything else going on in django's guts
> (philosophically). I also understand that this isn't something for near
> versions of django, but rather the distant future.
>
> Here's where the pin dropped:
> * The jQuery used by the admin site is conjured using the no conflict
> option and is relegated/isolated to it's own namespace (excellent).
> * There are many projects/apps out there that also rely on jQuery - they
> also "bundle" the framework, but may not be quite so quick to play nice.
>
> In my case, I noticed that when I added a few jQuery-enhanced form
> widgets to a form in my admin site, it resulted in 3 instances of the
> framework being sourced in the document head. Although, this is
> actually ok for the most part in terms of operation (so long as the
> scripted events that come with each widget are bound to the dom before
> the plugin of origin gets wiped by the next sourcing of jQuery), it's
> far from ideal.
>
> There are a myriad of ways to skin this cat, be it a simple
> recommendation to adopt the use of django's jQuery and a template tag
> to provide access to the appropriate script tag, or something more
> structured/engineered/formal
>
> My goal would be to provide app developers with scaffolding to add
> javascript/css resources to the rendered view in a non-competitive way.
> I'm thinking in terms of a template tag that works along the lines of {%
> include %}, but for script and link tags, allowing folks to add scripts
> with an optional way to influence the position in the "stack". A
> similar interface would also be provided for form media, and perhaps
> some kind of helper or shortcut for ease the addition of these scripts
> from our view functions.
>
> I understand that Django has historically been
> anti-javascript-framework-blessing, and I'm wondering if opening this
> can of worms would mean having to incorporate some kind of a pluggable
> backend system (for working with different frameworks, or multiple
> frameworks at a time) - something I've briefly considered, but started
> foaming at the mouth as a result.
> I've also considered the fact that the reaction here might be, "just
> don't - leave it all in the individual's hands".
>
> In closing... don't hit me!
>
> Regards,
> Owen Nelson
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group
> athttp://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
On Apr 22, 1:21 pm, Adam Nelson wrote: > 2. Assign all of these tickets to 1.3 and nothing else: > > http://code.djangoproject.com/query?status=new&status=assigned&status... A, only 900 tickets to work through for 1.3? Don't go too easy on the core team! ;-) All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trac workflow assistance (commiter feedback needed)
I've been dancing around this idea for a while. I know it's not a new
thought, and Alex Gaynor and Justin Lilly even started work on "piano
man" [1]... I'd be curious to know what the state of that project is
and if a few more devs working on it might be able to bring it to a
place where it'd be ready for prime time.
Re-inventing the wheel is usually a bad idea, but at the same time a
Django-based tracker just seems like such a natural choice.
- Gabriel
[1] http://github.com/alex/piano-man
On Apr 25, 11:10 am, "burc...@gmail.com" wrote:
> Hi Russell, Jacob,
>
> What do you think, is it good idea to write django-based bug tracker
> as a trac replacement?
> As we all know, Django would be a perfect fit for such project!
>
> Current Trac templates & layouts can be used for prototyping the project.
>
> On Sun, Apr 25, 2010 at 6:15 PM, Russell Keith-Magee
>
>
>
>
>
> wrote:
> > On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
> >> Hello,
>
> >> On Apr 23, 12:32 pm, Russell Keith-Magee
> >> wrote:
> >>> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
> >>> > Commiters and triagers,
> >>> > I've gone through the contributing doc and tried to identify places
> >>> > that tickets might get stuck (or other places that automation might
> >>> > smooth the process).
> >>> > If you could take a few minutes to give feedback on the list,
> >>> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> >>> > focus effort.
>
> >>> Comments by row number from the spreadsheet:
>
> >>> 2: Would be useful as a work list for people looking for. It would
> >>> also be useful if tickets could be auto-disowned; i.e., if there's no
> >>> activity from the owner after a month, post a comment asking for a
> >>> status update; if no activity after another month, remove the
> >>> ownership. This might get annoying for long-lived tickets with an
> >>> owner that has a vested interest, though.
>
> >>> 3: That's essentially just a list of people who can't (or won't) read
> >>> the contribution guide. I'm not sure tracking that stat would help.
>
> >>> 4: Is essentially a list of 'active tickets'. I keep track of that by
> >>> manually eyeballing Trac updates; it might be a useful stat to have
> >>> exposed for people who don't watch Trac as much as I do.
>
> >>> 5-10: The most useful of the lot for me personally. An automated
> >>> process that applies patches and runs tests would be nice; if it can
> >>> autocheck the appropriate flags ("patch needs improvement", "needs
> >>> tests" etc) that would be even better.
>
> >>> There are edge cases that will make this difficult; e.g., patches that
> >>> span multiple diffs, or tickets where the submitter provides multiple
> >>> alternative patches.
>
> >>> I would also add to this list checks that the test is actually a
> >>> regression test - that is, that the contributed test fails unless the
> >>> rest of the patch is applied.
>
> >>> I'm also not sure if a direct email or adding a comment to the ticket
> >>> in trac would be the best approach. I suspect a comment would be
> >>> better, since it provides a public record of the automated reporting
> >>> activity.
>
> >>> 11: Useful as a working list for someone looking for something to do.
>
> >>> 12-14: Nifty stats, but I'm not sure they would help much
>
> >>> 15-17 would be useful if we wanted to audit the work of volunteers,
> >>> but that's not really something we do. I keep a rough eye on every
> >>> ticket change as they come in; if something looks way off, I'll jump
> >>> on it, but otherwise I just live and let live and let the crowd sort
> >>> it out.
>
> >>> 18: I'd be interested to see what this produces. My gut tells me that
> >>> tags aren't used often enough (or consistently enough) for this to
> >>> provide any real patterns. However I might be wrong. If it works, it
> >>> might be a handy way to work out common themes that need a broader
> >>> approach.
>
> >>> 19: Again, like 3; this is just a list of people who don't follow process.
>
> >>> > Also, I'm planning on building the tool using the XMLRPC trac plugin
> >>> > (I'm assuming the live app can't easily have access to the DB, or that
> >>> > the RPC API's abstractions are useful at the app level). Correct me
> >>> > if I'm wrong.
>
> >>> If you're looking to implement this as a standalone thing, it probably
> >>> *could* access the Trac DB directly, but in the interests of
> >>> everyone's sanity (including Trac's) it's probably best to keep to
> >>> public interfaces like XMLRPC.
>
> >>> However, it's also possible that some of these features would best be
> >>> implemented as a Trac plugin.
>
> >>> I'd also suggest that before you embark on a big Trac-specific
> >>> tool-building exercise that we investigate what we could gain by
> >>> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
> >>> got lots of quirks and bugs that annoy the bejezus out of me, and
> >>> there are many aspects of Django's development process
Re: Trac workflow assistance (commiter feedback needed)
I'm in a similar boat to Russell... LaunchPad's UI always seemed like
a complete disaster to me...
However, in reading through LaunchPad's FAQ to give it a fair chance,
I saw a couple of other features that Trac doesn't have to add to the
list:
* Out-of-the-box OpenID support
* "Bug Expiry" to handle tickets that are both outdated and inactive
* Multi-project bugs (so that different projects can track, say, the
same bug in Python in a concerted manner)
* Sprint management
* Tracker interaction via email reply
* Concrete "triaged" statuses and indicators for "project
supervisors" beyond those available to the community.
* The ability for Launchpad to watch and integrate bugs from other
trackers (such as Trac) in an ongoing fashion.
Not necessarily advocating for Launchpad, just thought it was
interesting.
- Gabriel
On Apr 25, 11:34 am, yml wrote:
> As you have noted I have avoided to the DVCS matter because I knew it
> is a slippery slope and because it don't really matter. Launchpad
> allows you to import branch from many of the popular VCS [1] cvs, svn,
> git, hg. The documentation mention that drupal is using this feature
> to import on a regular basis their "trunk" which is control in a CVS
> repository. This import capability is the reason I kept the DVCS
> aspect out of my initial post my understanding was that nothing
> describes before would require a move from svn to bzr for django's
> "canonical trunk".
>
> I am adding a link to the "Karma calculation" [2].
> Regards,
> --yml
>
> [1]https://help.launchpad.net/Code/Imports
> [2]https://help.launchpad.net/YourAccount/Karma?action=show&redirect=Kar...
>
> On Apr 25, 11:15 am, Russell Keith-Magee
> wrote:
>
>
>
>
>
> > On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
> > > Hello,
>
> > > On Apr 23, 12:32 pm, Russell Keith-Magee
> > > wrote:
> > >> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
> > >> > Commiters and triagers,
> > >> > I've gone through the contributing doc and tried to identify places
> > >> > that tickets might get stuck (or other places that automation might
> > >> > smooth the process).
> > >> > If you could take a few minutes to give feedback on the list,
> > >> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> > >> > focus effort.
>
> > >> Comments by row number from the spreadsheet:
>
> > >> 2: Would be useful as a work list for people looking for. It would
> > >> also be useful if tickets could be auto-disowned; i.e., if there's no
> > >> activity from the owner after a month, post a comment asking for a
> > >> status update; if no activity after another month, remove the
> > >> ownership. This might get annoying for long-lived tickets with an
> > >> owner that has a vested interest, though.
>
> > >> 3: That's essentially just a list of people who can't (or won't) read
> > >> the contribution guide. I'm not sure tracking that stat would help.
>
> > >> 4: Is essentially a list of 'active tickets'. I keep track of that by
> > >> manually eyeballing Trac updates; it might be a useful stat to have
> > >> exposed for people who don't watch Trac as much as I do.
>
> > >> 5-10: The most useful of the lot for me personally. An automated
> > >> process that applies patches and runs tests would be nice; if it can
> > >> autocheck the appropriate flags ("patch needs improvement", "needs
> > >> tests" etc) that would be even better.
>
> > >> There are edge cases that will make this difficult; e.g., patches that
> > >> span multiple diffs, or tickets where the submitter provides multiple
> > >> alternative patches.
>
> > >> I would also add to this list checks that the test is actually a
> > >> regression test - that is, that the contributed test fails unless the
> > >> rest of the patch is applied.
>
> > >> I'm also not sure if a direct email or adding a comment to the ticket
> > >> in trac would be the best approach. I suspect a comment would be
> > >> better, since it provides a public record of the automated reporting
> > >> activity.
>
> > >> 11: Useful as a working list for someone looking for something to do.
>
> > >> 12-14: Nifty stats, but I'm not sure they would help much
>
> > >> 15-17 would be useful if we wanted to audit the work of volunteers,
> > >> but that's not really something we do. I keep a rough eye on every
> > >> ticket change as they come in; if something looks way off, I'll jump
> > >> on it, but otherwise I just live and let live and let the crowd sort
> > >> it out.
>
> > >> 18: I'd be interested to see what this produces. My gut tells me that
> > >> tags aren't used often enough (or consistently enough) for this to
> > >> provide any real patterns. However I might be wrong. If it works, it
> > >> might be a handy way to work out common themes that need a broader
> > >> approach.
>
> > >> 19: Again, like 3; this is just a list of people who don't follow
> > >> process.
>
> > >> > Also, I'm planning on building the tool using the XMLRPC trac plugin
> > >> > (I'
Re: Django unit test coverage
One of the GSOC projects that was accepted is about updating and improving Django's test suite. The guy doing it has expressed interest in using coverage.py to help with the project (whether as a long-term part of django or just for the GSOC project), so there'll probably be more concrete information available in a few months... All the best, - Gabriel On Apr 28, 8:36 am, Vinay Sajip wrote: > Can someone please point me to any information about stats on coverage > of Django's own code by its unit tests? I searched for "Django test > coverage" and "test coverage site:djangoproject.com" but I'm getting > pages about testing code which uses Django using Django's test > infrastructure, and I couldn't spot anything which refers to coverage > of Django's own code. If I've missed something blindingly obvious, > sorry for the bother, but a pointer would be appreciated! > > Regards, > > Vinay Sajip > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trac workflow assistance (commiter feedback needed)
On Apr 30, 8:02 am, Jeremy Dunck wrote: > I haven't heard one proposed. I'll take a look at RedMine and/or > steal ideas from launchpad -- but writing a new tracker isn't the > problem I'm trying to solve. FWIW, I currently use (and administer) Redmine for my company. I'd say it's only a marginal improvement over Trac overall. We like it better because it's more friendly towards non-software project management, and has easy workflow setup. But the big downside: it's Ruby/Rails. The thing is a resource hog, and tends to be slower than I'd like overall. There's a fair plugin community to add cool features, but having tried a bunch of them I'd say they fall in the "unstable" category more often than not. Those are my two cents on Redmine. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trac workflow assistance (commiter feedback needed)
I'd also be interested in working on this, as long as I'm not alone on it. Have you and/or Alex set up any kind of mailing list for it? Do you plan to use git's issue tracker or something else? What's the process plan for getting development kick-started on it? - Gabriel On Apr 30, 11:22 am, Idan Gazit wrote: > FWIW, I spoke with Alex the other week about turning piano-man into a > more finished product. > > So long as core guarantees that they'll at least take a look at > whatever is made, I'm +1 on rolling our own, and am willing to > champion this project. > > I think having something we can easily shape to meet our process needs > will be a Good Thing. A good ticket tracker helps devs paw through the > pile of tickets and keep kicking the ball forward with a minimum of > effort. Reducing the overhead on core will make those people's lives > more pleasant (and free up their time for dealing with, you know, > code.) > > Another benefit: one of the complaints I (anecdotally) hear all the > time is that it is hard to contribute to django. Part of that is the > high bar we set for contribution, and the (necessary) process we > impose in order to prevent oopses, but I posit that a significant part > of the feeling stems from people confusing a lack of activity on their > ticket with a lack of activity. Making it easier for devs to update > tickets will help, and providing some kind of dashboard on project > stats will give us something to point to next time somebody throws > their toys out of the pram because their pony isn't being seen to. > > I'll be in Berlin, and plan to sprint on piano-man there. Plan: > > 1. Figure out a handful of "most useful" tricks that trac doesn't > accomplish, and adding those to piano-man. I particularly like the > idea of baking in some behaviors like timed ticket death and other > things that prevent a buildup of detritus and cut down on ticket > gardening chores. > 2. Put up a test instance with a dump of data from trac. > 3. Kick the tires and see if it engenders interest. > > If people think it's awesome, we'll keep going. :) > > -I > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Upgrading Trac
Is it worth upgrading to the 0.11.X branch with Trac 0.12 scheduled to be out the door within a couple weeks? On the one hand, a brand new Trac release would be more likely to contain bugs than a bugfix branch that's now on it's 7th revision. The configurable workflows and per-user permissions were the big features for 0.11, and both of those require an inordinate amount of setup to be made useful (inordinate being relative to how those tasks are managed in other trackers). On the 0.12 side, the improved query system sounds like it would be a big boost for some of the issues that have been discussed, and live previews, ticket interface improvements, and translations all sound like really good features to have. Just throwing it out there. All the best, - Gabriel On Apr 30, 8:06 am, Jeremy Dunck wrote: > Does anyone have crib notes on what upgrading from (presumed) 0.10.4 > to 0.11.7 would buy us? If not, I can go read changelogs. > > Separate from that, I'd like to open discussion on what it would take > to do the upgrade. > > Who has access to the server? What do I need to do to convince to let > me upgrade? > > This is purely exploratory-- I imagine the workflow stuff I'm trying > to do doesn't really need the upgrade, but Russ complained a bit about > nits, so I thought I'd at least see what's what. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feature idea
I like the idea of boxing up the autodiscover code into a publicly
accessible utility class... it's a problem many people solve for
themselves (myself included) but even moreso it would go well with the
new startup.py proposal that's in the works.
Once it's easy to have things run once at startup, the desire to run
some sort of autodiscovery mechanism from those startup files is
likely to take off. And it's not that it's a hard problem for someone
to solve themselves, but it might be one worth solving once and being
done with it.
The downside, of course, is the cost of maintaining it and ensuring
backwards compatibility going forward.
All the best,
- Gabriel
On Jun 1, 12:02 pm, Gregor Müllegger wrote:
> I also needed this functionality in one of my apps and just went the
> way of copy and pasting the existing solution that is already
> implemented in django.contrib.admin. But making this code reuseable
> would IMO be a benefit for some app developers.
>
> But I think the approach of using an setting for this purpose is not
> the ideal way. Admin does a great job in that way, because it only
> uses the autodiscover functionality on demand. My need for an
> autodiscover functionality was directly tight to a management command.
> I don't want to load these modules unless I invoke the management
> command, which is possible with the admin like autodiscover() function
> instead of using a setting.
>
> My proposal would go into the direction of pulling the autodiscover
> function out of the django.contrib.admin module and putting it
> somewhere in the core. Since the admin needs some special
> functionality on errors while loading an admin.py module from an app,
> I would suggest a Autodiscover class that provides some hooks to be
> better customizable.
>
> Something like:
>
> class Autodiscover(object):
> def __init__(self, module_name):
> self.module_name = module_name
>
> def __call__(self):
> # existing autodiscover code from django.contrib.admin
>
> def pre_load(self, app_label):
> # gets called directly before trying to load an app's module
>
> def post_load(self, app_label):
> # gets called after trying to load an app's module even if the
> # import failed
>
> def on_success(self, app_label, module):
> # gets called if the module was imported successfully
>
> def on_error(self, app_label):
> # gets called if the module didn't exist or import failed
>
> In django.contrib.admin or in any other app we can use:
>
> from django.core.autodiscover import Autodiscover
>
> autodiscover = Autodiscover('admin')
>
> This also provides backwards compatibility since the following snippet still
> works:
>
> from django.contrib import admin
>
> admin.autodiscover()
>
> Yours,
> Gregor Müllegger
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
Personally, I solved this by writing a wrapper around django.utils.cache that can be dropped in transparently. It was a really simple matter to have it take a cache prefix (in my case from settings.py) and pass that into the original functions. It's a pretty easy fix if the core team agrees that it's useful. Seems like the debate might be more around adding another setting for it/ where/how to manage that prefix. All the best, - Gabriel On Jun 1, 8:12 am, Byron wrote: > I ran into a seemingly common problem with cache key conflicts between > two projects that both share an app and the same memcache instance. I > would imagine that being able to optionally set a PROJECT_CACHE_PREFIX > that is prepended to every key when setting/getting would be a nice > transparent way of ensuring there are no conflicts. Obviously if the > behavior is to share cache between projects, then no prefix can be > specified. > > I want to get initial feedback, implications, etc. on this before I > start writing a patch. > > Thanks, > -Byron -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #10284
Hi, J. Alheid, Don't be too afraid to get started. From looking at the history on that ticket (as well as the current codebase), my guess is that Jacob's concern is that there's no mechanism in place for handling what happens to those objects if commit=False. The current patch tells us what *not* to do with those objects, but doesn't do something else with them instead. Obviously it's not good to go ahead and delete anyway if commit is not True, but just bypassing that obj.delete() call would raise a completely different problem. The best way to see if that concern is valid is to write the necessary regression test for the patch. It should verify that under the current trunk the objects are deleted when they should *not* be, and that with the patch applied, the objects are not only not deleted on the first pass when commit=False, but that they are subsequently deleted when they should be later on. Offhand, I think I agree with Jacob that the existing patch will cause problems on the latter part of that test case. I'm sure he knows better than I, though. Anyhow, that's what it needs. Oh, and btw, the chunk of code has moved in the current trunk. The delete call is now at: http://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L604 So the patch itself needs updating regardless. All the best, - Gabriel On Jun 2, 12:49 pm, Shakefu wrote: > Hi, I'd really like to get this ticket resolved, and I'm willing to do > the work personally, but I've never contributed before, so I was > hoping to solicit some guidance. > > It seems to me that we'd need a similar patch to the one already > existing but updated against trunk and a patch for the documentation > to note the change in behavior. I commented last night (Wedg) and > someone set the needs tests flag, but I'm not entirely sure what tests > would be needed, except maybe to validate that commit=False doesn't > delete instances, and commit=True does. > > I dunno if I'm a bit too green with the contributing to take ownership > of this ticket, but I'd like to do anything I can to help get this > ticket's suggested behavior into trunk, for my own selfish reasons. :D > > Please advise, > J. Alheid -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
For the record, the "from settings_default..." method is exactly how my team's largest projects are deployed. It works just fine for us! Even more fun (though bordering on too tricky) is converting INSTALLED_APPS to a set instead of a list so you can add *or* subtract items. This whole argument has gotten silly, though, since Russ (rightly) rejected it about 20 posts back ;-) All the best, - Gabriel On Jun 7, 9:47 am, Tom Evans wrote: > On Mon, Jun 7, 2010 at 5:38 PM, Chris wrote: > > On Jun 7, 10:45 am, Alex Gaynor wrote: > >> On Mon, Jun 7, 2010 at 1:15 AM, Chris wrote: > >> >> try: > >> >> from settings_local import * > >> >> except: > >> >> # It's ok to not have any local settings. > >> >> pass > > >> > This pattern is used by almost everybody it seems. Is there any reason > >> > why this pattern hasn't been adopted by "django-admin.py startproject" > >> > yet? > > >> For one thing I'd say because most *really* large projects realize > >> this is a really bad way of handling settings. > > > Worse than one giant settings.py file? > > >> From my experiences > >> I'd say it makes a lot of sense to invert the dependencies, localized > >> settings require the global defaults, not the reverse. > > > The way I do it (and I'm assuming a lot of people do it this way too) > > is to have global settings tracked in their source control, while > > local_settings is something they have to write manually because it is > > untracked (due to having passwords and all). So it's way lore likely > > that the local settings file is missing instead of the global > > settings. Also, it really doesn't matter if one is more likely to be > > missing because both have to be present in order for the project to > > run. Does it really matter if the global or the local settings file > > raises the import error? > > Having posted the first way, I can appreciate that Alex's technique > gives slightly more control to the person writing the per-instance > config, without some of the cruft. For instance, my 'settings imports > settings_local' technique looks like this: > > try: > from settings_local import * > except: > # It's ok to not have any local settings. > pass > > # Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists, > # so we can append any extra ones supplied in settings_local.py > if EXTRA_APPS: > INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS > > where as if settings.py is the 'local' file, with it loading default > settings from settings_default.py, it could look like this: > > from settings_default import * > INSTALLED_APPS = list(INSTALLED_APPS) + [ > 'some_app', > ] > > The project will always have default settings, so no need for a > try/except block, and we can directly manipulate settings without > having to pass around extra arguments, it's much neater. > > OTOH, it works exactly the same once deployed :) > > Cheers > > Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
Extending the include tag seems like a fantastic idea! I end up
writing the {% with %}{% include %} combo all the time for my reusable
template snippets.
However, I feel like selectively clearing the context inside a
template tag is asking for trouble and/or confusion. It also sounds
like it goes against Django's "templates require no knowledge of
programming" principle. While I can see how you might run into context
name collisions in a *very* large or complicated project, the right
solution there seems like it ought to be to clean up your context and/
or templates outside of the template itself... Even in projects with
dozens of installed apps (both my own and third-party ones mixed
together) I've never had that problem where two minutes of tweaking
couldn't fix it for good.
I'm certainly not saying you don't have a use case for it, or that it
wouldn't be extremely helpful to you. Just that having a tag that
clears the context sounds fishy to me...
All the best,
- Gabriel
On Jun 7, 10:52 am, Marco Louro wrote:
> I'd prefer extending the {% include %} tag actually, but didn't of
> that in the first place.
>
> The clean context implementation was to make sure we don't pass
> variables we don't want to. One of the use-cases is including form
> field "templates", so I have code like:
>
>
>
>
> {% if label %}
> {{ label }}
> {% else %}
> {{ field.label_tag }}
> {% endif %}
>
>
> if there was a "label" variable in the context but not in the
> parameters, the code above would output the wrong values. There is one
> problem with not inheriting the context: {% csrf_token %} will fail.
>
> On Jun 7, 5:35 pm, Łukasz Rekucki wrote:
>
>
>
> > On 7 June 2010 18:13, Jacob Kaplan-Moss wrote:> On
> > Mon, Jun 7, 2010 at 5:03 AM, Marco Louro wrote:
>
> > >> I'd like to propose adding a tag that includes a template with clean
> > >> context, but can accept parameters that will be added to that
> > >> context.
>
> > > Is there a reason to do this as a separate tag? Why not just::
>
> > > {% include "some/template.html" with foo=bar baz=spam %}
>
> > Personally, I would expect this to extend the current context with
> > "foo" and "bar", render the include and restore foo, bar to old values
> > (if any). Using a clean context instead is a bit non-obvious to me.
>
> > --
> > Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: django.contrib.admin.ModelAdmin.formfield_for_manytomanyfield
You're right that formfield_for_manytomany probably ought to be better documented. If you aren't sure how to write a patch for the docs, the best thing to do is to open a ticket for the issue in Trac. That way it will be logged and someone else can look at it, write a patch, and eventually get it committed. File a new ticket here: http://code.djangoproject.com/simpleticket If you need to create an account in Trac: http://www.djangoproject.com/accounts/register/ All the best, - Gabriel On Jun 28, 6:55 am, Massimiliano della Rovere wrote: > Trying to solve (and it is solved now) my problem I found the > undocumented formfield_for_manytomany in contrib/admin/options.py > I think it is noteworth and I think it should be mentioned along > withhttp://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contri... > > I'd modifyhttp://docs.djangoproject.com/en/dev/ref/contrib/admin/ > page by myself but I do not know how to. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion of exception Http301 add as new feature
Http301 doesn't seem entirely correct to me, however I have found use
for an Http302/HttpLoginRedirect exception that can be raised from
anywhere to handle unauthorized users.
If your authorization process is handled somewhere other than directly
in a view or decorator (like in a manager that checks custom
permissions) it can be a nuisance to constantly be checking the
returned value to make sure it's not a redirect. Raising an exception
there and catching it with a middleware works nicely.
I'm not saying that it needs to be in core, but it's been extremely
helpful for me and might be useful for others.
All the best,
- Gabriel
On Jun 28, 8:14 am, Patryk Zawadzki wrote:
> On Mon, Jun 28, 2010 at 12:07 PM, kernel1983 wrote:
> > There is exception Http404 in the system.
>
> > During django programming, we often need to do some data valid:
>
> > def A(request):
> > valid()
> > return render_to_response(...)
>
> > def B(request):
> > valid()
> > return render_to_response(...)
> > ...
>
> > def valid():
> > throw Http301(url)
>
> from django.shortcuts import redirect
>
> def valid(method):
> def decorated(request, *args, **kwargs):
> if not 'Tim' in request.user.called_by_some_people():
> return redirect('some-view', ...)
> return method(request, *args, **kwargs)
> return decorated
>
> @valid
> def A(request):
> return render_to_response(...)
>
> @valid
> def B(request):
> return render_to_response(...)
>
> print 'There you go.'
>
> --
> Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
Hi all,
I'm certainly excited to see improvements in the form rendering arena,
so thanks Russ for putting in the work here!
I work with Django plenty as a programmer, but in truth I work more as
a designer. And as a designer, I've spent more than my share of time
wrangling Django's existing templating mechanisms into forms which
accomplish the requisite goals. As such, I'd like to chime in on a few
cases that certainly matter to me:
1. Ability to add attributes to individual fields.
Preston raised this concern and I strongly second it. It will only
become more important as HTML5 inputs expand the number of valid
attributes (I believe there are 10 or so, at least). If the new form
rendering can't accommodate this it ends up being a -0 for me since
I'll still be writing tags by hand. And I don't think writing custom
chrome is the place to add these types of attributes. They're
functional, not presentational.
2. Ability to alter individual fields without writing out the entire
form.
Tim has been the main proponent of this one so far, and I'm with him.
In the scope of "perfectionists with deadlines" I don't have time to
write out the entire form just to replace the chrome on a single
field! ;-) Not that this is the right syntax or method, but the idea
of being able to do something like {{ myform|
chrome:"birthdate=calendar" }} is VERY appealing. That said, I do like
the "using" syntax you've proposed.
3. Syntax and Readability.
There's been a lot of discussion on template tag(s) vs. filters, and
while wearing my designer hat I'd say that calling a "form" tag to
render individual fields doesn't make sense. Adding a {% field %} tag
or something of the sort sits better with me.
As for filters, I support them in elegance but not at the expense of
functionality. That said, I don't see any conceptual problem with "|
as_ul" since in my mind filters are simply transformations. Anybody
who's used Photoshop has seen the term "filter" applied in a similar
fashion. This leads me to my last concern, though...
4. Layout renderers being loaded implicitly by form libraries.
I'm a HUGE -1 on this. The choice of "as_ul", "as_p", etc. needs to be
as explicit as possible, and the idea that you could load multiple tag
libraries and accidentally override your form rendering sounds like a
nightmare. So, whether these become filters, or arguments to the {%
form %} tag, I really can't support them being implicit in the form
tag that gets loaded. No magic here, please!
Those concerns aside, I really like the rest of the proposal. This
seems like a great step forward, and the ideas about chrome and
doctype sound excellent to me.
All the best,
- Gabriel Hurley
On Jul 11, 8:36 am, Russell Keith-Magee
wrote:
> Hi all,
>
> I'd like to propose a few extensions to Django's form library for 1.3.
> I'm still working on some fine details, but before I get too far, I'd
> like to field opinions so that I can:
>
> * Discover any edge cases I've missed in my analysis
> * Field any criticisms from people with more design/frontend
> experience than myself
> * Determine any related problems that we have the opportunity to
> solve at the same time
> * Find out if there is anyone in the community who is interested in
> helping out.
>
> Apologies in advance for the length, but there's a lot of detail to cover.
>
> With this proposal, I'd like to address three problems:
>
> 1. The layout problem. Django's forms can be rendered "as_ul",
> "as_table" or "as_p", and that's it. These layout schemes can be
> overridden and customized if you know what you're doing, but it's not
> easy to do so. Furthermore, visual layout concerns aren't separated
> from data processing concerns. You need to write (and install) a form
> subclass to implement your own form layout. Although it's good
> app-writing practice to ensure that forms can be easily substituted,
> it's not an enforced or universal practice.
>
> 2. The widget problem. This is a variant on the previous point. A
> designer that wants to use a specialized calendar widget for a date
> field needs to modify form code. This is a complexity that shouldn't
> exist; a designer should be able to specify the widget library that
> needs to be used (with all it's required rendering requirements,
> javascript triggers etc) without modifying views and form processing
> code.
>
> 3. The DOCTYPE problem. Most importantly, there is the closing slash
> problem, but the introduction of HTML5 also means that there are
> richer input types like that aren't available in
> HTML4 or XHTML1. Django current
Re: Proposal: Revised form rendering
Thanks for the thoughtful reply, Russ! Just a couple quick points:
> As noted in my reply to Preston, this should easily possibly using
> chrome; I'm not sure I see why you disagree. The new options may be
> funcitonal, but from my reading of the HTML5 spec, they're functional
> in terms of UX, not in terms of data modification. The widget and
> field are used to process and parse the content of any value that is
> POSTed by a form; anything that the user sees about a form is a
> presentational issue, AFAICT.
Having now read that reply, I see what you mean about the chrome. I
hadn't understood chrome as being something that could be "layered".
It sounded more like your idea was "here is a complete calendar UI
solution" and that to add new attributes you'd essentially have to
subclass/rewrite the whole piece of chrome. If they're "stackable",
I'm all for it.
> > So, whether these become filters, or arguments to the {%
> > form %} tag, I really can't support them being implicit in the form
> > tag that gets loaded. No magic here, please!
>
> I think I understand the nature of your concern, but I'm not sure if I
> agree with calling this magic. You import a library that exercises the
> defaults you want to use. Library loads only survive for the duration
> of a single template, so there isn't any risk of a load in one
> template file accidentally changing behavior elsewhere.
The case where it becomes "magic" is if tag library authors start
including these renderers with bundles of other tags... so you go to
load up your favorite handy tag library, and you forget that it also
comes with a custom renderer, and suddenly you've got a mess on your
hands because it replaced your explicitly-loaded renderer. Admittedly
it's not the most common case, but it still concerns me.
> That said, the block-based {% form %} rendering proposal potentially
> gets around this by opening the possibility of making the layout
> selection a subtag that is explicitly specified in the context of a
> specific {% form %} instance.
That certainly seems reasonable to me.
> Thanks for the feedback, Gabriel.
Thank you!
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Sprint in San Francisco
I'll be there as well! Either set of dates works for me. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/hCK2OwboH40J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Logout user when they change their password.
Options 2 and 4 from that list both involve database-level changes, and thus aren't feasible (our lack of schema migration tools being the biggest problem). Of those, I'd go for option 3 as well. We definitely don't want to store the full hash in the session for obvious security reasons, but a small portion of the hash is probably enough to do the checking, be secure and provide a high degree of confidence that collisions would be unlikely. I'll leave it to PaulM or someone else better versed in hashing to comment on what the appropriate subset might be, or if that's just totally off base. Lastly, I'll add that it'd really be pushing it to get this into 1.4 at this point. I, personally, would be willing to allow it on the basis of it being a security concern, but we'd need to have a really solid patch for it in the next week or so to have time to review it, test it, etc. Once we release the beta it's definitely not making it into 1.4. All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/2FvSlmAuVOIJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: How many Django web pages does it take . . .
FWIF, the code that generates that message is here: https://code.djangoproject.com/browser/django/trunk/docs/_ext/djangodocs.py#L84 Feel free to open a ticket if you like. All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/B_MkGZqmbDQJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: python 3.x
The RHEL/Python 2.4 question was addressed at length not more than a month ago: http://groups.google.com/group/django-developers/browse_frm/thread/b7390024b28a694d/f72c272152e968d7 Russell's reply there spells it out as clearly as anyone will be able to right now... All the best, - Gabriel On Sep 3, 1:27 am, Markus Gattol wrote: > It is actually so that with using __future__ and >=2.6 you already have > most of the things available from Python 3 e.g. print() rather than > print. See table at the bottom of > > http://docs.python.org/dev/library/__future__.html#module-__future__ > > Sure, everybody is raving about Python 3 but 2.6 being the smallest > supported version with Django would already be a huge leap towards 3 I > think. > > As Russell said, looks like RHEL is going to be the indicator as to when > things will move forward. > > If I look athttp://distrowatch.com/table.php?distribution=redhat > however and assume that RHEL 5.5 is going to be supported for quite some > time then I think it might be a long time until Django arrives at 2.6 > being the smallest supported Python version. > > How long are we going to plan supporting RHEL 5.5 and thus Python 2.4 > after RHEL is out? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #13870: Correctly handling database isolation (in PostgreSQL)
I ran into this issue with daemons/scheduled jobs and "idle in transaction" in Django quite a while ago. I have a nice writeup of the problem and solution on this StackOverflow question if anybody's interested: http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-handle-transactions-or-db-connections Ultimately it's a matter of being aware of what Django will, and will not, do for you. The lack of a request/response cycle from the daemon means that the usual connection-closing mechanism [signals.request_finished.connect(close_connection)] never gets triggered. Being a *web framework* it seems reasonable to me that it's built around requests/responses... - Gabriel On Sep 6, 10:09 am, Jordan wrote: > On Mon, 2010-09-06 at 16:47 +0200, Robert Gravsjö wrote: > > Can you please show me the code you're running to reproduce this? > > > Regards, > > roppert > > I've experienced what Patryk is describing here. It seems that the > Django ORM, when not explicitly in a transaction, doesn't commit or > rollback after each query. > > You can reproduce this simply in the dbshell. Go into your favorite > project and try this (replacing `myproject`, `myapp`, and `MyModel` > appropriately): > > from myproject.myapp import models > models.MyModel.objects.all()[:1] > > Now, in a superuser database connection, check the results of "select * > from pg_stat_activity." You should see the database connection from the > dbshell stuck in the " in transaction" state. > > Regards, > Jordan > > signature.asc > < 1KViewDownload -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Sites Framework: RequestSite and get_current
I went to triage a few tickets tonight, and noticed that #8960, #10235, #10608 and #13814 have all arrived at essentially the same conclusion: there needs to be a single idiomatic way to get either the current Site object if contrib.sites is installed, or a RequestSite object if not. All four tickets use the same bit of code, the argument really only lies in where to put it. #10235 adds it as a utility function in contrib.sites.models, #13814 as a separate method on SiteManager, and #8960 and #10608 basically just copy and paste where needed. I'm of the opinion it should have its own home in contrib.sites, but where, and under what name? If we can agree on where this bit of code should live, I'd be happy to get all of these tickets fixed in one fell swoop. For reference, #8960 which has been bumped out of several releases now and is prime 1.3 material. Suggestions? All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sites Framework: RequestSite and get_current
I should add that #10909 is another ticket that ultimately revolves around getting a Site/RequestSite object to have access to the current domain. Easily fixed once this function/method exists. While I'm at it, #10944 would be moved one step closer by having a consistent way to get the current Site/RequestSite as well. - Gabriel On Sep 30, 11:48 pm, Gabriel Hurley wrote: > I went to triage a few tickets tonight, and noticed that #8960, > #10235, #10608 and #13814 have all arrived at essentially the same > conclusion: there needs to be a single idiomatic way to get either the > current Site object if contrib.sites is installed, or a RequestSite > object if not. All four tickets use the same bit of code, the argument > really only lies in where to put it. > > #10235 adds it as a utility function in contrib.sites.models, #13814 > as a separate method on SiteManager, and #8960 and #10608 basically > just copy and paste where needed. I'm of the opinion it should have > its own home in contrib.sites, but where, and under what name? > > If we can agree on where this bit of code should live, I'd be happy to > get all of these tickets fixed in one fell swoop. For reference, #8960 > which has been bumped out of several releases now and is prime 1.3 > material. > > Suggestions? > > All the best, > > - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: How to "lobby" for a ticket to be in 1.3?
Well, looking at those two tickets, #7028 is currently related to the
debate happening on this list ("rethinking raw_id_fields"), so the
best thing to do for that ticket is to actively participate in that
discussion.
For #6903 the ticket is in DDN, which means this is a perfect
opportunity for the core devs to use their new procedural rules.
Basically, you'd be best served by starting a thread particularly for
that ticket here, or hopping on IRC, and politely gathering a
consensus for a particular solution.
In both cases, once that's done you can either write/help write a
patch that has the desired effect, make sure it has docs and tests,
test it on your own systems/projects, give feedback on the ticket...
if you're certain it meets all the criteria at that point you could
even mark it as RFC.
Once a ticket is RFC, a core committer will eventually look at it.
Especially since both of those are old tickets I'd imagine they'll get
attention for 1.3 and won't get bumped again as long as there are good
patches.
Hope that helps,
- Gabriel
On Oct 1, 10:28 am, Marcob wrote:
> I see a huge list of tickets that shoud be in 1.3
> release:http://code.djangoproject.com/query?status=new&status=assigned&status...
>
> Within them I didn't found some that are, imho, a must for every
> Django installation I did in the last two years:
>
> Better raw_id_fields feedback in newform-admins
> branchttp://code.djangoproject.com/ticket/7028
>
> Go back to old change_list view after hitting
> savehttp://code.djangoproject.com/ticket/6903
>
> At each new django release it's a pita to adapt these patches.
>
> How can I help to make these two tickets in the 1.3 milestone?
>
> Ciao.
> Marco.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: How to "lobby" for a ticket to be in 1.3?
Sorry, that was phrased badly on my part. I meant to imply that if someone else wrote a patch, he could help by reviewing it... - Gabriel On Oct 1, 11:47 am, Jeremy Dunck wrote: > On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley wrote: > > ... > > > In both cases, once that's done you can either write/help write a > > patch that has the desired effect, make sure it has docs and tests, > > test it on your own systems/projects, give feedback on the ticket... > > if you're certain it meets all the criteria at that point you could > > even mark it as RFC. > > All correct, except that it's bad form for a person that writes a > patch to mark that patch RFC. Get someone else to review it and mark > RFC. Even frequent committers generally have others review their work > and mark RFC. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sites Framework: RequestSite and get_current
I can see why you might want control at the middleware level, but I'm not sure that's the only/best way to accomplish that goal, and it seems like the subject of a totally separate ticket to me. I'd rather see this set of redundant problems solved in a simple fashion rather than get into a debate over implementing a different feature... just my two cents, - Gabriel On Oct 1, 1:13 am, "burc...@gmail.com" wrote: > Hi Gabriel, everyone, > > I'd also like if such function can support option "developer provides > function that knows the current site based on the request". > That means, "get my site" function ultimately needs a backend connector! > > I think this might be fixed in the way we did with > urlconf:http://docs.djangoproject.com/en/dev/topics/http/urls/ > > So it will be taken from request: > request.site with default implementation to LazySite, with default > implementation of Site.objects.get_current() if sites_installed() or > RequestSite(request). > > That implementation would be overriden with middleware > > What do you think? > > > > > > On Fri, Oct 1, 2010 at 1:48 PM, Gabriel Hurley wrote: > > I went to triage a few tickets tonight, and noticed that #8960, > > #10235, #10608 and #13814 have all arrived at essentially the same > > conclusion: there needs to be a single idiomatic way to get either the > > current Site object if contrib.sites is installed, or a RequestSite > > object if not. All four tickets use the same bit of code, the argument > > really only lies in where to put it. > > > #10235 adds it as a utility function in contrib.sites.models, #13814 > > as a separate method on SiteManager, and #8960 and #10608 basically > > just copy and paste where needed. I'm of the opinion it should have > > its own home in contrib.sites, but where, and under what name? > > > If we can agree on where this bit of code should live, I'd be happy to > > get all of these tickets fixed in one fell swoop. For reference, #8960 > > which has been bumped out of several releases now and is prime 1.3 > > material. > > > Suggestions? > > > All the best, > > > - Gabriel > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=en. > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sites Framework: RequestSite and get_current
There is now a ticket and a patch for this, which includes the utility method and a rollup of fixes for the aforementioned tickets as appropriate. Tests and docs included. Details are in the ticket description: http://code.djangoproject.com/ticket/14386 I'd love to get some feedback on it when possible. Thanks! - Gabriel On Oct 1, 4:12 am, Luke Plant wrote: > On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote: > > I went to triage a few tickets tonight, and noticed that #8960, > > #10235, #10608 and #13814 have all arrived at essentially the same > > conclusion: there needs to be a single idiomatic way to get either the > > current Site object if contrib.sites is installed, or a RequestSite > > object if not. All four tickets use the same bit of code, the argument > > really only lies in where to put it. > > > #10235 adds it as a utility function in contrib.sites.models, #13814 > > as a separate method on SiteManager, and #8960 and #10608 basically > > just copy and paste where needed. I'm of the opinion it should have > > its own home in contrib.sites, but where, and under what name? > > I think a stand-alone function in contrib.sites.models is fine, called > `get_current_site` (or some other sensible colour of your choosing). > Since both Site and RequestSite already live there, it seems a good > place. > > Thanks for your work on this, > > Luke > > -- > "Despair: It's always darkest just before it goes pitch black." > (despair.com) > > Luke Plant ||http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Site app should be able to make absolute URLs #10944
I added some feedback on the ticket. Looks like a good start! - Gabriel On Oct 4, 2:12 pm, Laurent Luce wrote: > Hello, > > I added a patch to this ticket http://code.djangoproject.com/ > ticket/10944">#10944 > > - add method get_url to Site model to return an absolute url based on > a relative path passed as an argument. > - add site_url template tag doing the same > > I am not sure about the method and template tag names. Better naming > is welcome. > > Can someone review the patch? > > I will work on the documentation changes when I get more feedback. > > Laurent Luce -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #13914 Add natural keys to contrib.auth.User and Group models
You've got two sets of feedback on the ticket now. Basically the code is good but it needs tests and docs before getting committed. If you're unsure how to go about writing those, then you can certainly ask for help here. All the best, - Gabriel On Oct 4, 4:57 pm, Cesar Canassa wrote: > I am currently using the patch provided in the > tickethttp://code.djangoproject.com/ticket/13914in my Django project. It's a > small change, but I find it to be very helpful. > > Since the ticket seems to be be inactive I decided to come here and ask for > someone to review it. I am not very familiar with Django internals so I > don't fell very confident in reviewing it myself. > > I will be more than happy in writing tests or improving the patch if > the reviewer find it to be required! > > Thanks! > Cesar Canassa -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ANN: Improving our decision-making and committer process
I think Russell put it very well in pointing out that one of the few big technological impediments in Trac is that there isn't an easy way to see the last-modification time of tickets. Particularly to the point that it's hard to tell when a new patch is uploaded and an accepted ticket might need new review. Could that be made easier through technology, sure... However, from my own observations, a lot of the community contributors tend to be "subject matter experts" who focus in on certain areas. I'll go through and gladly triage a whole set of tickets in an area I know about regardless whether the patches are new or old. The point being that even if the technology was there to make it easier, it's still dependent on the actual volunteers themselves to take action. On a separate note, a few posts back there was mention of the HOWTO page that would encompass the spirit of contributing rather than the law of it. I think that's a fantastic idea and I've started a new thread regarding that issue. Thanks! - Gabriel On Oct 4, 7:32 pm, Russell Keith-Magee wrote: > On Tue, Oct 5, 2010 at 9:58 AM, Tai Lee wrote: > > Hi Russ, > > > On Oct 5, 11:48 am, Russell Keith-Magee > > wrote: > > >> > Perhaps we need another triage stage for these tickets, "Needs final > >> > review" or something? > > >> That's essentially what RFC is. This is an area where our documented > >> procedures have lagged behind in-practice procedures, but we've > >> essentially accepted that once a patch has been written by one person, > >> and reviewed by another and found to be ok, then it's RFC, which means > >> a core committer needs to take a look. > > > I'm happy for RFC to indicate that a ticket is ready for final review > > by a core committer, after being reviewed by at least someone other > > than the patch author. But, I think there's still a problem of > > accepted tickets that have a patch with docs and tests and no feedback > > indicating that it needs improvement, being lost in the shuffle, as > > well as how and why we ever end up with tickets in this state and how > > can the patch author get someone to review their work. > > You can get a list of tickets that meet that criterion very easily - > it's tickets in "accepted" with a "patch needs improvement" flag. > > This doesn't solve the problem of people who review a ticket, but > don't flick the "patch needs improvement" flag or provide feedback on > what exactly is wrong... but no technological solution will fix those > problem. The best we can hope for here is for a second reviewer to > come along and clean up the ticket state. > > > > > > > It could happen that a ticket is accepted on merit, then it gets a > > patch with docs and tests, and then sits there getting no attention > > because nobody knows it needs a review. The patch author could just > > move it to RFC themselves as it had previously been accepted and he or > > she subsequently added the required docs and tests, in order to get > > somebody to look at it. But I think this is generally frowned upon and > > might take up too much core committer attention before the ticket is > > really ready. > > > It could also happen that a ticket is unreviewed and already has a > > patch with docs and tests, if it is reviewed by a core committer (or > > not) and "accepted" without feedback about any necessary improvements, > > shouldn't it have simply gone straight to RFC instead? What should the > > original patch author do when his or her patch with docs and tests is > > reviewed by someone else and moved to "accepted" like this? There's no > > feedback that they need to incorporate into the patch, and they can't > > move their own work to RFC, even though someone else has reviewed and > > "accepted" the patch? > > > I'd like to see the ticket system work smoothly in and of itself, and > > for tickets to be reviewed without the patch authors having to ask > > around on IRC or django-developers for someone to take a look. I don't > > want to make the ticket system too complicated, but I think it is > > already a bit muddled by determining whether or not a ticket needs > > review by checking 5 or 6 different properties, instead of a single > > clear indicator set by the patch author that he or she would like > > somebody (not necessarily a core committer) to review the work. This > > could also help in eliminating another problem of not knowing if a > > ticket is still being worked on or if the patch author considers it > > finished. > > The problems you describe here fall into a couple of categories: > > * People doing triage, but not setting flags or giving feedback > correctly. This is a social problem; no technology is going to fix it > -- especially not adding *more* flags to our Trac configuration. > Improved documentation of what we expect *might* improve things here; > suggestions (and patches!) are welcome. > > * Improving visibility of work that needs to be done. This is > somewhere that Trac gardening is n
Contributing "How To"
There has been repeated talk of putting together resources for new contributors in a way that's more accessible and to-the-point than the current contributing docs. Most recently Russell mentioned it in this thread: http://groups.google.com/group/django-developers/browse_frm/thread/9ebc3e57d539d1ff I would like to put such a page in the official docs together, and to that end I have created a wiki page to serve as the basis for the eventual patch: http://code.djangoproject.com/wiki/ContributingHowTo I've also opened a ticket to hold the eventual patch and track the issue: http://code.djangoproject.com/ticket/14401 Contributions to the wiki page are more than welcome! Thanks, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Congratulations!
If you glance at the revision log for the committers page in the docs, there are actually a couple more ;-) http://code.djangoproject.com/log/django/trunk/docs/internals/committers.txt On Oct 8, 6:15 pm, Łukasz Rekucki wrote: > I just noticed we have 2 new Core Developers: Alex Gaynor and Andrew > Godwin and a new Admin Specialist Simon Meers. > > Just wanted to say: Congratulations guys and keep up the good work! :) > > -- > Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Possible thread-safety regression for sitemaps in r13980
I believe you are correct, since sitemaps are global objects, this would not be thread-safe. Fixing it should be fairly easy, however. Setting self.request was only necessary for two reasons: 1. Sitemap.get_urls() uses it, but either the request or the current_site variable could be easily be passed as a parameter to get_urls. Personally I'd lean towards passing around a current_site variable rather than request objects... Having read through all the arguments about thread-safety for the Class-Based Views feature, it seems like explicit passing should solve the thread-safety issue. 2. FlatPageSitemap.items() uses it... however, flatpages is directly coupled to the sites framework with an M2M field, so the better way to do this is to filter the FlatPage objects based on the current site. You'd never even get to the point of items() being called if you don't have contrib.sites installed so protecting against not having it is useless. I've opened a ticket for it here: http://code.djangoproject.com/ticket/14433 and added a patch which I believe should restore thread safety. - Gabriel On Oct 10, 10:27 am, Justin Bronn wrote: > After r13980, GIS sitemaps were broken, and when attempting to fix I > had questions about the underlying implementation of the changeset: > > http://code.djangoproject.com/changeset/13980/django/trunk/django/con... > > In the loop iterating over the `sitemaps` argument (L12), the `site` > value is a global Sitemap (or subclass thereof) instance typically > defined in a user module. While adding the missing `site.request = > request` assignment in the GIS sitemaps code enables tests to pass -- > this solution appears thread unsafe because we are assigning, on a per- > request basis to the sitemap view, the `request` attribute to a module- > level global. What if two different search engines request the > sitemap index at the same time? Each would be clobbering over the > `request` attribute for the other, producing inconsistent sitemaps. > > First, I'd like more eyes to confirm/deny my interpretation here. > Second, if this is confirmed, how should we solve it -- the situation > is compounded by the fact this changeset fixes 7 tickets. Luke, is > there anyway to decouple this from fixes for the other tickets? > > -Justin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: It is real to add ticket #8054 to 1.3 milestone?
Hi alekam, This is certainly the kind of ticket that we want to deal with in 1.3 since it's been around so long and deferred a couple times. Starting the discussion here is definitely the right way to make it happen. That said, at the very least it needs a thorough code review, a full set of tests, and good documentation before it can be included. I'm not personally sold on the way the functionality is implemented, but I'd have to think on what would be preferable. I'm sure others will have stronger opinions on it one way or the other. All the best, - Gabriel On Oct 12, 9:47 am, alekam wrote: > Hi All, > > I found very useful ticket #8054. This ticket has accepted status and > assigned to brosher about 2 years. The problem describes on ticket > detail page and in the wikihttp://code.djangoproject.com/wiki/ListColumns > The ticket has patch witch passes all existing regression tests and I > plan to write unit tests for it. > It is real to add ticket #8054 to 1.3 milestone? > > Cheers, > > Alex Kamedov -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #6375 -- Class Based Views: Opinions on commit plan
> What do you call this. I don't see how any software developer could > consider constructive criticism as anything other than helping out. You've posted three messages in this thread, but none of them seem "constructive" to me. You've pointed out areas of disagreement and used inflammatory hyperbole, but not offered your alternatives or improvements. While I firmly stand by your right to disagree with this API and anything else you see fit (including this response), this API represents consensus. It is the result of months (maybe years) of work, hundreds of messages between tens of developers, dozens of discussions, numerous attempts at different implementations, and who knows how many man-hours spent on it... In fact, it may be the most thoroughly discussed feature I've seen in my time with Django. So the question stands, what would your implementation look like? How would it improve things and still avoid all the pitfalls that have been mentioned over the course of development? Respectfully, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #6375 -- Class Based Views: Opinions on commit plan
I got my first real taste of the new API today by thoroughly proofing the docs for class-based views. I just wanted to say that there's some great stuff in there, and I give a big thanks to everyone who contributed! I'm really looking forward to using the new class-based views ASAP. Thanks! - Gabriel On Oct 14, 9:19 am, Russell Keith-Magee wrote: > Hi all, > > With the deadline for 1.3 alpha rapidly approaching, it's getting to > crunch time for class-based views. > > The wiki page [1] now contains a good summary of the debate so far, > showing why we have ended up at the "ClassBasedView.as_view()" > deployment solution. I've also got a implementation up on my bitbucket > repo [2] (in the class-based-views branch) that is integrated into the > Django source tree. > > I've done an audit of the simple (template and redirect), detail and > list views, and I'm reasonably happy with the feature set, feature > parity with old-style function views, and test coverage. I've also > checked that the outstanding generic-view tickets (#1282, #2367, > #8378, #9150, #12669, #13753, and #13953) are solved or are solvable > using the new class-based framework. > > The following things are still needed: > > * An audit of create/update views. > * An audit of date views. > * Documentation, including > - changes to the tutorial > - topic documentation > - reference documentation > - a migration guide for function generic views to class-based generic > views > * Feedback from the community on the API that has been exposed. > * Fixing Django's handling of PUT requests (this currently raises an > expected failure in the test suite) > > Unfortunately, the 1.3 alpha deadline is Monday. Over the next couple > of days, I intend to finish my audit of edit and date views, and make > a start on at least reference documentation, but it's highly unlikely > I'm going to get all the items on this list done by Monday. > > So - I'd like to field opinions on committing class-based views in an > 'almost finished' state. > > I won't commit anything until at least my review of create/update and > date views is complete. In particular, I'm not especially happy with > the current state of the create/update views. I'd also like to see a > couple of independent reviews of the API as a sanity check. > > Then, during the beta period, we will need to expand on the > documentation and finish the other outstanding items. I would also > expect to see some minor tweaks to the API as different use cases > emerge. Some of these changes may be backwards incompatible, but I > don't anticipate any widespread changes being necessary. Once we hit > beta, I would anticipate that any backwards incompatible changes we > need to make will have shaken out. > > One piece of evidence supporting this plan: history has shown us that > we don't really get much serious testing of new features until they > hit trunk, and we don't get the *really* serious testing until a final > release is made. Getting an 'almost finished' version into trunk may > actually help the feature develop faster than it would if we postponed > to 1.4, hoping that it will mature in a separate branch. > > Any opinions or objections to this plan? > > [1]http://code.djangoproject.com/wiki/ClassBasedViews > [2]http://bitbucket.org/freakboy3742/django- (class-based-views branch) > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model proxy instance does not equal the respective model instance
Speaking on a semantic level, a "proxy" is a stand-in acting on behalf of (or in place of) another entity. There is an implied near- equivalence, but inherent in the idea of a proxy is that it is *not* the same as the original. As in the case of assigning a proxy to vote for you in corporate elections: the proxy you delegate your right to vote to is the functional equivalent of you, but they are recognized as not *actually* being you. In my mind the same reasoning applies to Proxy Models. While they are a stand-in for accessing the same underlying data, they may have very different properties (ordering, methods, etc.). So while they may pass a rough equivalence test, they are in specific ways dissimilar. The underlying table/data stored by the model is only one piece of what makes up the sum total of a model. That said, I can certainly see the use case for comparing proxy models as equal to the original model... All the best, - Gabriel On Oct 20, 6:24 am, Byron wrote: > Continuing from...http://code.djangoproject.com/ticket/14492 > > > the real issue here is "What is a Proxy", and "what is equality" > > I agree, that is the real issue. I based most of my reasoning off of > what the docs already state in that a proxy model can be written to > extend the behavior of the model being proxied, i.e. the data model > cannot be changed. That being said, I feel the default behavior when > dealing with equality, other data related things... should inherit > from there parent. If there is a need to override this behavior, I am > sure other hooks can be implemented to customize proxy models > differently then there parent. With regards to my primary issue of > equality, in this context two objects are being compared to determine > whether they represent the same row of data. It seems less likely to > compare two model objects to only be interested in whether they are > equal data structures. > > Regarding permissions, the arguments presented > inhttp://code.djangoproject.com/ticket/11154 > all can be accomplished with writing a custom manager for the proxy > model or writing a custom ModelAdmin class for the admin. I agree with > Malcolm that a proxy model's permission should shadow its parent. > > On Oct 19, 9:08 am, Byron wrote: > > > > > Added ticket and patch:http://code.djangoproject.com/ticket/14492 > > > On Oct 17, 12:00 pm, Byron wrote: > > > > I came across an issue when comparing a model proxy instance and a > > > model instance, that is: > > > > obj1 = Entry.objects.get(id=1) > > > obj2 = EntryProxy.objects.get(id=1) > > > > obj1 == obj2 # False > > > > This I feel is a bug and the culprit is in ``Model.__eq__`` where it > > > tests to see if the object being compared against is an instance of > > > the same class of the Model itself.. which will always be false for > > > proxy models being compared to there non-proxied instance > > > counterparts. It should test if it is a proxy and whether the object > > > is an instance of the parent class as well. > > > > Was this a design decision or overlooked? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Admin sends out potentially harmful m2m_changed signals
I'd like to call attention to ticket #6707 [1], which deals with the implementation of ReverseManyRelatedObjectsDescriptor.__set__. Specifically, the problem is that the current implentation takes a very efficient "clear everything and add all the keys back in" approach to managing these relationships. However, since 1.2 gained signals for ManyToMany relationships, this is now a real problem. As reported in #13962 [2] and #14482 [3], rather than sending the correct pre_add/post_add/pre_remove/ post_remove signals based on changes to a ManyToManyField in the admin you instead get a set of pre_clear, post_clear, pre_add, post_add signals containing *all* the keys. This strikes me as having the potential for significant data loss, corruption or duplication if the wrong kind of signals are hooked up. Particularly to the pre/post-clear signals. It would be very easy to see a user accidentally clearing a related table of data with a signal not realizing that the admin application would be sending that clear signal only to add everything back a moment later. So, I want to get some discussion going on the right way to fix the problem. The patch on the ticket uses an extra query and sets to compute the added and removed keys; Malcolm suggested that the admin might independently track the old values to compute what's changed as per #4102. [4] The existing patch has the advantage of being much simpler to implement even if less efficient. What are other people's thoughts? Thanks! - Gabriel [1] http://code.djangoproject.com/ticket/6707 [2] http://code.djangoproject.com/ticket/13962 [3] http://code.djangoproject.com/ticket/14482 [4] http://code.djangoproject.com/ticket/4102 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Admin sends out potentially harmful m2m_changed signals
I see that this issue was also discussed in #13022 [5], wherein Russ argued that the current signals are technically correct but that solving #6707 would be worthwhile *if* it could be done efficiently. [5] http://code.djangoproject.com/ticket/13022 On Oct 20, 2:45 pm, Gabriel Hurley wrote: > I'd like to call attention to ticket #6707 [1], which deals with the > implementation of ReverseManyRelatedObjectsDescriptor.__set__. > Specifically, the problem is that the current implentation takes a > very efficient "clear everything and add all the keys back in" > approach to managing these relationships. > > However, since 1.2 gained signals for ManyToMany relationships, this > is now a real problem. As reported in #13962 [2] and #14482 [3], > rather than sending the correct pre_add/post_add/pre_remove/ > post_remove signals based on changes to a ManyToManyField in the admin > you instead get a set of pre_clear, post_clear, pre_add, post_add > signals containing *all* the keys. > > This strikes me as having the potential for significant data loss, > corruption or duplication if the wrong kind of signals are hooked up. > Particularly to the pre/post-clear signals. It would be very easy to > see a user accidentally clearing a related table of data with a signal > not realizing that the admin application would be sending that clear > signal only to add everything back a moment later. > > So, I want to get some discussion going on the right way to fix the > problem. The patch on the ticket uses an extra query and sets to > compute the added and removed keys; Malcolm suggested that the admin > might independently track the old values to compute what's changed as > per #4102. [4] The existing patch has the advantage of being much > simpler to implement even if less efficient. > > What are other people's thoughts? > > Thanks! > > - Gabriel > > [1]http://code.djangoproject.com/ticket/6707 > [2]http://code.djangoproject.com/ticket/13962 > [3]http://code.djangoproject.com/ticket/14482 > [4]http://code.djangoproject.com/ticket/4102 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: MultiWidgets
Personally, I look at this query every day, so I'm certainly aware of what remains to be done... http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&groupdesc=1&group=stage&component=Documentation&has_patch=1&has_patch=0&order=priority Identifying "low hanging fruit" is a tricky issue, though. I already made one pass at the full list, and everything I marked as "easy- pickings" (the official keyword) was patched and committed real quick. For some perspective: In just a few weeks since the slew of new committers, I've seen that report drop from 170 tickets to the < 130 that it's at now. And there've been plenty of new reports in the interim. There are no longer any docs tickets stuck in DDN... everything that the community triaged and marked as RFC has been wrapped up and committed... now I'm working through docs tickets with existing patches. So, as it always does, it comes down to someone writing a patch. If you don't feel confident writing docs for multiwidget that's no problem. I'd love to work with you on any other tickets you want to take on. And if you ever have questions about the docs or how to write patches, I'm happy to help! All the best, - Gabriel Hurley On Nov 1, 2:13 pm, Paul Oswald wrote: > Is it too late to have the 1.3 Milestone applied to these documentation > issues? > > http://code.djangoproject.com/ticket/13997http://code.djangoproject.com/ticket/11185 > > I'm trying to update some old code that has a custom MultiValueField and > MultiWidget to be 1.2 compatible and I've never made a custom field or widget > before. I have run into some issues and a Google search turns up a lot of > varying quality noise from over the years. At this point, the official docs > are at risk of not being in the first page for the search term "Django > MultiWidget". It sure would be nice to have something authoritative from > someone who understands it. > > More generally, as a relative newcomer to Django I have hit a frustratingly > high number of commonly understood but undocumented usage patterns, > incomplete and unorganized docs and general gotchas. Here is a search query I > wish I had seen on day one: > > http://code.djangoproject.com/query?status=new&status=assigned&status... > > It gives a pretty good overview of where the official docs are lacking. I > don't think I can document subclassing MultiWidget because I can't even get > it to work right (in my admittedly complex use case). Some of the issues in > that list seem like they would be small patches. Would it be possible to have > someone mark the low hanging fruit as 1.3? If I write small documentation > updates/fixes/editing for the things I've run into trouble with but now > understand, will they get applied? > > -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Call for review and comment: #7539 (ForeignKey on_delete)
> Another documentation-related question I have; is it necessary to mark > each passing referencing (and link) to on_delete with the version- > added marker? I went back and forth, and eventually decided against > it, for these reasons: (1) The passing references don't provide enough > info to use the feature; anyone following the link to the actual > feature documentation will see the version marker, and (2) inserting > the version-added markers in places like the QuerySet.delete > documentation made it appear ambiguous to me exactly which paragraphs > the marker referred to; it would be a reasonable interpretation to > think it covered everything through the end of the section, which > would not be accurate. Open to feedback from the documentation experts > here. As much as I'd like to agree that the "versionadded" directives aren't needed for the sake of not adding clutter, I have no doubt that within weeks we'd have someone opening a ticket because they tried to use the on_delete argument with a previous release, not realizing they were looking at the dev/1.3 docs. So here's my recommendation: 1. Add the versionadded directive to "docs/topics/db/queries.txt", and "docs/ref/contrib/contenttypes.txt". For reference, you can make it very clear what was changed/added by using the following syntax (note the *single* line break between the versionadded and the following *indented* text): .. versionadded:: 1.3 The on_delete attribute was [blah blah blah...] Thus the ambiguity about whether this paragraph or that paragraph was changed can be avoided. 2. The documentation for "docs/ref/models/querysets.txt" needs to have a versionadded directive as well, however the bulk of that text needs to be backported to the 1.2.X docs, as per #14599 [1], and the backported text shouldn't have any reference to on_delete at all. It looks like an excellent patch overall. Thanks to everyone involved! - Gabriel [1] http://code.djangoproject.com/ticket/14599 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
In a fit of coincidental timing, I was just being frustrated by this
very issue with inclusion tags today. I'm +1 on supporting kwargs with
"=". It is in fact *more* familiar to someone who works with HTML to
be able to assign attributes in arbitrary order, for example:
http://example.com"; class="green" id="my_id">
works the same as:
http://example.com";>
whereas this is just nonsense:
http://example.com"; "my_id" "green">
and this is even more broken:
http://example.com as src and my_id as id and green as class>
So any argument about not using kwargs being "for template authors"
seems a bit silly to me. Designers may not be programmers (though many
of them are these days), but the reality of the tools they already use
is that this is a familiar syntax.
All the best,
- Gabriel
On Nov 8, 7:16 pm, Peter Baumgartner wrote:
> On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo wrote:
> > +1 for {% include "foo.html" x=1 y=2 %}
>
> > This just seems more natural. My designer agreed based on the {% url
> > %} tags.
>
> +1 for using the = syntax here. My reasons have been mentioned above,
> but to recap:
>
> * and/as gets too verbose and difficult to read if you add more than a
> couple variables
> * HTML uses "=" to set attributes, so this shouldn't be a new paradigm
> for template authors
>
> -- Pete
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
I apologize for the unintentional insult. In retrospect "silly" was a
poor choice of words, and certainly not directed at you specifically,
Jannis. Your opinion is plenty valid, even if we disagree.
The real crux of my argument is this: Django's philosophy of keeping
programming concerns out of templates is a great principle; however,
it creeps into a tacit implication that template authors (in other
words, designers) need to be treated with kid gloves. As someone who
actually came up *as a designer* before I ever learned to code, and
who has been very involved in design communities in the past, I find
the implied necessity of readability specifically for "the target
audience" (designers) mildly pejorative. I'm sure it's not always
meant that way, but that's how it feels when I read these types of
rationales. I'm +1 on readability for readability's sake. -1 on
readability for the sake of "the target audience".
Getting back to the real subject at hand, I like the general human
readability of your syntax (and the current syntax in general), I just
like the "=" a little more. I'm +1 on "=", and +0 on "... as ...".
Either one gets the job done and I'd gladly accept either as they both
solve the same problems.
Thanks!
- Gabriel
On Nov 10, 1:36 am, Jannis Leidel wrote:
> On 10.11.2010, at 09:20, Gabriel Hurley wrote:
>
>
>
>
>
>
>
>
>
> > In a fit of coincidental timing, I was just being frustrated by this
> > very issue with inclusion tags today. I'm +1 on supporting kwargs with
> > "=". It is in fact *more* familiar to someone who works with HTML to
> > be able to assign attributes in arbitrary order, for example:
>
> > http://example.com"; class="green" id="my_id">
>
> > works the same as:
>
> > http://example.com";>
>
> > whereas this is just nonsense:
>
> > http://example.com"; "my_id" "green">
>
> > and this is even more broken:
>
> > http://example.comas src and my_id as id and green as class>
>
> While I appreciate that you think that's a fact, comparing HTML semantics
> with those of the template language doesn't proof anything, at the most shows
> that they both have the concept of parameters. If that's all you are implying
> we should probably move to using arrow brackets?
>
> > So any argument about not using kwargs being "for template authors"
> > seems a bit silly to me. Designers may not be programmers (though many
> > of them are these days), but the reality of the tools they already use
> > is that this is a familiar syntax.
>
> Please stop trying to make a point by calling my argument silly. I've voiced
> my strong concerns about the proposed change but agreed with a different
> proposal.
>
> Jannis
>
>
>
>
>
>
>
> > On Nov 8, 7:16 pm, Peter Baumgartner wrote:
> >> On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo
> >> wrote:
> >>> +1 for {% include "foo.html" x=1 y=2 %}
>
> >>> This just seems more natural. My designer agreed based on the {% url
> >>> %} tags.
>
> >> +1 for using the = syntax here. My reasons have been mentioned above,
> >> but to recap:
>
> >> * and/as gets too verbose and difficult to read if you add more than a
> >> couple variables
> >> * HTML uses "=" to set attributes, so this shouldn't be a new paradigm
> >> for template authors
>
> >> -- Pete
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: IP addresses in docs.
IP addresses definitely don't belong in plain text since they're a value... so that option can be ruled out. Between the other two options, I'm torn: I think that using the ``"some_value"`` notation (quotes inside an inline code block) breaks the visual flow for what's usually an obvious distinction, but it could also be argued that it's technically correct when you're representing a string value. The quotes also serve to differentiate string values from attributes, methods, and other cross-ref targets which are automatically formatted similarly but without the quotes. If you hadn't raised the question, I would have used the double backtick without the quotes. However, thinking about it now I'm undecided... Who else would like to weigh in? ;-) - Gabriel On Nov 12, 4:55 pm, Łukasz Rekucki wrote: > Hi, > > While updating a patch for ticket #7735 I noticed that docs are > inconsistent about how IP addresses should be written. Some are > surrounded with double back quotes (``) and some are plain text[1]. > After a quick search I also found a quoted one[2]. > > Is there a preferred way of writing IP addresses in the docs ? Maybe > we could add a one to contributor docs. > > [1]:http://docs.djangoproject.com/en/dev/ref/django-admin/?from=olddocs#r... > [2]:http://docs.djangoproject.com/en/dev/ref/models/fields/#ipaddressfield > > -- > Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: making URL resolving/reversing gradually more flexible
> I'm not sure how open the core devs > are to non-core devs poking around in core parts of the framework > though. Anyone and everyone is welcome to write patches for any part of the framework! There's no sacred portion that only a core dev can touch. It sounds like you've given thought to the impacts on backwards compatibility, which is always the biggest concern when dealing with something as central as URL resolution. You've done the right thing by opening the thread here, and I'm sure some of the core folks who are more familiar with this area of the codebase will weigh in. Having a patch to look at is even better. Thanks for the contribution and for following through on the right process! - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: IP addresses in docs.
> Hmm, I don't agree. They are not 'values' in the Python sense - if I > type 127.0.0.1 at a Python prompt I get a syntax error. They are no more > values than integers and floats (less so, by the above definition), and > we don't put any special markup around numbers. They would become values > if wrapped in quotes to make them Python strings. I suppose that was my latter point as I reasoned through it: they're only Python values when wrapped in the quotes to make them a string. > So I would go for plain text with no quotes - it seems easier to read > that way and much more in keeping with how I've seen them written > elsewhere. If they appear in the sentence as text that must be typed, > then use the double ticks. So I would have sentences like this: > > Note that the default IP address, 127.0.0.1, is not accessible from > other machines on your network > > In the IP address field, enter ``127.0.0.1``. I can get behind this. It's appropriate to the context, and I never did like quotes inside backticks. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
I like this idea for an additional reason: I look at the Django timeline regularly, but I have ticket detail changes filtered out. Therefore I *don't* see changes like "unreviewed" -> "accepted", etc. I do, however, see ticket status changes (closing, reopening, etc.). Thereby these kinds of changes will be more visible, especially when a ticket is re-opened, presumably with more information. I do have one concern, though... I worry that it might be off-putting to new contributors who may not provide enough information if their ticket is *closed* with needsmoreinfo rather than commented on with "needs more info". All in all, I like it. - Gabriel On Nov 13, 11:58 am, SmileyChris wrote: > On Nov 14, 5:52 am, Daniel Moisset wrote: > > > In most cases we sent a reply back > > to the submitter asking for more details about their problem, but the > > ticket remains in the "Unreviewed" state, still taking the time of > > other triagers looking for tickets to review. > > > Many projects have a "need information" state to report this > > situation. I think adding this to the ticket state diagram [1] would > > be helpful for triagers, and to developers reviewing the ticket list > > and wanting to know how many tickets actually need to be looked at > > before a release. > > > What are the thoughts of the core team on this? > > Here's another more forward solution, requiring less follow-up > triaging: > Have a "needsmoreinfo" resolution. Tickets can be closed with that > with a note to reopen it when more info is provided. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
Having recently set up a Trac installation for another project, I can tell you that making the actual change will require some hacking in the trac.ini file. There's no way to do it through the admin. All the best, - Gabriel On Nov 16, 7:02 am, Luke Plant wrote: > On Tue, 2010-11-16 at 11:34 -0300, Daniel Moisset wrote: > > OK... after seeing a generally positive response (even if there's some > > bikeshedding about the actual implementation which I don't care much > > about, any of the proposals solve *my* problem ;-) ), how can this be > > moved forward? I know the process that django changes follow, but I > > don't know what's the process to change process :) (or who takes the > > decision) > > > Should I open a ticket about this proposal? > > Do open a ticket, because we need documentation patches for this, in the > 'contributing' page. The current page says this: > > “worksforme” > Used when the ticket doesn’t contain enough detail to replicate the > original bug. > > That happens to be very similar to what we are proposing for > 'needsinfo', so we at least need to think about how 'worksforme' is > different. > > This will also require a change to Trac, which I for one don't know how > to do (I don't see the configuration pages I would need in the Trac > admin interface). > > My 2 cents on state vs resolution: > > If we go for a 'needsinfo' triage state, then at some point we will need > to go and close ancient tickets which have 'needsinfo' and the original > reporter has not provided it - presumably closing as INVALID. This will > require some work to do (manual or scripted), and it may well be > incorrect - we don't *know* that the report is invalid (according to our > current definition), we just don't know enough to say it *is* valid. > That pushes me in the direction of a 'needsinfo' resolution. We just > have to remember to say 'Please re-open the ticket when the information > has been provided' - and the 're-open' action is very obvious in Trac - > more obvious than the 'Triage stage' box. > > Regards, > > Luke > > -- > "I spilled spot remover on my dog. Now he's gone." (Steven Wright) > > Luke Plant ||http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
> Maybe trac can be improved in this respect by notifying > reviewers when tickets that they have closed, or accepted, or provided > feedback on, are updated. In my experience Trac already does that... when a ticket is changed (by anyone), the reporter, the owner, anyone on the cc list, and anyone who has changed the ticket (by adding a comment, triaging, etc.) gets an email. I get quite a few notifications every day from Django's Trac install. I can only imagine what it's like for the most active devs. The issue which has already been alluded to is that these are unfiltered streams of information. Getting 30 emails that say someone added themselves as a CC on this ticket or that ticket makes it less likely that you'll see the one email where someone reviewed a patch and marked it as RFC. This is where good Trac queries come in. As always, the rest comes down to the real hours we're all willing and able to put in :-) All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
Bear in mind that this is a *very* old Trac installation... ;-) I don't have access to that server to see if the TracAdmin module is current enough to support the "resolution add " command. If so, that'd be the easy way. If not, like Daniel said, it's straight to the DB! - Gabriel On Nov 16, 5:37 pm, Daniel Moisset wrote: > On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant wrote: > > > This will also require a change to Trac, which I for one don't know how > > to do (I don't see the configuration pages I would need in the Trac > > admin interface). > > If you have the admin module ui enabled and TRAC_ADMIN permissions, > you should see an admin link to the right displaying a dashboard with > a "resolutions" link at the left where you can add ticket resolutions. > If you don't... you should, it helps a lot :) > > Otherwise you'll need to add a row to a table in the trac db. > > Regards, > > D. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: Add a "needinfo" state to triaging
> >> Example workflow: > > >> * Alice creates a ticket, with an incomplete patch (no tests, > >> incorrect implementation) > >> * Bob reviews the patch, marks it "Accepted, needs tests, patch needs > >> improvement" > >> * Alice updates the patch, adding tests (but not changing the > >> implemenation). She removes the two flags. > >> * Charlie reviews the patch, resets the 'patch needs improvement flag' > >> * Alice updates the patch, fixing the implementation. She removes the > >> needs improvement flag. > >> * Daisy reviews the patch, marks it RFC. > > >> At any point in this process, a search for tickets "Accepted & has > >> patch & !needs improvement & !needs docs & !needs tests" will reveal > >> tickets that need review of some kind. These tickets either need to be > >> moved to RFC, or need to have their flags set to indicate the > >> deficiency in the patch. > > > I admit I am guilty of breaking the (unknown to me) rule/etiquette of > > marking my own tickets RFC as a last resort to move them forward. > > To date, this hasn't been formally documented. This is something that > #14401 will hopefully address. Thanks for the example workflow. I'll definitely incorporate that into #14401. I'm gonna give that ticket one last call for "words of wisdom" from anyone who'd like to contribute to the wiki, then write it up as a patch. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Relation between models of different applications
Hi Alex,
Neither of the ideas you mentioned (making auth.user more extensible/
replaceable and improvements to app loading) are new to the Django
community. In fact, both were candidates for last year's Google Summer
of Code. The app loading project even got accepted and had a good deal
of work done on it and will likely be merged into a not-too-distant
Django release (not 1.3).
Both issues are very complex, and there have been extensive
discussions in Trac, on this list, in the IRC logs and everywhere else
you can imagine. Everyone agrees on the problems and the potential
benefits, but finding the right solutions is very difficult.
For some basic reading, I'd suggest taking a look at the GSOC 2010
wiki page. It's at least got a high-level overview of the issues
associated with both of those ideas:
http://code.djangoproject.com/wiki/SummerOfCode2010
A search on this mailing list will turn up plenty more info.
If you have new ideas on how to solve these problems your input is
always welcome; just be sure and familiarize yourself with the
existing (substantial) body of work on the subject as well.
All the best,
- Gabriel
On Nov 18, 8:20 pm, Alex Kamedov wrote:
> Hi all!
>
> It is really hard to replace some django.contrib modules on your own now.
> I'm have many reason to replace django.contrib.auth on my own module now
> in my current project, but in this way I've need to rewrite many others
> applications related with django.contrib.auth, if I want to use it. The my
> project has no long time and ends before any implementation of ideas from
> this message, but I think about future.
>
> Application abstraction is simply collection of models, views and others in
> Django Framework now. I propose extend application abstraction with adding
> something like application type and adding model relation by application
> type.
>
> Example of really reusable application:
>
> auth = get_app('auth')
>
> class MyModel(models.Model):
> user = models.ForeignKey(auth.User)
> ...
>
> get_app can raise AppIsNotInstalled exception, if required application type
> is not specified in project settings.
>
> Proposed changes in project settings to register installed applications:
>
> install_applications(
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> ...
> auth = 'django.contrib.auth',
> ...
> )
>
> install_applications adds applications to INSTALLED_APPS.
>
> Cheers!
>
> Alex Kamedov
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Documentation style guide hint for section headers?
Agreed with Alex. I brought this up on IRC a month or so ago, and the (small) consensus was that it'd be great to have the ":real markup:" generate TOC entries the way we want it to, but that doing so involves hacking Sphinx (or at best writing a plugin for it) and nobody was ready to jump into that project at the time. The issue had been raised before on the Sphinx mailing list, but didn't get a lot of response. However, to answer your question for the time being: In the reference documentation I don't mind the use of the backticks in the headings for methods/attributes. Since the backticks cause the entry in the TOC to show up in white instead of yellow it offers a visual distinction which I think is helpful. I'd carry that distinction through to any future Sphinx improvements that would allow us to get rid of those headings altogether. All the best, - Gabriel On Nov 25, 12:27 pm, Alex Gaynor wrote: > On Thu, Nov 25, 2010 at 2:25 PM, Adam V. wrote: > > The docs seem a bit inconsistent on the use of raw lines for headings > > that describe classes/methods/attributes. > > > The stated preference is to use a directive before the heading to make > > it easier to link. Is there also a preference on whether these > > headings should be raw quoted or normal text? > > > FWIW, my personal preference would be to remove quoting from API docs, > > so for instance, remove it from the headings on this page > >http://docs.djangoproject.com/en/dev/ref/forms/fields/for the field > > and class names. > > > But mostly I just want to know what the official stance is, if any. > > > Thanks. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=en. > > Personally I'd prefer that we only have the :real-markup:, however as > it doesn't generate actual TOC entries it makes them near useless. If > someone, , were to figure out how to have those it would be > awesome ;) > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback required: #14799 -- Problem with setting up test databases
#4 seems reasonable to me, with #3 as a runner-up. As you said: the majority of users can ignore the new setting, which makes it far less of a burden while still offering flexibility. All the best, - Gabriel On Dec 3, 7:56 pm, Russell Keith-Magee wrote: > Hi all, > > I've been looking at #14799, and trying to work out the best approach > for a solution. I can see three options, none of which are are > particularly attractive. I'm looking for feedback on which one smells > the least. > > First off - the problem: > > * The test framework needs to create test databases > * The DB backend call to create the test database implies a call to > syncdb on that database > * But a post_syncdb handler can invoke a query on *any* database > * If the database required by the code in a post_syncdb handler > hasn't been created yet, the test system falls over during database > setup. > * The test databases are specified as a dictionary, so there's no > guarantee on the order in which tests databases are created. > > There is one obvious manifestation of this bug. If you run Django's > own test suite, and the 'other' alias is created before the 'default' > alias, the test suite fails to initialize, because the post_syncdb > handler for contenttypes tries to run ContentTypes.objects.get() on > the 'default' database, but that database doesn't exist yet. > > Jacob has committed an interim fix for this problem, which involves > simply ensuring that the 'default' database is created first. This > works for Django's own test suite, but doesn't work in the general > case -- if you have a router that directs contenttypes read queries to > 'other', the suite will fail for exactly the same reason. Similarly, > if you have some other post_syncdb handler with dependency on > something other than default, > > So - how can this be fixed? > > Option 1: The documentation approach: "You may only assume that the > default database exists when post_syncdb runs on a non-default > database". This is the non-solution; the current code on trunk will be > sufficient, but it will leave some users high and dry. > > Option 2: Force the use of SortedDict when defining DATABASES. This > removes the non-deterministic database creation order, but requires > imports in the settings file, and requires action on the part of every > person that has migrated to using the DATABASES format. > > Option 3: Split syncdb into two parts -- phase 1: create tables, and > phase 2: post_syncdb, custom SQL, index creation and initial data. > > I haven't implemented this -- but I've taken a look at what will be > needed, and it will be messy. The current syncdb command and > backend.create_test_db() API guarantees a full syncdb cycle, so > implementing this in a way that preserves backwards compatibility will > involve introducing a bunch of flags that only do partial syncdb runs > (either phase 1 or phase 2). There's also the question of whether this > will violate any existing expectations -- after all, we will be > effectively changing the order in which syncdb will be invoked in a > non-configurable way. > > Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES -- > that allows the developer to explicitly encode the dependency between > databases. This means the developer can explicitly encode the > dependencies that exists in database creation order. We can default to > assuming 'everything depends on default' (which is what the current > trunk implements); but this gives end users the flexibility to define > any dependency they need. The patch on #14799 implements this solution > (although it needs some tests for the dependency resolution code and > documentation for the setting itself) > > My personal preference is for (4). I don't like the addition of a > setting, but it's a setting that most users will be able to ignore > (since there is a reasonably sensible default), and it is the most > explicit and configurable option available. > > Opinions? Alternatives? > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Purpose of constant_time_compare?
You wanna hand over your paycheck now, or later? :-) I know someone with a functional white-hat timing attack script sitting on their laptop. They've been honing the statistical analysis to get the number of data points needed down to a less noticeable size, but the technique can already be successfully applied. To your latter point, you can run a timing attack as slowly as you like, and a lot of sites have very poor monitoring for things like 404s. A month or more of patient low-level attacking to gain access to a prime target is well worth it. The point being that we all ought to take timing attacks seriously. They're not nearly as unrealistic as people think. All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ForeignKey with null=True
I'm in favor of the patch you've provided, Luke. Raising an exception seems like the best option here to me. While it *is* a logical error to get the related objects of an unsaved instance, the current behavior seems buggy and (as Ian Clelland points out) it can be potentially harmful. FWIW, I'm almost certain Russ's original wontfix was based on the same understanding we all had upon first reading the ticket. It was only when I tested it myself that I saw the behavior the OP was really trying to describe. All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Style guide for section headers in docs?
And that's what I get for having an MLA reference sitting on my desk... - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Regressions in 1.2.4
On Thursday, January 6, 2011 6:29:32 AM UTC-8, James Bennett wrote: > > It'd also be a major > maintenance/bookkeeping headache and, I think, *more* likely to result > in us accidentally crossing the streams while trying to keep track of > what goes on in which branch. > I have the same concern here. With an A.B.C.D system my concern is that a lot of people would simply be confused. It'd be confusing enough for the core team to manage, let alone trying to explain it to users. > Personally, I'd be in favor of keeping the overall release process > as-is -- one release branch, which gets all bugfixes while applicable, > plus highlighting the individual security patches as released -- and > providing better documentation of what the release branch really is > (i.e., not a security-only branch) and how to pull just a security > update if that's what you want. > +1 on that. As long as it's easy for people who *only* want the security patches to get them without any other updates I think that's fine. >From a slightly more philosophical point of view, I'll add two other points of consideration: 1) Even security patches can introduce regressions, so creating a security-fix only branch doesn't inherently provide a regression-free branch; it only make it less likely by decreasing the number of changes which could potentially contain a bug. 2) Any bug is a potential liability for a user. While the bugs that are serious enough to trigger security releases are more urgent, there is a statistical net gain to having all the fixes included in the branch. While it's psychologically frustrating to a user to upgrade and be faced with a new regression that was previously unknown, from a purely mathematical standpoint you're actually better off in the aggregate. All that is to say that a 1.2.5 release is completely appropriate and I'm +1 for it, and I think it's better to continue as we have and be as responsive and responsible as possible when new regressions are found. That's my two cents, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Customizable Separator for slugify
Adding Yet Another Setting doesn't seem like much of a solution here. To the original poster's question I'd say that using anything but dashes for slugify would be very uncommon, but I don't see any reason why the slugify filter *couldn't* take an optional parameter to define what token should be used if some people would find that useful. Providing a patch against trunk with tests and docs are a good way to see it happen. The issue of Russian (or any other unicode) characters with slugify is an unrelated issue. I wasn't around for the initial creation of the slugify filter, but I'm sure the conversion to ascii in it is because Internet Explorer didn't support IDNs until version 7. While a majority of browsers support IDNs now, it's still not 100%. Off the top of my head I'm not entirely sure what the right solution for Django is for that issue, but there are quite a lot of possible solutions that don't introduce new settings. All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Customizable Separator for slugify
I did actually just come up with two problems involved in having a customizable separator for slugify: 1) SlugField would also have to take a parameter to define the separator so that there wouldn't be inconsistencies in the output of SlugField and slugify. This seems like it would be a big pitfall for potential user error. 2) For users who have been using slugify as-is, but then change to a new separator: if you stored a URL path component in your DB with a SlugField then changed the slugify separator from a dash to a something else, not only would you end up with an inconsistent mix of things in your DB, if you ever tried to reconstruct that same URL using slugify you wouldn't come up with the same result. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Kilobyte or Kibibite
Though technically accurate, I would say it goes against the rest of the purpose of that filter: "human readable". And though technically inaccurate, everyone from hard drive manufacturers to major web companies use KB, MB, etc. to represent filesizes. I'd argue that it's become a de facto (if inaccurate) standard. The "why is my hard drive X GB less than what it said on the box" comes up all the time thanks to this wonderful trick of marketing. So while you are technically correct (and that is the best kind of correct), my money's on keeping the filter as it is. Everyone else is more than free to disagree. :-) All the best, - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.sites and multitenancy
I would be more in favor of seeing a new setting to configure `get_current_site()` than seeing the existing `SITE_ID` setting shoehorned into a new purpose (and being permanently misnamed for legacy reasons). For the sake of allowing complete customization of the site lookup process I suppose a new settings makes sense here. As I noted on the ticket, I'm not entirely sure that deprecating Site.objects.get_current_site() is necessary, and there are arguments to be made for both sides. Avoiding user confusion is a good thing, but there are cases where authors may want to make use of the Site model exclusively, in which case the shortcut and its associated caching is still useful. In response to Yuri: 1. You would not need the Sites Framework installed. The get_current_site function works by checking to see if contrib.sites is installed, and returning a RequestSite if not. RequestSite is just a generic object which implements a common interface with the Site model. Using a custom callable could similarly bypass any need for the Site model if so desired, or it could simply be a different way to retrieve a Site object. 2. Allowing a custom callable solves the problem of being tied to a particular model, because your custom callable can return an object of any type you like so long as it implements the appropriate hooks (as RequestSite does). This practice is generally referred to as "duck typing". The "correct interface"--as I understand it--is that all authors should be moving towards get_current_site() as the single point of entry for gaining access to a Site-like object, and that you should not expect the returned object to be a Site instance, but simply that it will behave like one and have an equivalent base set of attributes and methods. All the best, - Gabriel -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Status of InstalledAppsRevision, soc2010/app-loading branch?
I haven't been tracking it closely, but last I heard on the subject is that it's on target for the 1.4 release cycle. So basically once we get 1.3 pushed out (and have a little rest) that'll be towards the top of the heap to be wrapped up and worked into trunk. There's almost certainly still some polishing that needs to happen on it, but like Russ said, it's looking reasonably good. All the best, - Gabriel -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.sites and multitenancy
On Wednesday, January 19, 2011 12:01:57 PM UTC-8, Carl Meyer wrote: > > Contrib.flatpages is an example > of this -- the flatpage model has an FK to Site, so it doesn't make > sense for flatpages to call a method which might return a Site object > or might return something else. It needs a real Site object. In my > mind, this use case is why deprecating Site.objects.get_current() is > not a good option.The current patch on #15089 deprecates I'm very much in agreement here. This is what I ran into when I first tried to replace all the calls to Site.objects.get_current_site() with get_current_site()... there simply *are* cases where a Site object is required, and using the object manager is the right way to do it, as you pointed out. > In my mind, the introduction of a multitenancy hook (in the 1.4 > timeframe) could then look something like this: > Also agreed on the 1.4 timeframe. While there is a valid concern for making sure that get_current_site() (introduced in 1.3) doesn't end up getting changed in 1.4, this whole task seems like it's snowballing a small feature whose main purpose was to be more DRY into a large feature with a totally different goal, and doing so very late in the game for the 1.3 release cycle. > * Add an optional "request" argument to Site.objects.get_current_site(). If > > SITES_BACKEND is set and Site.objects.get_current() is not passed the > request, it's an error. But existing code, with no SITE_BACKEND, > continues to work fine calling Site.objects.get_current() with no > request. > I'm a little uneasy about this... I think it would be an error for Site.objects.get_current() to ever return an object which is not a Site instance, and if we're dealing with arbitrary callables from a SITES_BACKEND setting being responsible for returning a Site-like object it seems like this could break in non-obvious ways. What that means to me is that while you might want Site.objects.get_current_site() to have multiple ways of retrieving the current Site object based on data in the request, I don't think those should be conflated with the arbitrary SITES_BACKEND callables. I'd rather see Site.objects.get_current_site() try more ways of getting the current site if a request is passed in, and/or have a separate method on the Site manager that can take a request and do request-based lookups. Expand the options on the built-in manager but keep them finite. I'd say all the SITES_BACKEND functionality should remain tied to get_current_site() and out of the Site manager. > * Both Site.objects.get_current() and get_current_site() call > SITE_BACKEND, if its set, and return whatever it returns. > Site.objects.get_current() should check this return value and error if > its not an instance of the Site model. get_current_site() doesn't care > what it returns. > See my previous comment. Raising an exception if the SITES_BACKEND callable returns an object of the wrong type is one way to handle it, I'm just not sure it's my favorite solution. Seems brittle given that a developer using a custom callable might not think about how other apps (especially in contrib) are going to interact with the return value of their callable. That's what I've got for now. Thanks to legutierr for the work on the patch so far. All the best, - Gabriel -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: validate urlconfs when the server starts
If you try this in any of the more recent versions (sorry I don't know exactly when this was changed) you'll get a ViewDoesNotExist exception telling you which view in which module it couldn't find. If you have DEBUG = True you'll get a nice Django 500 error debug page giving you everything you need to diagnose the problem. If you have DEBUG = False you'll get an exception in your error log that you can use to debug. This will happen regardless of whether or not the invalid function is actually called or referenced by your templates or other code. And for the record, there's absolutely nothing wrong with using strings instead of actual functions in your URLConf. In fact, I would go so far to say that it is the *preferred* method, and that's why it's in the tutorial. The tutorial (to the best of our abilities) does not contain anything that the core team and/or the community considers "bad practice". Try it out with a current version of Django. If you think there's something more that should be added, feel free to write back. All the best, - Gabriel -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Various small issues
As Russ mentioned, check out ticket #14401 [1], and its associated wiki page [2]. Those should offer some more insight. That ticket was my pet project to start and it's come time to finish it (the vagaries of the real world be damned). If you have particular aspects you'd like to see better explained or that would be more useful, please add them to the wiki or leave them as comments on the ticket. All the best, - Gabriel [1] http://code.djangoproject.com/ticket/14401 [2] http://code.djangoproject.com/wiki/ContributingHowTo -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Contributing Guide Request For Input
Some time ago I opened ticket #14401<http://code.djangoproject.com/ticket/14401>to address the "how to" spirit of contributing to Django as opposed to the hard and fast "contributing reference" that we've got currently. I feel the time has come for me to wrap up that ticket one way or the other, and I'd love to get as much into it as possible before landing it in the docs. The associated wiki page<http://code.djangoproject.com/wiki/ContributingHowTo>has culled quite a lot out of the Django Dev discussions, but I'd still love to get more collaboration on writing this guide. I know there are numerous people who feel very strongly on this subject, so please, be bold and offer your contribution so that EVERYONE will better understand how to work together in contributing! I'm going to give it about another week before I write it up in reST, so now's the time to make your voices heard! Thanks so much, - Gabriel Hurley -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Interested in contributing to Django
Hi Vivek, It's great to hear you're interested in contributing! This year's GSOC is just getting underway and while Django will likely participate as it has in years past, we're not quite at that stage yet. However, if you're serious about GSOC you'll have a much better chance of being selected if you've gotten your feet wet with contributing to Django already. So definitely take on some issues you're interested in. If you'd like some ideas on how to get started, we are actually working on a new "how to" guide for new contributors right now! It currently lives in the wiki so the community can add to it, but it'd be great if you want to give it a read and give some feedback on how it could be made more useful to you as a new contributor! Check it out here: http://code.djangoproject.com/wiki/ContributingHowTo If you have further questions you can always ask here on the mailing list or in the #django-dev IRC channel. All the best, - Gabriel -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
