Re: cache.get_or_set()
On 1/31/07, Joseph Perla <[EMAIL PROTECTED]> wrote: > Along the lines of get_or_create(), does it make sense to implement a > get_or_set() function for quick caches? I'm not sure I see the use case here; it only works when the code to calculate the expensive value can be fit into a single statement, and (in my experience at least) that's not usually how things work. -- "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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django ORM bug when your app has a model named "ContentType"?
Rob Hudson wrote: >> Django has a builtin type called "ContentType", >> http://code.djangoproject.com/browser/django/trunk/django/contrib/con... >> >> I'd just rename yours to something else and be done with it. > > As a workaround, sure. I've already worked around the issue. > > But I don't think Django would want this type of restriction. I've > tried to track how this might get in the SQL myself but it's beyond > me. I'm just offering to help assist or share my model offline if > needed. I agree; if your app isn't using the bundled ContentType, why should Django complain if you make your own? -- Brian Beck Adventurer of the First Order --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
On 1/31/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > > > Django has a builtin type called "ContentType", > > http://code.djangoproject.com/browser/django/trunk/django/contrib/con... > > > > I'd just rename yours to something else and be done with it. > > As a workaround, sure. I've already worked around the issue. > > But I don't think Django would want this type of restriction. I've > tried to track how this might get in the SQL myself but it's beyond > me. I'm just offering to help assist or share my model offline if > needed. ContentType is used all over the place, if I remember correctly (been awhile since I looked). Marc is right, it's a reserved name. It's a bit like saying you want to use the word "if" as a variable name. It's reserved, it has it's place, it got there before you did :) Jay P. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django ORM bug when your app has a model named "ContentType"?
> Django has a builtin type called "ContentType", > http://code.djangoproject.com/browser/django/trunk/django/contrib/con... > > I'd just rename yours to something else and be done with it. As a workaround, sure. I've already worked around the issue. But I don't think Django would want this type of restriction. I've tried to track how this might get in the SQL myself but it's beyond me. I'm just offering to help assist or share my model offline if needed. -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
looking for a django contractor (Chicago area)
Dear Djangoists, the company I work for is looking for a new contractor to work on a "phase 2" of a django app now in production. You are the captain of the ship but will be working alongside a team of pythonists and rubyists, a handful of whom will be available to conduct code reviews. _ Company: Leapfrog Online Location: Evanston, IL (Chicago) Budget: $75 - $135 / hour Time frame: Immediate need. 1 to 3 month contract. Description We have immediate need for a Python/Django programmer to help develop and maintain a new public-facing web application (first generation already in production). This is a 40-hour/week contract commitment, working on-site in our Evanston office with our project manager, DBA, sys admin, design shop and business stakeholders in an Agile, open source environment. You must be demonstrably well-versed in Python programming, database usage (PostgreSQL), unit testing and test-driven development and Subversion. Demonstrable experience with the Django web framework is a big plus. You don't need to have any web design experience beyond the familiarity with HTML, CSS, Javascript and graphics needed by any web-based application developer. We will only consider contracting with a local developers who can work on-site for this contract. Please send sample code, hourly rates and references. To apply Send email to [EMAIL PROTECTED] (you can CC me as well) thanks for reading, Kumar --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
On 1/30/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > > I'm getting a weird bug here and this is what I've deduced... > > I've got a "Page" model and a "Content" model. Content has a FK to > Page. I also have a "ContentType" model and Content has a FK to > ContentType. This is where I tell it if the content is text or other > media content. Django has a builtin type called "ContentType", http://code.djangoproject.com/browser/django/trunk/django/contrib/contenttypes/models.py I'd just rename yours to something else and be done with it. Jay P. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: A question related to URLConf, Reverse URL, etc...
Ah, ok.. I understand a little better now what you are trying to do.
I definitely agree that a solution to this would be a useful addition;
I would only advocate for considering the "request.stem" method
instead. As with your patch, it is completely backwards-compatible
and works with nested includes; I find it slightly more simple/
unintrusive, as you don't need to add anything to the URLconf in order
to use the stem in a view.
I haven't written docs/tests for the request.stem patch yet, but I can
do so and post it if anyone is interested for the sake of comparison.
On Jan 31, 10:56 am, "medhat" <[EMAIL PROTECTED]> wrote:
> Well, Matt and Adrian closed the ticket with some similar argument.
> But I respectfuly disagree :-)
>
> In muramas example above, (r'^news/', 'myproject.apps.news.urls',
> {'stem':'news'}) this does not solve my problem, because in my case
> (assuming that this pattern is in an included urls.py) the stem is not
> 'news' it is whatever was matched in the urls.py that included this
> current one.
>
> In the ticket the argument was that in the including urls.py you can
> have something like:
> (r'^(?Pnews)/', include('myproject.apps.news.urls')),
> and then use section as a kwarg. I see some problems with this:
>
> 1. This will only work for one level of includes (granted I only have
> one urls.py that is a second level, and probably no one will ever need
> more than two levels) Of course you can do something similar for more
> levels but it will be very messy.
> 2. The more you add parameters to the pattern, the more it becomes
> complex and harder to read.
> 3. Doing it this way (?Pnews) will force me to have a
> 'section' kwarg for every view in the included urls.py while I only
> need it for only one view.
> 4. In the django documentation, it says the following on the URL
> Dispatcher page "Whenever Django encounters include(), it chops off
> whatever part of the URL matched up to that point and sends the
> remaining string to the included URLconf for further processing." And
> that's what sounded weird to me... "it chops off..." why chop off
> something that seems to be useful to pass to the view?
>
> In my case, as I mentioned before, adding /tags at the end of almost
> any url will display a page with the tags of the item that was viewed.
> And on that page when constructing the links for the tags I want it to
> include the stem. So for example /galleries/tags will show only the
> tags in galleries (and all these tags will be links that will show
> gallery items with that tag) and /galleries/2004/tags will do the same
> thing but only for galleries of pictures that were taken in 2004. Same
> thing can be done for /blog/tags etc...
>
> My solution (the one in the patch in ticket 3402 is fully backward
> compatible, will only affect the views that *need* the stem, and is
> not affected by how many levels of includes there are. And imho I
> think it solves the problem in a simple non-obtrusive way.
>
> So, I would like you guys to reconsider the patch in light of this
> more in-depth explanation :-)
>
> --
> Thanks,
> Medhat
>
> On Jan 31, 8:02 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > I actually wrote a patch yesterday to solve the same problem, but for
> > different reasons (and using a different method). From my
> > perspective, the larger problem that access to the URL 'stem' can
> > solve is to decouple apps from projects, making it much easier to
> > write relocatable, "drop-in" applications.
>
> > Currently, if an application wants to construct absolute URL's for
> > anything, one needs to either hardcode the 'stem' into the
> > application, and into the project's URLconf. (For most things, of
> > course, it is at least possible to use relative URLs, but it can
> > certainly be less convenient sometimes..) With the solution described
> > above (and in medhat's patch) you still need to know what the
> > particular application wants the stem to be passed as, so in a lot of
> > cases, it seems you might be just as well doing this:
> >(r'^news/', 'myproject.apps.news.urls', {'stem':'news'})
> > instead of:
> >(r'^news/', 'myproject.apps.news.urls', {'stem':stem})
>
> > The solution I went with was to add the stem transparently to the
> > request variable as the URLs are resolved. (I agree it's not exactly
> > a property of the request itself, so this might be suboptimal; it is
> > at least backwards compatible, though..) This would allow application
> > authors an easy way to refer to themselves absolutely, and let folks
> > installing those applications do so at any URL prefix with only a
> > simple include, and without having to figure out what stem variable
> > the app wants to be passed.
--~--~-~--~~~---~--~~
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
Re: A question related to URLConf, Reverse URL, etc...
Well, Matt and Adrian closed the ticket with some similar argument.
But I respectfuly disagree :-)
In muramas example above, (r'^news/', 'myproject.apps.news.urls',
{'stem':'news'}) this does not solve my problem, because in my case
(assuming that this pattern is in an included urls.py) the stem is not
'news' it is whatever was matched in the urls.py that included this
current one.
In the ticket the argument was that in the including urls.py you can
have something like:
(r'^(?Pnews)/', include('myproject.apps.news.urls')),
and then use section as a kwarg. I see some problems with this:
1. This will only work for one level of includes (granted I only have
one urls.py that is a second level, and probably no one will ever need
more than two levels) Of course you can do something similar for more
levels but it will be very messy.
2. The more you add parameters to the pattern, the more it becomes
complex and harder to read.
3. Doing it this way (?Pnews) will force me to have a
'section' kwarg for every view in the included urls.py while I only
need it for only one view.
4. In the django documentation, it says the following on the URL
Dispatcher page "Whenever Django encounters include(), it chops off
whatever part of the URL matched up to that point and sends the
remaining string to the included URLconf for further processing." And
that's what sounded weird to me... "it chops off..." why chop off
something that seems to be useful to pass to the view?
In my case, as I mentioned before, adding /tags at the end of almost
any url will display a page with the tags of the item that was viewed.
And on that page when constructing the links for the tags I want it to
include the stem. So for example /galleries/tags will show only the
tags in galleries (and all these tags will be links that will show
gallery items with that tag) and /galleries/2004/tags will do the same
thing but only for galleries of pictures that were taken in 2004. Same
thing can be done for /blog/tags etc...
My solution (the one in the patch in ticket 3402 is fully backward
compatible, will only affect the views that *need* the stem, and is
not affected by how many levels of includes there are. And imho I
think it solves the problem in a simple non-obtrusive way.
So, I would like you guys to reconsider the patch in light of this
more in-depth explanation :-)
--
Thanks,
Medhat
On Jan 31, 8:02 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I actually wrote a patch yesterday to solve the same problem, but for
> different reasons (and using a different method). From my
> perspective, the larger problem that access to the URL 'stem' can
> solve is to decouple apps from projects, making it much easier to
> write relocatable, "drop-in" applications.
>
> Currently, if an application wants to construct absolute URL's for
> anything, one needs to either hardcode the 'stem' into the
> application, and into the project's URLconf. (For most things, of
> course, it is at least possible to use relative URLs, but it can
> certainly be less convenient sometimes..) With the solution described
> above (and in medhat's patch) you still need to know what the
> particular application wants the stem to be passed as, so in a lot of
> cases, it seems you might be just as well doing this:
>(r'^news/', 'myproject.apps.news.urls', {'stem':'news'})
> instead of:
>(r'^news/', 'myproject.apps.news.urls', {'stem':stem})
>
> The solution I went with was to add the stem transparently to the
> request variable as the URLs are resolved. (I agree it's not exactly
> a property of the request itself, so this might be suboptimal; it is
> at least backwards compatible, though..) This would allow application
> authors an easy way to refer to themselves absolutely, and let folks
> installing those applications do so at any URL prefix with only a
> simple include, and without having to figure out what stem variable
> the app wants to be passed.
--~--~-~--~~~---~--~~
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: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Hi, A few days ago, I wrote: > I see three ways to fix the problem in #3370: > > a) newforms stops passing unicode strings to the Database API and uses > bytestrings. > > b) the database wrapper in Django sets connection.charset (but needs to > translate the charset name since the databases don't understand all > charset name variants, see ticket #952 here). This is the approach of > the patches in tickets #1356 and #3370. > > c) the database wrapper in Djago must check whether it gets unicode. In > this case, it needs to encode it into a bytestring. I now see a fourth way that would resolve #952 at the same time: d) make the database wrapper accept both unicode and bytestrings in the models, but always pass unicode strings to the database backend. Details: For #952 to work, the name of the character encoding has to be translated from python naming conventions to these of the used backend, and this would need a huge table (see the ticket). It looks easy, but it's a major annoyance. Now, instead of doing this, how about modifying the database wrapper so that it actually tests whether it gets unicode or bytestrings, and in the case of bytestrings, decodes it to unicode using settings.CHARACTER_SET as encoding? Then it could use unicode to talk to its backend. As far as I see, psycopg2 is unicode capable, and python-MySQLdb, too. This is different from the proposal in the thread 'Unicode or Strings in Models', as I'd still accept both forms in the model and deal with it only when I send it to the database. 'Only unicode in models' would be a major change with many scattered pieces. My proposal is for a transition phase, to support piece-wise conversion to Unicode without breaking everything on the way (as newforms does). Disadvantage: The backend will probably decode it again to get it across the wire, to either UTF-8 or settings.DEFAULT_CHARSET (or something else), adding overhead to the database communication. I think this is a necessary transition from bytestrings to the Great Unicodification of Everything. As soon as there's unicode everywhere, the code that deals with bytestrings can be removed and the solution will fit in perfectly. What do you think? Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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: A question related to URLConf, Reverse URL, etc...
I actually wrote a patch yesterday to solve the same problem, but for
different reasons (and using a different method). From my
perspective, the larger problem that access to the URL 'stem' can
solve is to decouple apps from projects, making it much easier to
write relocatable, "drop-in" applications.
Currently, if an application wants to construct absolute URL's for
anything, one needs to either hardcode the 'stem' into the
application, and into the project's URLconf. (For most things, of
course, it is at least possible to use relative URLs, but it can
certainly be less convenient sometimes..) With the solution described
above (and in medhat's patch) you still need to know what the
particular application wants the stem to be passed as, so in a lot of
cases, it seems you might be just as well doing this:
(r'^news/', 'myproject.apps.news.urls', {'stem':'news'})
instead of:
(r'^news/', 'myproject.apps.news.urls', {'stem':stem})
The solution I went with was to add the stem transparently to the
request variable as the URLs are resolved. (I agree it's not exactly
a property of the request itself, so this might be suboptimal; it is
at least backwards compatible, though..) This would allow application
authors an easy way to refer to themselves absolutely, and let folks
installing those applications do so at any URL prefix with only a
simple include, and without having to figure out what stem variable
the app wants to be passed.
--~--~-~--~~~---~--~~
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 Builbot (was: dbsync for mysql lacks...)
Hi, inline On 1/31/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > The Django buildbot slave is currently running inside a Solaris 10 > zone so it is virtualized...kind of. > > Let me clarify that testing python 2.3 and 2.4 would require a > separate buildbot master than pybots unless you can talk the pybots > maintainer into running 2.3 and 2.4 tests as well. Why don't you join > the pybots mailing list and ask? As far as I know pybots sets new build jobs when changes occur in the python code base, so If we want to launch build jobs on new commits on django/trunk we'd need to setup a separate master anyway, wouldn't we? Having 2.3 and 2.4 there would make it possible to test django/trunk when commit occur there but not when commit occur on django's SVN. And I think that the original comment of this thread from Michael was to keep django's trunk tested on every commit and trying to test patches from TRAC before they get commited. In this scenario, am I wrong or we do need a separate master? Cheers, Marc --~--~-~--~~~---~--~~ 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: Dynamic choices for newforms?
Hi,
see ticket
http://code.djangoproject.com/ticket/3257
it conatins a ModelChoiceField, that does a bit more - it also returns
a valid object, not just the ID
the ticket has been accepted I am only waiting for decision on whether
to prepend an empty choice ("", "--") or any suggestion on other
ways of doing that...
Honza
On 1/31/07, Rubic <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Aside from putting choices in __init__, my other current workaround is
> to use Python's property feature:
>
> class PhysicianChoices:
> def _physicians(self):
> return [(e.id, e.name) for e in \
> Physician.objects.order_by('lastName','firstName') if
> e.active]
> choices = property(_physicians)
>
> --
> Jeff Bauer
> Rubicon, Inc.
>
>
> >
>
--
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
-~--~~~~--~~--~--~---
