on't understand, is: why is this an issue? can't we assume
that the developer knows the encoding of his own files? and if he knows
them, he should be able to easily recode them to utf-8, for example.
i'm personally for the one-encoding
m also +1000 for this change. switching to full unicode is a lot
less risky than trying to make the unicode-newforms-with-bytecode-django
chimera work correctly.
so, if the unification process starts, i'm also eager to help with it.
let's hope Malcolm "branch" will work until
d_admin = True to the model's field, but
now i do not know how it should be handled...i realize that the
new-admin is probably using the newforms... and i do not know how
raw_id_admin is handled there
gabor
--~--~-~--~~~---~--~~
You received this message
validate a model instance, that is not built from
from-data using a view, but using it's constructor in python-code?
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
to work on it
, patches were created, so i think the unicode-conversion could happen
in a reasonable time.
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to t
mes other
> databases are using the encoding specified by DEFAULT_CHARSET.
>
> Does anybody have comments on that patch before I commit it?
>
+1
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&quo
emplates
but this would mean that we have to "unicode-interpret" the template,
and i don't think that will happen before django goes completely unicode.
so, imho your best way of action is to strip the BOM from your templates
gabor
--~--~-~--~~~---~--~-
Adrian Holovaty wrote:
> On 12/1/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>> what about the following change?:
>>> if not isinstance(output, basestring):
>>> -return str(output)
>>> +try:
>>> +return str(output)
>>> +except UnicodeEnc
> class UniInput(Form):
> text = CharField(max_length = 200)
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 it's a p
; This is a problem reported in bug #305. I am using the work-around
> provided in that report to encode unicode strings to utf-8, but it seems
> inelegant.
>
> I've installed psycopg2, as I believe this does not suffer from this
> issue. However I cannot find a straightf
e an unique SlugField. a SlugField implies db_index, so:
1. postgres automatically creates an index, because the field is unique
2. afterwards, django also creates an index, because db_index was specified.
ps: of course, it might happen for entirely different reasons in oracle,
i haven't te
Adrian Holovaty wrote:
> On 11/16/06, gabor <[EMAIL PROTECTED]> wrote:
>> - what is the plan, how should incoming data (GET or POST) handled?
>> some possibilities:
>> [...]
>> - we assume it's DEFAULT_CHARSET. we do not failover (means that if that
>>
not fail)
so, which direction should be taken?
gabor
--~--~-~--~~~---~--~~
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 unsubscri
the "workaround" is simple. simply remove the
db_index=True.
but it's not that simple always.
for example imagine an unique SlugField. in that case the only possible
fix is to manually delete the redundant index from the db.
gabor
--~--~-~--~~~---~--~--
sure that the
documentation of the branch is up-to-date, so that it's clear if it's is
testing-ready or not, and what it does offer.
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
James Bennett wrote:
> On 10/16/06, gabor <[EMAIL PROTECTED]> wrote:
>> would you use something in the db? (from what i know about transactions
>> (very little :), they "solve" the potential conflicts by simply
>> reporting an error-condition to one of the
hing completely different? a
temporary lock-file in a temp-directory perhaps?
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
Thomas Steinacher wrote:
> gabor wrote:
>> Thomas Steinacher wrote:
>>> I already included
>>> "django.middleware.transaction.TransactionMiddleware" in my
>>> MIDDLEWARE_CLASSES (as described on
>>> http://www.djangoproject.com/document
Thomas Steinacher wrote:
> On Oct 16, 2006, at 8:46 PM, gabor wrote:
>>> What, if two Django processes transfer money from account A to account
>>> B simultaneously?
>> these situations are (afaik) handled using transactionssimply start
>> a transaction at t
these situations are (afaik) handled using transactionssimply start
a transaction at the beginning, and commit/rollback at the end...
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django devel
r one, for the sake
> of everybody's sanity.
hi,
+1
btw. i'm slowly (VERY slowly :) working on the unicodification
(currently on the template system), so it is not halted (just very slow :)
gabor
--~--~-~--~~~---~--~~
You received this message because you are
the user's input was ""
wouldn't it be better to represent this in html as a checkbox+an input
field?
and by default have the checkbox unselected, and the input-field disabled.
and then if the user checks the checkbox, enable the field.
and then in the view code, simply che
Malcolm Tredinnick wrote:
>
> [I'm a leading advocate for the "give Gabor a unicode branch in svn"
> school, btw, so that you and he and others can go nuts and just do it.]
>
+1 :-)
gabor
--~--~-~--~~~---~--~~
You received t
s do not validate their input.
you will have to use a manipulator (Name.AddManipulator) to validate
your input (and then save the object).
making the models validation-aware is planned, but not done yet.
gabor
--~--~-~--~~~---~--~~
You received this message bec
said, if you keep everything in UTF8, you should be fine
(in fact, theoretically you could use any other unicode-complete charset
(like utf-16 or utf-32), but utf8 is basically the ideal one in nearly
all the cases).
gabor
--~--~-~--~~~---~--~~
You received this
nteract
with django
please don't take this wrong, i very much welcome this django/sqlalchemy
integration... i'm just curious how exactly would it work... how will i
be able to go "deeper" (from django-level into sqlalchemy level) when
needed...
or ...well..maybe
... a "yes, we'll do it, but
haven't found the time to create the branch yet, wait a little" answer
is enough :)
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
JP wrote:
> Also, exceptions are very
> expensive,
while this is true in java or c++, it is not necessarily true in python.
even python itself uses exceptions for example when doing a for-loop
over an iterable (the iterator's next() method raises StopIteration when
it's at
> need pools (definition 2) to help it scale better in some environments
> and to reduce request startup time.
>
hmmm..so am i correct when i say, that in a non-multithreaded web-app
definition-2-pools are not needed/ do not help?
gabor
--~--~-~--~~~---~--~---
Adrian Holovaty wrote:
> On 8/8/06, gabor <[EMAIL PROTECTED]> wrote:
>> i think unicodizing django can be done in 4 easily separated steps/parts:
>>
>> 1. request/response
>> 2. templating-system
>> 3. database-system
>> 4. "overall u
ake it possible to have a system with mixed charsets?
(well, maybe having a different DB_CHARSET and a DEFAULT_CHARSET could
work. maybe)
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&qu
st somewhere of what people
> need to do to port existing applications across to using this
> functionality. Ideally, the answer would be "not much" and we can cast
> from the default encoding to unicode internally where necessary. But I'm
> sure there will be some changes r
Ivan Sagalaev wrote:
> First of all, Gabor, thank you very much for doing this!
>
thanks :)
> gabor wrote:
>> today i experimented a little with the django source code,
>> and here are the results.
>>
>> if you apply a very small patch (65lines, attached), you
be a more coordinated
approach would be better?
because the actual conversion is not that hard. it's just that it
touches a lot of parts... so it's not too deep, but very wide :-)
gabor
--~--~-~--~~~---~--~~
You received this message because you are
ld do what the current spaceless-tag does.
what do you think?
gabor
--~--~-~--~~~---~--~~
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@googleg
uld we
un-escape the strings that we match in the urlconf (means the strings
that then are sent to the view as parameters).
i hope with these questions i can start some kind of a discussion to
better specify what we want from this unicode-conversi
e widely used hepburn transliteration? Or perhaps even nippon-shiki
> if you feel like sticking to strictness.
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-transliter
Jay Parlar wrote:
> On 6/17/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
>> On 6/17/06, gabor <[EMAIL PROTECTED]> wrote:
>>> could you post your model and the relevant part of the view code?
>>>
>
> The relevant model:
>
> class Product(m
reliant on your project name and
> can create portable apps.
could you please try what i described here:
http://tinyurl.com/kkpgw
for me it still fails :-(
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
base, it will not
find anything.
if you repeat this example in postgresql, it works.
so it seems to be a bug with sqlite3... will dig around a little more.
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&quo
Jay Parlar wrote:
> On 6/16/06, gabor <[EMAIL PROTECTED]> wrote:
>> Jay Parlar wrote:
>> currently you have to use manipulators, if you want to validate the data
>> that enters your models, see
>> http://www.djangoproject.com/documentation/forms/
>>
>>
entation/forms/
later, when validation-aware models will be implemented, this validation
step will happen in the model itself.
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
(people do forget):
a block level tag will not help. people will forget to use them the same
way they forget to use the 'escape' filter.
my guess is (b)
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google G
al" validation.
why do they behave differently?
or, better question:
what's the recommended approach:
add validators to the field's validator_list, or remove those and do an
explicit validation in the validate() method?
gabor
--~--~-~--~~~---~--~---
validation.
why do they behave differently?
or, better question:
what's the recommended approach:
add validators to the field's validator_list, or remove those and do an
explicit validation in the validate() method?
gabor
--~--~-~--~~~---~--~~
You rece
Adrian Holovaty wrote:
> On 6/7/06, gabor <[EMAIL PROTECTED]> wrote:
>> so now the decisions are already done, and when all the fields will have
>> the necessare to_python (+validate) methods, then save will be changed
>> to call validate, and the task is done?
>>
have
the necessare to_python (+validate) methods, then save will be changed
to call validate, and the task is done?
or still some decisions have to be done first?
i'm simply asking whether patches should be sent in for the remaining
fields?
thanks,
Adrian Holovaty wrote:
> On 6/5/06, gabor <[EMAIL PROTECTED]> wrote:
>> i'm building a https site, and have many times problems with the Site
>> objects, which kind-of assume that the site is http.
>>
>> would it be a good idea for the site objects to also
post
(http://tinyurl.com/qm6ny), but i thought that maybe it would make sense
to mention it (also) in a separate mail.
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To pos
Adrian Holovaty wrote:
> On 6/1/06, gabor <[EMAIL PROTECTED]> wrote:
>> any chance of this patch getting applied?
>> http://code.djangoproject.com/ticket/1857
>>
>> it fixes the problem (bug?) that get_next_by_FIELD and
>> get_previous_by_FIELD don'
this patch getting applied?
http://code.djangoproject.com/ticket/1857
it fixes the problem (bug?) that get_next_by_FIELD and
get_previous_by_FIELD don't take params.
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
Ivan Sagalaev wrote:
> gabor wrote:
>
>> i'm also willing to help with this task... but..do i understand this
>> correctly, that it's agreed that django is going to switch to unicode?
>>
>>
> Being one of the proponent of the all-unicode way back wh
Jeroen Ruigrok van der Werven wrote:
> On 5/29/06, gabor <[EMAIL PROTECTED]> wrote:>
>> but then, to have a nice unicode-integration in django, we'd
>> need to convert EVERYTHING to unicode..httpRequest, httpResponse etc.
>> (as at http://code.djangoproject.co
Jeroen Ruigrok van der Werven wrote:
> On 5/29/06, gabor <[EMAIL PROTECTED]> wrote:
>> it works fine in all the cases...
>
> At least that's good news. I just wonder if it means that psycopg is a
> dead-end for dealing with Unicode and psycopg2 should be the preferre
Jeroen Ruigrok van der Werven wrote:
> On 5/28/06, gabor <[EMAIL PROTECTED]> wrote:
>> further debugging showed, that psycopg is at fault, because it quotes
>> byte-string params, but not unicode-string params.
>>
>> also, take an unicode string, like u"gáb
you think about such approach?
p.s: of course it's quite possible that i simply overlooked a
DO_WHAT_GABOR_NEEDS setting in settings.py, so if that's the case,
please tell me :-)
thanks,
gabor
--~--~-~--~~~---~--~~
You received this message becaus
protocol? or just a boolean to be able to differentiate between
http/https. what do you think about such idea?
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post t
rge from
http://code.djangoproject.com/changeset/2392,
which is based on the following discussion:
http://tinyurl.com/sxlcp
so it was a performance (cleanness) optimalization for queryset.get().
it makes sense in the get() case, because get() can be only used if the
queryset only contains one item.
b
shell, or "standalone" python script) situations. in "normal" view code
i can use this import without problems.
anyway, it's not such a big problem as such. the problem i think is that
it can lead to confusing situations (the "non-reverse" lookups work fine
re if i'm doing something stupid here, or this is a bug.
thanks,
gabor
--~--~-~--~~~---~--~~
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
and in firefox will show
http://www.example.com/g%C3%A1bor
(unless you switch that setting)
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
can imagine that some people want to
restrict to that.
p.s: to make sure we understand each other. i understand the need for
being able to create non-english links/urls. i'm just not sure if a Slug
is the best place for it.
p.s.2: btw. are non-english URLs common/widespread nowadays?
ga
at all? why
don't allow all the unicode characters?
i'm pretty sure i'm missing something there... :-(
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gro
. With every hit I'm
getting another entry in the process table
"
so if he's only hit by the reuse-open-connection effect, it should be
pretty easy to reproduce:
setup apache with maxclients = 3, and do more than 3 requests.
if the number of open psql connections stays 3, eve
ng, which is for now quite simple (6-7
models, functionality is mostly only the default admin-stuff provided by
django), which will be probably released next month. so i am waiting if
i'll be able to change it to magic-removal :)
gabor
--~--~-~--~~~---~--~~
Yo
,
gabor
--~--~-~--~~~---~--~~
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
just like before.
yes, i agree.
the only problem for me is:
is the string-to-date auto-conversion a *critical* validation-part?
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developer
Max Battcher wrote:
> Authentication/Authorization really doesn't belong in every view. That
> way leads to bad coupling and lots of repetition.
please note, that even with the current auth-system, you have to handle
it in every v
words are common enough that a field dedicated for
them would be necessary.
gabor
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-devel
first de-html-escape the content.
i understand that it seems silly for this configuration. i only wanted
to demonstrate that even with auto-html-escaping you can still use those
markups fine.
gabor
--~--~-~--~~~---~--~~
You received this message because y
Max Battcher wrote:
> gabor wrote:
>> i actually got around this problem by adding the project-dir to the
>> PYTHONPATH, but it seems a little as a hack...
>
> I'd have to disagree. I don't think it's a hack at all, as far as I'm
> concerne
.polls.views". so if later i want to use this application in a
different project, i will have to change the urlconf in the application.
wouldn't it be better if i could simply say "polls.views.detail", or
"views.detail" ?
are there any other ways to do this?
o
of magic-removal :(
gabor
--~--~-~--~~~---~--~~
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 ema
73 matches
Mail list logo
