gabor wrote:
> 3. will assume the database is in DEFAULT_CHARSET
> - maybe can we somehow ask the db for it's charset?
>
> so, what do you think?
> or should we make it possible to have a system with mixed charsets?
> (well, maybe having a different DB_CHARSET and a DEFAULT_CHARSET could
olive wrote:
> Graham Dumpleton August 17, 2006 at 11:59 p.m.
>
> You really need to provide an explanation of why the worker MPM cannot
> be used and the prefork MPM must be used.
Uhm... I would not say that it 'cannot' be used. It can (after some long
time ago threading issues with db connec
[EMAIL PROTECTED] wrote:
> http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_code_cleanup_review.diff
One thing I disagree with is that streaming on disk is done
unconditionally. This is very good for files the size of tens of
megabytes bu
SmileyChris wrote:
> On a side note, most people just want access to media_url, so I
> actually would be happy with just
> http://code.djangoproject.com/ticket/2532. Every web site wanting to
> use static CSS will need to access this variable somehow, won't they?
No, I asked my two sites and they
Malcolm Tredinnick wrote:
> Metaphorically cutting off both our arms so that we appear
> more aerodynamic is probably not a gain worth making.
This is the explanation! :-)
>> 5. Internally, work with unicode strings exclusively (after
>> transcoding the request and the template). Response shou
SmileyChris wrote:
> But Ivan, you need to access the STYLE_URL setting. Having access to
> settings via SafeSettings could be useful still, right?
Not much. Adding couple of needed settings in my own project's context
processor (which I already have anyway) is not a big deal. S
[EMAIL PROTECTED] wrote:
> For example, if I wanted to build a malling application, I have to
> display the email address each time an email is sent, say every 2 sec.
> Processing can be quite long, so I cannot accumulate the output and
> return the HttpResponse at the end, because the connecti
JP wrote:
> Looking back over the multi-db branch today, I realized that it seems
> to be duplicating the thread locality of connections. The connection
> management classes in multi-db django.db manage all connections as
> thread local, and the DatabaseWrapper classes in the backends are all
> su
JP wrote:
> Not a dumb question at all. I'll try to explain better by contrasting
> how multi-db handles connections with how connections are kept thread
> local in trunk.
BTW, I happen to know how it works now since I was among those who was
trying to solve threading issues before Eugene Lazutk
Kevin Menard wrote:
> I've experienced the exact opposite. When I can say in a config file
> that I want 10 connections in a pool, that's a lot easier for me than
> setting up an external utility.
In my experience such simple behavior is rarely needed. When you
actually need a pool it means tha
Dan Watson wrote:
> Ideally, it seems django should offer simple connection pooling with 2
> options: number of connections and an on/off switch. That would satisfy
> the needs of some/most, and for those that need something more robust,
> look into an external pooler.
In your words this looks us
Brantley Harris wrote:
> Maybe it's a philosophic question, but I see it best
> defined in the "model" space because then it provides a modular
> process for views to leverage.
Manipulators can (and do) serve not only as model savers. They can
authorize, register, send mail etc. Manipulator is j
Dan Watson wrote:
> Actually that was one of my favorite pieces. I think it captures what's
> going on in a very intuitive way: try to create/update, if that fails,
> redisplay with errors.
I think the piece on which I agree with JP is that a _form_ serving as
an exception is counter-intuitive.
James Bennett wrote:
> I'm not so sure about that. The form itself was the thing that was
> "bad" and needs to be dealt with, so why *shouldn't* it be the
> exception?
It just feels right to me... When you're opening a file and you, say,
don't have permission you get OSError, not this "bad" file
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 selected with 'follow'. And it seems to me like it should be
this wa
Gábor Farkas wrote:
> is there a way to filter with the "follow"?
> for me it seems you can enable/disable certain fields...
>
> and that does not help with the AddManipulator, because then those
> fields are not even saved...
I mean when you're creating a manipulator you can list fields that y
crankycoder wrote:
> I really *really* need to be able to save and load unicode data in a
> non-painful way. I have to support at least English, Vietnamese, Thai
> and a half dozen other scripts.
Why can't you use utf-8 for this? I support a two-language site
(Russian, English) with psycopg1 an
I've just found out that request.user is an attribute of request's class
not of an instance. Which means that in the environment with multiple
requests (threaded or not) every request.user always points to a single
LazyUser instance which is obviously a bad thing. What was the reason
for this
Joseph Kocherhans wrote:
> Hmm... looking into this more, Ivan was right... kind of (and maybe
> this is what he meant, but it's not how I read it, sorry if I
> misunderstood).
Or it's rather me being a bit sloppy explaining... I saw the __get__
thing but I know how it works
Jacob Kaplan-Moss wrote:
> Out of curiosity, did you consider having a single ``Form`` object
> that may be bound or unbound? It seems like most of ``BoundForm``
> simply delegates down to the enclosed ``Form``, so perhaps ``Form.bind
> ()`` should store the data internally and just behave di
Adrian Holovaty wrote:
> The template would look like this:
>
>
> {% if form.sendername.errors %}{{ form.sendername.errors.as_ul }}{% endif
> %}
> Your name: {{ form.sendername.as_text }}
Does this 'as_text' mean that template will be the only place where an
actual form control
Adrian Holovaty wrote:
> Similarly, how would is_valid() and errors() work? If is_valid() or
> errors() get passed kwargs, does the form instance automatically
> become a BoundForm? What if it's already been bound? Do the kwargs
> replace any existing bound data?
I think with just one Form class
Joseph Kocherhans wrote:
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the validation and probably populates form.errors or .errors() or
> whatever. bind returns True or False depending on whether validation
> succeeded or not. bind does not short circuit on the first e
A bit of discussion in Track has reminded me of one thing that I wanted
to write long ago. So I decided not to spam any tickets and write it here.
There are tickets that appear from time to time that deal with
unicode-related issues in various places. The problem is that patches
are rejected w
Deryck Hodge wrote:
> Don't take my comment on the one ticket (#2727) as dev's rejecting the
> patch.
I don't :-). It really just has reminded me of this thing I wanted to
write long ago but forgot...
--~--~-~--~~~---~--~~
You received this message because you ar
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 :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goog
Afternoon wrote:
> I disagree. For background, I have a context processor which simply
> pushes a dictionary of standard items, such as URLBASE for media and
> links, to all templates. It's very unlikely that an error will have
> occurred which makes this a bad thing to do.
Other people may have
Max Derkachev wrote:
> There were a lot of words about unicodification of Django, but things
> has not been moved a bit further.
Or at least it would be nice to hear from someone of the core team why
it can't be done (either right now or at all). I remember Jacob (I
think) has said once along t
Adrian Holovaty wrote:
> I'm very interested in getting this done, but we've got quite a few
> branches open at the moment. I think we should focus on merging at
> least one of these branches before opening another one, for the sake
> of everybody's sanity.
Thanks, Adrian! This is clear now :-).
James Bennett wrote:
> I would like to see examples of this; I have a pretty comprehensive
> set of ego searches and tag subscriptions for Django-related postings,
> and I don't get the "Django is closed, don't bother trying to get
> involved" vibe as much as you apparently do.
Smart people don't
Michael Radziej wrote:
> I like Django, perhaps I rather contribute
> more tiny stuff of which I feel that it will get integrated, and I have
> my own patchset for Django. So what? It works fine for me. Why should I
> turn to a different framework when I like the concept and code (and the
> docs!)
orestis wrote:
> ProgrammingError: ERROR: current transaction is aborted, commands
> ignored until end of transaction block
>
> SET TIME ZONE 'Europe/Athens'
> }}}
>
> I have tried issuing the statement SET TIME ZONE 'Europe/Athens' using
> psql and it runs fine. So, it seems that the problem i
orestis wrote:
> I wonder why does a cursor has to be involved for the debug page to be
> shown... I'll look into it.
Debug page shows repr()'s for many local objects for each level of the
call stack. And repr()'s of models often do some queries to show
readable representation.
--~--~-
David Blewett wrote:
>>> Actually this could be integrated into the core.
>>> When you create a model, you could add translatable=True to fields
>>> that have to be in the language-specific table.
>>> When you make selections, you would need to set the language name in
>>> the following or a simil
Ivan Sagalaev wrote:
>> What about using generic relations for this?
>
> +1. Keeping all translations in one table instead of creating separate
> tables for each user table is what I was going to propose but you beat
> me :-)
On a second thought I think it has certain proble
Jacob Kaplan-Moss wrote:
> RoR has a performance and scalability problem that FCGI makes worse,
Jacob, do you have any links to read on the subject or your own
thoughts? I'm asking because I wonder if Django running in an external
FCGI server would also scale worse then under mod_python... From
Casey Marshall wrote:
> I am faced with a situation where I really need to be able to import
> models from multiple Django projects. We have many projects that stand
> well enough alone on their own with their own supporting
> infrastructure. The projects we need to develop now need to work with
Hi!
I'm now 'having a look' at newforms upon Adrian's request.
I noticed a thing I was long forgotten to file as a ticket. So may be
it's a good time to fix it.
CheckboxSelectMultiple is in effect just an alternative representation
of . Ideally one would be able to just switch between
these
Hi!
A new Form class' default representation (that is goes out of `print f`)
is an HTML table. For those who cares about that proverbial 'semantics'
thing this looks wrong. From the practical point of view it's also not
very convenient since it (for example) doesn't allow to layout the form
i
Adrian Holovaty wrote:
> How would CheckboxSelectMultiple work otherwise, and how is the
> compatibility broken?
Consider :
John
Paul
If you select both items in a POST you'll get:
beatles=John&beatles=Paul
... which you will then nicely get as request.POST.getl
Adrian Holovaty wrote:
> I like the output,
> but I can definitely appreciate the argument for using s instead.
I would say not using tables for layout may count as a good practice
like encouraging clean URLs, proper distinction of GET and POST etc.
--~--~-~--~~~---
Adrian Holovaty wrote:
> Ah, you're talking about the *old* form system...django.newforms has a
> way of dealing with this -- check out
> CheckboxSelectMultiple.value_from_datadict(), which is automatically
> called by Form.full_clean().
Ah... I was in fact just looking at HTML and just recalle
Honza Král wrote:
> I get a ProgrammingError, the SQL command is missing quotes around the
> value in question. I worked around this using str(
> form.clean()['form_field'] ), but that doesn't strike me as very nice.
As far as I remember psycopg2 does correctly accept unicode strings. You
can ju
Brantley Harris wrote:
> Maybe good practice, but not practical. I'd love to not have to use
> tables. But practical CSS just isn't there yet.
Many web sites prove otherwise though :-)
> Yes, tables aren't
> good for general layout, but they still have their uses, and forms are
> a prime examp
James Bennett wrote:
> Now, I'm pretty picky about my markup, and I'm certainly willing to go
> to unusual lengths to get it just the way I want it, but it'd be
> awfully nice if there were some way to get HTML-style output from
> newforms without having to manually subclass all the widgets and
>
Ivan Sagalaev wrote:
>
> Since all these things happily work in browsers the only difference
> between "/>" and the rest is that it is not DTD-valid HTML 4.01.
In fact I'm wrong here... I just checked that W3C's validator doesn't
object to ""s.
James Bennett wrote:
> Yup. And in fact, I do that (quite deliberately).
Nice to meet a like-minded person :-)
> I'm just asking for a simple way to get form inputs without trailing
> slashes
As you said the problem is how to make it simple enough... What about a
middleware that seeing 'text/h
James Bennett wrote:
> Well... define "near future" ;)
When the library will be usable.
> Whenever HTML5-the-specification is finished and
> HTML5-the-cross-browser-implementation is available, then yeah,
> that'll work.
You don't have to wait for this because html5lib would work with
existing
2006/12/5, Mario <[EMAIL PROTECTED]>:
>
> Hi, I'm a Spanish native speaker from Chile. I use django in
> productions systems and I've seen the po files. Some msgid's are not
> translated and I want to help with that. Also, there's an es_AR but
> not es_CL, I'd like to help with that to :-)
>
>
Adrian Holovaty wrote:
> This is an interesting problem. That template fix would be OK by me,
> but it's sort of a hack. I think we're going to run into similar
> issues with Form.__str__() returning a Unicode object. Maybe, as you
> suggest, Form.__str__() should return a bytestring according to
> Well, we could have the 'es' translation in 100% completed first and
> then start to think in another countries. The 'es' file is about 80%
> translated so if you let me I'll do my best to translate all the file.
>
Where is this 'es' file perhaps you mean es_CL ?
> So, why we need differen
2006/12/5, mario__ <[EMAIL PROTECTED]>:
> This is my little help
> http://media.forestal.udec.cl/django/
>
Perhaps you want to use Django I18N mailing list for this kind of affairs.
Regards.
--
Iván Alemán
--~--~-~--~~~---~--~~
You received this message becaus
Adrian Holovaty wrote:
> What other sorts of things can we make abstractions for,
> given a Form?
First thing that comes to mind is the same thing you describe but
without preview. In other words it's what update_object generic view
does now but it works only on models and often it is desired t
Adrian Holovaty wrote:
> Yes, *definitely*...That one is next on the list.
I just wanted to make sure :-). I'm about to create a forum for my site
and am waiting for this bit to use it and test it :-)
--~--~-~--~~~---~--~~
You received this message because you a
> > Perhaps you want to use Django I18N mailing list for this kind of affairs.
> >
>
> Wow, I didn't know, I'm sorry. But, not should be l10n? in any case,
> where are they?
>
Look for the list on google groups.
--
Iván Alemán
--~--~-~--~~~---~--~~
You recei
Adrian Holovaty wrote:
> This would be a great addition. Rather than requiring sessions, what
> do you think of passing intermediate form data in hidden fields?
+1
It's cleaner anyway since all data accumulated in one place.
--~--~-~--~~~---~--~~
You received th
Waylan Limberg wrote:
> Presumably each page would do validation on submit (we don't want to
> send the user back to page one after completing 10 pages). If the
> validated data is now in hidden fields, couldn't someone alter that
> data (with evil intent) requiring re-validation?
Why would it be
James Bennett wrote:
> Of course, this would be a backwards-incompatible change and would
> require refactoring of Django and of any end-user applications which
> were using the messages framework
We could maintain compatibility to some extent by replacing
User.messages with some bridge object w
Jacob Kaplan-Moss wrote:
> I remember looking at that patch and not being able to quite figure out what
> it does...
The main purpose of that patch was to be able to specify a charset for
database independent of DEFAULT_CHARSET for two reasons:
- database charset is different (and can't be cha
Adrian Holovaty wrote:
> Yes, there should be a way to specify the widget for a field in the
> model. The question is, should it be specified as a keyword argument
> to the field declaration, or should it be passed in the "class Admin"?
Would it be better to specify it as and additional parameter
Darren Redmond wrote:
I could not find any way to make the Integer Field use the int8 type
without changing the django db mappings code,
I once hacked it with initial SQL that changed column type after creation:
ALTER TABLE "table" DROP COLUMN "column";
ALTER TABLE "table" ADD COLUMN
James Bennett wrote:
> 1. I've done the content-negotiation thing before, and I don't really
> want to go there again.
> 2. I don't have need of any XML-specific features, so I don't really
> have a valid reason to dump something that's been working remarkably
> well up until now.
> 3. HTML 4.01 l
Hello Django developers!
I'd like to draw some attention to ticket 2606
(http://code.djangoproject.com/ticket/2606) about exposing URL reversing
into templates. It's useful, has a patch, docs and tests. Is there
anything I should do to move it closer to be committed?
Thanks!
P.S. This might
Hello Django developers!
I'd like to draw some attention to ticket 2606
(http://code.djangoproject.com/ticket/2606) about exposing URL reversing
into templates. It's useful, has a patch, docs and tests. Is there
anything I should do to move it closer to be committed?
Thanks!
--~--~-~
simonbun wrote:
However, this solution doesn't take generic views into account, and
those are pretty hard to give up.
In fact I have some ideas how to make it but it requires some more
thinking from my side...
Anyway I'm a bit reluctant to add it to this ticket because as of now
it's very
Michael Radziej wrote:
can anyone tell me right away how the database handling works with the
threading fastcgi server? I suspect that there's one global connection
object, and then in each thread separate cursor objects created from the
global connection, which is not going to work with mysql.
Mihai Preda wrote:
> Hi,
> in the documentation (here:
> http://www.djangoproject.com/documentation/fastcgi/ ) it is written
> that the "current preferred setup" for running Django is mod_python
> (rather than FastCGI).
>
> I'd like to know why is that. Does mod_python offer some advantages,
> an
Michael Radziej wrote:
> Hi,
>
> we have a bit of chaos here ... Tickets 3370, 1356 and probably 952
> all are about this problem, all are accepted, and #3370 and #1356
> have very similar patches. I ask everybody to continue discussion
> here in django-developers, and I ask the authors of these
ak wrote:
> Ticket http://code.djangoproject.com/ticket/952 contain a complete
> solution of this problem and I don't know why it was not merged into
> the code but at the moment it is not matter and here is the reason why:
> Since newforms library was born and the decision about using unicode
> f
ak wrote:
> Could someone please explain me what was a problem with unicode support
> in oldforms so newforms have been made with unicode inside ?
I can! The thing is it has absolutely nothing to do with forms, it's
just historical coincidence.
Originally Django was written with using byte stri
Michael Radziej wrote:
> 1. Are all these tickets really about the connection encoding?
>
> 2. If so, what's the problem of using utf8 for the connection for
> everybody? I don't see how this would be a problem for anybody who is
> using a different encoding for templates, within the database's s
[EMAIL PROTECTED] wrote:
> Hi Ivan
>
> Thank you very much for making things very clear here.
I actually thought I make everyone angry with my constant bugging about
these things :-)
> Do you know which parts of django still use bytecode strings?
A better person to ask is Gábo
ak wrote:
> So if I start a new
> project based on django, or I extend existing project, there is very
> strong reason for me to use newforms, BUT they don't work. Confused ?
> Me too :(
Actually it is exactly like this because newforms are not ready. And
unicode issue is not the only one. Ne
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
> 2. when django passes data fr
ak wrote:
> Bjorn, if you read my first messages and specially my patch #3370, you
> find that I made a suggestion that if the guys want to move to unicode
> they better drop all native encodings support and so does my patch.
With all due respect, you seem to not understand this. 'Unicode' does
Michael Radziej wrote:
> I'm not sure about what the last sentence means--are you suggesting to
> put #3370 (the mysql part) into "Needs design decision"?
## 3370
I'm -1 on setting MySQL connection to 'utf8' in #3370. It *will* make
sense when we will have newforms ready and models containing u
Michael Radziej wrote:
> Hey, I now finally understand why you need #952 as soon as you switch to
> a different charset. I understand your point, but I'd rather offer a
> solution than postponing this for such a long time.
+1
#952 is good to include now since it plays nice with byte string model
[EMAIL PROTECTED] wrote:
> I think the next step in the unicodeification of django is to decide where
> the conversions happen. Or has this already been decided?
>
> I like the picture of "unicode circle of trust": everything inside the circle
> is trusted as unicode strings. Everything outside
Russell Keith-Magee wrote:
> http://code.djangoproject.com/ticket/3389/
That thing:
Article.authors = [4,7]
is now done by
Article.authors = [Author(id) for id in [4,7]]
I.e. Author(id) creates some strange incomplete object that can be
nonetheless used for m2m relations since only
Gábor Farkas wrote:
> i think currently the "missing" thing is a decision from the "upper
> level" :), about whether django-1.0 will be unicodized( unicodified?) or
> not.
Well... Given that newforms are all-unicode and already cause pain on
unsuspecting developers it's either Django should fo
Michael Radziej wrote:
> I thank you for all your patience with me. I was completely off-track. I
> read all the mails again, and everything is starting to make sense now.
Then I hope not to confuse you (and everyone else) with my answer :-)
> First, contrary to my former opinion, #3370 is a bug
Russell Keith-Magee wrote:
> I hadn't considered that approach. I'm not a big fan of the
> half-complete object instance, though.
So do I :-). I merely bring this up to remind that it kinda works but
may be it should be removed in favor of a more clean way.
--~--~-~--~~~
Bill de hOra wrote:
> Yep; it's a problem on the way back in. Python won't let you interpolate
> encoded bytestrings and unicode; you have to state the encoding. Ivan -
> could the db encoding be declared in settings.py?
This is what #952 is about. Though it doesn't
Michael Radziej wrote:
> d) make the database wrapper accept both unicode and bytestrings in
> the models, but always pass unicode strings to the database backend.
>
> Details:
>
> For #952 to work, the name of the character encoding has to be
> translated from python naming conventions to these
Michael Radziej wrote:
> I admit that I haven't thought about the details at all. If your
> code works, that's great!
Oh... It only shows the general idea. But I could try to elaborate if
people agree.
--~--~-~--~~~---~--~~
You received this message because you a
gabor wrote:
> up to now i simply added raw_id_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
I was thinking of it a bit... My first sol
James Bennett wrote:
> One suggestion that I kind of like is the ability to pass a QuerySet
> to 'choices' and, in that case, have it generate the choices from,
> say, the id and __str__ of each object in the QuerySet.
Then you'll loose a 'blank' choice. Current Field.get_choices does a bit
more
[EMAIL PROTECTED] wrote:
> 1. Full if support - if/elif/else with python access - It could be
> done in the view but making a loop in view and second one in template
> isn't a nice solution.
I bet you can find such or similar discussion in the archives of this
list or django-users. In short -- n
Adrian Holovaty wrote:
> The first option sounds better to me, too. Are you willing to code up a patch?
OK. I'll post a follow-up here with the ticket number in a day or two.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Adrian Holovaty wrote:
> The first option sounds better to me, too. Are you willing to code up a patch?
Here it is: http://code.djangoproject.com/ticket/3436
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django d
Michael Radziej wrote:
> No, I'd propose simply to use the file system's encoding for files
> within the file system, that's all,
This will fail in some cases. The problem is that file system itself
doesn't check (nor enforce) any encoding in file names. And files may
come to server from differ
Marc Fargas Esteve wrote:
> But psycopg1 is obsolete so newcomers should be recommended to version
> use 2 unless there are still outstanding issues with it.
Am I right that psycopg2 extracts string as unicode (I really don't
know)? If yes then unicode will go straight into models' attributes an
Michael Radziej wrote:
> A few days ago, I wrote:
>> I see three ways to fix the problem in #3370:
>>
>> a) newforms stops passing unicode strings to the Database API and uses
>> bytestrings.
>>
>> b) the database wrapper in Django sets connection.charset (but needs to
>> translate the charset nam
Michael Radziej wrote:
> Ivan Sagalaev:
>
>> Michael, the ticket http://code.djangoproject.com/ticket/3370 just got a
>> patch that does a) and it's really small. It's not as full as having b)
>> and d) but I think they are really a corner cases: b) for differ
Michael Radziej wrote:
> (meeting postponed ...)
Nice :-)
> You're right, sorry. I was in a different ticket and somehow thought
> it was the same.
>
> Yes, #3370 looks interesting and is a different solution. I'm not
> sure whether it deals with all the issues of this thread.
I tried to show
Adrian Holovaty wrote:
> Hi Ivan,
>
> Could you explain again why you think newforms should output
> clean_data as bytestrings rather than Unicode strings?
I don't think so :-). Quite the opposite. I think it's good that you
made newforms in unicode since it effect
Marc Fargas Esteve wrote:
> You could set the additional class to the container so you can use
> simple CSS selectors to apply different styles to any element from the
> container and inside it. Setting the class on the label or the input
> field would not allow to modify the container.
+1 (if by
sime wrote:
> Adrian seems to think it's feature creep. But how else are we supposed
> to link media without access to MEDIA_URL?
To answer directly: by using get_FIELD_url() methods of models. Media
directory is primarily intended to keep files that are uploaded into
FileFields and automatical
James Tauber wrote:
> I'm taking on the task of improving Atom support in Django, both from
> the point of view of extending support for the feed format and also
> implementing the Atom Publishing Protocol (APP).
Hello James!
This is a rather nice coincidence :-). In the coming weeks I'm abo
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 (at least with the right backend module version ...)
> Isn't this a contradiction?
>
> References:
>
> [1] h
101 - 200 of 569 matches
Mail list logo
