Re: Issues surrounding IDN validation and URLs in general
>> Validation of IDN (Internationalized Domain Names) was added in
>> [12474], but I noticed that the verify_exists option doesn't work when
>> you use an IDN. This is caused by urllib2 not supporting IDN and the
>> validation code using the original unicode version of the URL when
>> testing for existence.
> This seems only to be true for python 2.4. In 2.5 and above urlopen will
> happily accept IDNs.
Are you sure?
I have just tested the following:
$ python2.6
Python 2.6.4+ (r264:75706, Feb 16 2010, 00:09:58)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.urlopen(u'http://пример.испытание/')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.6/urllib2.py", line 391, in open
response = self._open(req, data)
File "/usr/lib/python2.6/urllib2.py", line 409, in _open
'_open', req)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 1161, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.6/urllib2.py", line 1133, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File "/usr/lib/python2.6/httplib.py", line 910, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python2.6/httplib.py", line 947, in _send_request
self.endheaders()
File "/usr/lib/python2.6/httplib.py", line 904, in endheaders
self._send_output()
File "/usr/lib/python2.6/httplib.py", line 776, in _send_output
self.send(msg)
File "/usr/lib/python2.6/httplib.py", line 755, in send
self.sock.sendall(str)
File "", line 1, in sendall
UnicodeEncodeError: 'ascii' codec can't encode characters in position
49-54: ordinal not in range(128)
>>> urllib2.urlopen('http://пример.испытание/')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.6/urllib2.py", line 391, in open
response = self._open(req, data)
File "/usr/lib/python2.6/urllib2.py", line 409, in _open
'_open', req)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 1161, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.6/urllib2.py", line 1136, in do_open
raise URLError(err)
urllib2.URLError:
Same for python2.5.
PS:
I was forced to slightly google on this subject and found urlnorm.py
from Sam Ruby. At http://code.google.com/p/url-normalize/ I have
created a fork of this module (pep-ized and with the IDN support
addition)
It would be wonderful if django.utils.http will contain something like
this for URI normalization.
--
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.
Where are 2.0 ideas/fixes being tracked?
I'm looking at http://code.djangoproject.com/ticket/12359, and (with some guidance from Alex_Gaynor), think that there's really two fixes here: a short term, backwards-compatible fix which removes the forced help_text appendage, and a long-term, backwards-incompatible fix which adds a help_text layer to widgets so they can carry around presentational help_text in addition to the field help_text which we already have. The short term fix is managed via trac, and I'll spare the details here as it's not really my question. The question is: where do we track these "only in 2.0" improvements? I looked in trac for a 2.0 version target, but there isn't one. -I -- 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: Issues surrounding IDN validation and URLs in general
This seems only to be true for python 2.4. In 2.5 and above urlopen
will
happily accept IDNs.
Are you sure?
Yes:
~/ python2.5
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib2 import urlopen
>>> urlopen('http://пример.испытание/')
0x559eb0>>
~/ python2.6
Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib2 import urlopen
>>> urlopen('http://пример.испытание/')
0x70b330>>
I have just tested the following:
$ python2.6
Python 2.6.4+ (r264:75706, Feb 16 2010, 00:09:58)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import urllib2
urllib2.urlopen(u'http://пример.испытание/')
[...]
UnicodeEncodeError: 'ascii' codec can't encode characters in position
49-54: ordinal not in range(128)
This isn't a IDN problem it's a "normal" python unicode string
handling problem. What is the locale on your System?
Ulrich
--
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: dbsettings, and user configurable app settings
On Feb 27, 1:53 pm, stuff4ash wrote: > b) easy way to register, override, configurations for apps. > a settings.py in an app folder that is "magically" loaded the same way > other things are would suffice, but there has to be a way to: I've never understood the desire for more magical behavior here. My apps have a settings.py that imports django.conf.settings and provides any necessary defaults for unset settings; the rest of my app imports from there. Works great, easy to look and see what settings my app consumes and what defaults they have. I don't see what advantages a more complex system would provide. Example here: http://bitbucket.org/carljm/django-adminfiles/src/tip/adminfiles/settings.py > -override and prioritize settings, as sometimes you have to override > things. I'm not sure what this means. In my setup, project-level settings always override app-level defaults; which is as it should be, I think. > -mark defaults, get defaults from other apps, and mark some settings > as obligatory. I use getattr(settings, 'SOME_SETTING', 'default') for defaults. If I want to get a default from some other app, I can import it and do so. If a setting is obligatory, I raise an import-time ImproperlyConfiguredError. > i have a django mingus blog now. when i upgrade mingus, and the many > many many apps it has, how do i know without reading all the docs, if > there is a new setting that i should set or change? If it's a required setting, you should get an error when you try to run the project without it (I sure hope you're testing the upgrade somewhere other than your production server...). If it's optional, why should you be bothered with it unless you already know you want it? If you really want to know all the available settings, that's what docs are for. Carl -- 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: Where are 2.0 ideas/fixes being tracked?
On Sun, Feb 28, 2010 at 6:26 PM, Idan Gazit wrote: > I'm looking at http://code.djangoproject.com/ticket/12359, and (with > some guidance from Alex_Gaynor), think that there's really two fixes > here: a short term, backwards-compatible fix which removes the forced > help_text appendage, and a long-term, backwards-incompatible fix which > adds a help_text layer to widgets so they can carry around > presentational help_text in addition to the field help_text which we > already have. > > The short term fix is managed via trac, and I'll spare the details > here as it's not really my question. > > The question is: where do we track these "only in 2.0" improvements? I > looked in trac for a 2.0 version target, but there isn't one. 2.0 ideas aren't getting tracked anywhere specific at the moment. This is mostly because we don't really have a plan for when 2.0 will happen, or what will be in it when it does. However, you're right that we should have a way of tracking ideas that are big backwards incompatibilities that we know we are going to make. I've just added a 2.0 milestone to track such ideas. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
Abstract models and their managers
Hi there, I'm just getting an understanding around how managers from abstract models are applied to a subclass model and it appears as though if a model inherits from two abstract models that each define a manager with the same attribute name, eg "objects", then normal mro applies and the derived model picks up the manager from the one abstract model and loses the other one. What are people's thoughts around changing this behaviour so that the derived model's "objects" attribute is actually a newly created type, using each of the abstract models' managers as the bases for the new manager? For example the calls at the end of this would work: class ManagerA(Manager): def methodA(self): pass class ModelA(Model): objects = ManagerA() class Meta: abstract = True class ManagerB(Manager): def methodB(self): pass class ModelB(Model): objects = ManagerB() class Meta: abstract = True class ModelC(ModelA, ModelB): pass ModelC.objects.methodA() ModelC.objects.methodB() It seems to me that this would be desired behaviour especially if the abstract models are parts from separate applications that weren't aware of each other, with each of their managers providing required functionality. I've started working on a patch for this and I'm just looking for some feedback before I go any further. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deprecating cmemcache, adding pylibmc
Thanks all for the helpful discussion here. From the sounds of thing, my course of action will be: 1) Get a patch that throws a FutureDeprecationWarning when cmemcache is used + Change of the docs to note the coming deprecation of cmemcache 2) Begin working on a more involved patch that hopefully get slated in for 1.3. I'll throw 1) in on the cmemcache ticket (Ticket #12484 may be able to be merged into it), and put my work for 2) into the pylibmc ticket once I finish it. On Feb 23, 6:29 am, Mat Clayton wrote: > On Tue, Feb 23, 2010 at 2:41 AM, Mike Malone wrote: > > > At this point in the release process, I'm not sure we can do > > > everything that's being talked about in this thread. Given that we're > > > feature-frozen and that there's no way we can spring a completely new > > > cache backend on people at the last minute, here's what's possible > > > within our release process right now for 1.2: > > > > 1. Specifying memcached as the cache backend continues using the same > > > "memcached://" scheme as it always has. There is no way we can change > > > that in the 1.2 timeframe. > > > > 2. The memcached backend in Django should look first for the correct > > > library, and fall back to the old one as needed. > > > > 3. When falling back to the old memcached library, 1.2 should raise > > > PendingDeprecationWarning; 1.3 should promote that to a > > > DeprecationWarning and 1.4 should remove the support entirely. > > > > Anything and everything else being discussed is out of scope for 1.2 > > > and must wait for the 1.3 feature proposal window. > > > Yea, at this point doing anything significant in 1.2 seems like a bad > > idea. But, some of this stuff could potentially be done using query > > string args to the cache backend URI, which would maintain backwards > > compatibility. Without thinking too much about naming the arguments, > > it'd look something like this: > > > CACHE_BACKEND = > > "memcached:// > > 127.0.0.1:11211/?binding=pylibmc&enable_compression=True&min_compress_lengt > > h=15&fix_zero_timeout=True > > " > > > Still, I'm hesitant to rush into this sort of decision because I'd > > hate to make the wrong one and then have to support it going forward. > > > Also, since the URI isn't known at the module level (it's passed into > > CacheClass.__init__) we'd probably have to import the memcache client > > in __init__ or something. Not the end of the world, but kind of messy. > > > > Mike'shttp://github.com/mmalone/django-cachinghas some good examples > > of fixing 2/3 > > > FWIW, the "more correct" way to do this is to create your own custom > > cache backend like this:http://gist.github.com/299905then use the > > full module path in the CACHE_BACKEND setting, like: > > > CACHE_BACKEND = 'foo.bar.custom_memcache://127.0.0.1:11211/' > > That makes much more sense, but is surely out of scope for 1.2, essentially > I need slightly finer grain control over the cache and I suspect some others > may do also, Django wont manage to cover everyone's edge cases, but it would > be good to be able to still user some of the good points of django's caching > code and be able to extend it as required. Wasn't expecting that any of > these to be built, just thought I'd flag them as "hacks" we currently use on > the normal caching system, to achieve what we need, as its in the same part > of the code base. > > Mat > > > > > Mike > > > -- > > 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 > i...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > -- > -- > Matthew Clayton | Founder/CEO > Wakari Limited > > twitterhttp://www.twitter.com/matclayton > > email m...@wakari.co.uk > mobile +44 7872007851 > > skype matclayton -- 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.
Proposal - admin actions with no elements selected
Hi there, Currently, if no elements are selected, any action selected in the admin interface will not fire. However, sometimes it is useful to create actions which do not require any elements to be selected - ie x removing all elements x drag-n-drop reordering of all elements x arranging elements into some sort of tree structure and etc. - essentially, actions which work on all / certain subset of elements, which is defined in the logic of the action (one more example - "delete all unpublished articles") Wouldn't this be useful? Regards, George -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal - admin actions with no elements selected
On Mon, Mar 1, 2010 at 12:23 AM, George Karpenkov wrote: > Hi there, > > Currently, if no elements are selected, any action selected in the > admin interface will not fire. > > However, sometimes it is useful to create actions which do not require > any elements to be selected - ie > > x removing all elements > x drag-n-drop reordering of all elements > x arranging elements into some sort of tree structure > > and etc. - essentially, actions which work on all / certain subset of > elements, which is defined in the logic of the action (one more > example - "delete all unpublished articles") > > Wouldn't this be useful? > > Regards, > George > > -- > 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. > > It was an intentional design decision to not support admin actions with 0 items. Having 2 separate sets of functionality (those that operate on selected items, and those that operate on all, none, or something else entirely) in a single UI element was deemed to be very counter intuitive. If you search this list you'll see that this has been discussed several times. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
