hi,
i think there is some use of unnecessary mark_safe in the above-mentioned
function, but maybe i am overlooking something, so i thought before opening
a ticket i will discuss it here.
if you check the urlize-function
https://github.com/django/django/blob/master/django/utils/html.py#L173,
it b
On Fri, May 27, 2011 at 7:04 AM, Sean O'Connor wrote:
> A better approach would for Django to provide some tools and documentation
> to help people work around the conflict. One easy solution would be to
> provide a verbatim tag like what ericflo wrote
> at https://gist.github.com/629508. Anothe
On Mon, May 11, 2009 at 6:22 PM, Malcolm Tredinnick
wrote:
> The choice to be made in an API implementation of this kind is whether
> NULL checks on fields in related models implies a related instance
> exists or not. Django follows SQL there and doesn't insist that a
> related row exists: absenc
On Mon, May 11, 2009 at 11:37 AM, Michael Radziej wrote:
>
> On Mon, May 11, Gábor Farkas wrote:
>
>> Group.objects.filter(person__stamp__isnull=True)
>>
>> i get an OUTER JOIN,
>>
>> but if i do this:
>>
>> Group.objects.filter(person__stamp=&#
hi,
i'd like to discuss ticket 10032, because it was closed as WONTFIX,
and i think the issue i raised was somehow misundersood,
perhaps i explained it the wrong way.
the problem is that i'm filtering a queryset
by doing a join using a foreign-key in the "opposite way",
and django sometimes does
On Thu, Mar 19, 2009 at 9:53 AM, Thomas Guettler wrote:
>
> 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 b
On Fri, Dec 12, 2008 at 2:48 AM, James Bennett wrote:
>
> On Thu, Dec 11, 2008 at 7:06 PM, Simon Litchfield wrote:
>> +1. Definitely need some kind of cascade=False option somewhere. I'd
>> argue it should be the default. I have some production horror stories
>> which I'm sure I don't need to sh
On Sun, Nov 9, 2008 at 3:48 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee
> <[EMAIL PROTECTED]> wrote:
>> However, to clarify - are you talking about a backwards incompatible
>> change, or are you talking about putting a backwards compatible l
On Thu, Jun 12, 2008 at 4:03 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> "Maybe" features
>
>
.
.
.
>
> 5. Model-level validation (#6845).
hi,
it always seems quite ugly, that you can create a model with invalid data,
and save it. so when you want to validate it's conte
On Mon, Jun 9, 2008 at 11:02 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
>> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
>> rc or two, and then a final release. Features that are done by
J. Cliff Dyer wrote:
> On Thu, 2008-04-10 at 20:26 +0200, Gábor Farkas wrote:
>> the point is,that in my opinion, 99% of all developers want to have
>> their unicode-data normalized, before they process it. (maybe they
>> don't know yet that they want it, but they want i
RY_STRING']), but
even that would require that i copy the convert-get-post-data-to-unicode
code from django. which seems to be quite ugly and can cause
errors/incompatibilities in the future.
gabor
>
> On Apr 10, 11:26 am, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>> On Thu
On Thu, Apr 10, 2008 at 06:44:35AM -0700, simonb wrote:
>
> On Apr 10, 2:48 pm, Gábor Farkas <[EMAIL PROTECTED]> wrote:
> > hi,
> >
> > would it be a good idea to add support to django to unicode-normalize
> > incoming get/post-data?
>
> class NormC
Amit Upadhyay wrote:
> On Thu, Apr 10, 2008 at 12:18 PM, Gábor Farkas <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> p.s: if there is a way to achieve this without touching
> django-internals, please tell me :)
>
>
> I would have
hi,
would it be a good idea to add support to django to unicode-normalize
incoming get/post-data?
the normalization problem is basically this:
for example my name, 'gábor' can be written in 2 different ways in
unicode: u'g\xe1bor' and u'ga\u0301bor'.
the first one uses the 'LATIN SMALL LETTER
Simon Willison wrote:
> I'd love to have a simpler alternative to the regexp method that is
> more friendly for developers who haven't fully grokked regular
> expression syntax yet.
while i agree that simplifying things is always a good idea, i think
that "developers who haven't fully grokked reg
Greg_IAP wrote:
> Hello,
>
> i'm trying to understand how the method "select_related" works and it
> doesn't seems to...
>
> Does someone could explain to me how to make it work?
> several examples on the net show that it doesn't...
just a small note:
if you use select_related, make sure that
or mod_fastcgi
thanks,
gabor
>
> Graham
>
> On Oct 22, 5:20 pm, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>> Graham Dumpleton wrote:
>>> They have now committed changes in relation to this:
>>> http://www.initd.org/tracker/psycopg/changeset/902
>&g
Graham Dumpleton wrote:
> They have now committed changes in relation to this:
>
> http://www.initd.org/tracker/psycopg/changeset/902
>
> On visual inspection the changes look to do what I was suggesting.
>
hmm.. could you please summarize the situation?
in other words, what problems am i f
Hi,
before the unicode-change, QueryDict.update handled also updating from a
MultiValueDict (where on a key there might be several values) correctly.
but now it does not support it correctly,
so if you are updating a QueryDict with a MultivalueDict (for example a
request.GET which contains a
Russell Keith-Magee wrote:
> On 8/23/07, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>> hi,
>>
>> i posted this one week ago, could someone with commit access please
>> respond to it?
>
> If we're haven't addressed these tickets, it's n
hi,
i posted this one week ago, could someone with commit access please
respond to it?
thanks,
gabor
Gábor Farkas wrote:
> hi,
>
> when django deletes an object (using the object's delete() method),
> then all related objects are also deleted.
>
> this is
hi,
when django deletes an object (using the object's delete() method),
then all related objects are also deleted.
this is not always a good thing.
there are various approaches to solve this, like:
http://code.djangoproject.com/ticket/1007
and
http://code.djangoproject.com/ticket/2288
,
but th
Jacob Kaplan-Moss wrote:
> On 8/2/07, Daniel Brandt <[EMAIL PROTECTED]> wrote:
>> I am recieving POST-data that is submitted to my application not via a
>> form or a browser, but from other web applications, according to a
>> known protocol. This data may or may not have the charset of the data
>>
David Danier wrote:
>> The point is that I don't have write permissions on the subversion
>> tree...
>
> If you want to keep a log of your changes try using some decentralized
> version control system. I use svk, but git/mercurial/darcs/... might
> work similarly. I prefer svk, because it integra
David Cramer wrote:
> In my opinion BlobField's need some kind of support inside of Django
> before the coming of 0.97 release.
>
> They have never been officially supported, but they were at least
> usable (as say a TextField) before Unicode. Now they're unusable as
> you run into encoding/decod
Jacob Kaplan-Moss wrote:
> On 7/30/07, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>> approximately when do you plan to finish this rewrite? i realize it's
>> hard to predict, i'm just asking for very rough estimates... are we
>> talking about days or weeks or mo
Malcolm Tredinnick wrote:
> On Fri, 2007-07-27 at 08:55 +0200, Gábor Farkas wrote:
>> hi,
>>
>> ticket 4789 fixes a bug in select_related-queries when used with the
>> depth parameter.
>>
>> it contains a patch which fixes the problem. it also contains th
hi,
ticket 4789 fixes a bug in select_related-queries when used with the
depth parameter.
it contains a patch which fixes the problem. it also contains the tests
for this fix.
without this patch, select_related is unusable with the depth parameter.
i understand that everyone has limited time
oggie rob wrote:
>>> does this also affect psycopg1?
>> Looking at psycopg1 code, the answer would appear to be that it is not
>> affected. Changes to support Decimal appear to be psycopg2 specific.
>>
>> Graham
>
> The problems I was seeing the other day were repeatable both using
> strictly psy
Graham Dumpleton wrote:
>
> The reason I am asking is that there were recently problems found with
> pyscopg2 module and its support for use of decimal.Decimal type. In
> practice this only affects people who use mod_python or mod_wsgi and
> run two different Django application instances in two d
Michael Radziej wrote:
> Hi,
>
> I think I've hit a show stopper.
>
> I'm still porting my application to Unicode ... well, before the
> unicode
> changes it was possible to use a TextField for pickles, like
> contrib.Session
> does (Session.session_data).
>
> But pickling gives a bytestring, a
David Cramer wrote:
> Is there any reason why its storing the keys in QueryDict (possibly
> others) as unicode?
>
i think it's for consistency.
i mean, when i see mentioned that django is fully unicode,
i assume every string i get from django is in unicode,
unless there's a very good reason for
Malcolm Tredinnick wrote:
> On Tue, 2007-07-10 at 09:20 +0200, Gábor Farkas wrote:
>> hi,
>
>> i'm always using the "pythonic" way (import the view function, and give
>> it to the urlconf), and assumed that this is the recommended way.
>>
>> b
hi,
when specifying view-functions in the urlconfs, you can either specify
them by their name as a string, or by referencing them "pythonically"
(importing them, and giving the urlconf the callable).
which is the "preferred" way?
i'm always using the "pythonic" way (import the view function,
Michael Radziej wrote:
> On Thu, Jun 28, Gábor Farkas wrote:
>
>> Michael Radziej wrote:
>>> I use git-svnimport to sync the svn with my git repository, and it seems to
>>> fail around every 6 months under unknown circumstances (probably something
>>> wi
Michael Radziej wrote:
>
> I use git-svnimport to sync the svn with my git repository, and it seems to
> fail around every 6 months under unknown circumstances (probably something
> with merges)
maybe try to use 'git-svn'... it seems that the development for
'git-svnimport' has stopped.
p.s: o
David Larlet wrote:
> 2007/6/18, David Larlet <[EMAIL PROTECTED]>:
>> Hi,
>>
>> I've just tried to use the permission_required decorator for my views
>> and I realise that there is a missing 'retrieve' permission. It's a
>> bit odd because others ones follow the CRUD permissions.
>>
>> Am I missin
Noam wrote:
> telephone = CharField(u'טלפון', maxlength=30)
>
> However, it causes the admin app to fail with a nasty
> UnicodeDecodeError.
>
as Malcolm wrote already, the unicode-branch will solve this, but for
now, try to use a bytestring in your application's encoding there.
so, for exa
hi,
i'd like to know if the unicode branch is now in the
"more or less done, please test and report bugs" state,
or still in the
"not complete yet, it is still changing" state?
thanks,
gabor
--~--~-~--~~~---~--~~
You received this message because you are subs
Malcolm Tredinnick wrote:
>
> What I'd really like from you guys (Michael, Ivan, Gábor -- and anybody
> else who wants to play along) is to see how the code fits in with your
> existing workflow. What are the bits that are still hard for you? What
> are the problems that aren't solved? I'm thinki
Malcolm Tredinnick wrote:
> On Tue, 2007-04-10 at 10:02 +0200, Gábor Farkas wrote:
>> hi,
>>
>> i've been reading http://code.djangoproject.com/wiki/StringEncoding,
>>
>> and the idea seems to be, that for "Passing Strings Between Django and
>>
hi,
i've been reading http://code.djangoproject.com/wiki/StringEncoding,
and the idea seems to be, that for "Passing Strings Between Django and
the Developer's Code",
django will/should accept both utf-8 encoded byte-strings, and
unicode-strings.
wouldn't it be simpler to only accept unicode
Ned Batchelder wrote:
> I think it would be a great idea. I have used similar tracing
> facilities in other (non-Django) projects, and they were invaluable for
> quickly zeroing in on the pathological code that swamped the performance.
>
> I don't know what the feeling of the devs is on clutte
xgdlm wrote:
> Thanks for your reply Malcolm
>
>> Hmm... this precise example works for me. Are you using a reasonably
>> recent release (like 0.96)? I remember there was a unicode fix that went
>> in not too long ago to add smart_unicode() calls in various places for
>> things just like this.
>
Michael Radziej wrote:
> Hi,
>
> Jacob states in Ticket #3357 [1] that Django were far from being
> thread-safe. But on the other side, Django
> is able to run as threaded
> fastcgi-server
i think this part is the one where we have to be more exact.
does that mean that : "it is guaranteed
Michael Radziej wrote:
> Gábor Farkas:
>>
>> 1. we do not mandate yet that GET/POST data is in settings.DEFAULT_CHARSET
>
> We don't mandate any particular encoding in
> settings.DEFAULT_CHARSET? Take a look at ticket #951 and the recent
> discussion about it her
Michael Radziej wrote:
> Gábor Farkas:
>> Michael Radziej wrote:
>>>* What encoding does python use if you pass unicode to open()?
>> for os.listdir it uses sys.getfilesystemencoding(), so i assume it does
>> the same for open().
>>
>> so usually
Michael Radziej wrote:
> Hi Tsuyuki!
>
> tsuyuki makoto:
>> Proposed solution: punicode conversion before call
>> django.util.text.get_valid_filename.
>
> Why punycode? I'd think that most filesystems these days support UTF-8
> (though, with different normalization, which *is* a problem).
>
>
Ivan Sagalaev wrote:
> Splitting this into new thread since it's already not about db client
> encodings...
>
> ak wrote:
>> So if everyone agreed, the way is simple:
>> 1. when django loads data from db and fills in a model object, all
>> strings have to be encoded according to DEFAULT_CHARSET
hi,
(first i apologize if this was already discussed or solved. i could not
find anything about it in the newsgroup-archives)
i've seen that one of the latest commits did some changes to the
"raw_id_admin" attribute.
for the admin this is fine, but there is also an another aspect of
raw_id_a
Julian 'Julik' Tarkhanov wrote:
>
>
> Python's unicode is actually UTF-16
sorry, but no. it's not utf-16.
it's decided at compile-time,
and i'ts either utf-32 or utf-16.
on linux it's usually utf-32, and on windows it's usually (always?) utf-16.
but you should not care about it. you see,
Honza Král wrote:
> Hi there,
>
> I have been playing around with newforms for some time. since I don't
> come from an English speaking country, I did also put the unicode
> stuff to the test.
>
> It has bitten me on several occasions. I agree that I am not used to
> python unicode strings, but
hi,
after i've read this blog post:
http://superjared.com/entry/urgent-upgrade-django-if-deployed-fastcgi/
i also became a little nervous because i also have a fastcgi-backed website.
but the problem is, i am unable to reproduce this problem.
actually i use a custom fastcgi script ( the fastc
Adrian Holovaty wrote:
> On 12/10/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> What if instead of adding various as_* methods that we have a
>> FormFormatter class that determines how the form displays. The
>> _html_output and as_* methods would become FormFormatters. Formatter
>> could be a p
Adrian Holovaty wrote:
> On 11/30/06, gabor <[EMAIL PROTECTED]> wrote:
>> but if i want to render it in a template and it contains non-ascii text,
>> it fails in /home/gabor/src/django/django/template/__init__.py,
>> line 745, UnicodeEncodeError.
>>
>> the code there calls str() on the form, and i
Jay Parlar wrote:
> On 11/6/06, David Blewett <[EMAIL PROTECTED]> wrote:
>> I would like to suggest that the branches that are felt to be complete
>> sans testing be merged into a single branch. I am anxiously awaiting
>> several different branch merges to core but do not have time to check
>> eac
Malcolm Tredinnick wrote:
> On Fri, 2006-11-03 at 22:19 +, Rob Hudson wrote:
>> Jacob Kaplan-Moss wrote:
>>> Try this::
>>>
>>> from innovate.innovation.models import Innovation
>>> from django.contrib.contenttypes.models import ContentType
>>>
>>> i = Innovation.objects.get(id=1)
Adrian Holovaty wrote:
> Hello all,
>
> I've attached the first draft implementation of the manipulator
> replacement framework -- it's just a single Python module.
>
> * All output is Unicode. I did this because eventually Django's
> internal strings will all be Unicode, and we might as well do
Russell Keith-Magee wrote:
> On 10/11/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>> Russell Keith-Magee wrote:
>
>> sorry, but is this the description of the __iter__ case, or the
>> iterator() case?
>
> Now that you mention it (looks furiously at code
Russell Keith-Magee wrote:
>
>> somehow i assumed that the QuerySets never load in the whole result-set,
>> except when they are forced (cast to list for example). but now i see
>> that of course, if you cache the results, then you will have all the
>> results in memory anyway...
>
> This is wha
Michael Radziej wrote:
> Malcolm Tredinnick schrieb:
>> Interestingly, looking at QuerySet.iterator() and QuerySet.__iter__,
>> they aren't synonyms. The point is that QuerySet.__iter__ iterates over
>> the result of QuerySet._get_data(), which actually sucks everything into
>> memory before itera
Ivan Sagalaev wrote:
> Gábor Farkas wrote:
>> now, when you call Owner.AddManipulator(), he's going to fetch the WHOLE
>> Thing-table. just to construct the AddManipulator.
>
> I've seen that in one of my projects and fixed it by filtering out
> unneeded se
Michael Radziej wrote:
> Gábor Farkas wrote:
>> =
>> class Owner(Model):
>> name = CharField(maxlength=500)
>> thing = ForeignKey(Thing)
>> =
>>
>> now let's say you have a LOT
hi,
yesterday i was bitten by something in the manipulator-behaviour, which
i did not really expect to work that way...and i'm now not sure if i
should submit a bugreport, or it should behave like that. also, it's
quite possible that i understood this wrong, if that's the case please
correct
James Bennett wrote:
>
> 2. Admittedly I don't have a whole lot of experience in the area, but
> creating and managing a pool of connections to be passed from thread
> to thread just feels like much more hassle and overhead than we really
> need, especially since there are external pooling utilit
Bill de hÓra wrote:
> gabor wrote:
>
>> so what do you think about the following approach:
>>
>> try ascii-decoding
>> if fails, try utf8-decoding
>> if fails do iso-8859-1-decoding (this cannot fail).
>>
>> ?
>
> Dumb question maybe. How do you know this encoding ladder will work?
it depends o
Bill de hÓra wrote:
> Malcolm Tredinnick wrote:
>
>> table design with
>> lots of sparse columns won't get me invited to the cool parties.
>
> Qotd!
>
(added to my quotes-collection :-)
gabor
--~--~-~--~~~---~--~~
You received this message because you are sub
Jeroen Ruigrok van der Werven wrote:
> On 7/16/06, gabor <[EMAIL PROTECTED]> wrote:
>> i think we do not need to discuss japanese at all. after all, there's no
>> transliteration for kanji. so it's imho pointless to argue about
>> kana-transliteration, when you cannot transliterate kanji.
>
> If
Simon Willison wrote:
>
> On 19 Jul 2006, at 13:19, Ivan Sagalaev wrote:
>
>> Talking about QUERY_STRING... While the string itself is in ASCII
>> it has
>> urlencoded data and there the encoding matters. As fas as I can see in
>> practice browsers tend to encode those data in the same encodin
Ivan Sagalaev wrote:
> Simon Willison wrote:
>> In the absence of anything better than that, I think it's safe to
>> assume that CGI environment variables should always be ASCII encoded.
>
> Talking about QUERY_STRING... While the string itself is in ASCII it has
> urlencoded data and there th
Bill de hÓra wrote:
> gabor wrote:
>
>> questions:
>> 1. django publishes the whole environ dictionary as request.META. the
>> environ dictionary is a normal byte-string dictionary. so, should we
>> convert it to unicode so that the request.META dictionary only contains
>> unicode strings?
>>
Antonio Cavedoni wrote:
> On 17 Jul 2006, at 8:25, tsuyuki makoto wrote:
>> We Japanese know that we can't transarate Japanese to ASCII.
>> So I want to do it as follows at least.
>> A letter does not disappear and is restored.
>> #FileField and ImageField have same letters disappear problem.
>>
>
hi,
i've found (by browsing the source-code),
that if i want to put raw html code into a column
in django.contrib.admin's list views,
i can do it by setting the allow_tags attribute to true
for the given "something" :)
but this feature is not documented, so before i use it in an
application, i
Michael Radziej wrote:
> Gábor Farkas wrote:
>> regarding running a "fake" webserver.. did you look at twill?
>
> But it does not allow to test against the context!
>
yes, that's why i said 'regarding running a "fake" webserver' :-)
but
Simon Willison wrote:
>
> On 12 Jul 2006, at 02:28, Malcolm Tredinnick wrote:
>
>> I approached things from a different direction, though, more
>> concentrating on how to unit test templates and views (as in not
>> requiring a full end-to-end application setup in order to test
>> them). So
>>
Gábor Farkas wrote:
> Jacob Kaplan-Moss wrote:
>>
>> So I think -- for now -- there are more important places to spend our
>> energy.
>
>
> 2. 'to spend our energy'. i think it's a little more complicated. if
> someone is willing to help-with/
Jacob Kaplan-Moss wrote:
> On Jun 28, 2006, at 6:07 AM, Gábor Farkas wrote:
>> what i think we are missing the most is to hear about the "main"
>> developers (project owners?) (adrian, malcolm, jacob etc.) opinion
>> about
>> unicode-ification. if they thi
hugo wrote:
> Hi,
>
>> So, what's stopping Django from switching to unicode? Is someone working on
>> it? And finally, what should I do to see my sweet Django fully
>> unicode-aware? :)
>
> Well, as a start, take a look at the impact analysis page at
> http://code.djangoproject.com/wiki/UnicodeI
Uros Trebec wrote:
> class Post(models.Model):
> author = models.CharField(maxlength=100)
> title = models.CharField(maxlength=100)
> content = models.TextField()
> date = models.dateField()
hi,
sorry to jump in so late into the discu
[EMAIL PROTECTED] wrote:
> Fist up, apologies if I'm posting this in the wrong place and apologies
> if this issues is covered somewhere else -- I searched for it but
> couldn't find the answer I was looking for.
>
> OK, I'm new to Django but have a quick, hopefully easy-to-answer
> question,
>
Simon Willison wrote:
>
>
> The ideal situation would be for auto_escape to be on by default, and
> let templates turn it off if they need to. This has serious backwards
> compatibility issues however.
the official opinion is that there's no backward-compatibility
guarantees before 1.0 any
Ivan Sagalaev wrote:
> gabor wrote:
>
>> for example, i was building a very simple web-file-manager. you can ask
>> python to get you the os.listdir, etc, data in unicode, which i think
>> the only sensible way, because otherwise you have to watch out for the
>> filesystem-encoding. but becaus
Gábor Farkas wrote:
> hi,
>
> is it intentional that slicing a queryset ignores the Meta_ordering?
>
> for example:
>
>
> class Thing(Model):
> name = SlugField()
> pub_date = DateTimeField()
>
> class Met
hi,
is it intentional that slicing a queryset ignores the Meta_ordering?
for example:
class Thing(Model):
name = SlugField()
pub_date = DateTimeField()
class Meta:
ordering = ['-pub_date']
>>> T
Jorge Gajon wrote:
>> from proj1.app1.models import User
>> User.objects.get(poll__question__exact='x')
>
>> from app1.models import User
>> User.objects.get(poll__question__exact='x')
>
>
> I don't see any difference except for the 'from' statement.
well, that's it :)
> What 'reverse lookup'
Malcolm Tredinnick wrote:
> On Tue, 2006-05-16 at 09:00 +0200, Gábor Farkas wrote:
>> Jeroen Ruigrok van der Werven wrote:
>>> On 5/16/06, Ville Säävuori <[EMAIL PROTECTED]> wrote:
>>>> I think that this problem applies in most european languages, too.
>&g
Jeroen Ruigrok van der Werven wrote:
> On 5/16/06, Ville Säävuori <[EMAIL PROTECTED]> wrote:
>> I think that this problem applies in most european languages, too.
>> Like, say, Swedish, German and French.
>
> The same appliesa for Dutch where we use trema's (sort of umlauts) to
> denote any possi
Jacob Kaplan-Moss wrote:
> On Apr 18, 2006, at 3:30 AM, Amit Upadhyay wrote:
>> How about shipping a prepopulated sqlite db? To avoid dependency I
>> recommend splitting the distribution in django, and django-dev?
>> django, bare minimum for deployment, django-dev with examples and
>> whatno
Adrian Holovaty wrote:
> On 3/27/06, binaryfeed <[EMAIL PROTECTED]> wrote:
>> What's most frustrating about this thread is that no one has responded,
>> really. I mean, it'd be great to know if it was going to be a matter
>> of days, weeks, or months. Much as I search for it, this information
>>
ChaosKCW wrote:
> This is a common thread :-) and one I am interested in, but you can
> search the forumn for the results. Bascially it will be done when its
> done it seems :-)
>
i'm following the forums, and i knew that probably the answer would be
when-its-done :-( just wanted to make sure,
Jacob Kaplan-Moss wrote:
> On Mar 13, 2006, at 9:41 PM, James Bennett wrote:
>> Sure they can. Imagine explaining Django to someone who's never seen
>> an MVC model before; if you told them "the model is where you provide
>> all the information about a class of objects, and describe how it
>> work
Adrian Holovaty wrote:
>
> EXAMPLE CODE:
>
> class Person(models.Model):
> name = models.CharField(maxlength=50)
> birthday = models.DateField()
> favorite_number = models.IntegerField()
>
p = Person(name='Joe', birthday='never', favorite_number='foo')
p.validate()
> {'bir
Gábor Farkas wrote:
> Jacob Kaplan-Moss wrote:
>> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
>>> Now, did I miss something and is this already fixed? Should this be
>>> treated differently? How do other people handle this?
>>
>> The problem
Jacob Kaplan-Moss wrote:
> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
>> Now, did I miss something and is this already fixed? Should this be
>> treated differently? How do other people handle this?
>
> The problem in the admin was fixed in [1982]: http://
> code.djangoproject.com/changes
Adrian Holovaty wrote:
> On 2/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> I still thing Java has it place in heavyweight Enterprise applications
>> and dealing with integration concerns BUT for everything else there is
>> perhaps Python and cool frameworks like Django...
>>
>> Django se
kmh wrote:
>> This breaks semantics of a property of an object: you should be able to
>> read exactly what you just set. Imagine explaining this magic to a newbie:
>>
>> c.crime_date = request.POST['crime_date'] ## user submits '2006-1-2'
>> if c.crime_date == '2006-1-2': ## false!
>>
Maniac wrote:
Jeroen Ruigrok van der Werven wrote:
Makes sense given the recent push for making the Django core UTF8.
No, recent push is to make Django core Unicode (arrays of 2-byte
normalized characters).
well, it's not always 2bytes (usually it's 4bytes).
(sorry, couldn't resist :)
g
hugo wrote:
i understand that django's architecture should use unicode because it's
the better way, but from the "outside"... what functionality is not
working fine with non-english characters?
currently you are up to your own to turn the
unicode strings returned from those into utf-8 bytest
hugo wrote:
I think that Django should support(use only) python unicode strings.
Since the work needed would be a bit involved (not the actual work, I
think, but finding and fixing all relevant places), I set up a wiki
page to collect places and procedures regarding unicodefication.
I think
100 matches
Mail list logo
