Re: Newbe questions (firebird)
I am using FB 2 and am planning on going on to 2.1. Any overly complex queries I will probably hand code, as I am pretty familiar with pleasing FB's optimizer. This project won't be ready for production for some time, probably going to wait for Django to go 1.0 first anyway. Thanks for all your help everyone. On Mon, May 5, 2008 at 6:19 PM, Ivan Illarionov <[EMAIL PROTECTED]> wrote: > > Hi, Rahein, > > The Firebird patch and backend is against latest Django trunk and > depends on the newest Django features, especially new QuerySet/Query > classes. Please note that there are known bugs with very complex ORM > queries. It's also important to use the latest Firebird (> 2.0). > Earlier versions of Firebird (1.5) don't work with model inheritance > and queries like filter(...).filter(...) and few others while Firebird > 2.0 works. > > And, remember, Firebird backend is ALPHA software. It's not for > production yet. > > Regards, > Ivan > > On May 6, 1:23 am, "Rahein Sorite" <[EMAIL PROTECTED]> wrote: > > Ahh that must be it, thanks. I am using 0.96.1. I am about to head out > for > > the day, but I will try it with the current trunk tomorrow. > > > > Thanks for your help Ian. > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Want to have unit tests in multiple files
Hi, we're just getting started using Django unit tests, and it looks like the documentation says you can only have unit tests in two files: models.py and tests.py. We would prefer to put our unit tests in many different files, with, say, each main-line .py file having a corresponding unit-test file. Is there a convenient way to do this in Django? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Want to have unit tests in multiple files
Hi, you can always define your own test runner which will look not only in tests and models, but in every module. This question is more suited for the django-users mailing list, this list is intended for discussing development of django internals. On Tue, May 6, 2008 at 10:21 PM, Steve <[EMAIL PROTECTED]> wrote: > > Hi, we're just getting started using Django unit tests, and it looks > like the documentation says you can only have unit tests in two files: > models.py and tests.py. We would prefer to put our unit tests in many > different files, with, say, each main-line .py file having a > corresponding unit-test file. Is there a convenient way to do this in > Django? > > > -- Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: Want to have unit tests in multiple files
No. Not `tests.py`, but `tests` module - that can be a package of many other modules/files On May 7, 12:21 am, Steve <[EMAIL PROTECTED]> wrote: > Hi, we're just getting started using Django unit tests, and it looks > like the documentation says you can only have unit tests in two files: > models.py and tests.py. We would prefer to put our unit tests in many > different files, with, say, each main-line .py file having a > corresponding unit-test file. Is there a convenient way to do this in > Django? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
markdown, unicode, and escaping
Markdown 1.7, released February 17, 2008, has a backwards-incompatible change. " Additionally, the encoding argument has been removed from both markdown and Markdown. Markdown expects unicode (or ascii) input and it is the users responsibility to ensure that's what is provided. " The current django filter[1] passes the results of smart_str, which is explicitly a byte-string, defaulting to utf-8. I think there should be a branch checking the markdown version, and passing in a unicode object if markdown.version_info >= (1,7,0,''). Also, and probably more important: markdown allows HTML to be passed in and spit out; the markdown filter marks output as safe. Is it an intended design choice to have applying the markdown filter result in unescaped output? Perhaps this side-effect should be noted in the docs[2]? [1] http://code.djangoproject.com/browser/django/trunk/django/contrib/markup/templatetags/markup.py#L35 [2] http://www.djangoproject.com/documentation/add_ons/#markup --~--~-~--~~~---~--~~ 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: markdown, unicode, and escaping
On Tue, May 6, 2008 at 6:30 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Markdown 1.7, released February 17, 2008, has a backwards-incompatible change. > > " > Additionally, the encoding argument has been removed from both > markdown and Markdown. Markdown expects unicode (or ascii) input and > it is the users responsibility to ensure that's what is provided. > " Apologies; quote is from here: http://www.freewisdom.org/projects/python-markdown/News --~--~-~--~~~---~--~~ 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: API question for model saving
Here is the patch i was talking about: http://code.djangoproject.com/ticket/5309 On Apr 28, 5:02 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-04-28 at 13:49 +0200, David Danier wrote: > > > For this particular case it saves a whole line. One concern I have is > > > that if there's more complex logic in your overridden save method, some > > > of it is going to be useful in both cases and now you have to create > > > extra sub-functions for the common bits and remember to call them both > > > times. It leads to duplication. If you look around at sample code on > > > django-users and other places, you can see people doing a number of > > > pieces of auxilliary processing as a result of save happening on the > > > instance, so this isn't a trivial issue. > > > No, it does not duplicate code, as you still could use save() for common > > code. > > Common stuff *must* to be called from both create() and update() in your > case because you're proposing that people should be allowed to call them > directly. > > That means save() is only ever going to be a placeholder for backwards > compatibility. Not worth it. > > > > > > > >> BTW, create()/update() sounds more explicit to me than save(). > > > > Which immediately leads to one of the problems with it. Suppose I'm > > > writing a function that accepts objects, does something to them and then > > > wants to save them. Do I call create() or update()? There's no way to > > > tell. Currently, I call save() with no ambiguity problem. > > > > Also, this presents an unnecessary backwards-incompatibility. Every > > > single piece of code now has to change to use one or other of these > > > methods. Every save() call. Currently and with the parameter approach, > > > *zero* existing code has to change initially. If you want to support the > > > must insert vs. must update difference, you can add a parameter (or two, > > > depending on which approach we take) and it's still backwards > > > compatible. > > > Sorry, but this sounds like you did not read my email at all (to which > > David Larlet sent a reply). I proposed still having save(), but > > implementing it like this: > > I did read your mail. Then, whilst writing my reply, I forgot that you > had proposed this plan because I was noting the problem with the common > code. save() becomes a dead method here unless people are forced to call > it. If an individual wants to split their save() handling into a create > and an update path in separate functions, that's fine. They can do that. > But Django's core doesn't need to do that; there just isn't the amount > of code to require it. > > I didn't mean to dismiss your code fragment, David. I apologise. I was > trying to collapse multiple responses into one. > > [...] > > > You don't have to stick to this names. I just used them, as I think they > > are pretty self-explainig. > > The point is that any names have the potential for a clash. We're very > miserly about taking names form the common namespace for that reason: > you have to pick something easily understandable and not likely to > collide. Not introducing any new names is safest of all. > > Regards, > Malcolm > > -- > Save the whales. Collect the whole set.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: markdown, unicode, and escaping
On Tue, May 6, 2008 at 7:30 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > > I think there should be a branch checking the markdown version, and > passing in a unicode object if markdown.version_info >= (1,7,0,''). Um, what about lines 71-74 [1] does not do this? Yeah the check is the other way, but it has the same effect. Added in changeset 7423 [2] three weeks ago. [1]: http://code.djangoproject.com/browser/django/trunk/django/contrib/markup/templatetags/markup.py#L71 [2]: http://code.djangoproject.com/changeset/7423 > > Also, and probably more important: markdown allows HTML to be passed > in and spit out; the markdown filter marks output as safe. Is it an > intended design choice to have applying the markdown filter result in > unescaped output? Perhaps this side-effect should be noted in the > docs[2]? > Yeah, we probably should mention this in the docs, along with an explanation of how to enable Markdown's safe_mode. Sure, it's explained in the source, but the other markup filters don't offer any extra features so I doubt most people even look unless they encounter a problem. -- Waylan Limberg [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 -~--~~~~--~~--~--~---
Re: markdown, unicode, and escaping
On Tue, May 6, 2008 at 8:21 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > On Tue, May 6, 2008 at 7:30 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > > > > > > I think there should be a branch checking the markdown version, and > > passing in a unicode object if markdown.version_info >= (1,7,0,''). > > Um, what about lines 71-74 [1] does not do this? Yeah the check is the > other way, but it has the same effect. Added in changeset 7423 [2] > three weeks ago. > ... That's what I get for looking at my local, old rev, then assuming it's still a problem on trunk. Sorry. :-/ > Yeah, we probably should mention this in the docs, along with an > explanation of how to enable Markdown's safe_mode. Sure, it's > explained in the source, but the other markup filters don't offer any > extra features so I doubt most people even look unless they encounter > a problem. Also, with 1.7, django trunk makes safe mode either True or False, but markdown takes three values (replace, escaped, remove) and True equates to replace. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Partial Models Discussion
I'd like to present my concept for partial models, which would be an attempt to replace the use of .values() returning a dictionary (although .values() still has uses if you dont actually want an instance). Keep in mind, the way I'm presenting this would keep #17 working :) values, values_tuple, and partial models, in my opinion, should all be replaced with one method call (what if theres a values_list or values_set, seems ugly). This would become a new values method: values(results=[object|tuple|dict]) or something similar Upon returning the object, you would get proxies, which held a model instance in it. The proxy itself, would allow you to override any field (e.g. this would be useful for .extra(select)), but any fields which aren't set could be passed back to the model (so you could override a foreignkey, without affecting the model instance, and thus not affecting #17). When the proxy is instanced, we would identify which fields are currently available, and map those in. We would also similarly make sure all fields are identifyable. We would then (possibly, didn't think this through) add proxy attributes for each field/relation that isn't available in the dataset, and set this as a LazyLookup. Upon calling this attribute, it would do an SQL query for this single attribute, and throw a warn() signal to make the developer aware (as you most likely don't want to do this). The biggest thing about this for me, is I don't want to return dictionaries or tuples, but I want to optimize my SQL usage. I don't need to return an article's body just to show headlines, but I do want to be able to call get_absolute_url, for example. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Partial Models Discussion
On Wed, May 7, 2008 at 11:35 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > I'd like to present my concept for partial models, which would be an ... > When the proxy is instanced, we would identify which fields are > currently available, and map those in. We would also similarly make > sure all fields are identifyable. We would then (possibly, didn't > think this through) add proxy attributes for each field/relation that > isn't available in the dataset, and set this as a LazyLookup. Upon > calling this attribute, it would do an SQL query for this single > attribute, and throw a warn() signal to make the developer aware (as > you most likely don't want to do this). If I've understood you correctly, It sounds like you are proposing the same thing as: http://code.djangoproject.com/ticket/5420 Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Partial Models Discussion
Sort of, although I'm going to go against Adrian on the hide() method (I'd rather be explicit than implicit). On Tue, May 6, 2008 at 8:46 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On Wed, May 7, 2008 at 11:35 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > > > I'd like to present my concept for partial models, which would be an > ... > > When the proxy is instanced, we would identify which fields are > > currently available, and map those in. We would also similarly make > > sure all fields are identifyable. We would then (possibly, didn't > > think this through) add proxy attributes for each field/relation that > > isn't available in the dataset, and set this as a LazyLookup. Upon > > calling this attribute, it would do an SQL query for this single > > attribute, and throw a warn() signal to make the developer aware (as > > you most likely don't want to do this). > > If I've understood you correctly, It sounds like you are proposing the > same thing as: > > http://code.djangoproject.com/ticket/5420 > > Yours, > Russ Magee %-) > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: markdown, unicode, and escaping
On Tue, May 6, 2008 at 10:45 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On Tue, May 6, 2008 at 8:21 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > > > Yeah, we probably should mention this in the docs, along with an > > explanation of how to enable Markdown's safe_mode. Sure, it's > > explained in the source, but the other markup filters don't offer any > > extra features so I doubt most people even look unless they encounter > > a problem. > > > Also, with 1.7, django trunk makes safe mode either True or False, but > markdown takes three values (replace, escaped, remove) and True > equates to replace. > I've given that some thought and I'm not sure how to approach it. Truth be told, I never cared for that API change (passing in one of three possable strings), but we wanted to keep some backward-compatability and definitely wanted the 'escape' feature, so in it went. Not sure how to pass that on from the django filter though. Any suggestions? -- Waylan Limberg [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 -~--~~~~--~~--~--~---
