Re: Renaming of mailing lists to avoid user confusion
On Tue, Aug 19, 2008 at 8:16 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Please take this thread to django-users. This list is for the internal > development of django and this thread doesn't contribute to that. Done. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple weblogs or catecorized news
On Mon, Aug 18, 2008 at 7:36 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > On Mon, Aug 18, 2008 at 7:01 PM, tezro <[EMAIL PROTECTED]> wrote: >> >> Hi all. Got a question unsolved yet. > > Wrong list — you want django-users. django-developers is for > development *of* Django, not *using* Django. ^_^ (And you know, I still think we'd be better off with "django-YES-THIS-ONE" and "django-NO-THE-OTHER-ONE". Or perhaps a tad more seriously, something like "django-community" and "django-core" — otherwise we'll be fighting this battle forever.) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple weblogs or catecorized news
On Mon, Aug 18, 2008 at 7:01 PM, tezro <[EMAIL PROTECTED]> wrote: > > Hi all. Got a question unsolved yet. Wrong list — you want django-users. django-developers is for development *of* Django, not *using* Django. ^_^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Last call for 1.0 alpha
On Mon, Jul 21, 2008 at 10:18 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > If there's anything that absolutely *MUST* be in 1.0 alpha, speak up > now. Please keep in mind that the alpha release is intended only for > the "must-have" features, which are now all in. This means that the > only things that should hold up the release are serious blockers -- > things that would prevent substantial numbers of users from > successfully using Django. Gah, I really haven't had time to do the move-code-out-of-__init__-modules dance. I'm fairly certain that it'll be completely backwards compatible (via re-importing back into __init__), though, so I'm not too worried; I got a tad anxious about it a couple of weeks back, but I can't come up with a scenario that would break existing code. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: QManager - suggested inclusion in Django
On Thu, Jul 17, 2008 at 10:01 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > On Thu, Jul 17, 2008 at 6:46 AM, zvoase <[EMAIL PROTECTED]> wrote: >> >> Dear Developers, >> I've written a module which may be helpful to a lot of Django >> developers, and would like to suggest it for trials and testing, and >> possible inclusion with Django. > > Well, for starters, it appears to be licensed under the GPL while > Django had a BSD license. As long as the conflict exists, your changes > of inclusion are pretty slim, I would think. A general plea to everyone working on Django extensions: if you have any inclination towards eventually seeing your code merged into Django itself, *please* don't release it under a restrictive "share-alike" (to use the CC turn of phrase) license. If Django wants to remain BSD-licensed, it can't accept such code. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Future-proofing against circular imports -- sane for post-1.0?
On Tue, Jul 8, 2008 at 8:49 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > *Deprecation*, dagnabbit! Depreciation is a different word. :-) Ye grammar gods! I'm usually more on top of things than that. Shame on me! ^_^ [...] > Anyway, you've got a few weeks. Probably worth whacking together a first > pass to see that there are no hidden shoals. Good idea; we'll have a much better idea of where things stand. I've done it before in the limited case of django.template, with all tests passing, but this was a few months back; time to take another crack at it. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Future-proofing against circular imports -- sane for post-1.0?
On Tue, Jul 8, 2008 at 6:08 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-07-08 at 09:55 -0500, Tom Tobin wrote:
> [...]
>> I'm curious as to
>> whether others think we can still manage this cleanly post-1.0. If we
>> can, great! — I'll just wait until then. If not, is there any chance
>> we can squeeze this in somewhere?
>
> It depends on what will change. "from django import templates" seems
> like pretty public API. So if your change will mean that any external
> code doing that would have to change it's imports at all (i.e. if things
> that were previously available under the django.templates are no longer
> there), it must be done pre-1.0, otherwise it's not API stable. So work
> that out and then we're in a better position to decide.
I don't want to change the public APIs. If "from django import
templates" works now, it should work after I'm done. The chief BICs
would be for importing non-public pieces, and even in those cases I
think a period with a DepreciationWarning might be justified (which,
being non-public pieces, could be post-1.0).
What I'm trying to achieve here isn't so much for the public API as
it is for private/internal sanity: when someone sits down and
refactors something (the original case being my hacking on
django.templates), they shouldn't be stuck in circular import hell
because the actual code lives in an __init__ module. By all means, if
a public API is better off having a collapsed namespace inside of the
__init__, I don't want to stop that ("from django.templates.base
import *" inside the __init__ should work).
> It sounds like you *are* talking about a change that is that intrusive,
> so it needs to be done beforehand. Just how bad are the import lists
> going to be? Hopefully you can arrange so it's still basically a
> one-file import: "from django.templates import main_file" or something.
> Except you have to think of a better name.
Maybe I'm making a mountain out of a molehill. If the public-facing
API is the only thing we're guaranteeing, maybe there's not much of a
problem 1.0-wise: I could still yank everything out into "base"
modules at a later point. I'm trying to come up with scenarios where
these changes might break someone else's code once made; does anyone
have an example?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Future-proofing against circular imports -- sane for post-1.0?
Since bringing up the topic a few months ago (and getting support for the idea) [1], I haven't had time to whip up a patch to move the contents of various modules' __init__ out into "base" or "main". It finally clicked (you know, several weeks *after* 1.0 features were nailed down, ugh) that this may-or-may-not be such a sane thing to do post-1.0 with a stability freeze. Since I'd like to see non-public API pieces no longer imported back into the __init__ modules eventually (following a depreciation period), I'm curious as to whether others think we can still manage this cleanly post-1.0. If we can, great! — I'll just wait until then. If not, is there any chance we can squeeze this in somewhere? [1] http://groups.google.com/group/django-developers/browse_thread/thread/35aae0e8da804bd9 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ModelForm Choices with session data
On Sat, Jul 5, 2008 at 3:10 AM, Keir <[EMAIL PROTECTED]> wrote: > I have recently been working on my first project in Django and have > encountered a small problem when using ModelForm. Here's my ModelForm > class You're on the wrong list. ^_^ For support questions, you want django-users. The terms "users" and "developers" in this case are probably a tad confusing; everyone *using* Django is a developer of some sort, so many naturally write "django-developers" for help, not realizing that the term is meant to refer to developing Django *itself*. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: tickets and use of the 1.0 milestones
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <[EMAIL PROTECTED]> wrote: >> Even if these sorts of features have a patch and are "Ready for checkin," >> that does not mean they get a 1.0 milestone. They still take core >> developer time to review and commit, time that also needs to be >> focused on higher priority tickets. > > Just out of curiosity, could we fix that bottleneck by appointing more > developers to be core developers? I think that Just Happens once someone has been consistently making quality contributions over a long period. (Other than Whiskey-Media-era Jacob, I don't know how any of them do it; I think you need to take the super-Django-soldier serum first.) ^_^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation
On Thu, Jul 3, 2008 at 9:26 AM, phillc <[EMAIL PROTECTED]> wrote: > > random person: "i need help" > magus: gives technical answer > random person: does understand python > magus: points to docs > random person: you are rude 1) Let's stop referring to specific people, mmkay? I made that mistake, had it pointed out that it was a mistake, and want to make good on not repeating that mistake. 2) The sort of interaction you outline is *not at all* what *I'm* talking about when I feel that someone is being rude. But again, this is the sort of thing I want to understand: what *do* people mean? I consider rudeness to encompass behaviors such as yelling, disparaging remarks, and using a condescending tone. Pretty simple, IMHO. Refusing to help someone who doesn't understand the first thing about Python is *not* being rude; it's merely recognizing that the other person is in the wrong place, and that your time could be better spent helping others. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation
On Wed, Jul 2, 2008 at 7:17 AM, Arien <[EMAIL PROTECTED]> wrote: > > Can we get back to our regular program now and move personal problems > to private communication, please? Thank you. Insofar as referencing particular individuals goes, I agree. I should have raised any issues with particular community members in private, and I ask that others do the same. That said — I do think it would be nice to outline just exactly what is, and isn't, over the line for *anyone*; if we have a yardstick, we can measure, as opposed to this vague "I know it when I see it" pornography-like property of rudeness that everyone seems to disagree on. I honestly don't know if this is the right mailing list for such a discussion; it's certainly not "development of django", but a case might be made that it's "development of the community". I *do* want to have that discussion, however; I'd just like to know where to have it before continuing. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation, or, #django user "Magus-" needs to go far away
On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > why should he be more polite? He follows the policy of 'teaching to > fish' rather than spoonfeeding. I have several times got flamed by > him for getting impatient and giving the answer. I would say that he > is the single most important person in the channel. He has even taken > the trouble of writing a script whereby he can generate almost > instantaneous references to the *relevant* docs. It is easy to give > direct answers - difficult, irritating and time consuming to 'teach > to fish'. Let him be as rude as he wants, as long as he is there. Stepping back for a moment from the way I approached this issue — which I readily admit was the wrong way to do it, and which I apologize to the community for — and the parties in question, I'm concerned with the general sentiment expressed in this thread. It is quite understandable to be grateful to someone for performing a difficult task; it's another thing to allow that gratitude to mute necessary criticism. I think there's room in our community for both charity *and* civility; if we can improve, we *should* improve. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
On Mon, Jun 30, 2008 at 4:29 AM, Antti Haapala <[EMAIL PROTECTED]> wrote: > > 2008/6/27 Tom Tobin <[EMAIL PROTECTED]>: >> >> Well, it stores the *offset*, which is virtually useless in real-world >> applications. > > I haven't tested on 8.3, but on 8.2 it does not. In PostgreSQL, the datatype > "timestamp" corresponds to python naive datetimes. > "timestamp with time zone" instead means: "convert the given input from to > UTC; default to client timezone if none specified explicitly. > When outputting, convert to the client's local time zone." Django uses "TIMESTAMP WITH TIME ZONE" in the "creation" module for the PostgreSQL backends. But yes, PostgreSQL behaves as you describe. > In addition, the time zones are returned in offset format because SQL99 > mandates that :/. If we don't use "WITH TIME ZONE", the offset isn't part of the returned format. > But PostgreSQL never really stores zones, which AFAIK is a violation of the > SQL99 optional feature that specifies timestamp with tz. AFAIK SQL99 doesn't specify storing full zoneinfo-style time zones; PostgreSQL can store offsets, which (as outlined) are fairly useless. >> Since Django does everything with naive datetimes (a *huge* mistake >> IMHO --), > > I second that. However, python time zone aware datetimes are not without > problems either, and those should be considered in Django too. > However, I have yet to publish the blog entry that I've written about it. Well the problem with Python's time zone support is that *it's not there*; the datetime object can take a "tzinfo" argument which should be a tzinfo object ... and then they leave it up to you to implement anything useful. These batteries certainly *weren't* included, alas. Thankfully, both dateutil and pytz have support for zoneinfo-style (i.e., proper) time zones; my code uses dateutil, but I'm considering adding support for pytz as well. If you have a blog entry's worth of thoughts on this, I'd love to see it. ^_^ Once we've been running our time zone code for a few weeks (and I've made the corresponding tweaks), I'd like to write up a full article on the topic. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
On Fri, Jun 27, 2008 at 5:55 AM, Antti Haapala <[EMAIL PROTECTED]> wrote: > > > On 25 kesä, 19:12, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > >> All PostgresSQL supports in terms of *storage* is >> a fixedtimezoneoffset, not the actual zoneinfo name; this isn't >> very useful, and causes problems such as the above. > > Actually, in PostgreSQL TIMESTAMP WITH TIME ZONE does NOT store the > TIME ZONE! I found it out the hard way yesterday. Well, it stores the *offset*, which is virtually useless in real-world applications. All PostgreSQL TIMESTAMPs are stored internally as UTC. Since Django does everything with naive datetimes (a *huge* mistake IMHO, and what I'm trying to correct), the Postgres backend stores these in the database as per settings.TIME_ZONE, with that offset. It also retrieves as per that offset, back into naive datetimes. If you change settings.TIME_ZONE, you now get different naive datetimes back with no way to distinguish them. If you want to use multiple time zones at the same time ... good luck, you'll need it. ^_^ Check out the code in Bulbs (The Onion's open source code snippets) for my current crack at this problem; we're about to push a major site live with my "DateTimeZoneField", and I'd love to see something similar make its way into Django: https://launchpad.net/bulbs It could use better documentation, which is on my to-do list as soon as the APIs stabilize a tad. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Spam detection
On Fri, Jun 27, 2008 at 11:36 AM, rskm1 <[EMAIL PROTECTED]> wrote: > >> Help me out here: how can I make it more obvious? You missed that; >> others often do to. Can you share with me some insights on how you >> missed it? > > I'll chime in. Basic rule of thumb for GUIs: > * If it's going to fail _ANYWAY_, just GRAY IT OUT!! > > In other words, make the form-input fields of the > http://code.djangoproject.com/simpleticket > page simply NOT APPEAR, or be DISABLED, if there is no user logged-in. > > That would make the message about registering and being logged-in > pretty much IMPOSSIBLE to miss =). And nobody will ever again see the > error page about attempting to create a new ticket anonymously. +1; this makes worlds of sense. :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ordered ManyToMany
On Thu, Jun 26, 2008 at 9:05 AM, Mike Scott <[EMAIL PROTECTED]> wrote: > I understand there are some complexities involved, but essentially its > just creating a uniform javascript API to use - not unlike the may we > have a uniform database api. That's a gross understatement. :-) The various Javascript toolkits vary wildly in their implementations; any API attempting to unify them would necessarily become a toolkit-onto-itself, which is *way* out of Django's scope. Many of us probably wish that our favorite toolkit would simply be blessed for the admin and whatnot (yay jQuery!), but that would likely become the largest flamewar in Django history. :p --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation, or, #django user "Magus-" needs to go far away
On Wed, Jun 25, 2008 at 4:48 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Calling someone else out publically is a move of last resort, and one > that should be avoided at all costs. ::sigh:: I'm sorry; after this and another spat on the ChiPy list, I think I'm not very good at the whole tactful-resolution thing. :-( I'll try starting from scratch (starting with contacting Collin directly) in a few days. Meh. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Community representation, or, #django user "Magus-" needs to go far away
I don't spend much time in #django on Freenode, but for a moment, I'd like you to check the logs of that channel. http://oebfare.com/logger/django/ Specifically, I'd like you to note interactions with user "Magus-" (with trailing dash). I think we have a representation problem on our hands. If this guy is the first person most users encounter, they're going to have a *very* different view of the Django community than I consider ideal. I've heard from several individuals that they've migrated from Ruby on Rails *specifically because* our community was nicer; "Magus-" threatens that. I've had an awful experience speaking with Magus; one of my co-workers at The Onion has, as well. But don't take my word for it; check those logs. This guy has to go. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
On Wed, Jun 25, 2008 at 11:17 AM, Ramiro Morales <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 25, 2008 at 1:12 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > >> >> I propose that the PostgresSQL backends start acting like the other >> backends regarding time zones: they should start ignoring them >> completely (i.e., use a plain TIMESTAMP [WITHOUT TIME ZONE], and stop >> using SET TIME ZONE on connections), and leave time zone handling to >> appropriate Fields. All PostgresSQL supports in terms of *storage* is >> a fixed time zone offset, not the actual zoneinfo name; this isn't >> very useful, and causes problems such as the above. >> > > Is this related to ticket [1]1480?. Somewhat, yes; chiefly ticket #2626, though (which I originally reported, and now updated to reflect the proposal above). --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
Thanks to some happy signal magic, I've come up with a "DateTimeZoneField" that takes a "time_zone" argument; time_zone can be a tzinfo instance or a field lookup to a zoneinfo string (e.g., "America/Chicago"). The field can then consume any sort of datetime object, and will always spit back a timezone-aware datetime object (i.e., one with a tzinfo instance attached). This works wonderfully *except* for the PostgreSQL backends; since those backends actually use settings.TIME_ZONE to munge the data coming in and out of the database, things get pathological fast when changing settings.TIME_ZONE or database backends. I propose that the PostgresSQL backends start acting like the other backends regarding time zones: they should start ignoring them completely (i.e., use a plain TIMESTAMP [WITHOUT TIME ZONE], and stop using SET TIME ZONE on connections), and leave time zone handling to appropriate Fields. All PostgresSQL supports in terms of *storage* is a fixed time zone offset, not the actual zoneinfo name; this isn't very useful, and causes problems such as the above. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Experimental Git repository available
On Thu, Jun 19, 2008 at 4:27 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > El jue, 19-06-2008 a las 14:03 -0700, Michael Elsdörfer escribió: >> FWIW (I'm currently playing around with all three of them), bazaar >> appears to support pushing into svn as well. > > Yes, with bzr-svn. Didn't play too much with that one. But Bazaar is > slow, *really* slow. I settled on Bazaar after extensively using both Git and Mercurial; it's *not* that slow, and it keeps getting faster with aggressive monthly releases. (But alas, this isn't the right place for DVCS advocacy.) ^_^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Experimental Git repository available
On Thu, Jun 19, 2008 at 11:39 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I've published an experimental Git clone of Django's SVN repository > (created with git-svn). If you're a Git user and want to use this > repository, be my guest. Please still upload patches to Trac for > review, but mention you're using my clone so I can more easily apply > patches from you. Also let me know if you publish your clones > anywhere; I'll add 'em as remotes. Noted this on the appropriate wiki page (and cleaned up the section on DVCS mirrors): http://code.djangoproject.com/wiki/DjangoBranches --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:32 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 13, 2008 at 1:23 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: >> There is existing multi-lingual aggregator http://djangosearch.com/ > > I didn't realize djangosearch broke articles down by language, > complete with individual feeds! Looks like that's one problem down. > Combine that with Jacob's quick-and-dirty custom search, and maybe > we've already got all the bases covered. I think someone's got a time machine and isn't sharing. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Djangochatter [WAS: Django community aggregator and non-English posts]
Bah, simultaneous thread-splitting. Send any replies to the other "djangochatter" thread. On Fri, Jun 13, 2008 at 12:23 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > On Fri, Jun 13, 2008 at 12:07 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: >> >> There's an aggregator, IRC log, various mailing list archives, wiki >> articles, ticket comments, localized community sites, the list goes on >> and on. In the spirit of community-oriented sites (like djangosites, >> djangosnippets, etc), I'd like to propose djangochatter, a site >> dedicated to aggregated, managing and distributing communication >> taking place in the Django community. >> >> Essentially, it could pull together information from *all* those >> various sources, index it for searching, provide feeds for various >> tags and keywords (users would have to tag entries manually). In light >> of this discussion, I expect it could also reasonably auto-detect the >> text's language, so users could sign up for a feed for whatever >> language(s) they can understand. > > Mmm ... I like. There's a *lot* that goes on out there, and it tends > to be in several different places; having something slurp it all up > and spit it back out to-order would be nice. The Sphinx search engine > (not to be confused with the documentation tool of the same name) > would be a perfect fit, methinks; it's been doing a phenomenal job > indexing disparate nuggets of data and serving them up in an > integrated search for our new project at the Onion. > > >> I don't have time to head this up, but I think it would be extremely >> useful for everybody. I know I've spoken with a few people about this >> in the past, but is anybody interested in heading this up? I'd love to >> see it happen, and I'm more than willing to take part in discussions, >> but I just can't dedicate myself too much to it at the moment. > > Ugh, time. I have a bad habit of assuming I have more of that > resource available than I ultimately do. :) I'd definitely like to > help, but I don't think I could assume a driving role at this point. > (Chicago Djangonauts, languishing taghelpers patch, proper multiple > time zone support ... meh!) Maybe a mailing list for now? > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community search [was: Django community aggregator and non-English posts]
On Fri, Jun 13, 2008 at 12:25 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Also for anyone interested, there's this: > > http://djangosearch.com/ Well. Damn. That looks like what we're talking about here. I wonder if it indexes everything the "official" aggregator does? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:27 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > -100 > > Non-English post isn't noise! > > Some English posts has more less profit then non-English ones. *To me*, someone who can't read them, yes, they're noise. I'm sorry. If I can't read it, it does nothing for me but take up space and time. For someone who can read them, they are certainly *not* noise. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Djangochatter [WAS: Django community aggregator and non-English posts]
On Fri, Jun 13, 2008 at 12:07 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > There's an aggregator, IRC log, various mailing list archives, wiki > articles, ticket comments, localized community sites, the list goes on > and on. In the spirit of community-oriented sites (like djangosites, > djangosnippets, etc), I'd like to propose djangochatter, a site > dedicated to aggregated, managing and distributing communication > taking place in the Django community. > > Essentially, it could pull together information from *all* those > various sources, index it for searching, provide feeds for various > tags and keywords (users would have to tag entries manually). In light > of this discussion, I expect it could also reasonably auto-detect the > text's language, so users could sign up for a feed for whatever > language(s) they can understand. Mmm ... I like. There's a *lot* that goes on out there, and it tends to be in several different places; having something slurp it all up and spit it back out to-order would be nice. The Sphinx search engine (not to be confused with the documentation tool of the same name) would be a perfect fit, methinks; it's been doing a phenomenal job indexing disparate nuggets of data and serving them up in an integrated search for our new project at the Onion. > I don't have time to head this up, but I think it would be extremely > useful for everybody. I know I've spoken with a few people about this > in the past, but is anybody interested in heading this up? I'd love to > see it happen, and I'm more than willing to take part in discussions, > but I just can't dedicate myself too much to it at the moment. Ugh, time. I have a bad habit of assuming I have more of that resource available than I ultimately do. :) I'd definitely like to help, but I don't think I could assume a driving role at this point. (Chicago Djangonauts, languishing taghelpers patch, proper multiple time zone support ... meh!) Maybe a mailing list for now? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:04 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > I'll look into setting up language-specific feeds (and a general > non-English one). If it's easy, I'll do it. If not, anyone is welcome > to look at the djangoproject.com source and submit a patch; I'll > happily accept it. If you can't easily do it, I'll look into it; this is my bitch/gripe, after all. :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:02 PM, Arien <[EMAIL PROTECTED]> wrote: > > The non-English posts are clearly useful to the Django community as a > whole, as it appears that the majority of its members don't speak > English as their native tongue. I'm totally fine with non-English feeds being available. >> Having *only* a [language-agnostic] firehose feed, as we do now, is a >> problem. > > Why? Because, as I've mentioned earlier: users effectively get noise in their feeds. For any post in a language other than English, *the vast majority* of the Django community won't be able to read it. I'm not only talking about native English speakers here; why should we expect that a native Portuguese speaker will be able to read a Russian post? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 11:33 AM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > > It is not a problem. Just skip non-English posts at all. English is > international language of cource but not the one. Except it *is* a problem when I'm forced to deal with a regular influx of what is, to me, *noise* in my aggregator. I've come fairly close to actually unsubscribing from the Django aggregator over this; I thought I'd see if anything could be done before I lose what is otherwise an excellent resource. Again: I'm not suggesting that everyone speaks English, or that everyone should suddenly start posting in English even when their intended audience is local. I'm pointing out that the *core* language of the Django community is English (or have we been speaking something else on django-users and django-dev?), and that the primary feed should be English. I'd be *fine* with alternate-language feeds being available; I'd even be roughly +0 on making an English-only feed the "alternate". --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 11:31 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I propose an option on the side of the page that asks whether or not > to translate the posts into english. The google translator is fairly > effective and a lot of the russian posts I have looked at have bee > very good(at least as good as they can be in. A slighty mangled > state). Interesting idea (using Google translation); an alternate "firehose" feed using that might be one option. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 11:01 AM, pi song <[EMAIL PROTECTED]> wrote: > Are they real posts? I thought just spam. They certainly *look* like real posts, but I can't understand anything outside of the technical (English) terms used. :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django community aggregator and non-English posts
The Django community aggregator includes non-English posts, which are unfortunately pure noise for those of us who don't understand other languages. Can we either restrict the aggregator to English posts, or at least create sub-feeds for English and non-English posts? I don't mean to tread on the toes of those making non-English posts, but English is the lingua franca of most open-source development (including Django); non-English posts are of dubious usefulness to the Django community at-large. By no means do I suggest that these individuals cease posting; I only question whether those posts belong in the aggregator. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: pluralize filter bug(?!)
On Tue, Jun 10, 2008 at 7:13 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> However, I'm happy to defer to
> someone with a higher degree in grammarnazism.
With that in mind, I whipped out my copies of the Chicago Manual of
Style and Garner's Modern American Usage last night.
And came up short. :/
Reading through all the entries for "plurals", "numerals", "count
nouns", and the like yielded nothing useful. I'm strongly inclined
towards making anything other than the integer "1" be plural, but
there are oddities:
1) Decimals between 0 and 1: is it "0.5 meter" ("one-half meter") or
"0.5 meters" ("point-five meters")?
2) Negative 1: "-1 dollar" or "-1 dollars"?
3) The decimal "1.0": "1.0 second" ("one second") or "1.0 seconds"
("one-point-oh seconds", perhaps in deference to the significant
digit)?
I'm almost ready to burn an Ask MetaFilter question on this. ^_^
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Django releases
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > * Wait for newforms-admin to be done, merge it, and release 1.0 (well, > a series of beta/rcs, then final). This has been "plan A" all along. +1; this is The Right Thing. > * Release an interim release right away to respond to this supposed > "outcry" for a release. I've been opposed to this all along because I > don't the quality of something released just to get folks to shut up > will be all that high. A snapshot with an "official" number will > likely do more harm than good. -0; this is silly and wastes time, but isn't as actively harmful as ... > * Start a "train release" schedule: schedule a couple of 1.0 betas, a > rc or two, and then a final release. Features that are done by the > dates get released, those that aren't, don't. Make these dates > aggressive but not crazy. And -- here's the controversial part -- make > newforms-admin an "optional" part. If it's done, awesome; if not, > include it in the next release. The current admin has some bugs, yes, > but it's usable enough. As long as we advertised that it's on the way > out we shouldn't have too much trouble. -1. Releasing 1.0 with a major feature's implementation already depreciated seems like The Wrong Thing, no matter what project we're talking about. Echoing others: once we're past 1.0, this sort of aggressive timeline would be fine for minor releases. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ModelForm fieldsets?
On 2/18/08, Brian Rosner <[EMAIL PROTECTED]> wrote: > > > Is there any good reason why the "fieldsets" option of ModelAdmin (in > > newforms-admin) shouldn't be pushed down into the newforms library? > > What I'm doing right now by overriding change_form.html would be even > > easier if I could define my fieldsets on a ModelForm. > > I don't see reason why it shouldn't be at the newforms level. I agree > with Malcolm and say that this shouldn't be scoped to just ModelForms. Yeah, I never meant to imply that it should be limited to ModelForms; that just happened to be my use case. ^_^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [PATCH]: QuerySet in extra_context in generic views
On 2/12/08, Waldemar Kornewald <[EMAIL PROTECTED]> wrote: > Hi, > since Trac does neither allow me to post anonymously nor do I get a > registration mail (username wkornewald) I'll post here: Please don't post patches to the mailing list. Trac is the right place for these. If you're having trouble using Trac, *say something*! :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ModelForm fieldsets?
Is there any good reason why the "fieldsets" option of ModelAdmin (in
newforms-admin) shouldn't be pushed down into the newforms library?
What I'm doing right now by overriding change_form.html would be even
easier if I could define my fieldsets on a ModelForm.
Related to how I'm working around it it would be nice if the
change_form template had a {% block field_sets %} around the fieldset
include section. (I suppose I'll punch up a ticket and 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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Future-proofing django.template (and elsewhere) against circular imports
On 2/2/08, Justin Bronn <[EMAIL PROTECTED]> wrote: > > > I'm *way* off base at the moment (and stuck gradually walking towards > > HEAD, fixing my patch in increments; this is where git definitely has an > > advantage over hg, but I'm using the latter). > > I've found hg-svn to be particularly useful in helping me pull changes > from the various SVN Django branches -- if you aren't already using > it, it's definitely worth a try. Nah, I mean something different my patch is out of date, and if I try to apply it against HEAD, it breaks ... and furthermore, it's hard to immediately tell how to fix it. By gradually advancing towards HEAD, and fixing smaller breakage as it comes up, I stand a better chance of sanely figuring out how to bring it up to date. (I'm already thinking up an extension that combines "hg bisect" with "mq", hmm ) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Future-proofing django.template (and elsewhere) against circular imports
On 2/1/08, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I'm probably -0 on this. It's a little unnecessary code churn and being > able to track what lines changed when is unbelievable handy, so code > shuffling should be resisted. Copying in subversion retains history; why would we lose anything if we created the new module via "svn cp" before further tweaking? > Obviously some utility methods might need to be moved (I guess > standalone argument parsing functions are probably a case you hit), but > the overall template lexer and parser shouldn't be introducing circular > dependencies and really is the primary entry point. It's going to take a couple of days before I remember what blew up on me; since I've been a naughty boy and haven't been merging my local repository to trunk, I'm *way* off base at the moment (and stuck gradually walking towards HEAD, fixing my patch in increments; this is where git definitely has an advantage over hg, but I'm using the latter). > I'd prefer to address specifics here and fix the particular > implementation oddities that cause problems than "let's move the whole > thing" at this point in our development. Working out "what were they > thinking/smoking when..." is too useful. I agree with your reasoning, but I'm not sure it applies ... unless I'm just plain wrong about Subversion's history tracking, in which case, feel free to smack me upside the head. ;-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Future-proofing django.template (and elsewhere) against circular imports
I'm in the midst of resurrecting my "taghelpers" code that makes writing complex template tags much easier; as with all my patches, I'm using Mercurial to track Django locally while I work on them. Thing is, I've moved nearly everything out of django.template.__init__ into a django.template.main module in order to avoid some circular imports ... and it's nigh-impossible to automatically track upstream changes to django.template.__init__ after that point. That said, I'd like to propose that the majority of the contents of django.template.__init__ be preemptively moved to django.template.main, and imported back into __init__ as necessary. Furthermore, I'd like to see all use of __init__ modules for holding more than "moment-of-import" code to cease, for reasons of avoiding said nasty circular imports. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: deprecated Model.__init__(*args)
On 1/29/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I'd make the ``*args`` style start issuing DeprecationWarnings > immediately, and remove support entirely when we wipe deprecated > features in the run-up to 1.0. I'd make this change on the > queryset-refactor branch. I'm inclined to like *anything* that helps queryset-refactor along. ^_^ I've never been in the habit of using positional arguments for model instantiation (too confusing), so a +1 for axing it. The fromargs() alternative seems like a decent compromise. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: BaseHandler
On 1/28/08, Kaelten <[EMAIL PROTECTED]> wrote: > So I've had to dig into the handler setup for various things. Since then > I've broken down the handler and refactored more common code code into > BaseHandler, and cleaned up the error catching to I've tested the WSGI > handler and it works under 404 or 500 or other. Could you drop this on a ticket in Trac instead? That's our preferred way of reviewing patches. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
PyCon, The Onion, and model inheritance
Over at The Onion, we're working on a major new project in Django. (By "major", well, let's just say that it doesn't end in "theonion.com" or "avclub.com".) We absolutely *love* Django to pieces ... especially me, considering that Django's the reason I was hired. ^_^ Just like everyone, though, we have a list of stuff we'd like to improve; at the top of that list is model inheritance. So, we'd like to put our swag, and our keyboards, where our collective mouth is. (Or something like that.) We're planning on attending PyCon this year; during the sprints, we'd love to get a Django (sub-)sprint going on with a focus on model inheritance. We're looking to bring as much Onion swag as we can to the Djangonauts shirts and copies of Our Dumb World, at the very least. If model inheritance is still too much of a long shot by that point (e.g., if queryset-refactor is still in progress), we'll be happy to help work on the prerequisites instead. We'd like to blend nicely with the Django sprint-proper; whatever we can do towards that end, we're all ears. If anyone has any suggestions for fun Onion-type stuff we can do fire away! My boss is also interested in doing a lightning talk about our experiences using Django; if he does, we'll likely announce the new site that way (as if you didn't have enough reasons to attend PyCon, right?). --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: wiki coordinator position
On 9/20/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On 9/20/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I'd certainly like to simply > > "be bold" as per Wikipedia and be a bit more aggressive with improving > > the wiki, but of course the Django wiki isn't Wikipedia -- I don't want > > to step on anyone's toes! > > No, no -- please do! We need someone who'll take control. Besides, if > you screw up, I know where you live... > > :) > > Jacob Arr, that be true. I'll strive to see that ye and yers haven't th' ambition to sink mah ship and run meh through! (Apologies for getting Sep. 19th out of my system a little late.) ;-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: wiki coordinator position
On 9/20/07, Scott Paul Robertson <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 24, 2007 at 06:52:54PM -0500, Adrian Holovaty wrote: > > > > On 7/24/07, Scott Paul Robertson <[EMAIL PROTECTED]> wrote: > > > [ Discusion about editor for development wiki pages... ] > > > Since I'm throwing out the idea, I'm willing to do this. Is any one else > > > interested? > > > > This would be fantastic. It gets a big +1 from me. > > > > So someone out there may be asking, "What happened with this?" > > Answer: I have dropped off the face of the planet. > > Status: I'm not coming back anytime soon. > > I'm really bummed by this, I really was looking forward to helping out. > Life reared its ugly head and I'm not in a position to trim the wiki and > edit pages. I thought I should let people know. > > It would really keen if someone else picked this up, I still think the > Django wiki could benefit from a light hand keeping things orderly. > > In the spirit of the day (what there is left of it): "Avast ye sea dogs, > will one of ye take the plung to help the wiki?" :) Arrr, matey ... I'd be willin' to take up yer flag! Err, translation ... I'd be willing to do it. I've already found myself cleaning up stuff here and there simply because I'm a grammar/usage/organization nazi. I even started work on a TextMate bundle for Trac Wikis at one point. ^_^ I'd certainly like to simply "be bold" as per Wikipedia and be a bit more aggressive with improving the wiki, but of course the Django wiki isn't Wikipedia -- I don't want to step on anyone's toes! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for discussion on #5535
On 9/19/07, James Bennett <[EMAIL PROTECTED]> wrote: > > David Cramer has asked that Django's ORM lookup syntax be changed to > allow a single underscore for a foreign key lookup; in other words, > the following two examples would become equivalent: > > UserProfile.objects.get(user__id=3) #Currently works > UserProfile.objects.get(user_id=3) #Currently does not work > > Relevant ticket is #5535: > > http://code.djangoproject.com/ticket/5535 *Way* -1. I don't want to be looking at code and wondering whether a particular query is dealing with a local field named "foo_bar" or a related model "foo" with a field "bar". --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Breaking out Django templates into a standalone library
On 8/8/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > What I *do* think is worth fixing is allowing the template system to > be used on its own, for the simple, common case, without having to > configure stuff. This is what I was trying to explain in my last > e-mail. Tom, if we solved that, would you be happy? > > In short: I want to understand your goal. If you want to offer a > smaller download, then that doesn't justify the hassle of making this > change. If you want us to make it easier to use the template system > without configuration, let's talk. Forget I suggested anything. I don't really have the energy to keep arguing here; it's tiring when everything I suggest gets throughly shot down (and that's besides whether said shooting-down is valid or not; even if it's perfectly valid, it's *still* tiring). I'm not helping, so I'll move along. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Breaking out Django templates into a standalone library
On 8/8/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 8/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > A couple of other areas are going to be at least equally as > > interesting... > > Malcolm has made some *really* good points throughout this thread, and > I'm convinced that going down this path would be a not-so-good idea. > > My opinion on it at this point could be be classified as "blah," or > possibly "meh." > > I have a feeling that the underlying reason for wanting a standalone > django.template, deep in our collective subconscious, is that the > settings.configure() thing is inelegant. I shouldn't have to configure > anything just to use the template library. I should be able to import > django.template.Template and django.template.Context, and use them > immediately to render some text. I think there's a good psychological / community case to be made for making django.template available standalone; as I put it earlier, many people just don't like importing stuff they don't intend to use, no matter how small it may be byte-wise. Requiring someone to install Django just to use the templating system is going to prevent them, in various cases, from bothering at all. > I think some work in this area *would* be worth it, as it would make > it easier to use Django's template language in a standalone setting > but would stop short of being a complete reorganization of the code > and architecture. I don't really intend for things to get *that* reorganized; packaging and whatnot aside, my goal is for django.template to work without the rest of Django installed. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Breaking out Django templates into a standalone library
On 8/8/07, Robert Coup <[EMAIL PROTECTED]> wrote: > On 08/08/2007, James Bennett <[EMAIL PROTECTED]> wrote: > > > > On 8/8/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > > I'd ideally like the Django installer to detect if django.template was > > > already on the system, and drop Django into the same spot. As far as > > > versioning, Django should check for a minimum version of Django > > > templates (i.e., the version at the time of that Django's release), > > > assuming it was already installed on the system; if it detected a > > > version below the minimum, it would be nice for the installer to offer > > > to simply overwrite the entire django namespace. > > > > In theory, setuptools can do this sort of "namespace" trick, but the > > system which handles that has always seemed a little clunky to me. > > My concern would be when "setup.py install" does too much clever trickery > and starts conflicting with distribution packages. You install > django-templates via setup.py and it ends up in > /usr/local/python2.5/site-packages, then you install django > & templates from your distribution and presto, your django install now pulls > in templates from a different version. > > I know its a contrived case and there are many other opportunities for > making a mess of a system, but i'd be concerned about setuptools needing to > do anything but the basics. I'll definitely be looking into as many corner cases as possible with installing Django on top of an existing Django-templates install; I really do want it to be as painless as possible for those who might try Django after playing with just the templating system. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Breaking out Django templates into a standalone library
On 8/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-08-07 at 17:39 -0500, Tom Tobin wrote: > > At the end of the angsty autoescaping thread (said angst in no small > > part from my direction ^_^), I floated the idea that perhaps my > > concern over autoescaping was pointed in the wrong direction -- that it > > might be time to split Django's template module out into a standalone > > library. The idea has been raised before, but discussion always hits > > the point of "good idea, but a PITA ..." and a combination of time > > constraints and the bystander effect kick in to shelve it. > > That isn't my recollection, and I was involved in some of those previous > discussions. The main argument is that it isn't a really good idea, for > reasons outlined below. You don't address why we would want to do this. Err, to make it more straightforward for others to use *just* the templating system? > What's the really compelling use-case that isn't already handled by > installing Django and just using the templating code with standalone > configure (via settings.configure())? Package size isn't the argument -- > Django is relatively small and you don't gain that much by isolating the > templates, once you include all the supporting stuff, since the bulk of > the disk usage of Django is in the PO files. You're right, package size *isn't* the argument; when it comes down to it, many people don't like installing stuff they have zero intention of using. > > Since I've been championing the use of Django's template library as a > > general purpose library, and spending plenty of time in the guts of > > the template code while writing the taghelpers module, I may as well > > step up and offer to do this. And no, I don't want another Jinja [1] > > [2]; I want a Django template library that's still distributed as part > > of Django, in the Django namespace, and available in its separate > > split-off form from the Django website, similar to how the various > > Twisted modules are distributed [3]. > > > > I know there are various obstacles here, the largest one being the use > > of Django settings in the template code -- but nothing looks > > unsurmountable. > > The main reason we implemented standalone configuration (via > settings.configure()) was so that you could use the template library in > isolation. At the time (starting about 18 months ago), we had a bit of a > debate about where to include the defaults (in django.conf or > django.templates, etc) and decided the current approach wasn't really > hindering anything and meant there was only one spot you had to look for > things. That doesn't mean we can't re-approach the idea, assuming it was done well. > > I'd ideally like to have this done in time for Django 1.0, and to > > ensure stable releases in line with future Django releases. > > > > So ... thoughts? > > Please, no. > > The main problems are > > (1) It's not really worth it, since installing all of Django and then > just not using part of it is easy -- it's not a huge package after all. > > Experience has shown that the Twisted split hasn't been a no-brainer > success. By and large, the easiest thing to do, even with Twisted, is > install everything and just use the bits you need. Otherwise you spend > ages wallowing around trying to work out which bits you do need. When it > comes to packaging for distros, Twisted either has to be done as one > mega-package or something like TurboGears or Pylons as a combination of > a bunch of individual packages (usually the latter). That latter > situation is a packaging strategy Django intentionally avoids and it > will make downstream packaging after 1.0 much easier. People just have > to install django-1.0. People will *still* be able to just install django-1.0. Perhaps I didn't explain the packaging situation quite as clearly as I could have; the Django templating system would *still* be distributed as part of Django, in the django.template namespace. No separate package required. Batteries included. The Twisted analogy was meant to draw a parallel more with the namespacing than enforced separation (and even for Twisted, there's always the "Sumo" package). > (2) It leads to problems with debugging, installing, setting up and > helping people when they have both the separate library and the whole > Django package installed. Which template portion is being used, etc? Are > they up-to-date? Are they interfering with each other? If everything's > in one package, then we only have to worry about the people who have > multiple Django versions installed and that's much easier to debug. See point above. > (3) If the goal is that django-core will u
Breaking out Django templates into a standalone library
At the end of the angsty autoescaping thread (said angst in no small part from my direction ^_^), I floated the idea that perhaps my concern over autoescaping was pointed in the wrong direction -- that it might be time to split Django's template module out into a standalone library. The idea has been raised before, but discussion always hits the point of "good idea, but a PITA ..." and a combination of time constraints and the bystander effect kick in to shelve it. Since I've been championing the use of Django's template library as a general purpose library, and spending plenty of time in the guts of the template code while writing the taghelpers module, I may as well step up and offer to do this. And no, I don't want another Jinja [1] [2]; I want a Django template library that's still distributed as part of Django, in the Django namespace, and available in its separate split-off form from the Django website, similar to how the various Twisted modules are distributed [3]. I know there are various obstacles here, the largest one being the use of Django settings in the template code -- but nothing looks unsurmountable. I'd ideally like to have this done in time for Django 1.0, and to ensure stable releases in line with future Django releases. So ... thoughts? [1] http://jinja.pocoo.org/ [2] Not to disparage Jinja; I just have a different goal in mind. [3] http://twistedmatrix.com/trac/wiki/TwistedProjects --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Re[2]: Case-insensitive URLS (was: usability issues)
On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: > > If a core dev closes a ticket with a "wontfix", you shouldn't re-open > > the ticket unless you've made a compelling case on django-dev and > > gotten the core devs to change their minds. "Wontfix" essentially > > means that a design decision has been made against the proposal, and > > re-opening the ticket isn't going to change that. > > How can I find out that the one closed is the core dev? ^_^ I thought that > ticket was closed by a few volunteers reviewing them first (volunteers > are mentioned near the bug-reviewing-process-scheme). > Here is much of django process issues. Thanks for clarification. BTW > where can I find list of core developers? Well, a volunteer / triager might also close it as "wontfix" if it's been made clear in the past by a core dev that such a decision has been made, and in these cases the same thing applies. (They should hopefully point this out in the close comment.) The core devs are the people listed as "primary authors" here: http://code.djangoproject.com/browser/django/trunk/AUTHORS > > Yes, whenever a ticket is closed, it should have a reason attached; if > > one is missing, feel free to comment on the ticket asking for a reason > > -- but *without* re-opening the ticket. > > BTW I can't get why reopening tickets is treated as the major issue. > Just one more ticket. Just a message. Just a discussion. And so on. If > I request for comments without re-opening, time consumption is much the > same. So what's the difference? Developers use the "open" status of a ticket to track if it needs to be addressed; that's why the "open" status of a ticket matters. If something has been closed for a valid reason, there needs to be a *good* reason to re-open it; developer time is scarce and tickets are plenty. It has nothing to do with stifling discussion, and everything to do with making efficient use of limited time. You're more than welcome to raise a discussion here regarding the closing of a ticket when you disagree with the reasoning; you're also welcome to post a comment on the ticket while leaving it closed. If you change minds regarding the issue, the ticket will get re-opened. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Case-insensitive URLS (was: usability issues)
On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote: > > I never heard that tickets should not be reopened if you disagree. If > the bug is still reproducible it should be reopened. If its > resolution is changed to "won't fix", one should point why. And > not just - "Oh, it is good enough now". The only one who CLOSES the > ticket is the opener. So it's also very impolite to CLOSE TICKETS FOR > SOMEONE. Correct me if I'm wrong. You're (partially) wrong. ^_^ If a core dev closes a ticket with a "wontfix", you shouldn't re-open the ticket unless you've made a compelling case on django-dev and gotten the core devs to change their minds. "Wontfix" essentially means that a design decision has been made against the proposal, and re-opening the ticket isn't going to change that. If you can still reproduce a bug after it has been closed as "fixed", yes, you should re-open the relevant ticket while stating as much. If a ticket has been closed as "invalid", you should only re-open it if you're certain the issue really is with Django rather than something else. If in doubt, ask django-users for help regarding such an issue. Yes, whenever a ticket is closed, it should have a reason attached; if one is missing, feel free to comment on the ticket asking for a reason -- but *without* re-opening the ticket. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Autoescaping: good time?
On 8/4/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
> On 8/4/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > On 8/1/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > > Let's just do:
> > >
> > > 1. Autoescape on by default.
> > > 2. Autoescape is turned off by the {% autoescape off %}
> > > 3. Autoescape happens irregardless of what the template's source file
> > > or source string happened to be named.
> >
> > I'm +1 on this approach. Let's just do it.
>
> Do you have any particular issues with Simon's modification of my
> proposal (turning autoescaping off by default only for a whitelist of
> extensions such as .txt)? If I'm going to go ahead and whip up some
> code, I'd like there to be *some* chance in hell of it getting
> accepted. ^_^
Or hell, maybe I'm looking at this the wrong way.
A lot of my angst here comes from the collision between my desire for
Django's template system to serve as a good *general-purpose*
templating system for everything from HTML to LaTeX to what-have-you,
and Django's (obviously) web-centric standpoint. There's been quite a
bit of talk over time regarding splitting Django's template system out
into a separate library; maybe it's time to do that. It would make
perfect sense for the *library* to take a setting for defaulting
autoescaping to on or off depending on a developer's needs in various
contexts, while still keeping autoescaping on by default for Django's
use of the library.
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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Autoescaping: good time?
On 8/4/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/1/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > Let's just do:
> >
> > 1. Autoescape on by default.
> > 2. Autoescape is turned off by the {% autoescape off %}
> > 3. Autoescape happens irregardless of what the template's source file
> > or source string happened to be named.
>
> I'm +1 on this approach. Let's just do it.
Do you have any particular issues with Simon's modification of my
proposal (turning autoescaping off by default only for a whitelist of
extensions such as .txt)? If I'm going to go ahead and whip up some
code, I'd like there to be *some* chance in hell of it getting
accepted. ^_^
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: How submit a patch with files not in subversion?
On 8/1/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > - No, we're not going to create a branch (at least, not yet) I think we've more-or-less moved to a "not ever" policy for branches going forward, encouraging developers to maintain their own branches outside the official tree. (Core devs, feel free to correct me if I'm mistaken here.) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Autoescaping: good time?
On 8/1/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
> > Let's assume autoescaping is on unless the template engine knows
> > otherwise; your inline templates will work as expected both before and
> > after extraction (again, assuming you're extracting them to a file
> > ending in ``.html``).
>
> Let's just do:
>
> 1. Autoescape on by default.
> 2. Autoescape is turned off by the {% autoescape off %}
> 3. Autoescape happens irregardless of what the template's source file
> or source string happened to be named.
Thank you for taking this opportunity to remind me of the autoescaping
proposal. I must have forgotten it somewhere along the way here.
(Next time, you *could* just say you're -1.) :P
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Autoescaping: good time?
On 8/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Anybody who thinks this decision is actually a really big life-changing > decision needs to re-evaluate their priorities. And perhaps pick some > bigger-item bugs to fix. This is too depressing; just pick one and move > on. Translating "passionate about getting this right for Django" to "considering this a life-changing decision" is one *hell* of a jump. Please don't tar me with that brush; I'm sorry that you're weary of this debate, but that's just not cool. This is a priority for me *within Django*; we all have different parts of Django that we focus on perhaps more than others, and this happens to be one of mine. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Autoescaping: good time?
On 8/1/07, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Wednesday 01 August 2007 19:56:05 Tom Tobin wrote:
> > Okay, post-Starbucks chat with my co-workers, here's my last-ditch
> > mitigation proposal:
> >
> > Set autoescaping on by default for anything ending in ``.html`` (and,
> > perhaps, ``.htm``), and off otherwise.
>
> -1 on this, it's much too magic for me. If you actually look at
> implementing it, it feels even worse -- you have to modify the
> Template.render() method to use information it doesn't even reliably
> have (the name of the template -- won't exist for templates from
> strings), and then *modify* the context object it is passed in on that
> basis...it's nasty.
I'm indeed assuming implementation issues can be surmounted; right now
I'm just floating the idea, and I'm more than willing to take a crack
at implementation if it gets a reasonable pass.
> Also consider cases where someone goes from using a template inline in a
> Python file (as I have in a few places in my source code for very small
> templates) to having them stored in files. Copying and pasting into a
> new file certainly qualifies as a simple refactor in my mind -- I
> probably wouldn't bother even testing the contents of the output. It
> would be pretty evil if the template could start behaving differently
> after doing this.
Let's assume autoescaping is on unless the template engine knows
otherwise; your inline templates will work as expected both before and
after extraction (again, assuming you're extracting them to a file
ending in ``.html``). Inline templates that shouldn't be escaped can
either be decorated somehow, or have the ``{% autoescape off %}`` tag
prepended. (I'd prefer the former, but my objection for this uncommon
subset of an already uncommon case is weaker than my general
file-template autoescaping objection.)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Autoescaping: good time?
On 8/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Auto-escaping is off by default, so there shouldn't be any compatibility > issues at all. I felt my hackles rising until I read this part. ^_^ I'm somewhere between -0 and +0 at this point so long as auto-escaping is off by default (and -1 otherwise, as per my objections in previous discussions on the topic). I still don't like it, but I have the feeling this is *never* going to go away. :P --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: group_by() support
On 7/27/07, David Cramer <[EMAIL PROTECTED]> wrote: > > QuerySet refactoring is like Django 1.0 ya? Never coming? The Django developers are ::gasp:: real people, with real jobs and real lives. I see this perhaps more readily than most, since a few of them are my co-workers. Considering all the other stuff they have to do, it's amazing that they still find time to devote to Django. If you want to help QuerySet refactoring along, jump in and offer to lend Malcolm a hand; what you *shouldn't* do is toss out abusive, thoughtless remarks like that. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
On 7/26/07, Nicola Larosa <[EMAIL PROTECTED]> wrote: > > Tom Tobin wrote: > > I'm starting to seriously wonder if the 80-character line width has > > outlived its usefulness. > > It has not, and it never will, until human beings stay the same: it's not a > technological limitation. I'm guessing that should have been "until human beings change"? It certainly seems to have *started* as a technological limitation, even if programmers profess other reasons for retaining it these days. > > There are various naturally occurring bits > > of code that just don't fit onto a single 80-character line, and the > > options for chopping it up are all sub-optimal; > > Those options do not decrease readability, once you get accustomed to them: > it's just an initial phase. Remember your first hours staring at Python > code? ;-) I've been coding Python for many years; I doubt my feelings are part of an "initial phase". :P > Moreover, if a line is so long, maybe it's doing too many things, and > should be decomposed logically, before recurring to splitting it. In some cases, yes, this would be the correct thing to do. In other cases, the line really does make the most sense as one logical unit, and splitting to get under 80 lines in some of these cases *decreases* readability. > > Docstrings and comments also find > > themselves cramped for space after a few indentation levels. > > Docstrings are never indented that much; comments should be concise anyway. Docstrings for methods still get that much less room (8 characters) than module-wide docstrings; in certain odd cases (e.g., functions within functions), this can be reduced further. Multi-line comments *do* sometimes make sense. > Displaying the source code on a large screen is only one of its many uses: > the keyword here is *interoperability*. > > You want to print the code on paper. Adjust your font a bit. :P Regardless, that shouldn't be something the coder should worry about. > You want other non-overlapping windows open at the same time. Get a larger monitor. :P > You want to make manual three-way merges, with three files shown side by side. Ditto. > You want to include code snippets in emails, web pages and other documents. > > You want to display the code on smaller screens of small devices. Again, not the coder's problem IMHO. > You want readability, which is impaired by larger column widths. I'm making this (apparently quixotic, which I accept) argument in *favor* of readability. I'm certainly not recommending that anyone make lines any longer than they have to be! I'll also take a moment here to state that the number I tossed out initially, 120, was probably a bit much; 100 is more realistic. I do apologize for not thinking before I selected my example. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
On 7/26/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > I find it hard to imagine a programmer these days who is so starved > > for screen real estate that they couldn't handle a width of, say, 120 > > characters; > > Try to imagine a bit harder then. I'm in that position, for example, > even on my desktop. It's much more effective to be able to view more > than one window at a time (e.g. the bug report or details in the web > window and the terminal next to it), so 80 columns is the right sort of > width for that. It's the same reason people have web browser windows at > less than 1024 columns sometimes, despite big screens existing. Having > to flick back and forth between partially obscured windows is slower. > This workflow doesn't work on my laptop, since the screen isn't large > enough, but that's a problem with smaller screens. I'll accept that I'm an outlier, then; I'm also the only one at work who can't stand working with multiple and/or large monitors, and the only one who prefers quickly flipping between maximized windows for most apps rather than having multiple apps side-by-side. (Yeah, I guess that cements me as a weirdo.) ;-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
On 7/26/07, Andrey Khavryuchenko <[EMAIL PROTECTED]> wrote: > "Tom Tobin" <[EMAIL PROTECTED]> wrote: > TT> I find it hard to imagine a programmer these days who is so starved > TT> for screen real estate that they couldn't handle a width of, say, 120 > TT> characters; I code in Aquamacs Emacs on a 13" Macbook and a 15" > TT> Macbook Pro, and I come nowhere *near* using all of my screen real > TT> estate in the horizontal dimension -- and no, I'm not using tiny fonts. > TT> The same thing applies to any terminal inside of a GUI. > > Well, I'm on my 14" Thinkpad can fit two 80-column emacs windows > side-by-side... This increases productivity susbtatially and makes me > dislike lines more than 79 char :) Meh. I'd say that expecting to run two editors side-by-side on a small notebook screen is asking a bit much; you could always get by with soft wrapping. ;-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
On 7/26/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > ... increasing the minimum width would ... Err, *maximum* width, rather. ^_^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
On 7/25/07, Gary Wilson <[EMAIL PROTECTED]> wrote: > > Adrian, which BDFL do we follow :) I'm +1 to Adrian's style (descriptive, rather than prescriptive); it feels more natural to have the docstring be a description of the given code rather than a direct "English translation". The code itself is right there, and it's something of a given that a Python programmer can do an imperative translation for herself if she wants. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
On 7/25/07, Duc Nguyen <[EMAIL PROTECTED]> wrote: > > On a somewhat related note, is it just me or does no django core developer > follow the "no line longer than 79 characters" note. I like using emacs > and I have my frame width set at 80 and it bothers me to no end to have > to scroll to see every line. Turning on line wrapping makes things even > harder to read! I'm starting to seriously wonder if the 80-character line width has outlived its usefulness. There are various naturally occurring bits of code that just don't fit onto a single 80-character line, and the options for chopping it up are all sub-optimal; increasing the minimum width would decrease the number of occasions on which one might need to deal with this frustration. Docstrings and comments also find themselves cramped for space after a few indentation levels. I find it hard to imagine a programmer these days who is so starved for screen real estate that they couldn't handle a width of, say, 120 characters; I code in Aquamacs Emacs on a 13" Macbook and a 15" Macbook Pro, and I come nowhere *near* using all of my screen real estate in the horizontal dimension -- and no, I'm not using tiny fonts. The same thing applies to any terminal inside of a GUI. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: include tag security hole
On 7/22/07, oggie rob <[EMAIL PROTECTED]> wrote: > > This was my feeling also, however I think it is prudent to prevent > legitimate users from making mistakes. I don't know about designers, > but I have worked with some programmers that just don't think things > through like they should... This tells me they have a much deeper problem that Django really can't help solve. ;-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: reverse pagination be made default?
On 7/22/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > I have just uploaded a patch for what I call "reverse pagination". Please > read about it here: > http://code.djangoproject.com/ticket/4956. You can see it > in action on my blog: http://www.amitu.com/blog/. [...] > To avoid confusion I was wondering if reverse pagination should be made > default. This assumes pagination is always done on date-sorted items; there are plenty of other uses for pagination (e.g., splitting up a very long list of books, sorted alphabetically by title). I *really* wouldn't want to wonder why my books are suddenly going Z-A when my default sorting is A-Z. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
On 7/20/07, Derek Anderson <[EMAIL PROTECTED]> wrote: > > heh, i read this and was like "there are other backends?!?" ;p > > nope, sqlite/mysql/postgres is all she wrote right now, as that was all > that existed last summer when i did the bulk of the work on this. but > i'll add oracle and mssql, if someone can provide me access to a test > db. (well, maybe...i don't have any windows boxes around - can you > access mssql from a linux machine?) I wouldn't worry about mssql; that backend is pretty much dead at the moment. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: edit_inline for a reflexive m2m_intermediary
On 7/20/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Hi, > > actually, I find it a legitimate use of django-developers to report errors > that are probably caused by Django and look weird, especially if the mail > concentrates on the bug description and is, well, developer style (full > context etc.) It often helps to get to the point (or embarrass yourself ;-) > > Is this widely accepted, or just me? That's fine if you're fairly certain it's a bug in Django itself, although I'd certainly avail myself of the bug tracker and reference the ticket number so we can, well, track the issue. :-) My fault for jumping on Nicola that way. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: edit_inline for a reflexive m2m_intermediary
On 7/20/07, Nicola Larosa <[EMAIL PROTECTED]> wrote: > > Tom Tobin wrote: > > Django-developers isn't a "Help Desk Level 2"; please don't try to use > > it as such. > > Maybe too much politeness on my part obscured the main point, so let's be > blunt this time: > > there's a bug in Django. (Oh, the horrors! ;-P ) Or maybe not, whatever. > > Having followed all the steps in the bug reporting guidelines, I have > now filed ticket #4937: > > http://code.djangoproject.com/ticket/4937 > > Do what you will with it, and thank you. Sorry about that; I've been on a hair-trigger lately regarding posters misusing Django-developers, and I didn't immediately follow that you were pointing out a possible bug in Django itself. I didn't mean to catch you in the crossfire there. :-( --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: edit_inline for a reflexive m2m_intermediary
On 7/20/07, Nicola Larosa <[EMAIL PROTECTED]> wrote: > > [Sent this to the users list with no answer, and who knows, maybe it's not > me, but actually a bug instead. :-) I also tried using the newforms-admin > branch, but most URLs are absent or commented out...] [...] > What am I missing? Django-developers isn't a "Help Desk Level 2"; please don't try to use it as such. If it's been at least a week or so since your last try on Django-users, you might try to re-raise the issue there. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: customtags, a higher-level API for template tags
On 7/14/07, Brian Harring <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 13, 2007 at 11:19:53PM -0500, Tom Tobin wrote:
> >
> > On 7/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > >
> > > A few comments (mostly questions) from an initial reading:
> >
> > 3) Regarding Brian Harring's #3453, the type conversion logic is
> > redundant between his approach and mine. taghelpers already avoids
> > the issue he's trying to bypass, as it performs type conversion in one
> > initial sweep and stores the literal values for later. I'd rather not
> > use his approach in taghelpers; I don't like the idea of passing
> > around LiteralVariables when I can be passing around
> > honest-to-${deity} integers, strings, etc. :-)
>
> You actually *do* want to use my approach. Note the "resolve_variable
> leads to redundant work" summary- the up front 'type conversion'
> (literal/constant conversion is a bit more accurate) check is done
> every time parsing occurs; that patch just converts parsing down
> to a one time cost. The result of this is to speed up template
> variable lookup.
>
> For your approach, normal usage of a node with args render triggers
> self.resolve_context, which in turn invokes module level
> resolve_context, which in turn invokes resolve_variable, which in
> turn does the conversion every render.
>
> In other words, the purpose of my patch *still* exists- nuke the
> redundant reparsing of the var path. Your patches implementation
> means this gain isn't possible, since the re-parsing is forced
> everytime (further, the basic algo of it is duplicated in at least 2
> spots from what I can tell).
If you follow the conversation to this point, you'll see that I
already raised this issue and plan to correct it; it's going to take
some alterations to the relevant code in django.template.__init__, but
ultimately the goal is to not have any unnecessary type
scanning/conversion happening.
> > Ideally, I'd like to yank the type conversion logic out of
> > resolve_variable, as I believe type conversion and variable resolution
> > are really two separate things and should be available separately as
> > needed.
>
> #3453s patch already *does* this; two classes, LiteralValue (this is
> the value to shove in everytime this node is rendered), and
> ChainedLookupVariable (do a context lookup)...
... and I really don't like the idea of passing around LiteralValues
in place of actual basic integers, strings, etc. If there's a way we
can avoid it, we should avoid it.
> Meanwhile, back to your basic patch... while this is interesting
> code, frankly I'm not seeing the gain in it. Few reasons;
>
> 1) Gurantee you've not timed this sucker. I suggest you do so, it's
> going to be a noticable hit to tag instantiation, and more importantly
> tag invocation- 2x increase on simple tags wouldn't surprise me.
> Reasoning pretty much comes down to the overhead involved, and the
> fact your base code tries to assign everything back to the node
> instead of just returning back to the render func. If the node needs
> to preserve state, let its' render do it- don't mutate the node every
> run (it's slower, and opens up an angle for bugs).
"First make it work. Then make it right. Then make it fast."
No, I *haven't* timed it. Why? Err, I'm still writing it. :-) I'm
not obsessed with speed over functionality. I'll certainly start to
refine the speed once the functionality is all in place just how it
should be; I'm not going to worry about optimization prematurely.
Regarding instantiation, a hit there isn't exactly cause for alarm; a
once-per-run hit in exchange for the automatic argument handling is an
exchange I'll gladly make. As for invocation, again, I'll worry once
we cross that bridge.
> 2) Needless complexity. Example:
>
> class SomeNode(TemplateTag):
> class Node:pass
> class Constants:
> foo = 1
> foo2 = 2
>
> becomes
>
> SomeNode.constants['foo']. *cough* why not the following...
>
> class SomeNode(TemplateTag):
> class Node:pass
> constants = {'foo':1, 'foo2':2}
>
> Latter is the same, using normal pythonic constructs people know/love,
> and doesn't abuse classes as a forced indent (basically).
I'm not attached to the way constants are pulled in; I'm certainly
open to changes where they make sense.
> 3) extension of #2; while Model does make *good* use of metaclass/sub
> classes shoved into a class, it's also far more complex. This code
> could pretty easily have all of this shoved into __init__ of a target
> node, thus getting rid of the seperated parser func; instead, just
> register the class itself (which would handle the parsing and
> rendering)- fair bit simpler, via that app
Re: Proposal: customtags, a higher-level API for template tags
On 7/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> A few comments (mostly questions) from an initial reading:
I've now implemented most of your suggestions [1]; a few questions
remain, though:
1) If I'm going to import the taghelpers errors/API into
django.template, I'll need to in turn move the content in
django.template.__init__ into a submodule (django.template.main,
perhaps), or I run into circular import madness.
2) I'm still not sure exactly how I should handle failed resolution if
I simply resolve automatically; there are merits to each possible
approach. a) Setting to None is more or less how Django currently
does it, and doesn't provide any surprises. b) Setting to the string
equivalent of the variable name is a useful trick, and what we do in
several places internally by way of a "resolve_variable_or_literal"
function; this in turn gave rise to the taghelpers "auto" resolution.
Any suggestions here? (I suppose one solution would be to have a
TagArg argument to choose between the two fallbacks.)
3) Regarding Brian Harring's #3453, the type conversion logic is
redundant between his approach and mine. taghelpers already avoids
the issue he's trying to bypass, as it performs type conversion in one
initial sweep and stores the literal values for later. I'd rather not
use his approach in taghelpers; I don't like the idea of passing
around LiteralVariables when I can be passing around
honest-to-${deity} integers, strings, etc. :-)
Ideally, I'd like to yank the type conversion logic out of
resolve_variable, as I believe type conversion and variable resolution
are really two separate things and should be available separately as
needed. I'm fine with a utility function that does both; I just want
the logic available separately. Right now, the type conversion logic
in resolve_variable is needlessly called from taghelpers since type
conversion has already occurred.
Ultimately, Brian's approach may be fine as an available default; I
just want that resolution logic available separately for taghelpers,
dammit. ^_^
[1] http://hg.korpios.com/django.korpios.patches/file/tip/taghelpers.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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: QuerySet.exists() method
On 7/13/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > +0; seems like a reasonable addition. I wonder of "any" might be a > better method name (along the lines of the Python 2.5 built-in > function), but either name would be fine IMHO. Err, I wonder *if*. ::sigh:: :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: QuerySet.exists() method
On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > I'd like to add a QuerySet.exists() method, which would return True or > False if the given QuerySet contains at least one record. This would > be more efficient than qs.count() or len(qs) because it would perform > the following SQL under the hood: > > SELECT 1 FROM [table] WHERE [where] LIMIT 1; +0; seems like a reasonable addition. I wonder of "any" might be a better method name (along the lines of the Python 2.5 built-in function), but either name would be fine IMHO. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: customtags, a higher-level API for template tags
On 7/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-07-12 at 01:58 -0500, Tom Tobin wrote: > > Over at the Lawrence Journal-World, we have a bunch of custom template > > tags included in Ellington, our commercial CMS based on Django. One > > day, I finally got fed up with writing the same damned boilerplate > > code for custom tags over and over again (for parsing arguments, > > resolving context variables, etc.); the customtags library was the > > result. My wonderfully cool boss > > Suck up! :-) ::grin:: > (1) When it is ever going to be practical to pass strip_quotes=True to > split_contents()? > > For example, you never use that added functionality in the new code you > have here. Since you have quietly added the change that allows strings > to be delimited by both single- and double-quotes (something I thought > we'd "wontfixed" previously, but I don't care about it too much), it > means that if you want to pass the string "foo" as an arg, you can use > '"foo"' or "\"foo\"". I'm wondering if that argument could be removed > without harm. Oops; the strip_quotes is a leftover from an earlier form of the code that made use of it, so I'll be yanking it. I have no attachment to what quoting form gets used (single vs. double); I was going by what split_contents() did. I'm fine with standardizing on double-quoting only. > (2) Some stylistic note, about customtags.py: I always feel that > phrasing like "a higher-level API" is awkward in core code. Higher level > than what? I'd be tempted to just call it "an API for..." or "a helper > API for...". "Helper API" sounds good to me. > The subsection called "Advantages" is really just "Features", for my > money. I guess I'm a little against the idea of outright advocacy in > comments, but it's a very minor point, so feel free to ignore this > entirely. No, it's a valid point; "Advantages" made it through from when I originally wrote it for internal use here. ;-) > (3) What type of arguments do validators take? It looks like > oldforms-style, strings only and the user has to convert. Since you > already know if something is a string or number earlier (when processing > in convert_arguments(), at least), perhaps you could give them the type > that was determined at parse time? If so, numbers that are not integers > should be Decimal types (not floats), so as not to lose precision. I believe I may have already moved towards passing in the converted type without updating the documentation to match; I'll go over the code soon and check, and set things out that way if they're not already. Good point regarding float vs. Decimal; I'll change that. > For consistency, I'd probably prefer validators that worked like > newforms (and like Adrian has suggested for model validation): methods > called "validate_", rather than the inner class idea. I realise > one advantage of inner classes is avoiding name clashes, but the chance > of a name collision here is essentially zero (you would need args called > foo and validate_foo and somehow have strong technical objections to > calling the latter one validate_foo_ or validate_foo1). I'd like to have the library mirror the syntax of other parts of Django as much as possible, so I'll likely go ahead and do this. > (4) The name of customtags.py feels wrong somehow. Maybe taghelpers.py? I'm definitely not stuck on the name. :-) > (5) Need converting to handle Unicode. Tag and filter arguments need not > be ASCII. Mostly this is easy. A few of the reg-exps should switch to > using \w and being compiled with the re.UNICODE flag. Yeah, that should be straightforward to fix. > (6) The rewrites in defaulttags.py provide interesting reading, as an > example of how to use this. They don't strike me as being particularly > shorter, though. Again, I want to let this sink in over a couple more > reads and I'm not even sure it's a problem. Mostly noting that it's not > an immediately clear win in code complexity, although I realise there > are advantages in consistency of argument parsing. Mostly food for > thought on the layout of TemplateTag subclasses. Unfortunately, the tags in defaulttags.py are probably the worst examples in terms of brevity gains. :-) Most of our converted internal tags are much shorter, since they tend to be fairly simple and all of the boilerplate argument handling code (e.g., " if bit[2] == 'foo' ") gets hidden away. > (7) Is the "resolve" argument on TagArg really necessary? We tend to > always try to resolve at the moment and it works reasonably well. I > guess it might be necessary for the "url" and "for&quo
Re: Proposal: customtags, a higher-level API for template tags
On 7/12/07, Baptiste <[EMAIL PROTECTED]> wrote: > > I have tried to read this patch, but its presentation is really > awful.. But even if I have stopped to read, that seems to be a very > big work! I would like to see it from Trac or I don't know what but > from something that makes him legible ;-) Yeah, I'm sorry about the web view there; hgweb isn't really set up to handle Mercurial Queues patches in a "pretty" way, since it doesn't understand the "diff of a diff" concept. Maybe I'll hack a bit on hgweb when I get a chance and see if I can improve things. ^_^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: customtags, a higher-level API for template tags
Over at the Lawrence Journal-World, we have a bunch of custom template
tags included in Ellington, our commercial CMS based on Django. One
day, I finally got fed up with writing the same damned boilerplate
code for custom tags over and over again (for parsing arguments,
resolving context variables, etc.); the customtags library was the
result. My wonderfully cool boss agreed to allow me to contribute
this library back to Django.
customtags is a higher-level API for template tags that borrows much
of its syntax style from the Django model API; it makes writing new
template tags a breeze (if I may say so ^_^). I've been cleaning up
the code over the past few days, making improvements, and writing
documentation and tests; I'm not done, but I'd certainly like to get
some eyeballs on the code ahead of submitting a final patch for
inclusion into Django trunk. I've been maintaining the patch using
Mercurial Queues; the most recent version can always be found at:
http://hg.korpios.com/django.korpios.patches/file/tip/customtags.patch
Again, documentation is still quite raw; it should be good enough to
get a rough feel, though. The best "documentation" at the moment,
though, might be django.template.defaulttags; I've rewritten every
default tag as a customtags tag, with the exception of {% cycle %}
(since cycle is something of an odd case).
I'd appreciate any and all feedback, both positive and critical. :-)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: db parameter impemtation
On 7/11/07, Carl Karsten <[EMAIL PROTECTED]> wrote: > > Jacob Kaplan-Moss wrote: > > OK, we're 8 messages deep into this thread, and I've got no idea what > > the point is. > > > > Carl -- what is it you want to know? Is something not working > > correctly for you, or is this just an academic question? > > > > When I see SQL parameters being put into the SQL command string, should I > open a > ticket? Is there an actual *problem* running Django that you're running into? If so, can you clarify what it is? Is the MySQL backend not working for you? If you're not having a problem running Django, can you explain exactly what your concern is and why you're concerned about it? Is there an implementation detail you feel isn't optimal for some reason? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ned Batchelder's hyphenate
On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The code Ned put up contains data from the public domain and > was most likely restricted due to that. I'm not sure what you mean by this; "public domain" means anyone can do pretty much whatever they want with it, without restriction. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: defaults, filter_interface, radio_admin in newforms-admin
On 7/8/07, _ <[EMAIL PROTECTED]> wrote: > I'm doing my best to convert over to the newforms-admin model. You're on the wrong list; please redirect to django-users. Django-developers is for development *on Django itself*, not for development *using Django*. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: forms and designers
On 7/8/07, Al Abut <[EMAIL PROTECTED]> wrote: > Can anyone share their tips on ongoing work with forms and designers? You're on the wrong list; please redirect this to django-users. Django-developers is for development work *on Django itself*, not development *using* Django. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > On Jul 5, 11:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > > > > In the Python world, developing "against" a single specific version of > > the language tends to be frowned upon; there's quite a lot of code out > > there which runs compatibly on versions of Python from 1.5 through > > 2.5, and comparatively very little which is tied to a single specific > > version of Python. Web framworks that I've seen tend to be upwards > > compatible from 2.3 or 2.4, while in general a lot of Python software > > aims for compatibility from 2.2 or 2.4, depending on what features > > they need. > > > > Is there a reason why you were hoping Django would somehow "favor" a > > single specific version? > > It's complicated to explain, but basically, anything that goes onto > our systems must be approved and only certain versions of Python are > approved for use/development (2.4 and possibly earlier ones, but I'm > not sure). We haven't yet chosen a framework to use for development > and it would be easier to get something approved if it was developed > against version(s) of Python already approved for our systems. Django is made to work with Python 2.3 *and later*, as stated earlier in this thread. If your organization uses Python 2.4, you won't have a problem. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > On Jul 5, 10:42 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > > > > I think you're asking an unanswerable question; Django is developed > > *against* a particular minimum Python version's specification. > > Someone could, in theory, hack on Django without ever touching a > > Python interpreter (although I'd hope not, since running the test > > suite is a Good Thing). ^_^ What version used alongside development > > to test things will differ from developer to developer. > > Ok, thanks. That's the answer I was afraid of, unfortunately. > > Just in case anyone knows, is it the same with the other frameworks > for Python, like Pylons, Turbogears, etc? I'm thinking yes, based on > your answers here, but just wondering. Why is that answer troubling? I have the feeling there's a misunderstanding going on here regarding what you're trying to discover, and for what purpose. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > On Jul 5, 10:19 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > > On 7/5/07, anna <[EMAIL PROTECTED]> wrote: > > > > > Can anyone tell me what version of Python the latest version of Django > > > (and previous versions if available) is written/developed in? Or can > > > you tell me where I can find that info? > > > > Django is compatible with any version of Python greater than 2.3, as > > noted in the Django installation documentation: > > > > http://www.djangoproject.com/documentation/install/ > > Yes, I understand that. But does that mean that it's developed in > 2.3, 2.4 and 2.5 or just one of those? I know this is a weird > question, but I'm doing research for work and need to know this info. > The fact that it's just compatible with versions greater than 2.3 is > not enough - I need to know the exact version of Python the Django > code is written in. I think you're asking an unanswerable question; Django is developed *against* a particular minimum Python version's specification. Someone could, in theory, hack on Django without ever touching a Python interpreter (although I'd hope not, since running the test suite is a Good Thing). ^_^ What version used alongside development to test things will differ from developer to developer. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Requesting help from Oracle backend devs re: regex field lookups
On 6/26/07, Ian Kelly <[EMAIL PROTECTED]> wrote: > > Let me know if I can be of any other help, e.g. with testing. Thanks for helping me catch that bug; I think the patch is finally ready to be committed. :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Requesting help from Oracle backend devs re: regex field lookups
On 6/26/07, Ian Kelly <[EMAIL PROTECTED]> wrote: > > On 6/23/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > > > Am I on target here? Also, are there versions of Oracle usable with > > Django that might not support these? > > Hi Tom, > > You've got it right. In addition to Oracle 10g, we're also trying to > support Oracle 9i, which lacks the REGEXP_LIKE condition. However, > Oracle is ending support for 9i this month, so I don't think that we > necessarily need to support new Django features against 9i as long as > the documentation notes that 10g is required. > > Let me know if I can be of any other help, e.g. with testing. I've updated the attached patch on the ticket [1]; if you could test it out under Oracle (both trying the field lookups directly, and running the testing framework) that would be a huge help. :-) [1] http://code.djangoproject.com/attachment/ticket/1465/regex-field-lookups.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Requesting help from Oracle backend devs re: regex field lookups
Now that boulder-oracle-sprint has been merged into trunk, I'd like to ask the Oracle backend developers to take a look at Ticket #1465, implementing regular expression field lookups (i.e., "somefield__regex=foo" or "somefield__iregex=foo"); the patch there currently lacks support for Oracle. Based on docs from oracle.com [1], I *believe* the incantations for Oracle are: case-sensitive: REGEXP_LIKE(field, pattern, 'c') case-insensitive: REGEXP_LIKE(field, pattern, 'i') Am I on target here? Also, are there versions of Oracle usable with Django that might not support these? [1] http://www.oracle.com/technology/obe/obe10gdb/develop/regexp/regexp.htm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Error message: The Python markdown library isn't installed. - Help needed please.
On 6/21/07, john-f <[EMAIL PROTECTED]> wrote: > > Hi all > > I'm currently moving sites over to one server at my company. The > server will be hosting 2 versions of django (0.91 and 0.95). In the future, please direct help requests to the django-users mailing list; django-developers is for development on Django itself. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
On 6/19/07, Jonas <[EMAIL PROTECTED]> wrote: > > On 18 jun, 23:17, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > I'm going to give this one more pass and then dropout. We're just going > > around in circles now. > It's true that we are around circles, and I understand that you wann't > make that little change. It's more comfortable to have the framework > configured to your localization that: > > * to thinking in in the rest of people > * doesn't continue believing that USA is the world > * and that the international standards, -created to facilitate the > data interchange between all countries-, are not worthy for them. > > Indeed I just read the next news that leaves very clear what I am > saying: > http://digg.com/general_sciences/Nations_who_have_not_yet_adopted_the_metric_system_pic > > "Nations who have not yet adopted the metric system" > Only 3 countries in all world have not adopted it. I'm sure that you > guess one of them. I guess it :P Besides the fact that you're being utterly unproductive with your combative attitude here, you *do* realize Malcolm is Australian, right? Furthermore, you're trying to "shame" a project that has a stellar internationalization track record. Trust me -- these guys "get it". Apparently, you don't. > > Do you really say 2007-06-18 when your friends ask you what the date is? > > Does your grandmother, who doesn't use computers as much as you do, use > > that format? We are trying to encourage websites that feel natural to > > all users, not just friendly for people who have used computers all > > their lives. > I remember to you that we are to interacting with computers, not with > persons. It's by that reason that the operating systems show date and > time in that format -at least in my Debian- but it's possible that > you're using Windows. Did you miss the point, stated several times, that all of this has *nothing* to do with the internal representation of the date/time? Changing the format will have *nothing* to do with how your server stores the time. "-MM-DD HH:MM:SS" is just as much a *human* convention as any other textual date/time format; the database *does not* store the date like that. :: sighs and goes back to doing more productive things :: --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Regular Expression Field Lookups, Take Two
On 6/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > modeltests/lookup/models.py looks like the right location. Tests have been added there in the latest patch. > Then the maintainers of [Oracle] should be able to help with > the implementation there. Good to hear. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Customizable app/project skeletons
On 6/18/07, Jared Kuolt <[EMAIL PROTECTED]> wrote: > > I have a common set of extra bits that I put in my settings.py files > and re-input them each time I create a project. I would like to have a > directory like ~/.django_skeletons/project that houses my customized > settings.py (and perhaps others). This is already possible: - Create a default settings module somewhere (let's call it "skeleton.py"). - At the top of each project settings file, put: from skeleton import * ... and you're done. ^_^ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Regular Expression Field Lookups, Take Two
Context: http://groups.google.com/group/django-developers/browse_thread/thread/cb0dd0b5ba0ffe11/ I would like to submit for (re-)appraisal ticket #1465, which implements regular expression field lookups (``__regex`` and ``__iregex``). A newly attached patch is up to date with trunk, and additionally has both case-sensitive and case-insensitive matching working for each of the supported database engines. Additionally, the new patch does *not* implement the admin searching functionality which was frowned upon during the last discussion of the code. The two issues I might see with the current patch are: 1) It does not include any tests. I'm quite willing to write them; it's just a matter of *where* they might go. :-) Of the two primary test locations, ``regressiontests`` seems wrong as this is not a fix for an existing bug; ``modeltests``, on the other hand, does not have a location where the entire current range of field lookups are tested. (Maybe this, in itself, is something that should be created?) 2) It lacks support for two of the included backends: ``oracle`` and ``ado_mssql``. If developers using either of these backends are aware of how to implement regular expression matching, feel free to ping me and/or the ticket, and I'll gladly include the code. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: + Important: Repent, Completely trust in God only and, Love Him with all of your heart.
On 5/14/07, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Tuesday 15 May 2007 01:09:08 Secret wrote: > > There is a section below with the title "Atheism and Evolution are > > WRONG." > > > > All those who have sinned deserve to suffer in Hell forever. "Pride" > > is an example of a terrible sin. > > As a Christian, I am extremely embarrassed by this kind of inappropriate > and inconsiderate "evangelism" (regardless of whether or not I agree > with what the guy wrote, and whether he had good intentions in sending > it etc.). I imagine the atheists on this list find it even more > annoying, so I wanted to preemptively apologise on behalf of the > Christians for this. (Apologising for what other people have done > seems to be all the rage these days, why not me :-) If you're not part of the problem, there's no need to apologize; we atheists just click our "spam" buttons and hope the filters learn better for next time. ;-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Escaping in templates...
On 4/17/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > > I'm still -1 on autoescaping as implemented in the latest patch in > > #2359; the terminology used is strongly HTML-centric (e.g., > > ``convert_to_words.is_safe`` -- safe from what?). We should be using > > naming that makes it explicit that this is for HTML escaping, since > > Django templates see a wide range of application (e.g., emails, CSV > > files, Javascript . . .). > > > > If that's fixed, I'll consider myself -0 if autoescaping is off by > > default, and -1 otherwise. I still consider autoescaping to be a poor > > substitute for actually *knowing your code*, but I get the feeling at > > this point that the social pressure in its favor is going to win out. > > Malcolm hasn't tried to implement a general escaping framework to escape > mail, xml, pdf or else. It's only html escaping. So I don't see why > the terminology shouldn't be from html. > > A general escaping framework has been rejected, IIRC. First, Django is a > web development framework, and as such mostly produces html. Second, the > main motivation for auto-escape is to have a safeguard against scripting > attacks, and this is also for html. I think you misunderstood me; I'm not saying there should be a general-output escaping framework. I'm saying that if there *is* an HTML escaping framework, the object/variable naming should make it clear that we're dealing with HTML-specific escaping where such code comes into contact with the general templating system. Setting "is_safe" on a filter doesn't tell me a thing about what it's "safe" from; setting "is_html_safe" *does* give me an idea about what's going on. > Maybe in your case "knowing your code" is fine, but even within django > missing escapes have shown up as bugs in the past. This is the number one > reason of cross site scripting holes. I don't think this line of argument is ever going to reach resolution between the pro and con camps regarding auto-escaping, so I'm not really trying to argue that point here (my strongly-held views notwithstanding). I'm trying to make sure that whatever auto-escaping implementation *does* get accepted is tolerable. :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Escaping in templates...
On 4/16/07, James Bennett <[EMAIL PROTECTED]> wrote: > > Short and sweet: since we're already planning some > backwards-incompatible changes for the next release, how about we > hammer out auto-escaping of template output while we're at it? Even > those of us who don't like it (myself included) are probably at the > point of accepting that we have to do it eventually, so why don't we > get it out of the way? I haven't been participating much on Django-dev over the last few months, but this made me go "eep?". I'm still -1 on autoescaping as implemented in the latest patch in #2359; the terminology used is strongly HTML-centric (e.g., ``convert_to_words.is_safe`` -- safe from what?). We should be using naming that makes it explicit that this is for HTML escaping, since Django templates see a wide range of application (e.g., emails, CSV files, Javascript . . .). If that's fixed, I'll consider myself -0 if autoescaping is off by default, and -1 otherwise. I still consider autoescaping to be a poor substitute for actually *knowing your code*, but I get the feeling at this point that the social pressure in its favor is going to win 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
