Hi all,I've just submitted the second piece of the testing system puzzle; a mechanism for testing the context and templates that are produced in response to a URL. A patch and a more detailed commentary are attached to the ticket. The cliff notes version is that:
---b = Browser()response = b.get('
Malcolm Tredinnick wrote:
>
> That is also possible, but I was trying to avoid another reliance on the
> backend (things like "sqlall" start to get complex). Still, it's
> probably only a single proxy function call, so not too hard to maintain.
>
> I'm sure if I keep coming up with bad implementa
On Thu, 2006-07-20 at 02:25 +, DavidA wrote:
>
> Malcolm Tredinnick wrote:
> > I was trying to avoid a hash-based solution because it leads to
> > unreadable names (and I don't think every database supports unnamed
> > constraints, so that isn't a universal solution, either). I need to do a
>
Is xml_escaped just too verbose? Seems very descriptive and unambiguous.
Todd
On Jul 19, 2006, at 4:56 PM, SmileyChris wrote:
>
>> 'escape' and 'safe' have a different meaning for fireworkers, too ;-)
> Or bank robbers :-P
>
> Back on topic, I like finalization too (even though I cringe having
Malcolm Tredinnick wrote:
> I was trying to avoid a hash-based solution because it leads to
> unreadable names (and I don't think every database supports unnamed
> constraints, so that isn't a universal solution, either). I need to do a
> bit of research and them come up with a legal hash constru
On Thu, 2006-07-20 at 00:39 +, DavidA wrote:
>
> Malcolm Tredinnick wrote:
> > On Wed, 2006-07-19 at 11:24 +, DavidA wrote:
> > > MySQL requires each constraint to have the same name.
> >
> > I'm pretty sure you meant to say "different name" there. :-)
>
> Oops. I guess that's what the "
I got sick of waiting so attempted it myself.
http://code.djangoproject.com/ticket/61
It all works for me, the only thing it needs is some tests and work on
the "rel" stuff (which is used if it's used with edit_inline I think?).
But it is a complete working patch, feel free to test it out / submi
Malcolm Tredinnick wrote:
> On Wed, 2006-07-19 at 11:24 +, DavidA wrote:
> > MySQL requires each constraint to have the same name.
>
> I'm pretty sure you meant to say "different name" there. :-)
Oops. I guess that's what the "preview" button is for.
> The problem should be fixed in r3373
Hi,
I would like to use Django with MS-SQL server and the svn version
doesn't work yet.
I submitted a patch to make it work:
http://code.djangoproject.com/ticket/2358
It's not ideal, just a quick fix until I get a better understanding of
Django internals.
What is missing right now is LIMIT/OFFSE
Hi Chris,
Am 19.07.2006 um 22:56 schrieb SmileyChris:
> Back on topic, I like finalization too (even though I cringe having to
> write the american Z version).
Yeah, but default TZ is Chicago, so ... I chose zee. Be glad that
you're not forced to spell 'aluminum' somwhere!
The Old Britain Emp
> 'escape' and 'safe' have a different meaning for fireworkers, too ;-)
Or bank robbers :-P
Back on topic, I like finalization too (even though I cringe having to
write the american Z version).
--~--~-~--~~~---~--~~
You received this message because you are subsc
2006/7/19, Simon Willison <[EMAIL PROTECTED]>:
>
>
> On 19 Jul 2006, at 15:43, David Larlet wrote:
>
> > I'd like to know if it's possible to have access to django slides of
> > Simon's conf at Europython 2006.
>
> I've uploaded my slides to the conference site:
>
> http://indico.cern.ch/contribut
Simon Willison wrote:
> I don't see any harm in META using unicode strings, whereas
> if it were to use bytestrings our documentation ends up being that
> little bit more confusing (we can't just claim everything is a
> unicode string).
We can't do it anyway. First example is "raw_post_data
now i'm on my django site
https://example.org/
if I type https://example.org/admin it redirects to http://example.org/admin/
(note the change from https to http)
is this an expected behaviour?
Thanx
--~--~-~--~~~---~--~~
You received this message because you are
I know you guys have discussed the problems with binary data in the
ORM. But I have never seen a very comprehensive explanation of why this
is so bad. I have 3million binary images in my current postgres cluster
and it works quite well.
I would love to use the ORM for managing some of these table
On 19 Jul 2006, at 15:43, David Larlet wrote:
> I'd like to know if it's possible to have access to django slides of
> Simon's conf at Europython 2006.
I've uploaded my slides to the conference site:
http://indico.cern.ch/contributionDisplay.py?
contribId=26&sessionId=9&confId=44
They're a 2
On 19 Jul 2006, at 15:30, Ivan Sagalaev wrote:
> I just thought that may be they shouldn't. If META is a reflection of
> CGI's environment that is derived from HTTP environment that is
> essentially in byte strings then I think META being unicode is may be
> useless and misleading.
>
> Instead t
On 7/19/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> these days it seems quite impossible. "Craziness and mundane
> questions" wasn't supposed to hold any pejorative. Sorry if I have
> offended.
I think "crazies and retards" was more offensive. I also think that
'mundane' could be better
Yeah, and I certainly never meant for #django-devel to be in any way
"elite" or a replacement for #django. I've just noticed that in the
older days we could talk about more meta-django related things whereas
these days it seems quite impossible. "Craziness and mundane
questions" wasn't supposed
Hi!
I'd like to know if it's possible to have access to django slides of
Simon's conf at Europython 2006. Maybe I haven't found those but there
are not listed on the official page:
http://indico.cern.ch/sessionDisplay.py?sessionId=9&confId=44
Cheers,
David Larlet
--~--~-~--~~--
Simon Willison wrote:
> request.META should contain unicode strings that directly reflect the
> underlying raw bytestrings
I just thought that may be they shouldn't. If META is a reflection of
CGI's environment that is derived from HTTP environment that is
essentially in byte strings then I t
On 19 Jul 2006, at 14:37, Gábor Farkas wrote:
> 1. request.META should contain raw bytestrings (like it's currently)
> 2. request.META should contain unicode strings. for QUERY_STRING, we
> should convert it to unicode using the 'ascii' charset. and we should
> not url-decode it.
request.META s
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
Simon Willison wrote:
> We shouldn't be decoding QUERY_STRING in request.META at all - we
> should leave it as urlencoded ASCII. request.META is meant to give
> you access to the 'raw data' from the browser.
>
> We do however need to take charset stuff in to account when creating
> the requ
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
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 encoding as
> the
> page from where t
jeremy bornstein wrote:
> In some circles, "finalization" is what happens to an object immediately
> before it is GC'd, so this choice may end up being confusing. This is
> the case with respect to Java, for example.
Doesn't keep me from liking it, and Java is not python. Probably
each and eve
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 the encoding matters. As fas as I
On Wed, 2006-07-19 at 11:24 +, DavidA wrote:
>
> Alexis Smirnov wrote:
> > ALTER TABLE `console_restoreevent` ADD CONSTRAINT
> > `identity_id_referencing_console_identity_id` FOREIGN KEY (`identity_i
> > d`) REFERENCES `console_identity` (`id`);
> > ALTER TABLE `console_backupevent` ADD CONST
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?
>>
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?
>
> 1.a: if yes, how? some thin
Alexis Smirnov wrote:
> ALTER TABLE `console_restoreevent` ADD CONSTRAINT
> `identity_id_referencing_console_identity_id` FOREIGN KEY (`identity_i
> d`) REFERENCES `console_identity` (`id`);
> ALTER TABLE `console_backupevent` ADD CONSTRAINT
> `identity_id_referencing_console_identity_id` FOREIGN
On 18 Jul 2006, at 23:30, gabor wrote:
> 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?
>
> 1.a: if yes,
On Wed, 2006-07-19 at 00:30 +0200, 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
Gábor Farkas wrote:
> i somehow have the feeling that we lost the original idea here a little.
>
> (as far as i understand, by urlify.js we are talking about slug
> auto-generation, please correct me if i'm wrong).
>
> we are auto-generating slugs when it "makes sense". for example, for
> eng
Although it is an old problem and perhaps some of you already have
ways to solve it, I have noticed the same problem just a few hours ago
too, and I would like to share with a couple of solutions for that.
1. Use ForeignKey for ONE TO ONE relationship:
user = models.ForeignKey(User, unique=True,
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.
>>
>
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.
>
> def slug_ja(word) :
> try
On 19-Jul-06, at 12:33 PM, Malcolm Tredinnick wrote:
>
> On Wed, 2006-07-19 at 12:08 +0530, Kenneth Gonsalves wrote:
>>
>> On 19-Jul-06, at 11:46 AM, Brantley Harris wrote:
>>
>>> You keep #django open too and answer questions in there. Therefore
>>> they have no reason to enter #django-devel.
On Wed, 2006-07-19 at 12:08 +0530, Kenneth Gonsalves wrote:
>
> On 19-Jul-06, at 11:46 AM, Brantley Harris wrote:
>
> > You keep #django open too and answer questions in there. Therefore
> > they have no reason to enter #django-devel.
>
> dream on - you can never escape crazies and retards
Ca
40 matches
Mail list logo
