Re: Important info for translators (especially those with commit access)
Russell Keith-Magee wrote: > I've just committed [12003], which reverted commit [12000]. Sorry, my bad: couldn't resist the nice rev number. ;-) > This mirrors commit [11941], which reverted [11881]. These commits all > relate to translation updates for the 1.0.X branch. > > Translations should *not* be backported to the 1.0.X branch. Gotcha, won't happen again. > The 1.0.X branch is in security fix only mode. Translation updates > represent improvements to code, and while they are almost certainly > are almost certainly improvements, Are you almost sure? ;-) > they would represent a change in known behavior if they were put > into production. > > Translations should only be backported to the current stable branch - > at present, that means that trunk and 1.1.X are currently accepting > translation updates. Once 1.2 is released, the 1.1.X branch will be > frozen and no more translation updates will be accepted for 1.1.X. Got that too. > Thanks to all the translators for all your efforts. Your work is > greatly appreciated by the core team. We just want to make sure > you don't waste any time unnecessarily backporting. I won't, sorry for wasting your time too. -- Nicola Larosa - http://www.tekNico.net/ We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language. - Donald E. Knuth, 1974 -- 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: compressed fixture support
I have a use case for compressed fixtures too. > Jeremy Dunck wrote: >> I'd like to add support for fixture load/dump to deal with compressed >> (gzip) files transparently. Jacob Kaplan-Moss wrote: > I don't see a good reason *not* to do this, but I also don't see the > space requirements as a big deal, either; disk space is very cheap. Well, if fixtures are changed often, and the VCS does not employ binary diffs, the occupied storage space may actually be greater when compressing files. Subversion does binary diffs, Mercurial does not. I don't know about git and Bazaar. > How big are your fixtures, anyway? I have a number of files ranging up to 30MB. When storing them uncompressed in the repo, used storage increases much less, as if Mercurial stores them compressed anyway. However, commands are then slowed down significantly, as if Mercurial had to decompress the files in memory each time. We ended up storing the fixtures in explictly compressed form, to regain acceptable operating speed. -- Nicola Larosa - http://www.tekNico.net/ Like any other entrenched, complex, and often closeted industry, things in IT don't really work the way many people think they do. I'm guessing the Vatican is a bit like that, too. - Robert X. Cringely, May 2008 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Call for testing: new docs
Jacob Kaplan-Moss wrote: > The best way to help out right now is to grab the "docs-refactor" > branch from my git repo Hereby convened, we mourn the untimely demise of the "toys" hg repo: by many will it be sorely missed, time and again, bringing tears to the cheeks of the afflicted. But no! Don't let our grief get in the way of the good work still to be done. Only, from time to time, do spend a pious thought on our plight, and we shall be released. -- Nicola Larosa - http://www.tekNico.net/ The new totalitarianism is its own justification, and nobody in America or Europe is going to kick up much sand so long as the Darfurs and Haitis remain on the goddamned TV screen where they belong. - Joe Bageant, April 2008 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Is URL template tag's syntax going to change?
Johannes Dollinger wrote: > Of course that's subjective, everything is. You're in the wrong line of work, man... ;-) -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
Daryl Spitzer wrote: > If I don't, I see if I can at least make enough time to write up the API > I came up with at PyCon. Please do, that would be great. -- Nicola Larosa - http://www.teknico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
koenb wrote: > For those interested in multiple database support, I have started > working on it again, and posted my work-in-progress to ticket #4747. > ... > Anyway, if anyone is interested in helping, please let me know! I am going to need this in a month or so. Actions speak louder than words, so many thanks for your efforts. However, there were news two months ago, summarized in this thread: Yet another SoC introduction: Getting multi-db done http://groups.google.com/group/django-developers/browse_thread/thread/a0bc69e64ad8e318/ It would be nice to coordinate each one's efforts, to avoid wasting time. Ben, Daryl, any news? -- Nicola Larosa - http://www.teknico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Rethinking silent failures in templates
Simon Willison wrote: > Silent errors are bad. If we were to remove them, how much of a > negative impact would it have on the existing user base? +1 from me. I always set TEMPLATE_DEBUG to True and TEMPLATE_STRING_IF_INVALID to something that stands out, during development. -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
No locking, no preemptive multithreading [Re: Threading improvements]
Malcolm made great points about the locking problem (I collected them below, for reference). I'd like to add some more context. At the system level, the kernel uses preemption between processes, each with a distinct memory space: that's a safe model (until they interact via the file system, database or other means). When you have multiple threads of execution in the same memory space, you may use cooperation: the so called "green" threads, or coroutines. They are available to Python in Stackless, and with PyPy's greenlets: py.magic.greenlet: Lightweight concurrent programming http://codespeak.net/py/dist/greenlet.html However, preemption and shared memory are like nitric acid and glycerin: when combined, they make something that is sometimes useful, but horribly dangerous. Trying to paper over the problem by introducing locking only makes it worse. Unfortunately Python threads are preemptive, too. Some measure of sanity is restored by the threadlocal module, already used in Django, that gives each thread their copy of data, moving back to the process model. Another useful strategy makes threads only communicate via Queues. Here are more details: The problem with threads http://blogs.sun.com/rvs/entry/the_problem_with_threads I collected a few nuggets of wisdom, for your amusement: http://www.teknico.net/misc/fortune/concurrency.en.txt Sun (in Java) and Microsoft (in Windows) foisted this sorcerer's apprentice stuff on the world, making a disservice to us all. It is up to us to recognize it for what it is, and minimize its usage. Please do yourself and the world a favor: don't use preemptive multithreading for concurrency, if at all avoidable. Malcolm Tredinnick wrote: > I don't see the need for Django providing inter-process locking, since > it's unnecessary complexity, in the scheme of things (and not always > possible -- what if your views are running on different machines?). The > current lock-free approach appears provably correct and seems useful, > providing you have the correct database constraints in place. > ... > I don't think we need general locking primitives in Django because > requiring them is something that can be designed around and usually > makes the design stronger. Plus, getting locking primitives both > functionally complete and correct is unbelievably hard (since you > shouldn't rule out the most efficient ways of running websites: > multiple processes and multiple machines). That's why I'm arguing in > favour of generally lock-free algorithms that use the database as the > synchronisation point. > ... > The very strong argument in designing "shared nothing" styles of > architecture, particularly for web services is to enable proper > scalability without penalising smaller cases with the overhead and > without leaking abstractions into user code (proper locking management > will absolutely require client code to call it, which leaks the whole > locking and synchronisation structure into code that we should be > trying to insulate). > ... > Don't rely on locking more than absolutely necessary. They don't go as > far to say "design around it", since it's a paper on locking and they'd > like to remain relevant, but designing lock-free algorithms (which is > really the ideal solution here) is a much bigger area of computer > science these days with distributed systems. > ... > The critical part of this pattern is how expensive the is_lock() call > might be. Locking, even when there's no contention, on distributed > systems -- processes or machines -- isn't free and is easy to starve > for resources if you don't correctly release it and easy to deadlock if > you don't do it in the right order (and adding deadlock detection to > avoid that isn't free either). > ... > There's a very real risk with allowing locking to creep up into client > code: the rest of the process becomes hostage to that code behaving > correctly. If you take the lock and don't release it, or you take > multiple locks in the wrong order, it's resource starvation time. And > it's not just the request/response path that matters here, so whilst > putting a lock reaper in the response path will be a good idea for any > locking stuff, it isn't a panacea. Any scripts (e.g. cronjobs) also > have to obey the rules and they can be run from anywhere. Locking > primitives are a dangerous thing to add to large code bases. > > I firmly believe (which I think must be obvious from this post and my > last one) that if we can avoid introducing the necessity for this, it > will save everybody -- maintainers and third-party developers alike -- > a lot of trouble down the track. Locking done right means it works in > all cases, otherwise, as Craig pointed out, it's a delusion. Solving > these problems, though, doesn't necessarily require
Re: Django developers in Chicago
James Bennett wrote: > Please note that this list is for discussion of the development of > Django. Things which do not involve discussion of the development of > Django do not belong here. > > This concludes your friendly reminder. It's not over until it's over. ;-) shidokan, job offers are welcome on the django-users Google group. Thank you. -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: deprecated Model.__init__(*args)
Jacob Kaplan-Moss wrote: > I'd like to deprecate initializing models using positional arguments > (i.e. ``p = Person(1, 'Joe Somebody')``) in favor of only allowing > keyword-argument initialization (i.e. ``p = Person(id=1, name='Joe > Somebody')``). Huh? +1 to that. No, wait, make that +1 to erasing the ruttin' posargs "feature" from the gorram *language*. Dong ma? I'll be in my bunk. -- Nicola Larosa - http://www.tekNico.net/ I'm a leaf on the wind. Watch how I soar. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Patch polishing
> Jeremy Dunck wrote: >> As for close rates and other useful metrics, yeah, those should be >> more visible. :) Marty Alchin wrote: > I've wondered about building a Trac plug-in to monitor those types of > things and provide reports. There's a wealth of information in Trac > just waiting to be mined. Those Twisted guys have done it again: ;-) [Twisted-Python] Weekly Bug Summary http://twistedmatrix.com/pipermail/twisted-python/2007-November/016308.html and again: [Twisted-Python] Keeping track of what you're doing http://twistedmatrix.com/pipermail/twisted-python/2007-November/016328.html -- Nicola Larosa - http://www.tekNico.net/ Most users don't care about the distinction between GET and POST (sadly, neither do many developers), but I think there is an understanding that links just lead to another page, whereas buttons perform an action. I see no reason to violate this. -- Chris Shiflett, December 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Debugging Django
John M. Anderson wrote: > I'm trying to debug sql.py > > the steps I've taken so far: > > python /usr/lib/python2.5/pdb.py manage.py sql polls > (python manage.py polls works just fine) You cannot debug a single Django file in isolation. Instead, insert this line: import pdb; pdb.set_trace() in sql.py, at the point you're interested in. Then run Django normally, and go to a db-based URL: you'll get a debugger prompt. -- Nicola Larosa - http://www.tekNico.net/ I grew up with the colonialist propaganda, the "occupier's narrative", and it took me half my life to realize it was all a lie. [...] If I were among those directly afflicted by the genocide, paternalism, exploitation, theft and abuse committed every day by colonial invaders, in almost every nation on the planet, I would be consumed by rage. [...] We should be ashamed of ourselves. -- Dave Pollard, July 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 100% threadsafe with DB?
> Nicola Larosa wrote: >> Right. What *is* is scary is how much people cling to the horrible hack >> that preemptive multithreading is. Derek Anderson wrote: > you mean to say cooperative multithreading, right? > > if so, heck yeah. dear lord in heaven yeah. Erm... what?!? Cooperative MT *is* a hack, and preemptive MT is *not*?!? That sounds backwards to me. :-) I'd like you to elaborate, but we're off-topic here, so feel free to take this to private email, or some more relevant public place. Whatever you please, but do elaborate! :-) -- Nicola Larosa - http://www.tekNico.net/ Love is hate War is peace No is yes And we're all free -- Tracy Chapman, Why?, Tracy Chapman, 1988 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 100% threadsafe with DB?
Derek Anderson wrote: > but then again, python itself isn't multi-threaded. (all threading is > faked - google "global interpreter lock". lazy s.o.b. python devs) so > all your really hairy "c=c+1" type issues are already nixed. > > so not so scary. Right. What *is* is scary is how much people cling to the horrible hack that preemptive multithreading is. -- Nicola Larosa - http://www.tekNico.net/ Love is hate War is peace No is yes And we're all free -- Tracy Chapman, Why?, Tracy Chapman, 1988 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket 5034 Discussion
[EMAIL PROTECTED] wrote: > 5034 is my own ticket, and I have some views about why it should be > included anyway. But maybe I am just too attached to it :) Then be careful, sometimes Trac refuses attachments to tickets, and you may be left stranded in some nowhere land. -- Nicola Larosa - http://www.tekNico.net/ I've heard that directly from folks working on the relevant teams over there. Microsoft cheerfully shows up at the standards meetings to make damn sure they screw up the APIs for everyone else. -- Steve Yegge, September 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Migrating to new-admin...
jdetaeye wrote: > Personally, I feel the page is still very much "developer-oriented", > rather than "django-user-oriented". E.g. the refs to ticket numbers are > useful for the developer, but not for somebody who wants to get going > with the new-admin. > Given a green light I am willing to edit the page further. That *is* a developer-oriented page, since it's part of the dev wiki. :-) The user doc you're looking has been added to the newforms-admin: http://code.djangoproject.com/browser/django/branches/newforms-admin/docs/admin.txt It's in ReStructured Text format, as all the rest of the user docs. -- Nicola Larosa - http://www.tekNico.net/ I'd like to get to a point where I'm making a comfortable living that's independent of any single client or employer, with complete control over my schedule. That's my ultimate goal. -- Phillip J. Eby, April 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Many problems with edit_inline and unique_together
Simon Greenhill wrote: > If anyone's looking for something to do over the weekend [1], there > seems to be one whole metric tonne of issues caused by people trying > to use edit_inline and unique_together at the same time in the admin > section. Yeah, it's the very first I stumbled into, when modeling. > we should either fix the current admin (depending on > how long it'll take newforms-admin to land), to work out what's going > wrong so we don't have the same problem in newforms-admin (..and there > are a few tickets open requesting edit_inline in newforms-admin > already...). To this end, I tried making tests for some of those tickets, but I could not find any test whatsoever for the admin interface. I would really know how should I go in making one. -- Nicola Larosa - http://www.tekNico.net/ Courage, self-confidence, and trust in each other. If we had these things we could live without money, and without wage slavery. Is it any wonder that the politicians, big businesses, the elites of the rich and powerful, work so hard to make us fearful, full of self-doubt, distrustful, and "just like everybody else"? -- Dave Pollack, August 2005 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
Adrian Holovaty wrote: > There are two types of documentation changes: general improvements (bug > fixes, typo corrections, better explanations) and documentation of > new/changed features in trunk. The tension between those changes is the > issue here. Only if you make it so, and you shouldn't. :-) > Our philosophy so far has been that documentation improvements are > something that *all* current Django users should benefit from, including > users of trunk *and* users of the latest release. If we find typos, or > we take the time to write up better explanations of things, we want to > have that positive effect on as many users as possible. Hence, we point > people by default at the very latest versions of the docs, because they > have the latest and greatest stuff. The cost/benefit ratio is not there. > But the problem isn't with the documentation improvements, of course -- > those don't confuse people (we hope!). The problem is with the parts of > the documentation that are specific to the Django development version. It does not work. You cannot really get people to use the trunk docs, but in many places say: "Oh, by the way, this little thing changed, please refer to the *right* release docs, but do come back when you're done, thank you." again and again. It's confusing, and annoying: it's not worth it. Come on, you made a release, accept it for what it is, with its code, *and* its docs. Anyone wanting better code, *or* better docs, should just use the trunk. That way you may include usable docs with the release, which is what people expect anyway (see my other message). (Otherwise, by the way, why let those django/docs/*.txt files slip inside each release?) > I should stress that, if we continue down this path of pointing people > at the trunk documentation by default, all documentation changes that > refer to new trunk features *must* be written in a way that users of > 0.96 will understand the change does not apply to them. We need to do a > better job of telling contributors and documentation writers that this > is how we do things. That's a laudable and worthy goal, but it does not allow to err on the side of safety. Better to accept that each release docs are what they are, and move forward. > As Matt McClanahan and some others pointed out, we could instead point > to the latest *release* docs by default. The trunk docs would be at > another URL, and presumably if you're sophisticated enough to use trunk, > you're sophisticated enough to know to go to that other URL. Right. > The advantage of this is that in the common case of a new user > downloading the latest release and going to the main documentation page, > he/she won't get confused. They shouldn't have to go the web site: the release docs should be on their disk, within the installed release itself (see my other message). > The disadvantage is that those release-specific docs won't have the > dozens of documentation improvements that come in every week, Just accept it, it's not worth the effort. > unless we fork the docs and apply every improvement to *both* the > latest-release docs and the trunk docs (which isn't worth the overhead). Exactly. > Is there any other, better way to do it than how it's currently being > done? It's an imperfect system, but it's "more perfect" than the other > choice that comes to mind. Again, see my other message. -- Nicola Larosa - http://www.tekNico.net/ Itamar Shtull-Trauring: reactor.stop() is the way to go, yes. Call it when you want the program to start. Nicola Larosa: To be able to do that you would have to recall John and George from heaven, reform the Beatles, pay them a lot to compose "Stop Me Down", and use that as the sound theme. -- April 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
Adrian Holovaty wrote: > Is there any other, better way to do it than how it's currently being > done? It's an imperfect system, but it's "more perfect" than the other > choice that comes to mind. Yes, there is a better way to get the right documentation in the hands of those who use a release: include the documentation in the frigging release, and make it usable! Current situation - The doc ReST source files are included in the release, but not the HTML, generated ones. The HTML doc index is not included. Users have to install docutils, run buildhtml on django/docs, manually point the browser to that directory, and they get unstyled paged, with no images, and whose links among them do not work. How to do it Use something like the django-documentation app by SmileyChris: http://smileychris.tactful.co.nz/ramblings/django-documentation/ Let users access the docs from both without and within the admin interface. The HTML generated files should be included in the release, so that users do not need to have docutils installed. Pros The users can easily access the right documentation locally, without needing access to the web site. The users do not risk getting to the wrong version of the docs. The load on djangoproject.com lessens considerably. Cons None that I can see. It's a no-brainer to me! :-) -- Nicola Larosa - http://www.tekNico.net/ Itamar Shtull-Trauring: reactor.stop() is the way to go, yes. Call it when you want the program to start. Nicola Larosa: To be able to do that you would have to recall John and George from heaven, reform the Beatles, pay them a lot to compose "Stop Me Down", and use that as the sound theme. -- April 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Autoescaping: good time?
Simon Willison wrote: > Generally I'm really glad to see that most people have come round to > autoescaping being on by default now. I personally don't see it as a > way of protecting newbie developers so much as it's a way of > protecting all developers from one tiny mistake blowing the security > of their application wide open. Very well said, and worth emphasizing; thanks, Simon. -- Nicola Larosa - http://www.tekNico.net/ Any word not used as an expletive is not being used to its fullest potential. -- Fred Drake, March 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: edit_inline for a reflexive m2m_intermediary
Nicola Larosa wrote: > Having followed all the steps in the bug reporting guidelines, I have > now filed ticket #4937: > > http://code.djangoproject.com/ticket/4937 Marked as duplicate of #1939, sorry about that. #1939 and lots of other tickets are listed at: http://code.djangoproject.com/wiki/FeatureGrouping#edit_inlineIssues It looks like newforms-admin is actually the way to go, I'll search the wiki and this group for more info about it. -- Nicola Larosa - http://www.tekNico.net/ Having a job is not unimportant, but if knowing Perl is a requirement for a particular job, consider another one before taking that one. This is true even if you know Perl very well. Life is too long to be an expert at harmful things, including such evilness as C++ and Perl. -- Erik Naggum on comp.lang.lisp, March 2000 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
Tom Tobin wrote: > I'll accept that I'm an outlier, then; I'm also the only one at work > who can't stand working with multiple and/or large monitors, and the > only one who prefers quickly flipping between maximized windows for > most apps rather than having multiple apps side-by-side. (Yeah, I > guess that cements me as a weirdo.) ;-) Not so fast: I work exactly that way too, on a laptop's 15" display, wide format. But then, I've been labeled a weirdo myself more than once, so I cannot really disprove your notion. ;-) -- Nicola Larosa - http://www.tekNico.net/ If web applications liberated us from the domination of a single company on the desktop, why would we be eager to be dominated by a different company on the web? [...] I'm not eager to go from being beholden to Microsoft to being beholden to Adobe. -- Ted Leung, March 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: docstrings
Malcolm Tredinnick wrote: > That being said, whilst I strongly prefer 80 character limits, I can > handle lines being longer in circumstances, too, for all the normal > reasons (some lines just don't break). All lines break, and most break gracefully, unless there's an assignment left side longer than 70 chars: but then there are bigger style problems. :-) > People seem to forget that one of the key rules in any coding guidelines > is "do what the existing code does" (see, e.g., the second section of > PEP 8). Thus, our current standards are in not in conflict with PEP 8 or > PEP 257. Are Django committers willing to accept patches that reformat lines within 80 characters? -- Nicola Larosa - http://www.tekNico.net/ If web applications liberated us from the domination of a single company on the desktop, why would we be eager to be dominated by a different company on the web? [...] I'm not eager to go from being beholden to Microsoft to being beholden to Adobe. -- Ted Leung, March 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: edit_inline for a reflexive m2m_intermediary
> Nicola Larosa wrote: >> Having followed all the steps in the bug reporting guidelines, I have >> now filed ticket #4937: Russell Keith-Magee wrote: > You should note that the bug reporting guidelines don't suggest you > should announce tickets on django-developers. Good to know. I'll now meta-break this rule to announce that I have made the ticket #4942 with a patch to contributing.txt adding such rule. ;-) > You only need to start a django-developers discussion if there is some > sort of design issue to resolve (for example, if you want to fix the > bug, and want advice on the correct solution to a problem). Another thing I did not say clearly. Yes, I want to fix the bug. I'm going to start a debugging session right now to try fixing it. I understand it's probably related to oldforms, so I'd like advice about which course of action to follow: 1) trying to fix the current code: how? 2) trying to use newforms-admin instead: how? -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: edit_inline for a reflexive m2m_intermediary
Tom Tobin wrote: > Django-developers isn't a "Help Desk Level 2"; please don't try to use > it as such. Maybe too much politeness on my part obscured the main point, so let's be blunt this time: there's a bug in Django. (Oh, the horrors! ;-P ) Or maybe not, whatever. Having followed all the steps in the bug reporting guidelines, I have now filed ticket #4937: http://code.djangoproject.com/ticket/4937 Do what you will with it, and thank you. -- Nicola Larosa - http://www.tekNico.net/ The Christian religion, like those of Judaism, Islam and all the rest, are manufactured belief systems to keep their advocates in mental and emotional servitude, while being played off against each other to divide and rule. -- David Icke, February 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
edit_inline for a reflexive m2m_intermediary
[Sent this to the users list with no answer, and who knows, maybe it's not me, but actually a bug instead. :-) I also tried using the newforms-admin branch, but most URLs are absent or commented out...] I'm following the m2m_intermediary pattern: 9. Many-to-many relationships via an intermediary table http://www.djangoproject.com/documentation/models/m2m_intermediary/ However, I need associations, not between two different models, but between pairs of instances of the *same* model, as discussed in this thread: Friendship_type on symmetrical M2M http://groups.google.com/group/django-users/browse_thread/thread/72afc8b5540dd75e/68688173a04a027d Take this Person model: class Person(models.Model): first_name = models.CharField(maxlength = 100) last_name = models.CharField(maxlength = 100) and associate pairs of persons, while adding some data: class Association(models.Model): person = models.ForeignKey(Person, related_name='friend_of') associate = models.ForeignKey(Person, related_name='friends') some_data = models.IntegerField() The admin interface for these models works correctly. Now, to be able to add Associations while editing Persons, I add edit_inline and core to Association fields. If I add them to both ForeignKey fields: class Association(models.Model): person = models.ForeignKey(Person, related_name='friend_of', core=True, edit_inline=models.TABULAR) associate = models.ForeignKey(Person, related_name='friends', core=True, edit_inline=models.TABULAR) dummy = models.IntegerField() I get this error: Traceback (most recent call last): File ".../django/template/__init__.py" in render_node 754. result = node.render(context) File ".../django/template/defaulttags.py" in render 134. nodelist.append(node.render(context)) File ".../django/contrib/admin/templatetags/admin_modify.py" in render 171. bound_related_object = relation.bind( context['form'], original, bound_related_object_class) File ".../django/db/models/related.py" in bind 129. return bound_related_object_class(self, field_mapping, original) File ".../django/contrib/admin/templatetags/admin_modify.py" in __init__ 138. for (i,field_mapping) in self.field_mappings.items() ] File ".../django/oldforms/__init__.py" in items 264. self.fill() File ".../django/oldforms/__init__.py" in fill 283. field = self.parent_manipulator[full_field_name] File ".../django/oldforms/__init__.py" in __getitem__ 28. raise KeyError, "Field %s not found\n%s" % ( field_name, repr(self.fields)) KeyError at /admin/person/add/ 'Field association.0.associate not found [FormField "first_name", FormField "last_name", FormField "association.0.id", FormField "association.0.person", FormField "association.0.dummy", FormField "association.1.id", FormField "association.1.person", FormField "association.1.dummy", FormField "association.2.id", FormField "association.2.person", FormField "association.2.dummy", FormField "association.0.id", FormField "association.0.person", FormField "association.0.dummy", FormField "association.1.id", FormField "association.1.person", FormField "association.1.dummy", FormField "association.2.id", FormField "association.2.person", FormField "association.2.dummy"]' If I only add edit_inline and core to the first ForeignKey field: class Association(models.Model): person = models.ForeignKey(Person, related_name='friend_of', core=True, edit_inline=models.TABULAR) associate = models.ForeignKey(Person, related_name='friends') dummy = models.IntegerField() I get this other error: Traceback (most recent call last): File ".../django/template/__init__.py" in render_node 754. result = node.render(context) File ".../django/template/defaulttags.py" in render 134. nodelist.append(node.render(context)) File ".../django/contrib/admin/templatetags/admin_modify.py" in render 171. bound_related_object = relation.bind( context['form'], original, bound_related_object_class) File ".../django/db/models/related.py" in bind 129. return bound_related_object_class(self, field_mapping, original) TypeError at /admin/diet/person/add/ 'bool' object is not callable What am I missing? -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
> James Bennett wrote: >> Django is compatible with any version of Python greater than 2.3 Don Arbow wrote: > You mean >=, right? :-) Well, 2.3.6 is strictly greater than 2.3 . ;-) http://www.python.org/download/releases/2.3.6/ -- Nicola Larosa - http://www.tekNico.net/ I accuse you, Mr. Bush, [...] of fomenting fear among your own people, of creating the very terror you claim to have fought. -- Keith Olbermann, July 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: please help! need to know python version
Carl Karsten wrote: > Python code is not developed in Python. You should talk to the PyPy guys/gals someday. ;-) > that can be debated, but for the purposed of this thread, I think it > fits. Oh, you already took the above comment into account. :-) -- Nicola Larosa - http://www.tekNico.net/ I accuse you, Mr. Bush, [...] of fomenting fear among your own people, of creating the very terror you claim to have fought. -- Keith Olbermann, July 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Documentation should never show non-working examples. - was: "@cache_page" bug...
jedie wrote: > Sorry, you have misunderstood this. Thus I have not meant this. ;) > > Fixing the ticket #1015 is not important to me. Insisting on telling people what to do, and not really doing anything yourself, is obnoxious. Please make a patch first, and then quibble, preferably in the ticket. -- I accuse you, Mr. Bush, [...] of fomenting fear among your own people, of creating the very terror you claim to have fought. -- Keith Olbermann, July 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Shared memory across processes
Marty Alchin wrote: > I remembered seeing that FastCGI can not only run as prefork, Thank goodness. > but defaults to it. Thank *goodness*. One day mutable-shared-state, preemptive multithreading will be looked down on as the ugly, awful, historical accident that it is. The signs are good already. -- Nicola Larosa - http://www.tekNico.net/ Q: Aside from Dojo, what is your favorite Ajax framework? A: MochiKit. YUI is great code too, but MochiKit has it beat for clarity of vision and implementation quality. Bob Ippolito gets the constraints of the web. That, and I'm a Python guy at heart. -- Alex Russell, August 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
KIPS (Keep It Personal, Stupid!) [was: Re: International standard for date and time]
> Jonas wrote: >> I remember to you that we are to interacting with computers, not with >> persons. James Bennett wrote: > The problem is that we're not really "interacting with computers". > We're using computers as proxies to help us interact with *people*, > and they should be first in our thoughts at all times. Very well said, and easily and sadly forgotten, sometimes. In this day and age, these machines are not mere computing devices, nor "ordinateurs": they are communicators, conveying and embodying many facets of the human beings that use them. (Many other human facets still elude our machines, but that would be doubly off-topic. ;-) ) -- Nicola Larosa - http://www.tekNico.net/ I'm not expecting Ubuntu to be perfect, but I am now certain it will be enough better to compensate me for the fact that I need to learn a new set of administration tools. Fedora, you had every advantage, and you had my loyalty, and you blew it. And that is a damn, dirty shame. -- Eric S. Raymond, February 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
> Michael Radziej wrote: >> Publically cheering to dictatorial decisions is a good tradition all over >> the world ;-) Jacob Kaplan-Moss wrote: > When do I get to rename months after my family? > > [http://en.wikipedia.org/wiki/Saparmurat_Niyazov#New_Names_for_Months_and_Days] Don't know about months, but there's already a Physical Modeling Sound Synthesizer Board under your name: http://www.korg.com/gear/info.asp?A_PROD_NO=EXBMOSS -- Nicola Larosa - http://www.tekNico.net/ Anyone who says their ambition is "to be famous" is a fragile ego desperate for external recognition and for these people the Big Brother show can be a devastating experience, not least with the constant fear of public "reject- ion". Being voted out means "they don't love me" when the real problem is that the celebs don't love themselves. -- David Icke, January 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
> Jacob Kaplan-Moss wrote: >> I'm going to make a dictatorial call to paint the bikeshed MY color. Jason Davies wrote: > +1. What part of "dictatorial" is not clear? ;-) -- Nicola Larosa - http://www.tekNico.net/ Microsoft went berserk; tried unsuccessfully to get me fired as co-editor, and then launched a vicious, deeply personal extended attack in which they tried to destroy my career and took lethal action against a small struggling company because my wife worked there. It was a sideshow of a sideshow of the great campaign to bury Netscape and I'm sure the executives have forgotten; but I haven't. -- Tim Bray, January 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
James Bennett wrote: > In all seriousness: django.contrib.bikeshed. Magenta! Shall we paint it magenta? Pretty please? -- Nicola Larosa - http://www.tekNico.net/ Microsoft went berserk; tried unsuccessfully to get me fired as co-editor, and then launched a vicious, deeply personal extended attack in which they tried to destroy my career and took lethal action against a small struggling company because my wife worked there. It was a sideshow of a sideshow of the great campaign to bury Netscape and I'm sure the executives have forgotten; but I haven't. -- Tim Bray, January 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: + Important: Repent, Completely trust in God only and, Love Him with all of your heart.
Luke Plant wrote: > I imagine the atheists on this list find it even more annoying, In the meanwhile we, the agnostic ones, simply skip it. ;-) -- Nicola Larosa - http://www.tekNico.net/ That's what *professionals* do. They are always learning. Always. Because nothing you learn about what's "the best" or "the worst" stays the same forever. And if you don't keep up, you're just falling behind. -- Phillip J. Eby, January 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session unpickle exceptions silenced
Ben Godfrey wrote: > It was very hard to trace this to the Session.get_decoded method and it > felt like a bit of a slap to find all pickle.loads exceptions being > dropped silently. Is this really the best thing to do? Surely it would > be better to raise the exception so that the programmer can see it? There are currently 36 naked "except" clauses in the Django trunk. Most of them do something sensible, given each situation; a few just silence the errors, which is not good enough. A nice idiom is used in several places: try: ... except: if settings.DEBUG: raise Let's have more of those. :-) -- Nicola Larosa - http://www.tekNico.net/ PHP lends itself to a style of coding that is so not DRY, it's like coding underwater. -- Sean Schertelli, September 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The locmem patch and development progress
Jacob Kaplan-Moss wrote: > I've filed tickets and bugs against many other projects, and as you > might expect the results run the gamut from "fuck you"[1] to being > checked in instantly. > ... > [1] No prizes for guessing which project this was. I'll have a shot anyway: RoR? ;-} http://www.flickr.com/photos/doesrails/128015501/in/pool-canadaonrails/ > We all have some combination of full-time jobs, wives, That would be "spouses", even in the case all Django committers should be heterosexual males. ;-P > Once again I'm very sorry if any of the above comes off as dickish. It doesn't to me. You may want to save a copy of this message, it may come out useful next month. ;-) -- Nicola Larosa - [EMAIL PROTECTED] Crypto is like an ATM that only lets you get money after you authenticate yourself with your card and PIN. DRM is like some kind of nefarious goon hired by the bank to follow you around after you get your money out, controlling how you spend it. -- Cory Doctorow, December 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [Changeset] r4828 - django/trunk/django/conf/locale/de/LC_MESSAGES
[Cc: to Django-IT and Django-I18N] Malcolm Tredinnick wrote: > One thing we do have to watch out for as translation activity picks up > is that we currently have no language coordinators/maintainers. This > could potentially lead to translation "battles" with some phrases > changing back and forth, if there's any confusion or dispute. Having the > names of previous contributors makes tracking down the history and > resolving these problems a little easier. That's not going to help when one's having "battles" with oneself. Case in point, before 0.96 I updated the italian translation, more or less out of the blue. Then some discussion ensued on the italian Django mailing list, which prompted me to make further updates a couple of times. In the meanwhile, the author named the .po file stayed the same, of course. :-) > However, Jacob and I have discussed (after prompting from the > translators) giving commit privileges under django/conf/locale/ to > certain language maintainers -- one for each language -- to keep things > on an even keel there. That makes a lot of sense to me, because, > frankly, I have no way to judge if a patch for, say, the XYZ locale is > an improvement or not; I would much rather have a native speaker take > responsibility there. That would be great. It would make it easier having more frequent updates and corrections, relieving the burden of committing them from the main developers. It could also lead to a bit more instability and more changes than necessary, but that can be mitigated if the language maintainers try to discuss changes locally a bit, before committing them. Yes, I'm promising I'll do better on that front, from now on. ;-) > Jacob wants to make it easier for those people to > set up passwords via the web interface to ease his load a little, so > that will happen in due course, but I realise he seems pretty busy at > the moment, so I'm not pushing that yet. For now, we don't really have a > problem here, so it's not blindingly urgent. Well, as they say, best is enemy of good. :-) Setting up passwords centrally is a one-time job, while the translation-committing burden lightening is ongoing: maybe it's better not to wait for such a web interface to materialize. > Assuming you're happy with allowing locale maintainers to commit > directly (it's pretty normal on a lot of other projects), I don't think > there's a technical reason for having the names in the code, so we > should be consistent. Ok, go ahead and strip the italian translation of them too, I and the previous translator (hi, C8E!) are in AUTHORS already. No, I'm not creating a patch. ;-P -- Nicola Larosa - [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
OFFTOPIC: Italian translation ready [was: Re: Constraints and MySQL]
Jacob Kaplan-Moss wrote: > Right now #2333 is all that 0.96 is waiting on Please don't forget #1984. Thank you. -- Nicola Larosa - http://www.tekNico.net/ When talking about Security, most people think about something where "they" attack and "we" defend. If they succeed only once, we have lost. If we succeed in defending, the next wave of attackers will be ready, meaner and faster than the first wave. This is not "Security", this is "Space Invaders". -- Kristian Köhntopp, April 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Please encourage PsycoPG 2 usage (not 1!)
Dear devs, please apply the patch in ticket #3364 as soon as possible. There's still people around that do not use PsycoPG 2, because of that obsolete note in doc/install.txt . Thank you. -- Nicola Larosa - http://www.tekNico.net/ I've heard that some people have a saying: "Pain is weakness leaving the body." If that's true, then fear is also weakness leaving the mind. So, go ahead and do what you are afraid you can't. It is not the way to an easy life, only a worthwhile one. -- Phillip J. Eby, August 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Auto-escaping patch
Malcolm Tredinnick wrote: > But it's all "git" under the covers. I wrote up a brief description when > I started using this a few months ago: > http://www.pointy-stick.com/blog/topics/software/version%20control/ . (I know, I should have directly commented on that page, and I would have, if there would have been a way to do so. ;-) ) "One of the talks I went to at OSCON was about using mq: patch queue management on top of mercurial, a la quilt." ... "Inspired by this talk, I checked out stgit, since I tend to use cogito as my personal version control system of choice these days for various reasons." You don't say what those reasons are; presumably you were already using git and cogito, so trying stgit was the most efficient path. Nonetheless, I am interested in the reasons why you apparently did not consider using Mercurial and mq, that seem to have the features you need, and are mostly written in Python. It's not that one always aspires to a wholly Pythonic world (well, not when fully awake, at least ;-) ), but if the tools are Pythonic, it should be easier hacking *on* them, instead of just with them, if and when needed. -- Nicola Larosa - http://www.tekNico.net/ I've heard that some people have a saying: "Pain is weakness leaving the body." If that's true, then fear is also weakness leaving the mind. So, go ahead and do what you are afraid you can't. It is not the way to an easy life, only a worthwhile one. -- Phillip J. Eby, August 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Autoescaping for 1.0
On 13 Gen, 06:02, "SmileyChris" <[EMAIL PROTECTED]> wrote: > We need to come to a consensus on Django autoescaping There's an interesting discussion on GvR's blog, with several mentions of escaping: http://www.artima.com/forums/threaded.jsp?forum=106=146606 Speaking of Django 1.0, it also contains this promise from Adrian: :-) "Note that at the moment Django needs an environment variable DJANGO_SETTINGS_MODULE, as Guido mentioned, but that dependency for the template system will soon go away -- as I mentioned in a previous comment in this forum." -- Nicola Larosa - http://www.tekNico.net/ Cannavaro Cannavaro Cannavaro, what else is there to say? [...] He stopped Klose and he stopped Ballack and he stopped Podolski and he stopped Odonkor and he stopped Schneider and he stopped Schweinsteiger, most of them more than once. [...] Cannavaro was the knife in Germany's heart. -- Tim Bray, July 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Named auth backends and backend specific profiles
On 11 Gen, 22:34, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote: > I'd love to use a dictionary, but the order of backends matters. I > wish python had a decent syntax for what basically amounts to an > ordered dict. It's a FAQ, and bait for flamefests, here's a big one: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/5ac716f9ad14cc04/d5b97a5e2eb39d05 Every middle-to-big project has its own version, and Django is no exception, look in django.utils.datastructures. Here's a bit more fledged, documented and tested one, by yours truly: http://www.voidspace.org.uk/python/odict.html -- Nicola Larosa - http://www.tekNico.net/ Don't get me wrong, I like Ruby. And it's not particularly difficult to read. But the philosophy of the language designers led to design choices that emphasize writability over readability. And in that department I think the advantage has to go to Python. -- Mark Ramm-Christensen, June 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
That would be *cookieless* [was: Stateless sessions almost here]
Brian Beck wrote: > So I'm working on a stateless sessions app that people will be able to > swap with django.contrib.sessions in their settings if they need that > (a recent post mentioned mobile phone browsers for example, apparently > they don't support cookies?). I don't actually care that much but I > thought it would be a fun hack. "Stateless session" is an oxymoron, there's no such thing. You're talking about *cookieless* sessions. Yes, REST-purist speaking here. -- Nicola Larosa - http://www.tekNico.net/ In the developed world, we do not have a shortage of IPv4 addresses at this time. [...] In the developing world the situation is already dire. In some places, entire universities are hidden behind a single routable IPv4 address, and in others, NAT's are as much as 5 levels deep. -- Jim Gettys, June 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Have a look at django.newforms
Adrian Holovaty wrote: > The try/except in this case is meant to handle the case in which > somebody is using newforms without the rest of Django, which was an > early goal of mine. Since then, I've sort of resigned myself to > requiring Django, due to ties into the internationalization hooks and > various Django functions, but it's still an eventual goal. We're going to use newforms in a project centered on another framework, so it would be great if you could keep minimizing the dependencies it has on the rest of Django. -- Nicola Larosa - http://www.tekNico.net/ Who wants a nation of law-abiding citizens? What's there in that for anyone? But just pass the kind of laws that can neither be observed nor enforced nor objectively interpreted - and you create a nation of law-breakers - and then you cash in on guilt. -- Ayn Rand, Atlas Shrugged, 1957 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Moving old-style classes to new-style
This post on django-users: http://groups.google.com/group/django-users/msg/7d4773cccde8d51d manifests some interest in moving the old-style classes to new-style: with some fairly short grunt work I made a patch about it, and attached it to ticket #2109: http://code.djangoproject.com/ticket/2109 All tests pass. I did not convert the Meta and Admin classes in the model definitions, they break some tests, and it's also a user visible change. Furthermore, I did not convert the Promise class in utils/functional.py either, it break other tests about __proxy__ objects, I leave it to you. -- Nicola Larosa - http://www.tekNico.net/ Continuation-based web frameworks (like Seaside) seem lame to me. I'm so much more impressed by event-based programming, and continuations (used in that way) seem like a way to avoid explicit events. Events are the web. Continuations are people who want to make the web into an MVC GUI. -- Ian Bicking, February 2006 --~--~-~--~~~---~--~~ 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: the so-called [AUDIT]
C8E wrote: > and maybe also > > http://www.encyclopediadramatica.com/index.php/Ilias > > ;) Didn't want to steal your thunder, pal, but since you weren't speaking up, I did. Thanks for that URL! :-) -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
We're being had
Ilias Lazaridis is a known Internet troll. http://www.encyclopediadramatica.com/index.php/Ilias Let's stop feeding him/her/it, it's just a waste of time. -- Nicola Larosa - http://www.tekNico.net/ Users know the business better than you do, whoever you are. If you are willing to learn, you can change the world. -- Dratz, February 2006 --~--~-~--~~~---~--~~ 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: Patch review procedure?
>> Works like a charm. (I'm hardly an svk expert, though, so there are >> probably easier/less verbose recipes for doing the same thing.) > If only Darcs were the norm... As far as distributed VCSes go, I'd like to cast my vote for Mercurial. It's a little Python jewel, as fast as Git, more concise than Bazaar-ng, and command-compatible with Subversion. It also has a plugin for interaction with Trac, albeit not integrated yet. -- Nicola Larosa - http://www.tekNico.net/ we do what we're told we do what we're told we do what we're told told to do -- Peter Gabriel, We Do What We're Told, So, 1986 --~--~-~--~~~---~--~~ 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: OT: arbitrary precision decimals for Python?
> Sorry for the OT post, but what do people use for arbitrary > precision decimals in Python? > > I would think it's in the standard libraries somewhere, but I > must be googling the wrong terms. It's called... [drum roll] decimal! ;-) http://docs.python.org/lib/module-decimal.html -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ 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: svn merge problem
> I can't find it now, but I recall reading on the Mercurial site that it > doesn't support versioning directories, which seems like an awful step > back into cvs-land. Maybe I misunderstood? Directory versioning is obviously supported. There are some limits on renaming: http://www.selenic.com/pipermail/mercurial/2006-April/007822.html http://www.selenic.com/pipermail/mercurial/2006-May/008268.html -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
