Re: UUID Field really wontfix?
Am 11.12.2012 17:23, schrieb Jacob Kaplan-Moss: If someone can come up with a good patch I'd be fine considering it for core. Jacob I created a new ticket: https://code.djangoproject.com/ticket/19463 I want to moderate this ticket, but won't create patch. I am going to ask the current UUID-Field authors if they can create a patch. Thomas -- -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
UUID Field really wontfix?
This ticket is closed since several years. Maybe it is time to think about it again. Add UUID Field: https://code.djangoproject.com/ticket/4682 Thomas Güttler -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django UnicodeEncodeError in errorlist
this question belongs to django-user.
You need to use u'å' not 'å' in your python code.
> Is there a good reason
> why |force_unicode| and |lazy| do not use |smart_str|?
smart_str() creates a bytestring, but in Django everything is unicode until the
end. Only one of the last
steps is to encode the unicode result to (most of the times) utf8.
I have seem a lot of unicode errors in django. But most of them were fixed long
ago.
The last (I know of): https://code.djangoproject.com/ticket/18063
"repr() should return only ascii, not unicode"
Thomas
Am 26.04.2012 20:41, schrieb Andrei:
Hi,
I am having an issue with rendering Django's ErrorList if one of my error list
items is unicode. When Django renders my
errorlist
|{{ form.non_field_errors}}
|
it runs the following code
<https://github.com/django/django/blob/1.3.1/django/forms/util.py#L46>:
|class ErrorList(list, StrAndUnicode):
"""
A collection of errors that knows how to display itself in various
formats.
"""
def __unicode__(self):
return self.as_ul()
def as_ul(self):
if not self: return u''
return mark_safe(u'%s'
% ''.join([u'%s' %
conditional_escape(force_unicode(e)) for ein self]))
|
then in |force_unicode|
<https://github.com/django/django/blob/1.3.1/django/utils/encoding.py#L74>:
|s= unicode(str(s), encoding, errors)
|
and then translation in |lazy|
<https://github.com/django/django/blob/1.3.1/django/utils/functional.py#L209>:
|def __str_cast(self):
return str(self.__func(*self.__args, **self.__kw))
|
The problem is that my string contains 'å' symbol and |str(u'å')| raises
|UnicodeEncodeError|. Is there a good reason
why |force_unicode| and |lazy| do not use |smart_str|? I have to do it myself
and provide error messages as |str|
objects instead of unicode to make it work.
So I get TemplateSyntaxError /Caught UnicodeEncodeError while rendering:
'ascii' codec can't encode character u'\xe5' in
position 17: ordinal not in range(128)/. This seems telling that rendering my
error list item (which is |u'å'|) caused
the first UnicodeEncodeError having unicode message /'ascii' codec can't encode
character u'\xe5'/ and then second
UnicodeEncodeError while rendering the message from the first one. Am I
mistaken?
Django version: 1.3.1 (but this seems to happen in 1.4 as well)
Full traceback:
https://raw.github.com/gist/2499077/ba60cb752acdb429dd6c2814ffb24272037a367a/UnicodeEncodeError.txt
Thanks,
Andrei
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/pYaefZxhll4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Edit Ticket Description in Trac
Hi, I would like to modify the descriptions of tickets. Unfortunately this is not possible for me at the moment. Can someone give me the permission for at least modifying my tickets? Thomas Güttler Trac Login is "guettli" -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django
Am 05.04.2012 10:03, schrieb Łukasz Rekucki: On 5 April 2012 09:45, Thomas Guettler<h...@tbz-pariv.de> wrote: Hi, I created a ticket, incl. patch https://code.djangoproject.com/ticket/18062 While the example itself is useful, I don't really think Django's documentation should state obvious facts about Python, especially false ones. ... Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get a NameError. patch is fixed now. Unfortunately I can't modify the description in trac. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django
Hi,
I created a ticket, incl. patch
https://code.djangoproject.com/ticket/18062
Am 04.04.2012 18:41, schrieb Adrian Holovaty:
2012/4/3 Łukasz Langa<luk...@langa.pl>:
Explicit choice values::
GENDER_MALE = 0
GENDER_FEMALE = 1
GENDER_NOT_SPECIFIED = 2
GENDER_CHOICES = (
(GENDER_MALE, _('male')),
(GENDER_FEMALE, _('female')),
(GENDER_NOT_SPECIFIED, _('not specified')),
)
class User(models.Model):
gender = models.IntegerField(choices=GENDER_CHOICES,
default=GENDER_NOT_SPECIFIED)
def greet(self):
if self.gender == GENDER_MALE:
return 'Hi, boy.'
elif self.gender == GENDER_NOT_SPECIFIED:
return 'Hello, girl.'
else: return 'Hey there, user!'
This is a saner way but starts getting overly verbose and redundant. You can
improve encapsulation by moving the choices into the ``User`` class but that on
the other hand beats reusability.
I don't see the immediate need for Yet Another Sub-framework, as
described in this proposal. This is what I normally do, and it works
fine:
class User(models.Model):
MALE = 0
FEMALE = 1
GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
gender = models.IntegerField(choices=GENDERS)
def greet(self):
return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
If people aren't understanding that, we should improve our documentation.
Also, the fact that we *don't* have a sub-framework for this lets
people do whatever they want -- including using the dj.choices module.
So I am -1 on including this in Django proper.
Adrian
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: upgrading the choices machinery for Django
Am 03.04.2012 21:31, schrieb Łukasz Langa:
A nice HTML rendering of this proposal is available at:
http://lukasz.langa.pl/2/upgrading-choices-machinery-django/
==
Upgrading the choices machinery for Django
==
...
since most people have something like this in their code, a better solution
should require
only some additional characters.
GENDER_CHOICES = (
(0, 'male'),
(1, 'female'),
(2, 'not specified'),
)
# if this would be supported, updating the code would be easy
GENDER_CHOICES = Choices(
(0, 'male'),
(1, 'female'),
(2, 'not specified'),
)
#about Group
>>> class License(Choices):
... COPYLEFT = Choices.Group(0)
... gpl_any = Choice("GPL, any")
I don't like Choices.Group. I think it is better if choices must be set
explicit, not
implicit (auto-increment).
Here is my solution, which is similar to way3 in your proposal.
{{{
class ChoiceDict(SortedDict):
'''
Iterating this SortedDict will return
the items (and not the keys). This is handy if
you want to uses this for a choice list on
a model field
'''
__iter__=SortedDict.iteritems
class Foo(models.Model):
STATE_NEW='new'
STATE_DONE='done'
states=ChoiceDict((STATE_NEW, _('new')),
(STATE_DONE, _('done')),
)
state=models.CharField(max_length=16, verbose_name=u'Status',
default=STATE_NEU, choices=states)
}}}
I like this since, you can access the verbose string like this:
Foo.states[obj.state]
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Read only Test Was: Speeding up tests
Hi, same subject, but different content: we have a lot of tests which are read only. They don't modify the database or other files. You don't need to flush the database for every test of read only test cases. These tests can be run on production servers, too. At the moment, this unittest code is non public. But if there is any interest, we could make it public. Is anyone interested? Thomas Güttler On 16.01.2012 17:46, Anssi Kääriäinen wrote: -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#2131 SendFile Support
Hi,
Ticket #2131 (SendFile support) is open since 6 years:
https://code.djangoproject.com/ticket/2131
The implementation is stable: https://github.com/johnsensible/django-sendfile
I can live with current situation (sendfile is an external application). But,
maybe someone wants to close this
as "wontfix" or get these few lines into django.
{{{
Django Sendfile
This is a wrapper around web-server specific methods for sending files to web clients. This is useful when Django needs
to check permissions associated files, but does not want to serve the actual bytes of the file itself. i.e. as serving
large files is not what Django is made for.
}}}
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
common variable (Deploying Feature in manage.py)
Am 23.10.2011 21:59, schrieb feel: > Hi, I wanted to propose a new possible feature in Django project that > allows to sync the local folder with the remote one of the server > defining all the configuration directly in settings.py. > > I've just done some months ago a simple implementation using rsync and > I reported it in active state: > http://code.activestate.com/recipes/577767-managment-command-to-deploy-a-django-project/?in=user-4174931 Hi, I won't use rsync. Code should not be altered on the server but sometimes you (or someone else) does it. Rsync would overwrite it. Up to now I use unison, but there are better solutions. I would like to see a common variable in django's settings: STAGE=... with one of this choices: DEV, INTEGRATION, QUAL, PROD It would be nice, if the django core could agree on a variable name and its content. Several deploy apps could use this common variable. In our company we have a common variable. PROD is zero: if STAGE: # some dev system... -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#13024 Signal sent on application startup
Hi, I am missing a signal on application startup since a long time. Ticket: https://code.djangoproject.com/ticket/13024 My usecase: If there are some settings missing, I want add default values. I know that I could use this. settings.configure(default_settings=myapp_defaults, DEBUG=True) See https://docs.djangoproject.com/en/dev/topics/settings/#custom-default-settings But there are too many places, where the settings get loaded. I could write a patch, but this is more a design decision. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Advice on #13260 - '%' in args to urlresolvers.reverse()
Am 22.08.2011 07:14, schrieb Ben Sturmfels: > Hi Folks, > > Could I get a tie-breaking opinion on whether this "quoting of > parameters to reverse()" ticket #13260 is expected behaviour or not? > > http://www.mail-archive.com/django-developers@googlegroups.com/msg25678.html > > > The original message got two responses; one saying quote automatically, > the other saying it's up to the user. The ticket is in "design decision needed" since 14 months: https://code.djangoproject.com/ticket/13260 Who can make this decision? Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ImportError catching in urlresolvers.py
On 14.06.2011 22:19, Michael Blume wrote:
> In RegexURLPattern._get_callback, we attempt to fetch the callable named
> by the URL pattern, and catch a possible ImportError if this fails. If
> so, we raise ViewDoesNotExist.
>
> try:
> self._callback = get_callable(self._callback_str)
> except ImportError, e:
> mod_name, _ = get_mod_func(self._callback_str)
> raise ViewDoesNotExist("Could not import %s. Error was: %s"
> % (mod_name, str(e)))
I uncomment the try...except part in my local django version (and the
AttributeError). I want to see the original
exception. It would be nice to have a better solution in django. Maybe a
settings variable CATCH_EXCEPTIONS?
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: State of X-Sendfile support?
On 25.03.2011 12:55, Łukasz Rekucki wrote: > On 25 March 2011 12:34, Thomas Guettler <h...@tbz-pariv.de> wrote: >> Hi, >> >> I look at your example code. You need to name the webserver in the >> code. That's not very nice. I guess it should be possible to >> guess the webserver (apache vs nginx) by looking at request.META. >> > > -1 on guessing anything, especially something that doesn't change. > Also, a fairly common configuration is Apache behind an nginx proxy. > In this setup, I want nginx will be the one serving static files, not > Apache. Maybe you are right. Guessing is bad. But I think to write "nginx" into the application code is bad, too. Something like this could be in settings.py. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: State of X-Sendfile support?
Hi,
I look at your example code. You need to name the webserver in the
code. That's not very nice. I guess it should be possible to
guess the webserver (apache vs nginx) by looking at request.META.
Documentation would be nice
Thomas
On 25.03.2011 10:23, Gustavo Narea wrote:
> Hi all,
>
> Just to let you know that there's an X-Sendfile implementation for
> WSGI apps (inc. Django), which also works with Nginx:
> https://launchpad.net/wsgi-xsendfile
>
> You can use it in Django views via twod.wsgi. For example:
>
> """
> from twod.wsgi import call_wsgi_app
> from xsendfile import NginxSendfile
>
> file_sender = NginxSendfile('/var/www/docs')
> file_sender_wsgi_app = XSendfileApplication('/media/documents',
> file_sender)
>
> def django_view(request, article_id):
> article = Article.objects.get(article_id)
> if it's foggy:
> doc_response = call_wsgi_app(
> file_sender_wsgi_app,
> request,
> article.path,
> )
> else:
> doc_response = HttpResponseForbidden()
>
> return doc_response
> """
>
> That package is pretty stable, the only thing it's missing is
> documentation which should be sorted soon.
>
> Cheers.
>
> - Gustavo.
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Expensive queryset cloning
Hi Alexander,
I have seen this in my app, too. It still runs fast enough. But
I guess the django code could be optimized.
Thomas
On 15.03.2011 01:49, Alexander Schepanovski wrote:
> I was optimizing my django app and ran into this. My app was spending
> too much time cloning querysets. I looked into code but didn't find
> any simple way to make it faster. But this is not needed actually. In
> most use cases "a parent" of a clone is thrown out. So usually one
> just need to mutate queryset not clone it.
>
> For example:
> Item.objects.filter(category=12).exclude(visible=False).order_by('-
> date')[:20]
> clones 4 times and 0 is needed. Using Q objects we can reduce it to 3
> (still too much) and complicate the code.
>
> Even
> Item.objects.get(pk=2)
> clones 2 times.
>
> Personally, I would like all querysets mutate not clone by default.
> And when one need a clone just make it explicitly.
>
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: RFC #9964 - fix "missing" db commits by forcing managed transactions to close
Hi Shai and list, I tested your patch with my applications. All my unittests pass. Shai Berger wrote: > Hi list, > > #9964 is about managed transactions not being committed under transaction > middleware (or transaction.commit_on_success decorator) after the database > was > modified via raw SQL. The root cause of that is that, today, managed > transactions only become "dirty" when there is clear evidence of database > change -- that is, when a known-to-change-the-database operation (such as > saving a model) is performed. If this isn't the case (as in the case of raw > SQL), the user is required to call transaction.set_dirty() to get correct > behavior. > ... -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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.
#4992: Cache GET requests with QUERY_STRING
Hi, requests with a QUERY_STRING are not cached up to now. I uploaded a patch with tests and I think it is ready for commit: http://code.djangoproject.com/ticket/4992 According to http://docs.djangoproject.com/en/1.2/internals/contributing/#triage-by-the-general-community I (general community member) should not set "ready for commit". Could someone please review it? Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: No caching if request.GET not empty
I updated the patch http://code.djangoproject.com/attachment/ticket/4992/cache_by_request_full_path_v2.diff I think it is ready for commit. The patch has docs and tests. Can someone please test it on different plattforms? I used: Python 2.5.1 on linux. Thomas Mikhail Korobov wrote: > Hi Thomas, > > there is a ticket for that: > > http://code.djangoproject.com/ticket/4992 -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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.
No caching if request.GET not empty
Hi,
I got not response on django-users, now I ask here:
requests with a query string (http://example.com?foo=bar) are not cached in
Django:
http://code.djangoproject.com/browser/django/trunk/django/middleware/cache.py
{{{
if not request.method in ('GET', 'HEAD') or request.GET:
request._cache_update_cache = False
return None # Don't bother checking the cache.
}}}
If the query string would be used in _generate_cache_key() (utils/cache.py),
requests with a not empty request.GET could be cached.
I see no reason, not to cache requests with a query string.
Can someone explain this?
I read the documentation[1], but couldn't find a hint way GET requests
with a query string are not cached.
Should I open a ticket?
[1] cache docs: http://docs.djangoproject.com/en/dev/topics/cache/
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
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: #9459 forms.DateTimeField() looses microseconds
I uploaded a new patch (against trunk) which works on Python 2.4: http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py24.patch I think it is ready for commit. Thomas Tobias McNulty wrote: > On Thu, Sep 9, 2010 at 5:43 AM, Thomas Guettler <h...@tbz-pariv.de > <mailto:h...@tbz-pariv.de>> wrote: > > Here is the patch: > > http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py25.patch > > If the python version is greater-equal than 2.6, it uses %f to parse > the microseconds, > for older versions it parses the last integer itself. > > > The patch looks reasonable enough to me and I'm excited about getting it > in. Have you tested it on Python 2.4, 2.5, and 2.6? > > Cheers, > Tobias -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: #9459 forms.DateTimeField() looses microseconds
Tobias McNulty wrote: > On Thu, Sep 9, 2010 at 5:43 AM, Thomas Guettler <h...@tbz-pariv.de > <mailto:h...@tbz-pariv.de>> wrote: > > Here is the patch: > > http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py25.patch > > If the python version is greater-equal than 2.6, it uses %f to parse > the microseconds, > for older versions it parses the last integer itself. > > > The patch looks reasonable enough to me and I'm excited about getting it > in. Have you tested it on Python 2.4, 2.5, and 2.6? Sorry, I don't have a Python 2.4 around. Can anyone help? Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: #13870: Correctly handling database isolation (in PostgreSQL)
Patryk Zawadzki wrote: > On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö <rob...@blogg.se> wrote: >> Patryk Zawadzki skrev 2010-09-06 15.29: >>> The isolating transaction keeps going on until you either (1) commit, >>> (2) rollback or (3) disconnect. Django only commits/rollbacks the >>> transactions it explicitly starts, it does not care about the >>> implicitly started isolating transaction. That's what results in >>> " in transaction" and I can reproduce it with a two-line view >>> that does a simple SELECT with no transaction middleware involved. >> Can you please show me the code you're running to reproduce this? > > Right, I misremembered the original problem. I've now found the > testing environment. > > The problem is not with regular views but with Celery tasks, > long-running management commands such as daemons and any other place > where you access the ORM from outside of the usual > request→dispatcher→view→response flow I use the TransactionMiddleware for requests, and scripts which are started from the shell use the commit_on_success decorator. Utility methods that are used in both ways (shell and request) don't use transaction handling methods. Long running tasks are an exception, here I use something like this: for i, .. in enumerate(...): if i%1000==0: commit() If you have a daemon that lives forever, I would do it like this (untested if this does not leave an idle transaction open): The place where the daemon hangs around if nothing can be done lives must not use the ORM. If there is something to be done, the daemon calls methods that use the commit_on_success decorators. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: #11834: colorized debug page. Assigned to buriy
Hi buriy, http://code.djangoproject.com/ticket/11834 it would be nice, if the CSS could be customized. But how to do that? I think the debug html output should be self contained. It should not reference a CSS file. Example: I send the HTML output by mail to myself, to see if uncaught exceptions have happened on production sites. Maybe a new (optional) setting: DEBUG_PAGE_CSS_INCLUDE='/pathto/myfile.css' After we created a patch with configurable CSS, we could make a small contest, and the best gets commited to be the default. Thomas burc...@gmail.com wrote: > Hi, > > On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler <h...@tbz-pariv.de> wrote: ... -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: #11834: colorized debug page. Assigned to buriy
burc...@gmail.com wrote: > Hi, > > On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler <h...@tbz-pariv.de> wrote: >> Hi, >> >> a colorized debug page helps a lot. More than 99% of errors >> are in my code, and not in django's. This patch gives "own" code >> a different color. >> >> It is assigned to "buriy" since 6 months. >> >> http://code.djangoproject.com/ticket/11834 >> >> Why not commit? > > I'm buriy. Patch creator. > > The agreement between core devs and me (or at least how i get it) was > that we decided that this patch needs to be a part of larger "debug > page usability improvement suite". > My decision is that until that, the patch is "incomplete" to allow > only in-house use. Django: The web framework for perfectionists with deadlines But where/when is the deadline? I think with "release early, release often" you get perfect code faster. > I can do all development changes for all suite (and finish this patch > of course), if we discuss how it should be done. > > My issue needs few improvements: > - docs & tests AFAIK the current debug page has no docs and tests, too. > - ability to hide some traceback elements, keeping notice they are > hidden -- it's so easy to shot yourself in foot otherwise. Please explain this. What do you want to hide? The page is for developers only. > - better display for decorators -- i think they either don't deserve > separate line or should be displayed as @decorator in the short debug > output. I want to see the stacktrace the way it is (nested function calls) > - grouping template tags together and pretty display for them -- > please see below. > > At least, after my issue, there are 2 others: > - DEBUG_SHOW_DJANGO_TRACEBACK option ( > http://code.djangoproject.com/ticket/13148 ) > - output for template tags should be improved, since we're displaying > 4 traceback blocks instead of template tag itself. There was a code > written for this already somewhere, there was screenshot available, > and it was discussed in this group, but i can't find it right now. Can > anyone point me at it? > And yes, I don't know where to find designers to get a look at my > implemented improvements, I'd like contact them when I'm ready. I am not a designer, but here is my opinion: Your patch highlights own code quite good. But there are too many colors. I like the colors of http://www.djangoproject.com/ Why not use or copy parts if this style? I would just increase the size of "own" code, no different colors. It would be nice if you could define a list of apps that you consider "stable" and which should be displayed small. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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.
#11834: colorized debug page. Assigned to buriy
Hi, a colorized debug page helps a lot. More than 99% of errors are in my code, and not in django's. This patch gives "own" code a different color. It is assigned to "buriy" since 6 months. http://code.djangoproject.com/ticket/11834 Why not commit? Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: transaction.commit_manually masks uncaught exception
Hi, I closed the ticket, since it looks like a duplicate of http://code.djangoproject.com/ticket/6623 BTW, the tiny url does not work for me. Google wants me to log-in. Thomas JohnO wrote: > I wanted to offer an enhancement that would make > transaction.commit_manually much friendlier to work with. I only offer > it after banging my head on the wall for several hours. The problem is > that transaction.commit_manually() masks any uncaught exception within > the view it decorates. This made me lose a lot of hair today. > > I found a ticket addressing this problem, and have updated it: > http://code.djangoproject.com/ticket/13265 > I also even found some old discussion in this group from a cross- > poster experiencing the problem: http://bit.ly/9KqDNA > > Let me know if I can help in any way. Thanks for your time. > -JohnO > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: Beating on an old issue; counter intuitive cascade deletes on foreign keys
The documentation says django emulates "ON DELETE CASCADE": http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects But it is missing how to emulate ON DELETE SET NULL. In this thread Kevin Howerton posted an abstract base class to emulate ON DELETE SET NULL. But this does not work if you bulk delete with a query set. I opened a new ticket: http://code.djangoproject.com/ticket/13731 Thomas Russell Keith-Magee wrote: > On Wed, Jun 9, 2010 at 3:53 AM, Peter Bengtsson <pe...@fry-it.com> wrote: >> On 8 June 2010 13:09, Jeremy Dunck <jdu...@gmail.com> wrote: >>> On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson <pete...@gmail.com> wrote: >>>> I've now had to learn this the hard way by having real live data >>>> deleted from my database on two production projects and it pisses me >>>> off big time every time. >>>> >>>> I can accept that NOT nullable foreign relations cascade the delete >>>> but not if they have null=True on them. Example: >>> Actually, this looks to be fixed in 1.2. What version are you >>> running? Closed ticket (with test cases) here: >>> http://code.djangoproject.com/ticket/9308 >>> >> I'm running Django 1.2.1 so perhaps it's not fixed. >> Sigh. I have to make a test case to prove it. > > Looking at Trac, #9308 was fixed in r10822, so it should be fixed in > 1.1, and it was ported back to 1.0.X as well. > > We pretty clearly document that our deletion scheme emulates "ON > DELETE CASCADE"; if you can provide evidence to the contrary, please > open a ticket. > > Yours, > Russ Magee %-) > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: Beating on an old issue; counter intuitive cascade deletes on foreign keys
Hi, I think this is the related ticket: http://code.djangoproject.com/ticket/7539 "Add ON DELETE and ON UPDATE support to Django" Me and a lot of other people are on the cc list of this ticket. Peter Bengtsson wrote: > I've now had to learn this the hard way by having real live data > deleted from my database on two production projects and it pisses me > off big time every time. > > I can accept that NOT nullable foreign relations cascade the delete > but not if they have null=True on them. > ... -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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.
missing in SVN branches/releases/1.2.X
Hi, will there be a SVN branch releases/1.2.X? For 1.0 and 1.1 it exists: http://code.djangoproject.com/browser/django/branches/releases Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On "strip keyword arg for CharField"
>From http://code.djangoproject.com/ticket/4960
09/14/07 11:28:49 changed by adrian
{{{
Marking as wontfix -- it's too specialized for inclusion in the main library. A
bunch of us in #django-sprint agreed.
}}}
We should think about this decision again. The cc list of #6362 is quite long.
A lot of people (and me)
want something like this. Ten characters (strip=True), I don't want to type
more for this, since I would
use it for 98% of all my CharFields.
Thomas
Steven Davidson wrote:
> Loving v1.2, my first experience with Django: thanks for all the hard work!
>
> However this issue has bitten me twice now. I know it is entirely my
> responsibility to validate and clean user input as required but I really
> can't think of a valid use case where trailing white space would occur.
> Also it can snag a 'feature' in MySQL with unique indexes ignoring
> trailing spaces for comparison purposes.
>
> Any chance of a decision on whether this should appear in 1.3 and in
> what form?
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
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: Advice on #13260 - '%' in args to urlresolvers.reverse()
>>>> reverse('special', args=[r'+\$*'])
> '/special_chars/+%5C$*/'
>
> It would have to output:
>
> '/special_chars/%2B%5C%24%2A/'
Hi,
I think the current test case is broken. All args/kwargs should
be quoted.
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
The plan to make 1.3 a feature light release with focus on fixing old bugs and tickets, was a good one. I have some tickets in trac which are quite old, too. But it has been a very long time, since I reviewed tickets of other people, too. Sometimes I think the development process is slow. But that's wrong. The development is just in parts I don't need up to now (for example multi db support). Thomas Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to try to reboot the discussion that's been going on about > Django's development process. > > I'm finding the current thread incredibly demoralizing: there's a > bunch of frustration being expressed, and I hear that, but I'm having > trouble finding any concrete suggestions. Instead, the thread has > devolved into just going around in circles on the same small handful > of issues. > > So: here's your chance. You have suggestions about Django's > development process? Make them. I'm listening. > > Jacob > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- 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.
Subclassing db fields: to_python() need model instance
Hi, I want to subclass a db field (CharField), but in the to_python() method I need the value (which is given) and the model instance (which is missing). I looked at the source of django/db/models/fields/subclassing.py: http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/subclassing.py Unfortunately, it seems difficult to alter the Creator class. I could copy the whole file and modify the code, but that's not a good solution. But I guess I will go this way, since I don't want to run a modified django version. Is someone interested in a patch which modifies subclassing.py to make this possible? # Finally that's what I need for my db field: class Creator(object): ... def __set__(self, obj, value): obj.__dict__[self.field.name] = self.field.to_python(value, obj) Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature proposal: Test client form value extraction
Hi,
some time ago I wrote a snippet which does this:
http://www.djangosnippets.org/snippets/467/
{{{
If you want to test a post request to a form, you need to give all input
fields, even if you just want to test if one
value gets changed.
This snippets parses the HTML of a view and gives you a dictionary that you can
give to django.test.Client.
Needs ClientForm from: http://wwwsearch.sourceforge.net/ClientForm/
}}}
Joshua Russo schrieb:
> I've just put together an enhancement of the test Client used in unit
> testing. I added the parsing of the content to extract the form fields with
> their initial values as a dictionary, so you can just change a few values
> and throw it back at the server.
> http://dpaste.com/hold/85281/
>
> I had to do a small monkey patch to get it to work because direct override
> of the __ call __ method interfered with the transaction management for some
> reason.
>
> Let me know what you think. Should I submit it as a ticket?
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: #10355 Add support for email backends
Hi, Andi Albrecht schrieb: > Hi, > > I'm interested in working on #10355 "Add support for email backends." > > IMHO it's an good idea to make the email backend configurable. There > are at least two use cases I can think of. The first is to send email > with other services than SMTP, like App Engine as noted in the > ticket's description. The second is to deliver email asynchronously, > like the django-mailer application does already. Yes, I think it is a good idea. It would be nice to have several backends active, too. In my applications error-mails of uncaught exceptions should take a different backend than emails for application users. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Creating "Read-only" automated form views
Hi Ian, I am interested. I think this should be listed as feature request, if this list gets opened for django 1.2. Thomas IanSR schrieb: > Django's automated form renderers form.as_table, form.as_p and > form.as_ul are great. We have a recurring situation where we'd like > the equivalent of these but in a "read-only" version:... -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: BigInt Patch for Django 1.0.2
Hi, I once get BigInt working by a little "ALTER TABLE ... ALTER COLUMN" statement. No code change for django was needed. But I have only done this once and this application does not exist any more. rah schrieb: > I am Rahul.using Django0.96 from last 3 years. We are using > BinInteger field in one of our models. For BigInt we have added a > patch in Django. But now we want to migrate .96 to 1.0.2 . > The same problem is there in 1.0.2 it does not support to BigInt > field .The patch for 0.96 is not working with 1.0.2. Is there any > patch for BigInt in Django 1.0.2. -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: enable CSRF middleware by default
The CSRF middleware inserts a hidden input element in every form. Since GET Requests are mostly readonly, the bad guy needs a POST request to do some evil. If the bad guy can make a POST request with the user's browser, the bad guy might make a GET request with javascript first , read the hidden input element and use the value for the evil POST request. I just read this: http://en.wikipedia.org/wiki/Cross-site_request_forgery Maybe HTTP-Referer checking is a better solution. Thomas Luke Plant schrieb: > I have not been able to implement all of the CSRF proposals we made a > while back in time for the beta (in particular, replacing the current > CsrfResponseMiddleware with a template tag). > > However, significant improvements have been made, and it is much more > useful by default. I propose adding the two middleware (view and > response) to the MIDDLEWARE settings in following files: > > django/conf/global_settings.py > django/conf/project_template/settings.py > > Rationale: > > - the admin application is not safe from CSRF attacks without this, >so out-of-the-box it is quite insecure. This is a 4 year old bug >( http://code.djangoproject.com/ticket/510 ) which isn't really >fixed if the fix is not enabled by default. > > - the main objections to using the CSRF middleware were: >- problems for AJAX apps -- now automatically fixed in most cases >- a pain to selectively disable -- now fixable with 'csrf_exempt' > > Please let me know by Thursday evening (GMT) if there are objections. > > Luke > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Unittest on live data Was: Rolling back tests -- status and open issues
Thank you Karen for your work. Some weeks ago I wanted to write an "always_rollback" decorator, but found that it was not that easy, since Postgres transactions can't be nested. The first COMMIT commits everything. [1] I want to run readonly unittests on my live data. I looked at your patch, and saw the way you do it: you redefine the transaction methods to "nop". Are other developers interested in "readonly unitests on live data", too? Of course you the tests must not alter data on the filesystem something like this. Thomas [1] http://www.mail-archive.com/django-us...@googlegroups.com/msg58024.html http://www.nnseek.com/e/comp.databases.postgresql/nested_transactions_49494491t.html Karen Tracey schrieb: > One of the item on the list for 1.1 is "Run Django test cases inside a > transaction". The ticket for this is #8138: > > http://code.djangoproject.com/ticket/8138 > ... > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session-based messages (Contrib-05, #4604)
Ramiro Morales schrieb:
> What directions do [the rest of the] core devs think should this
> take?
I am not a core dev, but here is what I think:
- The current user based messages are not usefull for me.
- I use a own version of session based messages which is based
on code of this ticket. But I added an optional loglevel argument.
- Although I use sesion based messages, I want to use a different
aproach in the future, since they produce unneeded UPDATE statements.
HTTP POST, create_message('Changes were saved'), Redirect after Post,
GET, pop_messages() --> SQL UPDATE.
The second request (GET) could be readonly.
Maybe something like this snippet would be good:
http://www.djangosnippets.org/snippets/1064/
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Decoupling authorization from view
Eric Drechsel schrieb: > Hi Thomas, > > Ya, it would be really nice if there was a standard way of handling > authorization for views, so that external code can check if a view is > authorized. I have been doing identically the same thing, except I was > naming the view attribute "authorized". > > Hi Eric, I am very happy that someone understood what I want. > Perhaps you could post your code somewhere so that 3rd-party app > developers can standardize their authorization (git-hub?). > > I added a snippet: http://www.djangosnippets.org/snippets/1214/ Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Who can set "ready for checkin"?
Who can set "ready for checkin"? You know the answer: Ticket triagers But who are they? I have some tickets which are only small changes incl. unittest. Most of them wait in the state "Accepted": http://code.djangoproject.com/ticket/6160 Escaping of validation errors http://code.djangoproject.com/ticket/9089 urlencode should support MutliValueDict http://code.djangoproject.com/ticket/9031 Small bug if typo in testcase http://code.djangoproject.com/ticket/5964 urlunquote http://code.djangoproject.com/ticket/4786 debug view: Hilight application code (vs. framework/python code) I would like to know if I can set "ready for checkin" or what else can I do to see progress. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: Signal after model of app was loaded
Hi Malcolm and others, your solution would solve my problem. I drop this proposal. Malcolm Tredinnick schrieb: > On Tue, 2008-10-21 at 13:07 +0200, Thomas Guettler wrote: > >> Hi, >> >> what do you think about a signal which fires after the models >> of an application where loaded? >> [cut] > I think this can be done with a feature I want to add for 1.1 (I want to > add it as soon as I have time to re-review an existing patch). Ben > Slavin wrote a patch a while back to add support for functions that are > called once settings have been imported but before any other activity > happens. That is basically a "before anything else, do this" point in > the process. -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: Signal after model of app was loaded
Hi,
what do you think about a signal which fires after the models
of an application where loaded?
Use case:
Load static (never changing objects) from the database and make them
available
at module or class level. In my case I want to load some permissions and
make them
available as Permission instances at class level.
I added a comment line where the event should fire. The other lines are
unchanged.
{{{
#django/db/models/loading.py:
def load_app(self, app_name, can_postpone=False):
"""
Loads the app with the provided fully qualified name, and
returns the
model module.
"""
self.handled[app_name] = None
self.nesting_level += 1
mod = __import__(app_name, {}, {}, ['models'])
self.nesting_level -= 1
if not hasattr(mod, 'models'):
if can_postpone:
# Either the app has no models, or the package is still
being
# imported by Python and the model module isn't
available yet.
# We will check again once all the recursion has
finished (in
# populate).
self.postponed.append(app_name)
return None
if mod.models not in self.app_store:
self.app_store[mod.models] = len(self.app_store)
### here the signal should get fired
return mod.models
}}}
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Proposal: Decoupling authorization from view
Hi, The auth-decorators to check for permission are nice, but it would be better, if the authorization could be decoupled from calling the view. My goal: Check if a user can access a view without calling it, because I want to disable/hide a link if the user must not call it. I implemented it in my application, but it would be nice if something like this would inside django (This would improve plug-ability of applications) My implementation works like this: every view method as an attribute 'has_perm' which takes the same args, kwargs like the view: def myview(request, something) ... myview.has_perm=lambda ... For ease of usage you can set has_perm to True (no access restriction) or to a permission string (app_label.perm_codename) or to is_authenticated, is_staff, is_superuser. There is a small helper method for checking if a user/request would be allowed to access this view and a small middleware to render "403 forbidden" pages. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: "things are ready" signal?
Marc Fargas schrieb: > Hi there, > > Staring at #8638 I'm trying to find a way to hook code to be run "just > after Django is completelly loaded" and found no way ;( > ... > So, would a signal there be useful? I am missing this signal, too. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#689 Honour Webserver Provided Auth (REMOTE_USER)
Hi, #689 Honour Webserver Provided Auth (REMOTE_USER) http://code.djangoproject.com/ticket/689 I use it this patch since several weeks. This patch only adds new stuff, thus it wont' break running code. Why not commit it? Thomas PS: The current code is in a git repository linked in the ticket. -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: implementing app specific default settings
HenrikV schrieb: > I would like to make Django support settings defaults for > applications. Ideally defaults would be loaded together with > global_settings, but of course that is impossible as INSTALLED_APPS > must first be configured. So my approach is to add a default setting > if settings doesn't already have the attribute. > > Hi, sorry, I only read the first lines of your post. I think application settings should not be in settings.py. Maybe appname_settings.py. It would be good to have a default way, to make django applications more pluggable. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
Jacob Kaplan-Moss schrieb: > On Tue, Aug 26, 2008 at 3:38 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > >> So it's a couple of days later...got time to update with your thoughts? >> > > Yeah, I'm sorry; I lost track of this. > > Essentially I think that James is right that a systematic fix would be > better, but I don't see what that might look like. > > Unfortunately, I'm really not sure exactly what we can do -- there's > some places where perhaps we could not raise ImproperlyConfigured, but > the problem is that sometimes those messages are *more* helpful, and > other times less. It's not entirely clear (to me) what a fix, even a > half-assed one, would look like > > > I started going down the path of having ImproperlyConfigured take an > ``original_exception`` argument and displaying that original exception > from manage.py, but that's pretty fiddly. I think catching any exception an raising ImporperlyConfigured is a good solution. But the original exception should not be lost. I wrote a patch several month ago. The original exception gets displayed in the debug view. manage.py is not handled: http://code.djangoproject.com/attachment/ticket/6537/6537.diff > So I think we need to do something along the lines of what's in > #7524... it's far, far from perfect, but it's probably the only way to > go to avoid a lot of frustration. > > Yes, I think this is a show stopper which should be solved before 1.0. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: Debug logging of swallowed exceptions
Hi, Swallowed or reraised exception without a pointer to the real exception are bad. One point where I discovered this is here: http://code.djangoproject.com/ticket/6623 Writing to stdout out is not a good solution. I would prefere to use the python logging module. Thomas Güttler J Meier schrieb: > Hi folks, > > There's a number of places where Django deliberately swallows > exceptions. Most notably, misbehaving template filters are silenced. > Errors unpickling session data are silently also silently ignored (a > fact that brought me a two hours debugging session this afternoon). > These are always well-considered design decisions, but they leave the > developer in the dark about what has happened. > > I think it would be best if these behaviors were to remain unchanged, > but a log message with an informative traceback be emitted (if DEBUG > is set). Whether this is just printed to stdout or makes use of the > python logging module is immaterial to me. > > I've given a quick search and can't find a specific thread discussion > this idea - if I'm wrong, please point me to it/them. > > If this is seen as a desirable change, I volunteer to submit a patch > covering all swallowed exceptions - avoiding these 2+ hour "bug" > hunting sessions is well worth my time. > > There's no need for this to be a 1.0 feature. > > -Jim Meier > > > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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 schrieb:
>
> There are a few problems with inserting error output in the template
> rather than raising an exception, ...
I use this to raise an exception:
{{{
# settings.py
if DEBUG:
TEMPLATE_STRING_IF_INVALID = InvalidVarException()
}}}
This raises an exception, if a variable is missing.
See http://www.djangosnippets.org/snippets/646/
Unfortunately TEMPLATE_STRING_IF_INVALID is not used in all places:
e.g. Loops: http://code.djangoproject.com/ticket/6766
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
is_authenticated as property
Hi, is_staff, is_active, is_superuser are attributes. is_anonymous, is_authenticated are methods. This is insecure if you are not careful while programming: if user.is_authenticated: # Always true, since it is a method! It would be nice to find a solution. Here is what I thought: Make is_authenticated a property which returns a object which evaluates to the proper boolean value. This object has a method __call__ which returns the same value. This is backwards compatible. Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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 leaking a file descriptor.
Your post contains a lot of lines, but I don't see where the leaking
files descriptor should be.
You can find the open files with this command line (linux). You need to
modify the -C parameter
to fit your binary.
ps -C httpd2-prefork -opid= | while read pid; do ls -l /proc/$pid/fd/*;
done | grep -vE '/dev/null|socket:|pipe:|deleted|/var/log|inode:'
What files are left open?
I think it is a bad to put all open calls into a try: ...finally blocks.
But it could be necessary
in some places.
jikanter schrieb:
> I am pretty sure django is leaking a file descriptor, and the closest
> thing I could come to was was ticket #6482.
>
> localhost:~ jikanter$ curl http://test/
> curl: (52) Empty reply from server
>
> localhost:~ jikanter$ ps auxw |grep httpd
> root 16497 0.0 -0.142560 2864 ?? Ss6:44PM 0:00.88 /
> Users/jikanter/apache_dir/bin/httpd -k restart
> root 16688 0.0 -0.028932832 ?? S 7:22PM 0:00.39 /
> Users/jikanter/src/lighttpd/lighttpd-1.4.18/src/.libs/lighttp
> jikanter 16709 0.0 -0.131996 2812 q2 S+7:25PM 0:00.05
> vim extra/httpd-vhosts.conf
> www-data 17702 0.0 -0.033416936 ?? S11:53PM 0:00.00 /
> Users/jikanter/apache_dir/bin/httpd -k restart
> www-data 17703 0.0 -0.033416936 ?? S11:53PM 0:00.00 /
> Users/jikanter/apache_dir/bin/httpd -k restart
> www-data 17705 0.0 -0.133416 1300 ?? S11:53PM 0:00.00 /
> Users/jikanter/apache_dir/bin/httpd -k restart
> www-data 17706 0.0 -0.033416936 ?? S11:53PM 0:00.00 /
> Users/jikanter/apache_dir/bin/httpd -k restart
> www-data 17709 0.0 -0.033416 1016 ?? S11:53PM 0:00.00 /
> Users/jikanter/apache_dir/bin/httpd -k restart
> jikanter 17712 0.0 -0.027368448 pd S+ 11:53PM 0:00.00
> grep httpd
>
>
> change the third line of django/__init__.py to
>
> assert False, "wa-wah-wee-wah"
>
>
> localhost:~ jikanter$ sudo apache_dir/bin/apachectl -k restart
> httpd: Could not reliably determine the server's fully qualified
> domain name, using ::1 for ServerName
>
> localhost:~ jikanter$ curl http://test/
>
>
> MOD_PYTHON ERROR
>
> ProcessId: 17720
> Interpreter:'python1'
>
> ServerName: 'test.genetictree.net'
> DocumentRoot: '/Users/jikanter/public_html/'
>
> URI:'/'
> Location: '/'
> Directory: None
> Filename: '/Users/jikanter/public_html/'
> PathInfo: ''
>
> Phase: 'PythonHandler'
> Handler:'mywsgiserver'
>
> Traceback (most recent call last):
>
> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/mod_python/importer.py", line 1537, in
> HandlerDispatch
> default=default_handler, arg=req, silent=hlist.silent)
>
> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/mod_python/importer.py", line 1202, in
> _process_target
> module = import_module(module_name, path=path)
>
> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/mod_python/importer.py", line 304, in
> import_module
> return __import__(module_name, {}, {}, ['*'])
>
> File "/Users/jikanter/public_html/mywsgiserver.py", line 2, in
> module
> from django.core.handlers import modpython
>
> File "/Users/jikanter/public_html/django/__init__.py", line 4, in
> module
> assert False, 'wa-wa-wee-wah'
>
> AssertionError: wa-wa-wee-wah
>
>
>
> Has anyone experienced something similar?
>
> mod_python works fine without django, and the django serves files
> correctly without apache.
>
> does anyone mind if ticket #6482 was reopened?
> >
>
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
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: Add newform errors directly (without using ValidationError)
Simon Litchfield schrieb: > I tend to think there needs to be a documented, 'clean' way of adding > non_field_errors (and even field errors too) to forms, *outside* the > clean() methods. > > I had this idea some time ago, too. There is a patch with documentation and unittest: http://code.djangoproject.com/ticket/5335 -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: settings imported twice Was: logging & MODPYTHON
> Something like that should work though: > > try: > reimported = imported > raise Exception, "already imported!" > catch NameError: > imported = True > > Sorry, if __name__ is different, this won't help, too. The python interpreter thinks that there are two different modules. One is called 'settings' and the other is called 'myproj_foo.settings'. That's why I store the variable not in my module, but in the logging module. Because this is the same (exception you have an own module called logging). My solution is at the bottom of this snippet: http://www.djangosnippets.org/snippets/16/ Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: ***SPAM*** Re: logging & MODPYTHON
Graham Dumpleton schrieb: > On Mar 5, 6:56 pm, Thomas Guettler <[EMAIL PROTECTED]> wrote: > >> AndrewD schrieb:> I would like to contribute a general Django logging >> system. I have >> >>> MODPYTHON logging working, & a basic file logging sample. I think most >>> Django users want easy logging out-of-the-box, and it meets the DRY >>> principle. >>> >> It would be great if setting up logging would be documented (maybe in >> the wiki of trac). >> >> I had problems with it, because settings.py gets imported several times >> and this leads to >> all messages being logged twice. >> > > The settings file should not be getting imported multiple times in the > same process. You are most likely just getting confused by the fact > that Apache is multiprocess and so each process will do logging when > it is loaded if you are doing it in settings file. > > No, it gets imported more then once: (Answer of Malcolm): http://www.mail-archive.com/[EMAIL PROTECTED]/msg39061.html -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: SQLAlchemy + Django... Again?
Brantley Harris schrieb: > SQLAlchemy + Django > > What's the status on this? If someone was to work on it, would it be > supported by the lords of Django? > > Hi, I like the django OR mapping very much. I never used SQLAlchemy. Why do you think it is better? Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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: SVN not available
Works again. Am Mittwoch, 23. Januar 2008 12:54 schrieb Thomas Guettler: > Hi, > > http://code.djangoproject.com/browser/django/trunk/django/views > > ''' > 503 Service Unavailable > > Resources to service this request are not available. > > This message is sent by Packeteer PacketShaper. > ''' > > ===> date -R > Wed, 23 Jan 2008 12:51:42 +0100 > > Same on the shell: > ... oops, it failed one minute ago. Now it is OK. But > the error on the above URL is the same. > > Thomas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
SVN not available
Hi, http://code.djangoproject.com/browser/django/trunk/django/views ''' 503 Service Unavailable Resources to service this request are not available. This message is sent by Packeteer PacketShaper. ''' ===> date -R Wed, 23 Jan 2008 12:51:42 +0100 Same on the shell: ... oops, it failed one minute ago. Now it is OK. But the error on the above URL is the same. Thomas --~--~-~--~~~---~--~~ 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: Better Support for static file serving via django
Am Mittwoch, 12. Dezember 2007 21:34 schrieb SmileyChris: > On Dec 13, 9:19 am, "Robert Coup" <[EMAIL PROTECTED]> > > wrote: > > On 13/12/2007, Thomas Güttler <[EMAIL PROTECTED]> wrote: > > > How can you check that only authorized users can access > > > some files? > > Thomas, you might want to try out http://code.djangoproject.com/ticket/3583 > It needs some testing/feedback before I'll promote it to ready for > checkin. You seem like a perfect candidate ;) I will use mod_wsgi in the future. But according to a release note, it supports authentication and authorization, too. Thomas --~--~-~--~~~---~--~~ 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 few questions about FileField
Am Montag, 3. Dezember 2007 16:04 schrieb Marty Alchin: > There is one other question I've been meaning to ask for a while. As > would be expected, this FileField work adds a good amount of code to > db/models/fields/__init__.py, including 3 new classes, which aren't > even Fields themselves (but they're needed to make the Fields work). > If I get my way, and Django gets an AudioField as well, that's two > more classes, another one of which isn't a Field. > > Would it make sense to move the file-related Field code into a > files.py? I think it would be good. --~--~-~--~~~---~--~~ 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: ForeignKey(unique=True) and ForeignRelatedObjectsDescriptor
Am Montag, 5. November 2007 18:47 schrieb Jeremy Dunck: > Consider: > > class Place(Model): > ... > > class Retaurant(Model): > place = ForeignKey(Place, unique=True) > You can use a property. Code not tested: class Place(Model): def get_restaurant(self): try: return Restaurant.objects.get(place=self) except Restaurant.DoesNotExist: return None restaurant=property(get_restaurant) Thomas --~--~-~--~~~---~--~~ 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: FileField question
Am Freitag, 26. Oktober 2007 15:39 schrieb Marty Alchin: > Okay, just a quick update. I don't have a new patch ready yet, because > I wanted to outline a couple things and ask another question. I've > implemented the callable method for determining filenames, including > the ability to include a subdirectory in the filename. Also, ignore my > comment about reusing "default" for the callable argument. Doing so > causes more problems than it solves, and it's not really better > anyway. So, "filename" is what I'm going with for now. > > In doing so, I ran once again into a concern I had a while back, > regarding the strftime stuff currently supported by FileField. I've > gotten them to play nicely with the new filename callable, but it > makes for a bit of overlap, and i was wondering if it'd be possible to > merge them somehow. Consider the following example: > > def get_filename(obj, filename): > return '%s/%s' % (obj.id, filename) > > file = models.FileField(upload_to='songs/%Y/%m/%d', filename=get_filename) Hi, I would call the key word argument filename_callback. Both arguments are XOR. You must provide only one of them. If both are given, an exception is raised. This is backward compatible and flexible. I think that result of filename_callback must be an absolute path. Thomas --~--~-~--~~~---~--~~ 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: FileField question
Am Dienstag, 23. Oktober 2007 14:49 schrieb Marty Alchin: > In response to some recent questions regarding FileField usage, I > thought about including a way to format the filename based on details > from the model instance itself. It's looking like it' be best to add > an argument to FileField, called 'filename' perhaps, which takes a > format string, like so (pardon the inevitable line munging): > > class Song(models.Model): > album = models.CharField(maxlength=255) > title = models.CharField(maxlength=255) > artist = models.CharField(maxlength=255) > track = models.PositiveSmallIntegerField() > year = models.PositiveIntegerField() > genre = models.CharField(maxlength=40) > file = models.FileField(upload_to='songs', > filename='%(album)s_%(track)s_%(title)s.mp3') > > However, this raises two concerns, both stemming from the fact that > given people a cookie will make them want a glass of milk: > > * Many (though I expect not all) will believe that the filename would > update automatically when the model itself is updated. This is > obviously not the case, and the documentation would try to make this > clear, but it's a whole round of questions I expect to hear anyway. Hi, I am one of the people who asked for this. I only want to use the primary key for a directory name. I think a filename is not enough: I don't want to store the files under MEDIA_ROOT. Otherwise you can't use access control, since the request gets served by apache/lighttpd, not django. Example: if an Object class should have N attachments: class Object(models.Model): pass class Attachment(models.Model): object=models.ForeignKey(Object) filename=models.FileField() The file should be saved under /non-public-path/attachments/OBJECT_ID/ For me, it's enough to store the basename in the database. The leading directory (/non-puglic-path/attachments) could be stored in the models.py file as keyword argument: filename=models.FileField(media_root="/...") The idea of Robert Coup to use a callback looks good. Nevertheless, using anything other than a primary key is most of the time nonsense, since attribute can change, but the physical filename does not (except you have a script which updates the filesystem). > Frankly, I'm not sure it's worth it, given the above concerns, but > since working with filestorage, I've been paying attention to > FileField gripes, and this comes up more often than anything else I've > seen. Do you guys think this is worth implementing? > > It wouldn't be part of filestorage itself, but how it gets implemented > will depend a bit on when filestorage makes it into trunk. Please announce it here, if you update your patches. I will try them. Or send a email to [EMAIL PROTECTED] Thomas --~--~-~--~~~---~--~~ 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: content of request.path
Am Mittwoch, 5. September 2007 12:59 schrieb Michael Radziej: > On Wed, Sep 05, Thomas Guettler wrote: > > Am Mittwoch, 5. September 2007 11:27 schrieb Michael Radziej: > > > On Wed, Sep 05, Thomas Guettler wrote: > > > > [cut] > > > > > Is this the same problem as in ticket #285? > > > > > > http://code.djangoproject.com/ticket/285 > > > > Yes > > Is there a general agreement that the mod_python path is the correct one? That's why I started this thread. I see a lot of code that depends on request.path including the scgi/mod_python mount point: - settings.APPEND_SLASH - get_absolute_url = permalink(get_absolute_url) - creating absolute redirects from relative ones (http://code.djangoproject.com/ticket/987) Thomas --~--~-~--~~~---~--~~ 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: content of request.path
Am Mittwoch, 5. September 2007 11:27 schrieb Michael Radziej: > On Wed, Sep 05, Thomas Guettler wrote: [cut] > Is this the same problem as in ticket #285? > > http://code.djangoproject.com/ticket/285 Yes --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
content of request.path
Hi,
if the SCGI/AJP/mod_python app is mounted under /dynamic (http://.../dynamic)
and request URL is http://.../dynamic/test/
What should be the content if request.path?
With mod_python it is /dynamic/test/
With SCGI+WSCGI it is /test/
settings.APPEND_SLASH and other stuff don't work with WSCGI.
I think it would be right to prepend SCRIPT_NAME in request.path:
wsgi.py:
class WSGIRequest(http.HttpRequest):
def __init__(self, environ):
self.environ = environ
# old self.path = force_unicode(environ['PATH_INFO'])
self.path = force_unicode("%s%s" % (environ['SCRIPT_NAME'],
environ['PATH_INFO']))
self.META = environ
self.method = environ['REQUEST_METHOD'].upper()
docs/request_response.txt
path: A string representing the full path to the requested page, not
including the domain.
The docs should be more explicit here. The mod_python/wsgi/scgi mount point is
part of the path
and it starts with a slash.
related: http://code.djangoproject.net/ticket/1516
Thomas
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Session based Messages
Hi,
I hope this patch will be merged soon:
http://code.djangoproject.com/attachment/ticket/4604/visitor_messages.patch
Messages should be stored with sessions.
I would like to enhance the message system by a loglevel:
debug, info, error.
This way you could display important messages different.
Since session based messages have no database model. Adding
a loglevel would not brake old code:
create_message(self, message, level="info")
get_and_delete_messages(self, withlevel=False)
If you pass withlevel=True you would get tuples:
[("info", "..."), ("error", "...") ...]
What do you think?
Thomas
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
