Empty models don't get created (#1972)
I posted a ticket (#1972) a while ago and there's been a few other tickets reporting the same issue, so it sound like an issue that should be addressed. Basically: A model with no explicit fields doesn't get created by syncdb, but syncdb doesn't throw any warnings or errors. Consider the following: --- class SignupList(models.Model): # Has many SignupSlot objects pass class Event(models.Model): list = models.OneToOneField(SignupList) class SignupSlot(models.Model): parent = models.ForeignKey(SignupList) --- (i.e. Every event has a signup list, which has a one-to-many relationship with signup slots.) I have two ideas on how this could be addressed: 1. Throw a warning or error in Syncdb, letting the user know that every model must have at least one explicit field. 2. Build the field as the programmer defined them. Any ideas? -Tyson Tate --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Better input validation (was Proposal: default escaping)
On Jun 21, 2006, at 3:31 PM, Jacob Kaplan-Moss wrote:
> [...]
> Another place to start solving the XSS problem is at the input level;
> a policy of "don't trust data from the web" makes a lot more sense to
> me than one of "don't trust the template author".
Modded "+5 Insightful" :) I can attest personally [1] that doing it
the other way around is an invitation to disaster and inherently
insecure code. The last thing Django needs is a reputation for
insecurity and to go down the path of phpBB and mailman et al. Making
it easy to be secure (i.e. secure by default) benefits everyone. I'd
rather have to manually "non-escape" the occasional string than
escape most all of my strings by hand.
> 2. Methods exist somewhere to "translate" untrusted strings into
> "normal" strings given a particular format. Like Simon, I'm not sure
> how to spell this, but I'm sure a good syntax could be found.
Heck, why not Python's own cgi.escape? [2] Seems trusty enough to me,
though I could be wrong because I'm no Python expert. And, of course,
we can always just use a wrapper method to build on cgi.escape to
allow for further escaping/whatever. (Then again, perhaps I
misunderstood what you meant by "translate".)
> [...]
>
> 4. The template engine automatically escapes untrusted strings
> (unless explicitly passed through a ``raw`` filter) -- this protects
> you from errors when echoing back data given from the browser.
+1 Amen!
> 5. If untrusted strings "sneak" all the way down to the database
> layer... well, I'm not sure about this step; potential options are
> (a) automatically escaping before storing in the database, (b)
> raising an exception, or (c) just letting it happen. I think I
> prefer (b).
>
I think a full-on exception might be a bit harsh, but it could be the
best solution. I don't intend to open a can of worms up here, but
what if manage.py offered a "basic security check" function that is
either run only explicitly by the user or as part of some other
function (syncdb etc.) that checks for untrusted strings that are
publicly viewabel and simply lists them as warnings.
> Thoughts?
Given!
-Tyson
[1] Here at work, we have dozens of JSP intranet apss (*shudder*)
that we've had to go through and implement string escaping for
*everything*. Anything that gets displayed that in some way or form
could have possibly been touched by the outside world must be escaped
manually. *barf*
[2] Sample from Wikipedia's excellent XSS article:
>>> import cgi
>>> print "alert('xss');"
alert('xss');
>>> print cgi.escape("alert('xss');");
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Empty models don't get created (#1972)
On Jun 21, 2006, at 4:49 PM, Malcolm Tredinnick wrote: > What are the use cases for this sort of construction? > [...] I've always thought that any decent computer tool should either a) do what you tell it to, or b) tell you why it can't/won't do what you want it to (warnings, exceptions, etc.). I don't think we should be second-guessing developers. If we don't want to allow developers to do something, we should tell so, at the very least. However, in this case, there *are* valid reasons for having an "empty" model. See my example in the thread start. (Of course, it's not *actually* empty, it has a "one-to-many" relationship with a child model, but those sorts of relationships must actually be defined as a ForeignKey in the child model, thus leaving Mama model empty.) And regardless of any use cases, I don't think we should assume that no one will ever want to do something, because chances are that people will, and for good reasons. > [...] > For this reason, > I would be in favour of just creating the class in the database and > not > issuing an error. On the grounds, that it gets the framework out of > the > way of the developer and lets them get on with their preferred > method of > working. This is my preferred choice, as well, but I'm not well-versed enough in the internals of Django to know if allowing empty models can create other problems outside of the admin interface. If anyone could point me to the relevant areas of code (i.e. where in Django's code does it determine if a model shouldn't be created because it's empty, etc.), I'd be happy to take a crack at a patch or two to give these ideas a shot. > [...] Thanks for the input! -Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: default escaping (and branch request)
On Jun 21, 2006, at 6:57 PM, Jacob Kaplan-Moss wrote:
> Yes, I agree -- I've never been against a template tag which does
> autoescape because that's still leaving power in the hands of the
> template authors.
Then again, how often do you *want* to allow your users to put HTML
and JS in and allow it to be executed? Not often, I imagine. And
following that, I think Django should, of the two options, cover the
majority, which I believe is "escape by default" and allow {%
autoescape off %}. For the sake of security, I'm really hoping to see
escaping automatically turned on.
Regards,
Tyson
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Proposal: default escaping (and branch request)
On Jun 21, 2006, at 8:50 PM, James Bennett wrote: > Has the world honestly learned not one single solitary thing form > PHP's magic_quotes fiasco? Autoescaping all output by default is > something that is unequivocally not acceptable. Oh - I haven't heard of the magic_quotes fiasco. Do you have any links or more information about this? If it blew up for the PHP folks, I think I'd be prone to changing my position on the issue. Regards, Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[#2228] Add e-mail and URL fields to free comments
Most comment systems that I know of allow the commenter to optionally supply an e-mail address and/or a URL along with their comment for attribution or administrator records. I thought it would be really handy to have in Django's free comments, in an optional, fully backwards-compatible, and non-obtrusive way. Ticket #2228 includes a patch and a sample project which uses the optional e-mail and url fields. However, the only problem at this point is that my patch doesn't do any sort of e-mail address or URL format validation (i.e. are they well-formed and not just random junk?) I couldn't find where I should include this sort of field validation in the contrib.comments code, so perhaps someone can point me in the right direction and I'll throw in some simple RegEx validators with validation error messages. Let me know what you guys think. Regards, Tyson -- Tyson Tate * Graphic Designer, CalPoly Library * Assistant Librarian & Member, Mustang Band * Team Member, CalPoly Triathlon Team * Webmaster & Active, Kappa Kappa Psi * Freelance Graphic Designer --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Single-step object creation?
On Jun 26, 2006, at 7:16 PM, Jacob Kaplan-Moss wrote: > Yeah, as I read over my own email I'm inclined to agree with you -- I > think ``objects.create()`` seems a bit nicer. > > Jacob +1 Agreed! I'd very much like the ability to save me all those crazy p.save() calls. Regards, Tyson -- Tyson Tate * Graphic Designer, CalPoly Library * Assistant Librarian & Member, Mustang Band * Team Member, CalPoly Triathlon Team * Webmaster & Active, Kappa Kappa Psi * Freelance Graphic Designer --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [#2228] Add e-mail and URL fields to free comments
On Jun 24, 2006, at 11:14 AM, Tyson Tate wrote: > > Most comment systems that I know of allow the commenter to optionally > supply an e-mail address and/or a URL along with their comment for > attribution or administrator records. I thought it would be really > handy to have in Django's free comments, in an optional, fully > backwards-compatible, and non-obtrusive way. > > [...] I've since added proper form validation to the patch and the sample project: <http://code.djangoproject.com/ticket/2228> (HT to Greg for the pointer!) Regards, Tyson -- Tyson Tate - CalPoly Graphic Design Student - Work: Graphic Designer (CalPoly Library) - Play: Mustang Band, CalPoly Triathlon Team, Kappa Kappa Psi (Iota Pi) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: #2217 - Filtering using objects rather than IDs
On Jun 30, 2006, at 5:04 AM, Russell Keith-Magee wrote: > ... > Reporter.objects.filter(article=a) > > ... > However, since this change could effect people in the field, I > thought I'd check for objections before I commit. > > Comments? > > Russ Magee %-) I'm +1 on this too. I've done it many a time, expecting it to "just work". Thanks! -Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Generic View Bug and Issues
Note: I originally posted part of the following to the users list,
but I realized today that it's probably better posted here because it
deals with a potential bug and developer rationale behind some
generic view behavior that I find very odd. Sorry for the cross-post!
---
Using the latest SVN on MacOS X 10.4.7 with MySQL 5.0.22 and Python
2.4.3:
I've built a simple date-based app that works fine through the admin
and all proper URLs resolve to the correct template and display the
correct data. I reset the SQL for the project, ran 'syncdb' and then
ran it with 'runserver'. I added one object with a date and time of
today through the admin interface.
1. In the date_based.archive_index view, the 'date_list' object is
empty. It should have a date object for this year because there is,
of course, a post in the current year (2006). The docs for this extra
context variable state that this should contain: "all years that have
objects available according to queryset". This smells like a bug to
me. Can anyone confirm?
2. Both 'archive_month' and 'archive_day' generic views set
'previous_month' and 'previous_day' even when there are no previous
months/days in the current view. This is documented as expected
behavior. Can anyone supply the rationale for this? Unless I'm
missing something, it's completely illogical to do this. Why tell the
templates that there's a previous month/day when there really isn't?
If there's no next month or day, next_month/next_day is correctly set
as empty as you would expect, but not previous.
I'd like to use the following in my month template:
---
{% if next_month %}
Previous Month: {{ next_month|date:"F Y"}}
{% endif %}
{% if previous_month %}
Next Month: {{ previous_month|date:"F Y"}}
{% endif %}
---
Thanks in advance for any help/suggestions,
Tyson Tate
--
Tyson Tate
- CalPoly Graphic Design Student
- Work: Graphic Designer (CalPoly Library)
- Play: Mustang Band, CalPoly Triathlon Team, Kappa Kappa Psi (Iota Pi)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Generic View Bug and Issues
Is there any way I can get a response on this? I really hate to be
annoying and pedantic, but the following problems are literally show-
stopper problems for my Django projects and they're holding up what
is otherwise a working project. I would really appreciate something -
anything!
Regards,
Tyson
On Jul 16, 2006, at 2:10 PM, Tyson Tate wrote:
>
> Note: I originally posted part of the following to the users list,
> but I realized today that it's probably better posted here because it
> deals with a potential bug and developer rationale behind some
> generic view behavior that I find very odd. Sorry for the cross-post!
>
> ---
>
> Using the latest SVN on MacOS X 10.4.7 with MySQL 5.0.22 and Python
> 2.4.3:
>
> I've built a simple date-based app that works fine through the admin
> and all proper URLs resolve to the correct template and display the
> correct data. I reset the SQL for the project, ran 'syncdb' and then
> ran it with 'runserver'. I added one object with a date and time of
> today through the admin interface.
>
> 1. In the date_based.archive_index view, the 'date_list' object is
> empty. It should have a date object for this year because there is,
> of course, a post in the current year (2006). The docs for this extra
> context variable state that this should contain: "all years that have
> objects available according to queryset". This smells like a bug to
> me. Can anyone confirm?
>
> 2. Both 'archive_month' and 'archive_day' generic views set
> 'previous_month' and 'previous_day' even when there are no previous
> months/days in the current view. This is documented as expected
> behavior. Can anyone supply the rationale for this? Unless I'm
> missing something, it's completely illogical to do this. Why tell the
> templates that there's a previous month/day when there really isn't?
> If there's no next month or day, next_month/next_day is correctly set
> as empty as you would expect, but not previous.
>
> I'd like to use the following in my month template:
>
> ---
> {% if next_month %}
> Previous Month: lower}}">{{ next_month|date:"F Y"}}
> {% endif %}
> {% if previous_month %}
> Next Month: lower}}">{{ previous_month|date:"F Y"}}
> {% endif %}
> ---
>
> Thanks in advance for any help/suggestions,
> Tyson Tate
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Generic View Bug and Issues
On 7/18/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: I haven't had a chance to look at this issue, but I'll point out thatthere's no way this is a "show-stopper" problem, given that, ifgeneric views don't suit you, you can just write five-or-so lines of view code manually...AdrianBut surely bugs and odd behavior are best solved by fixing the problem rather than having to create endless work-arounds? If work-arounds were the solution, nothing would truly be a "show-stopper". Additionally, I'd much rather see Django improved than just "working around it". Who wouldn't?! After all, we're perfectionists on deadlines! :)Regards,Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Generic View Bug and Issues (Please? Agh!)
Here's an excellent suggestion for the proposed code sprint to 0.95: Fix date-based generic view bugs. I've created a minimal test case for these problems, which can be had here: http://fallingbullets.com/test_proj.zip Here's the instructions for exactly how I made it and what problems I encountered: http://fallingbullets.com/django_bugs.txt In summary, here's the problems I encountered: - 8. Navigate to the root page, the "archive view". PROBLEM: There are no years listed under the year list (i.e. no objects in "date_list"). The docs say that "date_list" contains "A list of datetime.date objects representing all years that have objects available according to queryset." It does not. 9. Navigate to /blog/2006/ PROBLEM: No blog objects are listed (i.e. object_list is empty). I certainly added objects this year, didn't I? Unless I ripped open another time warp worm hole. But that's another story for another day, kids. 10. Navigate to /blog/2006/jul/ PROBLEM: Last month is listed as a previous month even though there are no objects created last month. Yes, this is documented behavior. But why? Why should "previous_month" be non-empty when there's no previous month's worth of data? "next_month" is empty if there's no next data for next month. Which is logical. 11. Navigate to /blog/2006/ PROBLEM: Same problem as #10, above. - I'll go ahead and file bugs on these[1], but it feels so futile because I've been trying to get a response on these problems for the past two weeks and have been, I feel, completely ignored. No one can rationalize the fact that the date-based generic views give you "previous_month" and "previous_day" dates when you don't have any objects in the past month or year. No one seems to care that "date_list" in archive_year or "object_list" in archive_year are empty when they shouldn't be. So please, I'm begging, can someone, *anyone*, acknowledge these problems, at the very least? I'm at the end of my rope with these problems. I've spent the past two weeks trying to get the barest acknowledgment of these problems on the lists and on IRC, but I feel like a mute on the stock trading floor. Regards, -Tyson Tate, Exasperated web developer [1] <http://code.djangoproject.com/ticket/2385> <http://code.djangoproject.com/ticket/2386> <http://code.djangoproject.com/ticket/2387> --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Generic View Bug and Issues (Please? Agh!)
Thanks again to James for catching the problems in my test case - it looks like I made a number of mistakes in the translation from my real project to the minimal test case and didn't catch them. I really appreciate the help. On Jul 20, 2006, at 8:41 PM, James Bennett wrote: >> 10. Navigate to /blog/2006/jul/ >> PROBLEM: Last month is listed as a previous month even though there >> are no objects created last month. Yes, this is documented behavior. >> But why? Why should "previous_month" be non-empty when there's no >> previous month's worth of data? "next_month" is empty if there's no >> next data for next month. Which is logical. > > Continuing with a theme, this behavior does match the documentation > precisely. Whether it should be changed is another debate. Can any Django head honchos comment on this behavior? Regards, Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Generic View Bug and Issues (Please? Agh!)
On 7/21/06, monkeynut <[EMAIL PROTECTED]> wrote: > OK, patch mark 2 is up.. the only problem (and it might be a biggie) is that > this effectively breaks things for people who're using the arguments in > their intended way (eg. getting tomorrow and yesterday, etc.)? > > Pete. I think the two possible ways to see the "next_X" and "previous_X" objects are: 1. Use them to create navigation for users to navigate over my available objects. 2. Use them to report the previous X and next X, regardless if there's any objects in the previous or next X. Option 1, I think, is way more common. Those under option 2, however, would have had to have created a custom implementation already (template tags etc.) because next_X, as it stands, returns an empty value if it's in the future. In addition, regarding option 2, getting information that is independant of your data is something that shouldn't be coupled with the view that displays such data. Information that is relevant to your data, such as the previous and next dates that contain your objects is something that should be coupled with the data. Regards, Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: why are the date-based views restricted to only displaying past-events?
On 7/26/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > It'll get fixed one day, since it's useful functionality. Somebody can > submit a patch or I'll write it one day (low priority). It's really just > waiting on a patch that has reasonable API. > > Regards, > Malcolm I'm +50 on this because I'm about ready to jump in to a large calendar project next week and I'll need this functionality. If no one beats me to it, I'll try to remember to hammer out a patch next week. Any suggestions for how people would like to see this implemented? -Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Re: why are the date-based views restricted to only displaying past-events?
On 7/26/06, monkeynut <[EMAIL PROTECTED]> wrote: > http://code.djangoproject.com/ticket/2433 > .. hopefully I didn't miss anything, I've been out in the sun all day. > > Pete. Not sure if you're the same Pete, but hopefully that patch can work well with this one: http://code.djangoproject.com/ticket/2386 I'm *really* hoping 2386 will get implemented soon. And 2433. :) -Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Consider releasing a .95 beta
It'd be nice if .95 would take care of at least *some* of the bugs that have been piling up in Trac. I understand the few who have commit access are insanely busy, but I just can't fathom a .95 release with the current state of trunk. (Whatever happened to the bug-fix sprint?) It's a little disheartening to watch the Adium Trac and see tickets closed/resolved/fixed by the minute and then come to the Django Trac and watch the tickets pile up. (Yes, I know, different scope, etc etc.) Seems like this is a decision between marketing and engineering: Do we stamp a release number on it to appease management or do we wait and put out a stable release with the features and changes that developers have requested? I, for one, really hope Pete's date-based generic view patches get applied. :) Peace out, Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Consider releasing a .95 beta
On 7/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > When you talk all I hear is poop hitting a toilet. ... > astablished ... > use there nightly build it a production > enviroment? ... > last nights kernal build ... > If you have ever worked on a non-kiddy project (ie $$$) you will > understand the ideas behind milestones,stables, and real beta-testing. Really, I don't think you could discredit yourself any more at this point. I have, certainly, been critical of Django's processes at various times (release cycles, bug fixes, etc.). Malcom sure knows that. :) But 90% of the time, I'm proven completely incorrect and I'm glad for that, even if I'm a little embarassed aftwards for sounding so stupid. Sometimes we assume things about Django that we shouldn't and sometimes we act (blindly) on those assumptions. But you've taken it a step beyond that. Everything you've assumed about the release cycles has already been answered. If you can't handle using an in-development framework that's improving by the hour and have no wishes to see it become the best web application framework in the world, your time might be better spent working on all those "non-kiddy" projects you work on. -Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Consider releasing a .95 beta
On 7/27/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > I for one would like a 0.95 release. ... Earlier today: On 7/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: ... > We're working on the .95 release as I type > this, though. > > Adrian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Free SVN and Issue Tracker
I imagine there are some people here who (like me) want to open source some of their Django code, contrib apps, or other things but cant run Subversion or Trac on their host. Google to the rescue, as always: http://code.google.com Hopefully this can be useful to many of you. -Tyson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
Yeah, I'm a big +1 on this. I try to comment my code as much as possible to make it possible for me to go back months later and pick up where I left off in terms of understanding and this patch will greatly beautify comments. I know in the past a core dev or two resisted adding another tag type (to avoid JSP's problems with 500 different damn tag types, I imagine), but I think the benefits of this one far outweigh the "ickyness" of adding another tag. Thanks for the patch! -Tyson On Sep 13, 2006, at 9:34 AM, Will McCutchen wrote: > > No problem, I did the easy part. Figuring out where the tests go was > a lot easier that actually adding the new syntax to the template > system, I'm sure. > > I just hope this helps the new syntax get added. I really think it > would be an important addition to the template system. > > > Will. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
