Re: HttpResponseStreaming, ticket #7581, and [soc2009/http-wsgi-improvements] Final(?) status update
On Fri, Aug 14, 2009 at 3:13 AM, ccahoon wrote: > One bit of advice I am looking for is what people's opinions are on > the use of isinstance versus hasattr to determine functionality. I am > personally partial to hasattr, because it covers subclasses, but I do > not know what the community tends to go towards. Right now, in > core.handlers.base on my branch, I am using both to deal with > selective application of response middleware, but I would like to > choose one or the other. One thing I'm curious about here is the HTTP Content-Length header. It's late and I'm tired and cranky, so I may have missed it, but outside of the infrastructure for runserver I can't find any place where Django reliably sets it on outgoing responses. And the WSGI spec's stance is that if the client supports it, a missing Content-Length can be taken as a cue to chunk the response (unfortunately WSGI forbids the one HTTP header that truly serves as a reliable source of information for this). If we could get some sort of mechanism for having HttpResponse set the Content-Length header (or not) as needed, we'd have something which would be a lot more consistent, and not just at the Django level. Middlewares which want to look at the response body could check for the header: if it's there the response is safe to inspect/consume/fiddle with, and if it's missing the response is not safe to inspect/consume/fiddle with. Servers would still be free to do what they like, and presumably people who want to stream out a response piece by piece will use servers which implement the behavior permitted by WSGI. This sidesteps your question about type checking, and uses a mechanism which is at least semi-blessed by the gateway protocol, so it has interoperability benefits beyond Django middleware classes. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: Better way to extend user table
On Mon, Aug 17, 2009 at 10:57 AM, Jonas Obrist wrote:
> Thanks for your opinion on this, didn't know django had this feature
> once. But I just can't get it out of my head that there's gotta be a
> better solution than this profile-extending... It just seems ridiculous
> to me that half of the user properties is in one table and the other
> half in the other one. And I don't like the template variables looking
> like {{ request.user.user.someproperty }} and {{
> request.user.some_other_property }}. Especially since my designer isn't
> a coder and got all confused over which was where.
>
> So any thoughts on implementing my idea in a better way? To me (at least
> in my code) my version seems pretty elegant... And unless I find a
> better solution I'll continue using it for my own projects.
Well, now that you've described the actual problem you're trying to
solve, here's my five-minutes'-worth-of-coding solution:
from django.contrib.auth.models import AnonymousUser
from django.core.context_processors import PermWrapper
class MergedUser(object):
def __init__(self, user):
self.user = user
self.profile = self.user.get_profile()
def __getattr(self, name):
if hasattr(self.user, name):
return getattr(self.user, name)
else:
return getattr(self.profile, name)
def merged_user(request):
if hasattr(request, 'user'):
user = MergedUser(request.user)
else:
user = AnonymousUser()
return {
'user': user,
'messages': user.get_and_delete_messages(),
'perms': PermWrapper(user),
}
Drop this somewhere, disable the auth context processor and enable the
'merged_user' processor above. Authenticated users will appear in
template context as an object which transparently passes attribute
access to either the User object or the related profile object,
depending on where the required attribute actually exists.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Suggestion: Better way to extend user table
On Mon, Aug 17, 2009 at 11:35 AM, James Bennett wrote: > def __getattr(self, name): > if hasattr(self.user, name): > return getattr(self.user, name) > else: > return getattr(self.profile, name) And for some reason gmail ate the trailing double underscores -- that's "def __getattr__(self, name):" -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
Please don't feed the troll. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ANN: Django 0.96.5 released
Due to an issue with a misapplied patch in the recent Django 0.96.4 security release, tonight the Django project has issued Django 0.96.5. Full information is available here: http://www.djangoproject.com/weblog/2009/aug/19/bugfix/ Please note that this will be the *final* release in the Django 0.96 series. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
USStateField (again)
So, the USStateField in contrib.localflavor got neutered a while back, removing a number of items from its choices list which -- while not actually US states -- are valid postal codes which the US Postal Service recognizes and considers as "US" addresses. When this happened, Django lost useful functionality: there's no longer any field available that corresponds to what USPS will actually recognize. And, predictably, now we've got ticket #9022 open, which started by asking for support for US Armed Forces postal codes and has sort of snowballed from there. The current proposal is for a "USPostalCodeField" which corresponds to the US Postal Service's list of postal codes: http://www.usps.com/ncsc/lookups/abbr_state.txt Since it's likely that any code change we end up making will be fairly simple, I'd like to get the politics straightened out ASAP so that Django 1.2 can have something that'll actually be useful. Based on the various arguments up to this point, it seems like no single field is going to make everybody happy, so here's what I'd suggest: First, deprecate USStateField immediately. It's not and never has been just a list of states, and the implication that the things it lists *are* US states seems to offend some people. So kill it, already. Then, add two new fields geared toward the actual real-world use cases: 1. A field for the 48 "contiguous" US states and the District of Columbia. Lots of services restrict to this for shipping options. 2. A field which accepts anything the US Postal Service accepts. Call it "USPostalCodeField" in line with the patch in #9022, or call it "USPostalBikeshedField" for all I care. But get a field that equates to what USPS allows. If anybody can make a really good case for it, maybe we could do a third field that's a restricted set of states and territories, but in my experience places that'll ship to one overseas territory will usually ship to them all, so I'd be inclined to leave that out. If this sounds good, I can work up the patch and get it ready for review Real Soon Now, and then hopefully we can put this to bed for good. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time frame for GSoC projects integration
On Fri, Aug 28, 2009 at 10:09 AM, Yuri Baburov wrote: > but could anyone please tell me what's planned time frame for GSoC > projects integration into Django if there's any. There is no timeline I'm aware of. And, personally, I don't think there's a need for any sort of special process: these are pieces of work which can be proposed for inclusion in Django just like anything else. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: proposal: decouple admin index page from INSTALLED_APPS
On Fri, Sep 4, 2009 at 2:21 PM, andybak wrote: > 1. I think worrying about projects vs. apps is a red-herring. We are > talking about a way to configure an admin app. There might be several > of these on a 'site/project/whatever' Since this all seems to be specific to particular instances of AdminSite, AdminSite would be the logical place to do it if it's going to get code-level support. However... > 2. Some ability to regroup and choose better names is a biggie. It > pains me when I try and explain to my admins what 'auth' means... Practically everything being requested here is purely presentational. And Django has a component for doing presentational logic: the template system. The admin templates are deliberately easy to override with custom versions, and it feels like all of this is really just asking for things that are more cleanly done in templates. We (World Online) do this rather frequently, including shuffling things around, re-labeling bits, showing extra links to custom things we've added to particular applications. And we do it entirely in templates; it's not particularly hard. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Moving the Django Project to a DVCS
On Fri, Sep 11, 2009 at 4:36 PM, Jared Kuolt wrote: > Please correct me if my interpretation is wrong (for example, is there > a show-stopper about which the community is not aware?). Personally, my opinion is that there are good bridges from all the popular DVCS tools to Subversion, and that choice of DVCS is such a flamewar topic right now that it's best to stick with the lowest common denominator -- people can use whatever they want locally, and committers will just push it into SVN. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Moving the Django Project to a DVCS
On Fri, Sep 11, 2009 at 5:10 PM, James Bennett wrote: > Personally, my opinion is that there are good bridges from all the > popular DVCS tools to Subversion, and that choice of DVCS is such a > flamewar topic right now that it's best to stick with the lowest > common denominator -- people can use whatever they want locally, and > committers will just push it into SVN. And I hit "send" a little sooner than I'd meant... Given that switching would likely be contentious and make some people angry, I can't help wondering what actual *problem* it would solve for us. As it stands, there are up-to-date mirrors of the Django tree maintained in every popular DVCS, usually at popular hosting sites like GitHub and Bitbucket. Thus you have all the ease of use and flashy shiny Web 2.0 buttons on the page that people seem to like, and all without Django itself having to actually switch. The gatekeepers (core committers) would need to be the people who get patches for the final push into Django, and they all seem to already be using various DVCS bridges, so I don't really see what problem this would solve or whose life it would make drastically easier. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Replacing get_absolute_url, I am against it
On Mon, Sep 14, 2009 at 12:45 PM, Patrick J McNerthney wrote: > I am new to Django and am deep in the middle of my first major project > using Django. When I encountered get_absolute_url, my reaction was, > "What were they thinking!". Why does the model have any knowledge about > it's presentation? What if that very same model object is used for two > completely separate purposes in two different applications? Then you'd want something more complicated to handle that. But, really, "where does this object live" is a question the object itself ought to be able to answer. One can argue endlessly about the name, API, return values, etc., etc., but the fact remains that there's a valid problem whose valid solution is "ask the object". And so, like Jacob, I'd really like to start seeing actual *code* to try to improve the way that gets done, rather than the endless bikeshedding this thread seems to be headed for. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Replacing get_absolute_url, I am against it
On Mon, Sep 14, 2009 at 7:10 PM, Patrick J McNerthney wrote: > The objective is not to completely separate the two. URLs are roughly > the "Controller" in the MVC world, and need to know about both the > models and the views. It is the "glue" that binds the two together. > URLs already do know about models and that will remain. Except I can't help thinking this is an awfully arbitrary distinction to draw. In effect you're saying that nearly every question about an object should be answerable by interrogating it directly, *except* for "what's a URL I can use for you?" That's such a common question that I really think it needs to have an answer which doesn't involve hunting over multiple layers of the stack. > It is having models know about what URLs that is a circular dependency > that is both unneeded and problematic. Models should stand alone and be > usable by any number of applications within the same project. Having > the models be responsible for knowing how they are being presented does > not allow for unanticipated uses of those models. Keep in mind that the recommended practice is for get_absolute_url() to work with reverse() and friends, rather than hard-code information directly. Having it supply a pattern name and some arguments offers quite a lot of flexibility with no need to monkeypatch anything, and is why I've consistently harped on this technique in various talks on effective reuse of Django applications. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Tue, Sep 22, 2009 at 6:57 AM, Simon Willison wrote:
> Yeah, I'd like a builtin shortcut like that - used like this:
> render(request, 'template_name.html', {'foo':bar })
> The biggest problem, for me, is finding a decent name - since
> 'render_to_response' is already taken. Maybe something as vague as
> 'standard_response' would work.
FWIW most people I know seem to be using the direct_to_template
generic view for this; its argument signature is close to what's
desired, and it uses RequestContext.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: decorator_from_middleware change
On Mon, Sep 21, 2009 at 9:04 PM, Luke Plant wrote: > I've committed my change [1], and also replaced _CheckLogin with my method [2] > (it was essentially the same method, just generalised). The decorator_from_middleware change appears to have broken cache_page; I'm now getting "AttributeError: 'int' object has no attribute '__module__'" from views which use cache_page. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: decorator_from_middleware change
On Tue, Sep 22, 2009 at 4:07 PM, Luke Plant wrote: > Bummer, I tried hard not to break it - I added backwards > compatibility tests for the basic different uses. Could you produce > a test case? So, I've worked out what the problem is. Previously either of these worked: cache_page(timeout, view) cache_page(view, timeout) Now, cache_page assumes that the first positional argument will be the timeout. So what we're seeing when running some of our code on trunk is cache_page treating the timeout value (an integer) as the view to be cached, and failing when trying to find things like __module__ attached to it. I don't know for certain how many people may be using this idiom, since it was never documented (AFAICT cache_page always documented itself as putting the timeout first and the view function second), so I'm not really sure what (if anything) we should do about it. There may also be deeper issues with the fact that it's not possible to call cache_page with explicit keyword args, since it accepts **kwargs but doesn't do anything with it, always assuming that the timeout and view can be pulled from positional args. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ORM roadmap
On Sat, Oct 3, 2009 at 1:58 PM, Thierry wrote: > I know this is not a problem for most users. But when working with > complex projects or projects requiring some performance optimization > django orm doesn't suffice. Its a pity to see strong development on > django orm, while at the same time the sqlalchemy project has huge > traction. I currently run both orm's. The gap between sqlalchemy and > django orm is very large. Are there any plans to integrate sql > alchemy? In a word, no. There are several reasons, some quite independent of each other, for Django having its own ORM and trusting that people who don't like it or want/need something else will take advantage of the fact that Django's just Python, and will use whatever ORM solution they prefer. First, and dearest to my heart as release manager, is simply that a move toward SQLAlchemy would be large enough and disruptive enough that we couldn't in good faith do it during the Django 1.x release series; if it were to happen at all, it'd have to happen at a bump of the major version number (e.g., in a move from a Django 1.x -> Django 2.x). You'll notice, for example, that even something as tiny as switching ``AdminSite.root`` to an include of ``AdminSite.urls`` is going to need multiple full release cycles to complete, because we have a strong commitment to API compatibilty and stability, and so follow the same general process as Python itself for deprecating and removing pieces of API. Given what's involved even in a tiny change like the admin URLs, it should be fairly clear that we simply could not switch ORMs midstream in a release series even if we wanted to. Second, I don't particularly think there's a major need to try to make everyone converge on one single ORM, or even as large a community impetus as you may suspect; there are, right now, either four or five (depending on how you want to count) major Python ORM projects with decent community support, and none of the others seem to be particularly interested in abandoning their efforts (or even feeling any particular pressure to do so) in favor of a merge with SQLAlchemy. Third, and somewhat related to the above, I don't think it would be a good thing for Django to do this; SQLAlchemy is a very good ORM, certainly, but it also has a certain approach to and assumptions about ORM which are very deeply and very rigidly embedded into it. It is, fundamentally, a Data Mapper-style ORM, and that will practically always be visible and have effects on end user code even with extensions designed to emphasize a different approach. Django's ORM, meanwhile, has its own approach and assumptions which are, again, rather deeply and solidly built in; it is, fundamentally, an Active Record-style ORM, and that will practically always be visible and have effects on end-user code. And this is not a bad thing! Both of these are valid, respectable approaches to the ORM problem, and personally I think the Python ecosystem would be poorer, not richer, if one of these approaches were to be eliminated. Right now Django and SA represent the "best of breed" implementations of these approaches, and in order to keep good implementations available I think the Django ORM needs to continue to be developed and supported. Fourth, it's worth noting that we have certain stated goals for what we'd like our ORM to do, and those goals are irreconcilably incompatible with stated goals of SQLAlchemy. For example, it is a goal of Django's DB layer to eventually support backends which are not SQL databases (e.g., the BigTable implementation in Google App Engine, CouchDB, etc.). So far as I know, however, SQLAlchemy has stated unequivocally that they will remain SQL-only. I could probably go on for a while here, but hopefully it's clear by now that there are some fairly solid arguments for Django continuing to maintain and use its own ORM solution instead of switching to SQLAlchemy (or any other project which might come along and gain similar traction -- it's useful to remember that, in the beginning, emails such as yours asked why we didn't just switch to SQLObject, since that was at the time the standard default ORM in other major frameworks; had we done so we'd have been in a bit of a pickle when everybody abandoned it). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model.objects.raw() (#11863)
On Fri, Oct 2, 2009 at 9:37 AM, Russell Keith-Magee wrote: > Django's ORM is designed to make the simple cases really simple, but > once you move beyond the basics, you really should be looking to use > raw SQL. Indeed. I look at raw() really as "I know *exactly* the query I want to run, get the ORM out of my way and just make it easy to get objects". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ANN: Critical security updates to Django 1.0 and Django 1.1
Today the Django project is issuing a set of releases to remedy a security issue. This issue was disclosed publicly by a third party on a high-traffic mailing list, and attempts have been made to exploit it against live Django installations; as such, we are bypassing our normal policy for security disclosure [1] and proceeding with immediate release of patches and updated releases. Full information is available on the Django project weblog: http://www.djangoproject.com/weblog/2009/oct/09/security/ This issue has been fixed in Django's development trunk, and we've released the following new versions of Django to address this issue: * Django 1.1.1. * Django 1.0.4. These releases are available on our download page [2] and on PyPI [3]. This issue has seen active exploits in the wild. All users of affected version of Django are strongly encouraged to upgrade of apply the appropriate patch immediately. As mentioned above, this issue was initially disclosed publicly on a high-traffic mailing list. We'd like to remind our users that the correct channel for security reports is to send them to . This allows the development team time to develop a solution and coordinate disclosure, both to the Django community as a whole and to the numerous third parties who maintain and distribute packaged versions of Django. When debating whether a particular issue impacts security, we ask that you err on the side of caution and always contact ; we will be more than happy to work with you in analyzing and assessing potential security issues. [1] http://docs.djangoproject.com/en/dev/internals/contributing/#id2 [2] http://www.djangoproject.com/download/ [3] http://pypi.python.org/pypi/Django -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal for 1.2: Dumber email validation
In light of yesterday's security issue, I'd like to propose that we significantly dumb down the regex Django uses to validate email addresses. Currently, the regex we use covers many common cases, but comes nowhere near covering the entire spectrum of addresses allowed by the RFC; several tickets are open regarding this. Trying to cover more of the RFC is possible, although supporting all valid email addresses is not (various regexes claim to do this, but full coverage is impossible -- the RFC is flexible enough WRT things like nested comments that I'm fairly certain no single regex can handle them all), and -- as we've seen -- attempts to cover a broader chunk of the RFC can introduce issues with performance. So what I'd like to propose is that EmailField essentially check that the value contains an '@', and a '.' somewhere after it. This will cover most addresses that are likely to be in actual use, and various confirmation processes can be used to rule out any invalid addresses which happen to slip through that. Meanwhile, people who want to support comments inside a bang path or other such exotic beasts can simply write their own regex for it and tell a form to use that instead. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are threading.local objects evil? (was Re: shortcut proposal)
On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung wrote: > So I wonder what would be wrong with putting the request object in a > threading.local object. It would neither kill performance nor cause a > poor architecture by itself. What's wrong, to me, is that it's a code smell which conflicts with how Django works Django's approach is very simple and very much in line with how any other Python code would be expected to work: you write functions and methods which take the information they'll need as arguments, then ensure that information is passed as necessary. In the case of views, you write them to take the HttpRequest as an argument, and Django itself ensures they're called with it. Setting aside async concerns, making the request available implicitly would be both counter to that overall design (and I'm very much a fan of that design, and I suspect its simplicity and understandability is part of why Django's popular), and feels like an attempt to compensate for either poor practice on the part of developers, or a misunderstanding of what it means to be easy to use (I occasionally see people complain that explicitly taking the request as an argument in views, on grounds of DRY, and then wonder why those people choose to use a language that requires explicit 'self' in methods...). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal for 1.2: Improved URL system
On Sat, Oct 17, 2009 at 10:29 AM, Leaf wrote: > Sorry to propose this right up against the voting deadline for 1.2 > features, but it's one of the things that has always bugged me about > Django and I would really like to see this in 1.2. -1. Replacing regular expressions with... well, what looks like regular expressions with names doesn't make much sense, and even if it did we're not going to change a major component like this in the middle of a stable release line. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The this-needs-to-be-in-django angst
On Tue, Oct 20, 2009 at 8:44 AM, Yuri Baburov wrote: > Moreover, new contributors are considered the least important > creatures in the world!!! As they say on Wikipedia, "[citation needed]". This list grows with every new release: http://code.djangoproject.com/browser/django/trunk/AUTHORS#L27 > Half of feature requests in Trac got misunderstood or not replied or > reviewed within 1 year. The tickets currently open in Trac represent approximately 14.5% of all tickets ever opened. About 15% of all open tickets are currently at the "unreviewed" stage. These numbers suggest that you are, at the very least, exaggerating quite a bit. I'm sure you can and will cherry-pick a few tickets to try to show as examples of why you're right, but on the whole the statistics aren't in your favor here. That doesn't mean we can't do better, of course (we could always do better), but it does mean that your claims need to be taken with a pretty big grain of salt. > So I hope django team will analyze their management structure > critically and at least set responsible persons (maintainers) for > different parts, to ensure there are no items nobody wants to > listen/answer on feature request. You seem to think that any input anyone makes gives them an automatic claim to the time and attention of a committer. I think that's a rather strange idea, because I already don't have enough hours in the day to get the stuff done that I'm doing right now, and that's not exactly a unique situation to be in. This is the point where, traditionally, someone steps up and says we should just bring in a bunch of new committers -- then there'd be plenty of people with plenty of time! -- but it's still not going to get what you seem to want, since there'll always be times when nobody can spare much attention, or requests that nobody particularly feels like dealing with immediately (and, on the whole, I think it's been a very good thing for Django to be so stingy with the commit bits). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The this-needs-to-be-in-django angst
On Wed, Oct 21, 2009 at 7:36 PM, Russell Keith-Magee wrote: > Let me tell you a store about three people named Everybody, Anybody, > Somebody and Nobody. Four! The four people in this story are... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.2 feature voting
On Thu, Oct 22, 2009 at 10:27 AM, Phillip Temple wrote: > django-registration - rewritten to have pluggable work flow, this is a > fundamental feature of so many web sites I'm -1 on adding django-registration to contrib. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The this-needs-to-be-in-django angst
On Thu, Oct 22, 2009 at 11:20 PM, Vinay Sajip wrote: > How about using BitBucket? Does it have the same limitation? I see > there's already a Django mirror there: If anyone's interested, I can see about maintaining a copy pulling from any branches people are maintaining on bitbucket. (and with hg-git, I can probably pull github branches to it, too) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.2 feature voting
On Fri, Oct 23, 2009 at 5:12 AM, rjc wrote: > The only reason I will migrate to 1.2 is if you include schema > migration. It is that important for us (we have a lot of production > code out). Anyway, why did we pick south instead of django-evolution ? > I'm +1 (+1 +1) for any db schema migration. Guess you're gonna stay with 1.1 for a while. Seriously, why is it so difficult to use a solution you already have? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Feature Suggestion
On Sun, Oct 25, 2009 at 8:30 PM, Russell Keith-Magee wrote: > A wiki page doesn't really solve the problem either. If you make it an > exclusive list, someone has to decide who is on the list and who > isn't. If you make it a comprehensive list, a wiki page will very > rapidly become unusable due to the volume of reusable apps out there - > wiki format doesn't provide a lot of creative options for > indexing/organizing content on multiple axes. It seems to me that there's already a site out there which indexes and organizes on multiple axes: http://pypi.python.org/pypi?:action=browse&c=523 or just lists Django stuff: http://pypi.python.org/pypi?:action=browse&show=all&c=523 (several of my comments on proposed contrib additions for 1.2 pointed this out -- we already have the infrastructure, now let's encourage people to use it) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.2 feature voting
On Mon, Oct 26, 2009 at 6:53 AM, kugutsumen wrote: > Support for non-relational databases (AppEngine, #10192) +1 Repeating once again: the voting's over and done with. The proposals have been assigned their priorities. Time to move on. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature Request: Reinteract
On Fri, Nov 27, 2009 at 6:07 AM, noel wrote: > I really love this application Reinteract. Its an enhancement to > Python Interactive Shell. And it would be lovely if I can use > Reinteract with manage.py shell. Before submitting feature requests, please check the release cycle; Django 1.2's feature window is closed. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
On Fri, Dec 4, 2009 at 2:42 PM, Yuri Baburov wrote: > Like, calling current Manager a DefaultManager, and making "Manager = > load(settings.MODEL_MANAGER) or DefaultManager". Or > Manager.get_queryset calling customizable method. Any. If a suggestion like this is going to be implemented, I'd prefer it to be part of the database backend rather than a setting, because: 1. We already have a ton of DB-related settings, possibly more than we need. 2. Backends already support things like a custom Query class, and so this would be the logical place for it to go. 3. Encapsulating this as part of a DB backend most likely gives you a lot more freedom to build in all sorts of complex enterprisey stuff if you really want it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Conventions around plugable backends
On Mon, Dec 7, 2009 at 11:05 AM, Adrian Holovaty wrote: > My preference is (slightly) for class-based, because it's (slightly) > less magic. I think we should try to avoid requiring people to > remember what to name things. I like this as well, albeit for a slightly different reason: asking you to provide the name of the class implementing the API puts one less constraint on how your code gets laid out, and so allows people to organize their code logically rather than according to how we expect them to name things. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #399 -- bigint support
On Wed, Dec 9, 2009 at 8:10 PM, Karen Tracey wrote: > Yes, it's easy to do yourself. But to me this seems like an oddly basic > type to be missing from the base, with enough users potentially wanting it > that it deserves to be officially supported. So I'd be willing to spend > some time on it, but I don't want to waste time if that -1 stands in the way > of checking it in. James: how adamant are you on the -1? Would you > consider -0 instead? I was unaware that I wielded such power :) Basically, I gave it a -1 because I've never actually run into a situation where I've needed it, and I've done a *lot* of Django development over the years. But don't let that stand in the way if it's something y'all really want. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Python version roadmap
On Tue, Dec 15, 2009 at 4:23 PM, Luke Plant wrote: > We need a section in our release notes about dropping support for > Python 2.3. I was trying to write it, and I wanted to say "as > announced in such & such a place", but I can't actually find that > place. I know the decision was made somehow... > > Also, we should be adding any plans to drop 2.4, 2.5 etc into the > internals/deprecation.txt documentation, and we ought to do that > *before* 1.2 is released, to give as much warning as possible. I can write the docs for this; I'd assumed that the plan of "start by dropping 2.3 in 1.2 and then drop one Python version in each release after" was what we'd be doing. If I'm wrong on this, someone please let me know. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Python version roadmap
On Tue, Dec 15, 2009 at 9:15 PM, DULMANDAKH Sukhbaatar wrote: > Please note that python 2.4 is default in RHEL5. I'm aware of that, and concerns about RHEL were noted when I originally proposed the roadmap. But that's Red Hat's problem; if they want to keep shipping ancient versions of Python, their customers aren't going to be able to run modern Python applications. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket #8425 and USStateField (again)
I've previously brought up some issues with the removal of certain options from the choices on localflavor's USStateField[1] as a result of ticket #8425[2] and, with feature freeze for 1.2 approaching and perhaps more time soon to be available for such things, I'd like to call attention to it again since it just bit me pretty hard. Real-world use case: I'm importing data from a feed provided by the US Centers for Disease Control. The data's classified according to state and region (using the US Department of Health and Human Services' standard regional breakdown[3]), and so for parts of it I'm using a USStateField. But HHS and CDC -- like the US Post Office and every other US federal agency, considers Palau, the Marshall Islands and the Federated States of Micronesia to be valid "US" areas for data-gathering and reporting purposes. And this causes a data importer based on USStateField to required ugly workarounds, since those are not valid choices for the field. Any chance of getting the choices fixed so we can actually make use of USStateField with this sort of data? [1] http://groups.google.com/group/django-developers/browse_thread/thread/6b896421e63b6f9e/ [2] http://code.djangoproject.com/ticket/8425 [3] http://www.hhs.gov/about/regionmap.html -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
1.2 Feature freeze
Technically, the major feature freeze for Django 1.2 was to have happened sometime yesterday, US Central time. As of this moment, we're not actually frozen, but will be as soon as I hear status reports on the following (high-priority features which have not yet listed a commit on the 1.2 features page): * GSoC-1 (admin UI) * CSoC-2 (WSGI improvements) * GSoC-4 (model validation) * GSoC-6 (test improvements) * Templates-4 (tag loading improvements) * URLs-1 (get_absolute_url replacement) * Views-1 (class-based generic views) If you're one of the people involved with one of the above features, you need to get me a status update as soon as humanly possible, preferably in one of two forms: 1. "The code's ready and I'll check it in as soon as I finish writing this email to you", or 2. "The code's not ready, guess it'll wait for 1.3" If the status update consists of "it's checked in but nobody updated the 1.2 features page", you will be slapped with a large trout. (in case y'all can't tell, I have no plans to let 1.2 slip like 1.1 did...) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.2 Feature freeze
Since it appears there are some people who have code ready but have time constraints due to holidays, I'm going to (by release-manager fiat, unless Adrian or Jacob want something else) plan 1.2 alpha (and corresponding major feature freeze) for Tuesday, January 5. Any major feature not in trunk by then doesn't make 1.2. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #8425 and USStateField (again)
On Wed, Dec 23, 2009 at 9:44 PM, Russell Keith-Magee wrote: > I could live with either approach existing in the codebase. I won't > express a preference, though - I'll leave the decision of which > approach is preferable to those that will actually have to use it. Honestly, given both the controversy which prompted the original change and the varying real-world needs, I think the two-field solution is more appropriate: One field -- USStateField -- should only do things which are actually US states, plus the District of Columbia. Throw in a flag which defaults to False and which restricts it to the 48 contiguous states + DC. This avoids the political upheaval because it doesn't include anything exotic or "not really US" like territories, protectorates, COFA nations. It also provides for a couple extremely common use cases: companies which will do business with you only if you're in an actual US state, and companies which will do business with you only if you're in the "lower 48". The other field -- USPostalCodeField -- should accept any abbreviation the US Post Office accepts. This allows the broader use case of shipping to anywhere the Post Office can handle, and also lines up with the abbreviations used for data reported by the US federal government. The actual sets of choices can be built up as you've described, or in some other fashion (I don't particularly care, but would lean toward breaking them into logical sets so people can do more fine-grained stuff if they want). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #8425 and USStateField (again)
On Thu, Dec 24, 2009 at 5:22 AM, Russell Keith-Magee wrote: > My concern with having two fields is that it introduces a false > dichotomy. There aren't just 2 options here - potentially any > permutation of the following list is possible: While this is true, there are three common cases, which can be handled adeptly by two fields: 1. "Any US state" 2. "Any of the lower 48 states" 3. "Anything the US Post Office recognizes" > So as soon as you introduce a USPostalField that includes all of > these, I guarantee that someone will ask for a field that has all the > choices *except* the US Military drops, and then someone will find > some reason to why Guam should be on the list, but the American > Marianas shouldn't, until eventually you have a dozen US*Field fields. No, this is why you make the choices available in a fine-grained manner; the built-in fields cover the common use cases above, and then the ability to pick and choose the set of choices you want for your own custom stuff covers everything else. > The reason this discussion is happening in the first place is that we > couldn't come up with a single set of options that would keep everyone > happy. Increasing the number of options to 2 decreases the number of > disparate groups by 1 - but that doesn't mean we're left with 2 > disparate groups. No, the reason for this discussion is that "USStateField" included a bunch of things which weren't states, some of which weren't even part of the US, and people had problems with them being subsumed under that name. So let's not do that. > Adopting USStateField(choices=POSTAL_REGIONS) or > USStateField(lower_48=True, ...) means that end users can mix and > match whatever combinations they need - we provide a single field, and > let them mix whatever combination of options they want. Except your argument turns on its head here -- if your logic above were correct, you'd be against this as well, since obviously we'd need to start adding ever more fine-grained arguments to the field to tune the choices (palau=False, micronesia=True, armed_forces=True, virgin_islands=False, etc.). But you've recognized that covering the common case with fields and covering the rest with flexible choice sets works, so you really ought to be agreeing with me here ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #5025 - truncate filter, why hasn't it been accepted?
On Tue, Dec 29, 2009 at 6:15 PM, Nic Pottier wrote: > I'd be curious to hear what the reason for not accepting this patch > is. String truncation is a pretty common task, and having it built in > seems like a no-brainer. It is built in, though, it's just called "slice". The only thing people seem to offer to differentiate this proposal from the existing filter is that the proposed "truncate" would add an ellipsis at the end, and honestly I'm not really convinced that's a significant enough use case to warrant adding another built-in filter. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #5025 - truncate filter, why hasn't it been accepted?
On Wed, Dec 30, 2009 at 2:35 PM, Jerome Leclanche wrote: > This thread is 20 hours old, you've got a bunch of people who made clear > points on why the filter was needed/expected. You don't want to take lesson > off that? fine, as I said you can browse IRC logs, or even google > results[1]. I don't see anywhere any kind of mention of the "slice" filter > which, so far, has been the only working replacement proposed. > [1] http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=django+truncate+filter And yet there's also been some legitimate pushback, and no real response to actual design problems raised by the proposal. Instead of the litany of "+1, everybody needs this and it's so trivial, why won't you listen to us", how about giving good answers to the following questions: 1. How many filters are we talking about here? At the very least it seems like two: one for plain text and one for HTML (since you don't want tags or character entities getting chopped off partway). 2. How does this interact with internationalization? Not every language or locale uses an ellipsis for this (and, really, this needs to be solved regardless so the existing truncate_words can play nice with non-English use cases). 3. Similarly to the above two, how does this interact with languages which commonly use composed characters in Unicode? Cutting a character in half (and thus presenting output that's completely wrong) probably isn't expected behavior, so how would such a filter deal with this? Would it need to do Unicode normalization as well? 3. Is adding more filters really the way to do this? Could existing filters have their functionality expanded instead? These types of questions have to have answers before I'll even think about supporting a change, but so far I don't really see anyone proposing answers -- just an endless litany of "me too"-type comments which don't add anything useful to the discussion. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #5025 - truncate filter, why hasn't it been accepted?
On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclanche wrote: > When truncating characters, we are obviously talking about truncating just > that: characters. Truncating bytes is a behaviour implemented by |slice. You misunderstand: I'm not talking about bytes, I'm talking about composed and decomposed characters. For example, 'ü' can be represented as either: 1. 00fc (LATIN SMALL LETTER U WITH DIARESIS), or 2. 0075 (LATIN SMALL LETTER U) *followed by* 0308 (COMBINING DIARESIS) Option 1 is composed, option 2 is decomposed and is actually *two Unicode characters*, not "two bytes", and so character-based slicing will chop off the combining diaresis. The only way to avoid this is to have the filter do Unicode normalization to composed characters (e.g., normalization form NFC or NFKC). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Design and code review requested for Django string signing / signed cookies
Simon, the amount of pushback this is getting, and the changes which need to be made to start bringing it up to snuff, make me feel far too nervous about this being ready in time to make 1.2 at all. I know you've put in the effort to shepherd this along, but I'm starting to think it's time to push this to the 1.3 release cycle (especially since 1.2 alpha freeze is tomorrow, and I don't think there's any way it'll be even alpha-ready by then). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ANNOUNCE: Django 1.2 alpha 1 released
The first alpha preview package for Django 1.2 is now available. * Release notes: http://docs.djangoproject.com/en/dev/releases/1.2-alpha-1/ * Download instructions: http://www.djangoproject.com/download/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Possible contrib.humanize addition
On Wed, Jan 6, 2010 at 8:17 AM, sago wrote: > What is it about Django and NT scholars - have you come across James > Tauber (of Pinax fame?) There are at least three Django committers who can list one or another ancient Greek dialect among their studies. Not sure why that is, but it does make for fun conversation over drinks. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: custom signal fails silently, depending on import path (bug ?)
On Fri, Jan 8, 2010 at 1:41 AM, ssc wrote: > Has anyone ever come across this before ? Could not find anything > related in Trac, but I thought I better ask in here before I file a > bug... If you import a signal, using one particular path to specify the import, you get that signal object. If you import it again later using a different path, you get a different object. This is simply the way Python imports work, and the solution to this "bug" is to ensure you always use the same path (preferably the fullest possible path) whenever importing a signal. (also, your use of "from signals import ..." relies on implicit relative imports within a module, which is a deprecated feature of Python) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Thu, Jan 7, 2010 at 10:40 AM, Honza Král wrote: > ModelForm has a save() method that saves the model. It is reasonable > to assume that if the form is valid, the save() method call should > succeed, that's why the entire model is validated. Actually, I can see a strong argument against this: if I've defined a form class that I think constructs valid instances, and it doesn't, that's a bug in my form and Django should be making this as clear as possible. Of course, the flip side is that the bug in my form may be something subtle which breaks a constraint specified at the Python level but not at the DB level, and so the additional automatic validation could be the only way to catch it. > 2) Are you OK with ripping save(commit=False) functionality to some > other method? (current functionality can stay with a deprecation > warning for example) No. Suppose I have a ModelForm and call save(commit=False) to get the instance so I can do some more work on it. I'm basically saying to Django "I don't think this object is ready to be saved yet, but I need the object so I can do stuff to it". If Django goes ahead and does implicit model validation there and raises an exception, it's just telling me what I already knew: the object's not ready to be saved. But now I get to do extra work to catch the exception, and that's bad and wrong. Calling ModelForm.save(commit=False) should simply disable model validation, period. If I want to validate the instance before saving it, I'll validate the instance before saving it, but commit=False is as clear a way as we have of saying "I'm not going to save this yet" and model validation should respect that. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: REST & Django
On Fri, Jan 29, 2010 at 3:02 AM, pyleaf wrote: > hi,all. > how REST looks like in django? General usage questions belong on the django-users list. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
1.2 Beta Thursday
I'm kind of choosing this arbitrarily, but as far as I can tell we should be good to go for rolling a beta any time. So I'm picking Thursday. If there are any blockers I'm not aware of, let me know. Also, note that this will be the final feature freeze for 1.2; if it ain't in trunk when I roll the tarball, it'll have to wait until 1.3. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
1.2 Beta tomorrow (Friday)
Due to a combination of exhaustion and illness on the part of the release manager (me), I'm going to slide the 1.2 beta release one day; that means beta tomorrow (Friday, February 5, probably evening-ish US Central time). If anyone's got last-minute commits, get 'em in. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ANNOUNCE: Django 1.2 beta released
Tonight we've released Django 1.2 beta 1: * Blog entry: http://www.djangoproject.com/weblog/2010/feb/06/12-beta-1/ * Release notes: http://docs.djangoproject.com/en/dev/releases/1.2-beta-1/ * Checksums: http://media.djangoproject.com/pgp/Django-1.2-beta-1.checksum.txt Note that this constitutes final feature freeze for Django 1.2; no further feature additions will take place before the final Django 1.2 release. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Refining Django admin look proposal
My thoughts, as concisely as I can express them:
1. I'm not in favor of redesigns for redesigns' sake; yes, the current
admin UI has been around for a while, but if we rework it, we
should rework it because there are actual issues with it which need
to be resolved. A good first step would be to identify any such
issues and get ideas for solutions.
2. A design contest is (sorry, Russ!) a really bad idea. We don't hold
contests to design APIs, so we shouldn't hold contests to design
user interfaces.
3. The idea of having one or two folks who really know design and UX
shepherding this stuff ("design czar") is the best approach. They
do need to be people who know Django as well, and AFAICT Bryan fits
that description quite nicely.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
On Tue, Feb 9, 2010 at 2:09 AM, Harro wrote: > - Make email unique and username non-required on the model. That would > make implementing something that authenticated by email a lot > easier :) 1. It's *extremely* unlikely that changes will be considered which require every Django install on the planet to undergo a DB schema migration. 2. The appropriate time to discuss possible 1.3 features is when the feature-discussion window for 1.3 comes up. That will happen sometime in April, probably. Suggestions made now are likely to be forgotten by the time that happens. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
Once again: This is really not the time to be discussing this; anything in this thread's going to be long forgotten by the time 1.2's out and 1.3 feature discussions are going on. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Backwards-incompat with CsrfViewMiddleware
On Tue, Feb 16, 2010 at 4:39 AM, Ivan Sagalaev wrote: > It's not the question of responsibility. We're changing a minor version > which is supposed to be backwards compatible. If a site will break in this > case people won't go looking for some responsible person they'll just blame > Django for breaking a common expectation and creating a crunch job for them. Well... 1. The old middleware is still provided, and will continue to work in Django 1.2 and 1.3. It won't go away until 1.4. Two full release cycles is hardly a "crunch job". 2. django.contrib is not subject to the same compatibility policy as the framework itself; since the applications in contrib are Django applications rather than actually part of the framework, it's to be expected that they will change from time to time. Trying to force contrib to stay static until Django 2.0 isn't an option. >> I should also point out the possibility of doing the csrf_exempt >> decoration in the URLconf, as with any decorator - I don't know how feasible >> that is in this case. > > It's not. Because third-party apps typically provide their own urlconf along > with their own views. And if that URLConf doesn't work for a particular installation, the person administering it can and should substitute their own URLs as needed. Furthermore, anyone who blindly deploys updated code without doing any compatibility checking (or any third-party app developer who doesn't keep up with Django releases) probably won't be helped by additional documentation. > Again, it's not the matter of how to fix it, there are plenty of ways to do > it. But if our changes are backwards incompatible we should clearly say so > in upgrade/release notes. Perhaps that's why, in both the 1.2 alpha release notes and the draft for the final 1.2 notes, it's listed under a big heading titled "backwards-incompatible changes". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deprecating cmemcache, adding pylibmc
On Sun, Feb 21, 2010 at 11:22 PM, Jacob Kaplan-Moss wrote: > A bit more background: I've been told at PyCon that cmemcached is > unmaintained and deliberately being left to die in favor of pylibmc. > > Because of that I'm +1 on your proposal, and I'll argue that we not > consider it a "feature addition" so it can go in for 1.2. If you can > work up a patch I'll be happy to review. At this point in the release process, I'm not sure we can do everything that's being talked about in this thread. Given that we're feature-frozen and that there's no way we can spring a completely new cache backend on people at the last minute, here's what's possible within our release process right now for 1.2: 1. Specifying memcached as the cache backend continues using the same "memcached://" scheme as it always has. There is no way we can change that in the 1.2 timeframe. 2. The memcached backend in Django should look first for the correct library, and fall back to the old one as needed. 3. When falling back to the old memcached library, 1.2 should raise PendingDeprecationWarning; 1.3 should promote that to a DeprecationWarning and 1.4 should remove the support entirely. Anything and everything else being discussed is out of scope for 1.2 and must wait for the 1.3 feature proposal window. > I have a couple of questions: > >> A slight rework of the memcache client that implements a base class >> which resembles the current Django 1.1 memcache client. Anything that >> implements the current CACHE_BACKEND setting "memcached://server:port" >> would use this base class. Throw a deprecation warning if the >> cmemcache library is being used in this way. > > I'm not quite clear how what you're talking about here. You want to > raise a deprecation warning about anyone who uses "memcached://" > instead of something new-style? > >> Additionally, add explicit subclasses for pylibmc and python- >> libmemcache, so if "pylibmc://server:port", "memcached://server:port? >> lib=pylibmc" or some variety there of controls what subclass gets >> used. > > I discussed "memcached+pylibmc://", "memcached+cmemcache" etc. It's a > bikeshed, though, and if you write the patch you can paint it. > >> Forcing the user to be explicit on what library they use could be >> added later, although I don't know if it's necessary. > > "In the face of ambiguity, refuse the temptation to guess." > > We've violated this rule by guessing once; I'd like to switch to > *just* use python-memcached, and force anyone who wants anything else > (including cmemcached) to be explicit. We can't do that in 1.2, > though, so maybe this is the warning you were talking about? i.e. warn > if cmemcached is chosen automatically? > >> Pylibmc and python-memcache have almost identical API characteristics >> (from pylibmc's docs: "pylibmc‘s interface is intentionally made as >> close to python-memcached as possible, so that applications can drop- >> in replace it."), and only differ in pylibmc's flexibility of memcache >> behaviors and their hashing method. (See >> http://sendapatch.se/projects/pylibmc/#behaviors >> and >> http://sendapatch.se/projects/pylibmc/#differences-from-python-memcached). >> The subclass should end up being fairly lightweight. > > Please make sure if you do this that there's a mechanism to use > pylibmc's consistent hashing -- it's the main reason to switch to > pylibmc. Actually, the more I think about it, if you're using pylibmc > then consistent hashing should be the *default*. > > Thanks for getting this started! > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Moving all validation into the model layer.
On Thu, Feb 18, 2010 at 3:30 PM, orokusaki wrote: > I have thought for a year, pertaining to Django, about one thing: Why > doesn't validation propagate from the lowest level? Why should this > have to take place at a higher level? What happens with I want to do > things without using forms? Then, Django 1.2 came from the heavens > with validation in the models (which I currently use and love). The > only problem is that it still handles all validation (except the > basics "This field is required" validation) in the form level and a > special model field's only real functionality (outside of choosing a > DB column type and serializing if necessary) is to specify the form > field, which then does the validation necessary. > Is this the direct that Django's validation is moving to, or am I > thinking of this all wrong? The best thing you can do right now is come up with (and then hold onto until the 1.3 dev cycle starts up) examples of common, useful things you need to do, but which are difficult or impossible to do with the existing tools we have. Otherwise this feels largely like an argument that the API doesn't suit a particular notion of purity or design cleanliness, and I'll just ignore such things. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inheritance: Create a way to subclass and override attributes of a parent class.
On Fri, Feb 26, 2010 at 3:26 PM, orokusaki wrote: > 1) Allow for subclasses of normal models to override attributes of the > parent model. Then, if any attributes exists that override the parent, > simply use the subclass to create the table and treat the parent as an > ABC adding its attributes ( except ones that were overridden of > course ) into the subclass. Strong -1; while dogmatic application of the Liskov Substitution Principle is something I generally rail against, in this case it's strongly applicable. Subclasses which don't preserve at least the public interface of their parents aren't and shouldn't be considered "subclasses". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Problems with DatabaseCreation, table names, and index names
On Wed, Mar 10, 2010 at 4:55 PM, Andrew Godwin wrote: > The question is, is it even worth fixing? I'm tempted to conclude that > you're limited to shorter model/field names by your database (or use > db_table/db_column), but there's also the possibility of that method using a > much shorter way of generating the names (i.e. using the first 40 bytes or > so, then appending an 8-byte hash of the rest). I can easily write and > submit a patch to change the function to use this behaviour - we used to do > it in South, before I started using the ``creation`` methods - but it's > catering to such a small audience I'm not sure it's worth it, and > documenting this behaviour might be a better solution. At first glance, my preferred solution is: 1. Document (probably in the database notes) the length constraints for table names and how they affect index names. 2. Maybe a bit of a pony: have the backends know the maximum table length for the DBs they handle. Then we can have syncdb and other tools raise model-class validation errors and tell people to use db_table to avoid the issue. As for timing: I don't think this is critical enough for 1.2, but it's something we should do and probably could go immediately on the 1.3 milestone. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Transactions in Model.clean()
This message is inappropriate for this list. Before sending mail to Django discussion lists in the future, please read up on the difference between the django-developers list and the django-users list. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Small "bug" in inline_formsetfactory
On Fri, Mar 12, 2010 at 2:43 AM, Harro wrote: > See ticket: http://code.djangoproject.com/ticket/13095 Quoting from http://docs.djangoproject.com/en/dev/internals/contributing/#id1 "Don’t post to django-developers just to announce that you have filed a bug report. All the tickets are mailed to another list (django-updates), which is tracked by developers and triagers, so we see them as they are filed." If you felt the code was necessary you should have attached it to the ticket. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Transactions in Model.clean()
On Fri, Mar 12, 2010 at 9:50 AM, orokusaki wrote: > @James Bennett I was suggesting a new feature. Is it still not > appropriate? It still is not appropriate, and it's not hard at all to see why: *ANY* question which begins "How do I do this in Django" belongs on the django-users list, even if you plan to follow up with feature requests later on. In the future, please be mindful of this as far too much time is taken up redirecting questions to django-users when five minutes of basic research from the original poster could have prevented it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [Proposal] Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
On Fri, Mar 12, 2010 at 4:39 PM, aditya wrote: > The trouble is, there is no straightforward way to configure the name > and domain of a site. Sure there is: create a Site object, or edit an existing one, setting the values you want on it. > Currently, Django uses "example.com" for both the domain and the > name. The only way to change that is to wade into the actual > database. You say this as if it's something obviously evil and horrible and terrible, but provide no explanation of *why* it's bad. You then propose solving this problem by adding two new settings to Django which will be used only when syncdb installs the sites app and then never referenced ever again. If you want this proposal to be taken seriously, you'll need to: 1. Explain why you think it's such a bad thing for a framework which offers easy ways to interact with your database to... ask you to interact with your database. 2. If it turns out there's a real problem, provide a solution which doesn't involve one-time settings and which, preferably, leverages existing and proven features of Django rather than trying to add new ones just for this case. Admittedly these will be rather high hurdles, since I don't honestly see what the problem is here; yes, you'll end up editing the default Site object, but there are things which need a Site object to exist as soon as contrib.sites is installed, and so we just default to the safest possible thing: the example domain name reserved for this sort of use by RFC2606. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Call for sprinters for 1.2
Russ is about to put up a post on the Django weblog with the current state of 1.2. There's been quite a bit of progress since the last update, but there are still around 60 tickets which will need in-depth attention before we hit the point of releasing 1.2; the remainder of the tickets on the milestone are mostly trivial (documentation updates, translation fixes and other minor issues). To help get these tickets resolved (and 1.2 out the door), we'd like to organize a 1.2 sprint either this weekend (March 20/21) or the next (March 27/28), and put out a call for anyone who's willing and able to join in. The focus will be entirely on the 1.2 milestone tickets, with the goal of resolving as many as possible and getting to the 1.2 release candidate. So if you're interested and would like to help out, please head over to the wiki page for the sprint: http://code.djangoproject.com/wiki/1.2ReleaseCandidateSprint and add your name and when you'll be able to sprint. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation outside of ModelForms.
On Tue, Mar 16, 2010 at 10:36 AM, orokusaki wrote: > It doesn't seem that the core team is interested in working on Model > validation at the moment: http://code.djangoproject.com/ticket/13121 > (my failed ticket) Stop right there and actually go back and *read* all the feedback you've gotten, because right now you're just flat-out lying. Russell has, on multiple occasions, asked you, begged you, and pleaded with you to get proper discussion going on the things you've proposed. You've refused and instead adopted a method of opening duplicate tickets and screwing around with the metadata on existing ones, apparently out of a desire to annoy as many people as possible rather than get anything useful done. If you'll actually pay attention to what others say and actually put in the time to learn how the Django development process works, you may be a lot happier with the results. If instead you just continue what you've been doing, well, I for one will be happy to direct you to some other framework that's willing to put up with such antics. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation outside of ModelForms.
On Wed, Mar 17, 2010 at 1:00 AM, orokusaki wrote: > Actually I'm not lying. Russell hasn't given me any feedback regarding > my idea or patch. I didn't simply reopen tickets. Russell changed my > ticket to a documentation ticket, so I opened a new ticket to discuss > that which he avoided in his discussion. As you've been told now, multiple times: Discussion of feature design and other high-level work does not take place in Trac. Trac is good at organizing bugs and keeping tabs on patches and status, but absolutely terrible at that sort of high-level discussion. Thus, such discussion takes place here, on a mailing list well-suited to the task. This is not "ego-driven closed mindedness", this is simple practicality; it's the way things have to work in order for them to work at all. And it's incredibly easy to do; in the time you've spent opening and reclassifying tickets to try to get what you want, you could've accomplished your stated goal -- getting discussion and feedback on your proposal -- a dozen times over. Instead all you've done is waste developer time and annoy people. And just by way of official warning: if you decide to ignore this and just continue on as you have been, you may leave the dev team with no choice but to show you the door. We're short enough on developer time already, and we can't afford to stop and go over basic things like this multiple times (let alone doing so while you sit back and sling insults at us). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation outside of ModelForms.
On Thu, Jan 21, 2010 at 1:28 PM, Gerry wrote: > without using ModelForms? I really like the new Model validation but I > don't > like (nor think its very DRY) to override the save method for all of > my models > to just call full_clean(). It would be nice if there was someway I > could enable > validation by default. The problem with this is that it can't really be generalized. One of the reasons why ModelForm has the implementation it does is that often you have a form which doesn't contain all the fields from the model, or a view which uses the form for initial validation, then does further work before finally saving a complete, valid object. Similarly, being at the stage of calling save() doesn't necessarily mean that the object is complete and valid; one common example is default values, which won't yet be filled in when your custom save() method tries to validate the object, resulting in a validation failure even though the object *would* be valid by the time it hit the database. Developing an "automatic" validation option which is both simple enough to actually be useful and robust enough to handle all the edge cases is -- if it's even possible -- far more than can be accomplished on the 1.2 timeframe. Hence, for now, Django doesn't have any such thing, and won't have it in 1.2. If you think you can make it work for 1.3, your best bet is to work up a proposal, including at least some sample code, along with an explanation of how you'll keep it both simple and robust. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Grantlee version 0.1.0 now available
This message isn't appropriate for django-developers; in the future, please direct announcements of software releases (other than Django itself) to appropriate forums. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 4:34 PM, Taylor Marshall wrote: > There's already a unofficial mirror on GitHub which is maintained by jezdez: AFAIK there are mirrors on pretty much every DVCS/"social code" hosting site; bitbucket's got one as well, for example. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote: > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: >> With all respect, you still haven't addressed my main concern: You >> told me that it was because of backward compatibility that this simple >> change couldn't be put in the trunk. It is backward compatible. If I'm >> wrong, it would suffice to have a simple explanation of what it >> breaks. > > I'd like to second this question. orokusaki suggested a couple of things > in ticket #13100, but I'm seconding specifically this comment: > http://code.djangoproject.com/ticket/13100#comment:8 The difference between how ModelForm works and how Model works is that, if you're overriding clean() on a ModelForm subclass, you don't automatically get uniqueness validation -- you have to call up to the parent clean(), or manually apply the uniqueness validation in your own clean(). In Django 1.0 and 1.1, this is documented behavior: http://docs.djangoproject.com/en/1.0/topics/forms/modelforms/#overriding-the-clean-method http://docs.djangoproject.com/en/1.1/topics/forms/modelforms/#overriding-the-clean-method As such, changing ModelForm to always behave identically to, or to always call, Model.full_clean() would have to change documented behavior. We can't do that in the 1.1 -> 1.2 jump, and for future consideration trying to force them to behave identically is probably unworkable (better would be to come up with API that lets you explicitly control uniqueness validation). This is why that ticket has been changed to a documentation issue: the wording of the documentation with respect to ModelForm and model validation is pretty bad right now, and needs to be cleaned up for the 1.2 release. And this is why for a month now multiple committers have been saying that the proposed code changes are backwards-incompatible: ModelForm.clean() and Model.full_clean() *cannot* be made to function identically right now without changing documented behavior. And for the record, my own frustration on that ticket boils down to a simple thing: Joseph pointed out there was a backwards-compatibility issue, and opted to salvage the most workable solution by changing it to a documentation issue. The reporter reverted that. Russell chimed in and pointed out that Joseph was probably right and set the ticket back to a documentation issue. At that point our intrepid bug reporter could've gotten all the discussion he wanted by paying attention to something he'd been told multiple times, and which is clearly pointed out in the contributing docs we encourage everyone to read as they dive in: if you don't like the decision a committer made on a ticket, start a thread here on the dev list to talk about it. Instead he opened duplicate tickets, ranted in the tracker, insulted people, and generally turned the whole thing into a big radioactive mess that nobody wanted to touch with a ten-foot pole. And with that I'm going to bow out of this thread; Jacob's already posted a separate message to collect concrete suggestions, and that's the discussion I plan to pay attention to, since I think this one's pretty much boiled down to the same people endlessly saying the same things at each other and expecting different results. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 12:09 PM, orokusaki wrote: > Firstly, thanks to Jacob for the highly hostile nature of his bedside > manor. > > Secondly, I didn't assert anything. I merely referenced the docs (I > suppose this will be another case where you simply adjust the docs to > mirror your recent assertion) Strike one was your behavior in this thread: http://groups.google.com/group/django-developers/browse_thread/thread/b888734b05878f87/ Your behavior in this thread is now strike two. Be thankful that America's national pastime allows for three strikes, because if I weren't a baseball fan I'd be all for you being out already. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django 1.2 release candidate available
Tonight we're proud to announce, finally, the first Django 1.2 release candidate. If all goes well, it will also be the *only* release candidate, and Django 1.2 final will release one week from today. For more information, consult: * The Django project weblog: http://www.djangoproject.com/weblog/2010/may/05/12-rc-1/ * The release notes: http://docs.djangoproject.com/en/dev/releases/1.2-rc-1/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.2 release candidate available
On Wed, May 5, 2010 at 11:53 PM, Rajeev J Sebastian wrote: > When can we start discussing potential small/micro fixes for the next > version of django? A week or two after 1.2 final is released. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ANN: Django 1.1.2 and Django 1.2 released
We're pleased today to announce the release of both Django 1.1.2 -- the second bugfix release in the 1.1 series -- and the long-awaited Django 1.2. More information is available over at djangoproject.com: * Django 1.1.2 release announcement: http://www.djangoproject.com/weblog/2010/may/17/112/ * Django 1.1.2 release notes: http://docs.djangoproject.com/en/1.1/releases/1.1.2/ * Django 1.2 release announcement: http://www.djangoproject.com/weblog/2010/may/17/12/ * Django 1.2 release notes: http://docs.djangoproject.com/en/dev/releases/1.2/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ANN: Django 1.2.1 released
Following up on last week's Django 1.2 release, today we'd like to announce Django 1.2.1, the first bugfix release in the 1.2 series: * Announcement blog post: http://www.djangoproject.com/weblog/2010/may/24/121/ * Download: http://www.djangoproject.com/download/ * Checksums: http://media.djangoproject.com/pgp/Django-1.2.1.checksum.txt -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: www.djangoproject.com down?
On Tue, Jun 1, 2010 at 2:26 AM, Dougal Matthews wrote: > It's fine from here (Edinburgh) and I've not had any problems lately. There was an issue a few days ago where Media Temple -- which provides our hosting -- was under a DDoS attack, and so sites hosted there were intermittently available. That's since been resolved. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Free Django hosting
This list is for discussion of the development of Django, not for discussing uses of Django. Also, generally it's a good idea to use Google to search for an answer to questions like this. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django snippets site as a wiki
On Thu, Jun 17, 2010 at 3:39 PM, Jacob Kaplan-Moss wrote: > That said, your suggestions are sensible enough -- though personally I > think MediaWiki is a load of ... ahem .. -- so you probably should get > in touch with Charles or James (see links in the footer) and offer to > help out. That would be Charlie; djangosnippets is his baby now. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: documentation re-factor for 1.3?
On Sun, Jul 4, 2010 at 12:05 PM, dffdgsdfgsdfhjhtre wrote: > It seems right now, django's documentation is trying to do both at the > same time. One project that does reference documentation really well, > imo, is PHP. For example: http://us3.php.net/preg_replace Say what you > will about PHP, but it's documentation for each function it provides > is top notch. I really wish django had something like that for each > function it provides. Django doesn't have that, but Python does: it's called epydoc and it will happily generate for you a javadoc-style interface for browsing every module, class and function. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Should the template system try to be a bit smarter about TypeError?
While trying to answer a question in the IRC channel today, I was poking around in the template system and noticed that resolve_variable has a comment about a particularly odd "gotcha": because it catches and silently hides a TypeError raised by calling a method without the appropriate number of arguments, it also ends up catching and silently hiding a TypeError raised by something going wrong within the method itself. Out of curiosity, what's the reasoning for this? Would we incur a significant performance penalty by looking at the exception to see whether it's complaining about the number of arguments (in which case it should not propagate) or whether something else has gone wrong and raised a TypeError (in which case the exception probably should propagate and result in a 500 error)? -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Request of Ajax Status
On 5/9/06, Bryan <[EMAIL PROTECTED]> wrote: > I understand that this is not a priority for Django, but I would like > to know if anyone is working on Ajax support in Django. I read through > the proposals and was wondering if I could do anything to help with one > of the layers (preferably with the view, because I'm sure that needs > the most work). A patch is in Trac to do some re-usable Dojo integration; basically, I ported all the admin JS to Dojo packages -- it's meant both to be the way the admin will eventually be, and an example of doing Django/Dojo stuff. However, it was done against the magic-removal branch and feature freeze was called, so it'll probably be a while before the patch hits trunk. Once it does, though, Django will be shipping a Dojo build suitable for doing AJAX effects -- the admin will be using the "Events + I/O" edition of Dojo. Beyond that I'm not sure exactly where we'll go; we've talked about building a server-side RESTful API which could be called from JavaScript or any other language, and that would certainly be a help. So far as I know, there are no plans for the sorts of "AJAX helpers" or "press a button and get AJAX" that appear in other frameworks, and personally I think that's a good thing. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: composite primary key
On 5/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I need to be able to use models like this: > > class Xlwzl(models.Model): > xl = IntegerField(primary_key=True) > wzl = IntegerField(primary_key=True) You'll probably want to read this and save yourself some time: http://www.djangoproject.com/documentation/faq/#do-django-models-support-multiple-column-primary-keys -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: composite primary key
On 5/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > But I need this for an ugly existing database (tm) that I cannot > touch. And, of course, it's a ManyToManyField in very open disguise, > but it has additional attributes. Unfortunately, a ManyToManyField is > based on an association table with an additional id primary key ... > so it doesn't help me. So... model it with primary_key=True on one of the fields, and a unique_together in the model's Meta class. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: composite primary key
On 5/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I think you'll run into many problems since everything expects that > it can do a get(pk=...), which wouldn't work. Well, considering that Django explicitly advertises zero support for this situation, I'd say getting *anything* to work is pretty cool. So far as I can tell, you've got a choice to make: use Django and be careful only to use methods which will be safe for your DB setup (e.g., avoid "pk" lookups), or don't use Django. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: +1 on part of #1810 (put parse_dsn() in django.conf)
> On 05/11/06 17:02, [EMAIL PROTECTED] wrote: > (myself included -- I am not about to put my production db > password into a subversion repository that everyone in the company can > read). On 5/11/06, Steven Armstrong <[EMAIL PROTECTED]> wrote: > For putting the dsn in the env I'm -1 as it may cause security problems. > IMHO the only place where such config as a dsn belongs is in a file, > ideally only readable by the executed program itself. Somewhat OT, but you guys do realize that if you're really concerned about the security of your DB password, you don't have to use one? Just ensure that only trusted machines can connect to the database server in the first place... -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: streaming patches reloaded
On 5/12/06, arthur debert <[EMAIL PROTECTED]> wrote: > I have an app that uploads a 4mb file and is taking a ton of memory. > >From tickets 1484/1569 they are set as fixed, but I cannot find them on > django's source code. Are these patches active in trunk? If not, > anyones knows if they're working after the merge? Anyone using them? #1569 is marked as fixed, but it's for streaming *download*, not streaming upload. #1484 is for upload, and is still marked as 'new'. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: request: change title of django documentation
On 5/14/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Django documentation page titles are like: "Django | Documentation | Model > Reference", "Django | Documentation | Template Guide", "Django | Code | > RemovingTheMagic". If you have multiple tabs open with these pages, all you > get to see is "Django" written on all of them [see attachment], which is not > very informative. Foxpose is one option, but it would be really great if the > title were reversed, "Model Reference | Documentation | Django" and so on. What you see depends on the browser you're using and the number of tabs you have open; Safari, for example, does the opposite of Firefox and takes the last section of the page's title (which is arguably smarter, since the long-standing convention of the web is that the parts of a title get more specific as you go from first to last), so in Safari you see "Model reference", "Template guide", etc. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Exceptions in Templates
On 5/15/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > In the very beginning, I often made trivial errors in some functions > used by the methods. Sometimes this resulted in exceptions that were > ignored and resulted in missing data. This is then hard to spot since > you don't get a hint what exception it was. Sure you do, so long as you've got debug turned on. The only exception (no pun intended) to this rule is NameError, and that's because the template system isn't yet smart enough to distinguish between a NameError raised in the execution of a method and a NameError raised by the lookup system trying to call something as a method. > Or, why does Django need to ignore exceptions in functions called in > templates in the first place? Django doesn't ignore them when debug is on. However, some functions, specifically template filters and the render() methods of template tags, are deliberately written so that they will never raise exceptions. Note, however, that template tags very explicitly *do* raise exceptions in their compilation functions when appropriate: if you call a tag with the wrong number or type of arguments, the tag will throw an exception and you'll see an error page (again, assuming you've got debug on). -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: EVOLUTION - Add Field Schema Evolution Support
On 5/29/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > The "Add Field" functionality is nearly ready. You are aware that a full implementation of schema evolution for Django was accepted as a Google Summer of Code project, right? -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: is_approved
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote: > If we implement > that verification view by having it turn on is_active (is_active = > True) instead of using is_approved, then we can never explicitly make > our users inactive, because all they would have to do to reactivate > their account is click their email verification link. Thus we need to > separate the two, having an is_approved field in addition to the > is_active field. Or just set up your "confirm account" link to expire once it's been clicked. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: is_approved
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote: > I need their email to be verified at sign up and when they change it in > their profile. I don't understand how this system would verifiy > someone changing their email address. Honestly, now that I've read through this more thoroughly, I think what you want is to define a profile class and take advantage of the built-in features Django offers with respect to that. Here's the executive summary: 1. Define a class which has all the extra attributes you want for users. Maybe you want to add their site URL, a brief bio, etc. 2. Give it a OneToOneField to auth.User. 3. Add the setting 'AUTH_PROFILE_MODULE' in your settings.py and have its value be the name of your profile class (e.g., 'myapp.UserProfile'). Congratulations, you're done. You can now call 'get_profile()' on any User object in your system to fetch the associated profile and run whatever logic you need based on that. Perhaps someday this could be documented so that people won't have to read the auth code to realize you can do this ;) -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: is_approved
On 5/30/06, Bryan <[EMAIL PROTECTED]> wrote: > Now that you've mentioned it, first_name and last_name should not even > be in User. They should be in profile. Profile is for > personalization, not for user specific login criteria like (is_active, > is_staff, is_superuser, IS_APPROVED). My personal opinion on this, which reflects nothing other than that it rattles around inside my head: First name and last name are such overwhelmingly common components of a user that they belong in the User class. Multiple layers of active/approved/etc. are not as common, and belong in a profile tailored to the specific site's needs. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Enable Django Quick Start / Database Evolution Support
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > Additionally: The fact that I have _not_ the full domain knowledge (= > background information) enables me to make those "sweeping suggestions" > from a newcomers point of view (who cares not much about project details > and internals, but just about his own convenience during product usage). I guess the thing, to me personally at least, is this: You pop up on the list out of nowhere and preface your emails with an all-caps "AUDIT" notification. Yet a number of the suggestions you've made in the course of this "audit" seem to indicate that there's still quite a bit of homework you've left undone. And don't take this personally, but after seeing links back ot your site in every one of your posts, I clicked through and did some reading. The site is confusing, a number of things are unlabeled or so badly labeled that I can't figure out what they are, and your "samples" listing includes a prominent disclaimer not to assume that you've ever actually worked with the projects you did these audits on. All of that makes me more than a little bit skeptical of what's going on here. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: short poll: schema evolution interface
On 5/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 1) a commandline util only (via manage.py) This would maintain consistency with the rest of Django's management options; I'd always figured that at least part of the schema evolution interface would involve manage.py. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Enable Django Quick Start / Database Evolution Support
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > The term 'Audit' explained here: > > http://case.lazaridis.com/multi/wiki/ProjectOverview That page is a lot of marketing speak along with a note that open source projects can order your services at a "reduced rate". So now you sound like you're conducting the email equivalent of a sales call on us. There's a nasty word for making unsolicited sales calls via email, you know. > Please feel free to send me any concrete criticism about my website via > private email (your comments are very welcome). OK, let's see what we find on your site: * http://lazaridis.com/index.html <-- despite being fairly wordy, this doesn't actually tell me what you do. You "audit"? For "strengths and weaknesses?" Are you a usability consultant? A hardware consultant? An efficiency consultant? A marketing consultant? You'll help me define a "Coherent Requirements System", but you can't even give me a coherent one-page description of what you do, so why should I believe you can give me a coherent description of what I do? * http://lazaridis.com/services/index.html <-- OK, so if I actually click through from your home page you'll tell me what you do. Let's set aside for a moment the fact that if I'm a potential client I've already left your site to look at someone else, and take a gander at this flowchart. To start with you'll "retrieve first impressions". That's a good start, but why should I trust your ability to do this reliably given that your own site doesn't give a good first impression? The rest of this chart is so vague in its descriptions of steps that it's hard to know what's going on. Will I be getting a report from you? Will you be writing code? Do you bring in third-party consultants to help with the "transform" step? * http://lazaridis.com/services/description.html <-- OK, now I know a little more; at various points you'll give me reports and apparently I can pay you to act on them. How do you conduct "hardware verification" over the Internet? I still don't know if I'm dealing with you or with subcontracting consultants when we get to the "Transform" stage. You say you offer "Website Redesign"; where are the samples of your design work? * http://lazaridis.com/samples/index.html <-- disclaims any actual customer relationship with the projects you say you've audited. To an experienced eye this is an indication that you have yet to find a customer for your services, and that you have never actually conducted a professional project audit. * http://lazaridis.com/samples/com/ActiveState/index.html <-- Perhaps David Ascher, if he's reading this, could clarify whether you've ever had a customer relationship with ActiveState, since you won't say. Your suggestions are "Free", "Change", "Simplify"; "Free" for non-commercial use -- where's a statistic to back up this suggestion as being good for increasing ActiveState's sales of Komodo? "Change" how? "Simplify" how? It says "This sample demonstrates how a simple website review can lead to several findings which affect product management and marketing." No, it doesn't demonstrate anything; the only concrete suggestions you've made are the "free for non-commercial use", which doesn't have anything to do with the usability of the site, and to change "killer" to "dynamic", which you don't provide any explanation for. How do these suggestions affect product management and marketing? * http://audit.lazaridis.com/schevo <-- the first line of this page seems to indicate that they were doing you a favor, not that you were providing them a service. Which is it? "The documentation is not yet completed." What good is this as an example for me as a potential customer if I can't see the results? And I've clicked through several wiki pages but still can't find concrete details of both the suggestions you made and whether, when implemented, they resulted in Schevo achieving its goals more effectively. * http://lazaridis.com/samples/com/ActiveState/continue.html <-- "Please remember: one main goal of thes sample is to showcase the services." "More information within the service section." If this is showcasing the services, why do I have to go to a different page to get concrete descriptions of the services? And the "services" section has already been covered above; I'm still confused about how exactly you work. And, like a number of pages on your site, there's a typo. If your own site is lackign even in copyediting, how can I expect you to improve mine? * http://lazaridis.com/efficiency/graph/overview.html <-- At this point I just feel like making you read Edward Tufte over and over again. All the flowcharts in this section could easily be replaced by a few short paragraphs explaining each step of the process, with a link at the end to request more documentation. Ideally, each step would list an example of how it was applied on a particular project and what it contributed to the eventual result. * http://lazaridis.com/pj/index.ht
Re: [AUDIT] Enable Django Quick Start / Database Evolution Support
On 5/25/06, lazaridis_com <[EMAIL PROTECTED]> wrote: > * Replace command "django-admin.py" by "django-admin" or "django" Naming it 'django' would likely cause confusion, leading users to believe that it runs an entire Django-powered site. There is a web server built in to it, but this web server is explicitly not for production use. Just cutting the '.py' off the end doesn't seem to carry enough concrete usability enhancement to justify making a backwards-incompatible change in Django; if you have solid data to back up this suggestion could you please supply it? > * Replace command "manage.py" by "django" And confuse it with the other one that we'll be renaming to 'django'? > * Enable sqlite3 database / filename by default This would require us to dictate a location and name for the database; this might not be consistent with what the user wishes, or even with the filesystem permissions the user possesses, in which case the very act of starting Django up would yield an error message. > * Externalize database settings (e.g. dbdefault.py) Why? > * Enable Admin application by default Why? In the past users of Django have complained about it creating tables and installing applications by default, which is why Django does not do so now. > * Create a superuser by default (e.g. user:admin / pass:django) This is a severe security risk. > * Rename "startapp" to "createapp" Why? It doesn't create the app. It starts the process of creating the app. > * Provide basic Database Evolution (e.g. add field) Irrelevant because schema evolution is being worked on. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Enable Django Quick Start / Database Evolution Support
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > Please feel free to send me any concrete criticism about my website via > private email (your comments are very welcome). I seem to have screwed that up by forgetting that replies go to the list by default. My apologies for the mistake. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Some thoughts on Django and usability
OK, the other thread's getting a bit long and I doubt there's much more productive discourse to be wrung from it, so let's start anew. What follows is my own rambling personal opinion, and nothing more. One of the issues that seems to have come up from the "audit" thread is that of the usability of Django. There are a lot of solid general usability guidelines, but there's one that reigns above all, the uber-guideline if you will: Know your audience. It's a simple truth that you can't please all of the people all of the time, so at some point in any development process you have to sit down and mark out three groups: * The people you have to please to stay viable * The people you'd like to please, but won't necessarily bend over backwards for * The people you won't make any accomodations for at all Having that last group probably sounds awful, but consider what happens if you don't demarcate them: in Django's case, someone might well come along who doesn't even know what the Web is, let alone a web site, web application or web framework. How would Django accomodate that person? The answer: we can't, and trying to is a waste of time which diverts attention from our core concern, which is looking after the people in the first (and, to a lesser extent, the second) group listed above. So in terms of Django, here's how I see the groups break down: * The people we absolutely have to please: actual web developers, where by "web developers" I mean people who know at least one programming language, understand at least the basics of relational databases, and have written a significant part of the backend code for at least one dynamic, database-driven web application. * The people we'd like to please: less experienced developers, and web designers who may or may not know anything about programming but who'd like to learn. * The people we won't make any accomodations for: anyone not in the above two groups. Trying to get someone up to speed who's not a web designer or developer of any sort is a task that's not really compatible with providing a high-powered tool for more experienced users. If they can pick up Django and use it, that's great, but if they can't we shouldn't be losing sleep over it. The next question is how far we should be willing to accomodate the people in the second group, and the answer is simple: as far as we can go without inconveniencing the people in the first group. Let's look at a concrete example proposed in the audit thread: automatically setting up a SQLite database when a project is started, and installing the admin app into it. This would, probably, offer some benefit to novice developers, because it's a couple less things they have to do at the outset (though it arguably adds in some "magic" that it's better to have them understand). But it offers zero benefit to experienced developers and, most likely, would hinder them: they're going to want to develop on something resembling their production environment, which means probably MySQL or PostgreSQL (maybe even Oracle once the adapter for it stabilizes sufficiently), and there's no guarantee that they'll want to use the admin app -- there are plenty of uses for Django that don't involve the admin at all. So this gets in their way and detracts from the out-of-the-box usability of Django for its core audience. Thus, this proposal should probably be rejected. Ultimately, I think this is the way any usability-oriented proposal needs to be evaluated: step back and look at it in the context of the various types of people Django aims to please, and their priority relative to one another. This will tell us immediately if it's a clear win or a clear loss, and let us better choose the issues that are worthy of extended debate. Thoughts? -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: TEAM - Where can I find a complete Team Overview
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > Is such a document available, which lists e.g. > > * committers Not that I'm aware of. > * subsystem leads (or component leads) Except for the i18n system, there really aren't "component leads" for Django. > * code level contributors The AUTHORS file. > * documentation contributors The AUTHORS file. > * others The above covers pretty much everybody. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: TEAM - Where can I find a complete Team Overview
On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > Is is possible to have an overview of the currently _active_ team, > including roles? e.g. on a page on the project wiki? The Django project defines pretty much two roles: "core developers" and "everybody else". Again, with the exception of Georg steering the i18n system, there are no other officially defined positions within the project. IMHO, we haven't had enough need for that sort of bureaucracy to justify its overhead. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
