Free international calls to anywhere in the world just for click
http://www.freewebs.com/msmani007/freephonecalls.htm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
On Fri, 2007-03-30 at 21:03 -0700, Simon G. wrote:
> Hi Malcolm,
>
> Should ALL the strings in these be unicode objects, even if they don't
> have any extended characters? I'm looking at the already checked in fr
> localflavor, and these are all ASCII with the respective file set to
> UTF-8 with
On Sat, 2007-03-31 at 12:19 +0800, Russell Keith-Magee wrote:
> On 3/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, 2007-03-31 at 10:59 +0800, Russell Keith-Magee wrote:
> > [...]
> > > 1) Is there a valid use case out there for the default 'leave 1 space'
> > > behaviour tha
On 3/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-03-31 at 10:59 +0800, Russell Keith-Magee wrote:
> [...]
> > 1) Is there a valid use case out there for the default 'leave 1 space'
> > behaviour that I am missing?
>
> Readability of the generated source is not to be sneez
On 3/30/07, Simon G. <[EMAIL PROTECTED]> wrote:
...
> UTF-8 with that -*- thing (what is that called?), there's also a
http://docs.python.org/ref/encodings.html
Encoding declaration.
(Incidentally, the process of parsing the file given the declaration
is given pretty clearly there, too. Good to
Hi Malcolm,
Should ALL the strings in these be unicode objects, even if they don't
have any extended characters? I'm looking at the already checked in fr
localflavor, and these are all ASCII with the respective file set to
UTF-8 with that -*- thing (what is that called?), there's also a
Brazilian
Hey Russ --
I'm +0 on spaceless actually being spaceless; -0 on keeping a single
space as an option, -1 on one space being default or allowing an
arbitrary number of spaces.
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
I've had a first pass at documenting these in #3883 - any comments?
http://code.djangoproject.com/ticket/3883
--Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this grou
On Sat, 2007-03-31 at 10:59 +0800, Russell Keith-Magee wrote:
[...]
> 1) Is there a valid use case out there for the default 'leave 1 space'
> behaviour that I am missing?
Readability of the generated source is not to be sneezed at. Using the
spaceless tag, you can have a nicely laid out template
Hi all,
This discussion is about _very_ trivial change, but it would break
backwards compatibility, so I want to get some consensus before I
commit anything.
Ticket #3532 ( http://code.django.project.com/tickets/3532 ) discusses
the spaceless templatetag. In particular, there has been a request
Hi Nicolas,
On Fri, 2007-03-30 at 14:53 +, Nicolas E. Lara G. wrote:
> That is true, there are always cases where name will collide but the
> disambiguation allows users a little more flexibility. I'm not saying
> it will avoid all collisions but it is a simple extension that will
> help most
Hoi,
On Mar 29, 9:07 am, "Mir Nazim" <[EMAIL PROTECTED]> wrote:
> Now can anybody tell me about the status of Django's SQLAlchemy
> branch. I could not find any place describing the status on
> code.djangoproject.com.
Looks like it's pretty dead. Very sad. SQLAlchemy is kicking-ass,
especially
Hoi,
I filed this ticket (http://code.djangoproject.com/ticket/3734) some
time ago and it's still marked as "Design decision needed" :). Now i
added a patch and it works for me. I don't see any disadvantages in it
so i hope someone can apply that patch. If not I would love to read
comments about
On 3/30/07, Gulopine <[EMAIL PROTECTED]> wrote:
> So once it's ready, would I create a ticket to make that proposal, or
> just suggest it here?
Here, probably. The ticket system is good for relatively
uncontroversial changes, but new contrib apps might be controversial,
so it's best to put it her
On Mar 30, 11:02 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> It seems a general consensus is forming over handling this sorts of
> "contributed" subframeworks: create them as third-party projects -- I
> highly recommend Google's code hosting athttp://code.google.com/--
> develop them sepa
On 3/30/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>
> The code is not online (yet). I plan to, but will need to wait for the HP
> acquisition to settle down first...
>
Thanks for your patience with my pestering. :) I know you have
bigger fish to fry just now.
--~--~-~--~~
On 3/30/07, Gulopine <[EMAIL PROTECTED]> wrote:
> On the flipside, this certainly qualifies as "non-trivial", so does it
> need thorough discussion on this list before submitting a ticket? I'm
> not sure on this one, since it doesn't modify any existing Django
> code. I plan on bringing it up here
That is true, there are always cases where name will collide but the
disambiguation allows users a little more flexibility. I'm not saying
it will avoid all collisions but it is a simple extension that will
help most users (specially if you've already made your apps and views
and when writing temp
In working on my first major Django project, I've developed a few
subframeworks for Django that are greatly enhancing the project, and I
think many others would get good use out of them. Unlike my only thus-
far submitted app, however, these are considerably complex. In
addition to models.py, one
The code is not online (yet). I plan to, but will need to wait for the
HP acquisition to settle down first...
--Ned.
Jeremy Dunck wrote:
> On 3/30/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>
>> It wasn't a formal presentation. I was showing Tabblo during the Django
>> app demo session,
On 3/30/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>
> It wasn't a formal presentation. I was showing Tabblo during the Django
> app demo session, and Adrian noticed that my dev server was spewing more
> info than typical.
Yeah, I figured it was the app demo. I was asking if the middleware
It wasn't a formal presentation. I was showing Tabblo during the Django
app demo session, and Adrian noticed that my dev server was spewing more
info than typical.
--Ned.
Jeremy Dunck wrote:
> On 3/30/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>
>> At Pycon, when I showed
>> my tracing m
Hi xav --
Please direct questions of this nature to django-users; django-dev is
used to discuss the development of Django itself, not to answer usage
questions.
Thanks!
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
On 3/30/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> At Pycon, when I showed
> my tracing middleware, I got the distinct feeling that its seven new
> settings were a no-no.
I guess I missed that pres. Is it available online somewhere?
--~--~-~--~~~---~--~~
You
On 30 mar, 14:15, Gábor Farkas <[EMAIL PROTECTED]> wrote:
> what is the output of running "locale" in a console?
gabor,
Your are right ! I remaoved my DEFAULT_CHARSET = 'iso8859-15' from my
settings. Created a view to render a newform created form and
everything is working find. So this is du
Hello,
> what is the output of running "locale" in a console?
# locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_F
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.
>
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 cluttering the settings
with individu
adding
DEFAULT_CHARSET = 'iso8859-15'
to my settings.py solves this issue.
I'm wondering how to have a complete UTF-8 system :)
anyway thanks all for your investigations.
xav
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goog
Hi Everyone
I've posted this to the django-users list, though I realize now that
this is probably better suited for the developers list, since I am
more providing information about the behaviour of the Django Admin and
unicode than asking for help. Any help forhtcoming would be greatly
appreciate
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.
I'm running 0.96 and m
On Fri, 2007-03-30 at 01:52 -0700, xgdlm wrote:
> Hello All,
>
> Django brings me to python ... so I'm not a python specialist. I wish
> I could you the newforms library and get rid of the oldforms in my
> django projects. But I can't use newforms with French language. I read
> a lot of problems
A BIG +1 for me
On 29 mar, 16:34, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 3/29/07, Ted <[EMAIL PROTECTED]> wrote:
>
> > Were I work we have had to do this very thing to support I18N in our
> > forms. Something as simple as a ":" is not a given. Maybe I want a
> > " :" instead? This could
Hello All,
Django brings me to python ... so I'm not a python specialist. I wish
I could you the newforms library and get rid of the oldforms in my
django projects. But I can't use newforms with French language. I read
a lot of problems with unicode strings and special caracters. But I
couldn't r
Hi Ville,
On Fri, 2007-03-30 at 01:09 -0700, Ville Säävuori wrote:
> I'm the author of the Finnish localflavor, #3847.
>
> > So could triagers please mark tickets with such strings as needing an
> > improved patch and could original developers of these files please
> > include any strings contai
I'm the author of the Finnish localflavor, #3847.
> So could triagers please mark tickets with such strings as needing an
> improved patch and could original developers of these files please
> include any strings containing non-ASCII characters in as u"..."
> strings, not traditional strings.
I
37 matches
Mail list logo