Re: Proposal: use SQLAlchemy Core for query generation

See also syntax evolution of peewee ORM, which initially was Django's lightweight clone. http://peewee.readthedocs.org/en/latest/peewee/upgrading.html#goals-for-the-new-api -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this disc

Re: Proposal: use SQLAlchemy Core for query generation

Hi all, I've viewed a few interesting solutions. 1. Allows to use both, Django-ORM + SQLAlchemy. Single connection. SQLAlchemy's models are generated automatically form Django's models. https://github.com/Deepwalker/aldjemy 2. Uses only Django's ORM, but allows to use 4 SQLBuilders

Re: Proposal: use SQLAlchemy Core for query generation

вторник, 4 декабря 2012 г., 0:48:04 UTC+2 пользователь Ivan написал: > > >1. Allows to use both, Django-ORM + SQLAlchemy. Single connection. >SQLAlchemy's models are generated automatically form Django's models. >https://github.com/Deepwalker/aldjemy > &

Is file based cache is safe for concurrent process?

Hi all. Can anyone tell, does django.cache locks file for writing by concurrent process? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+

Re: Is file based cache is safe for concurrent process?

ked this on django-users. Django-developers is for > discussing the development of Django itself -- it shouldn't be used as > "second tier" support if you don't get the answer you want on django-users. > > Yours, > Russ Magee %-) > > On Wed, Mar 27, 20

Re: Is file based cache is safe for concurrent process?

d first to study the Contributing guide https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/ Thanks for answer. четверг, 28 марта 2013 г., 2:23:52 UTC+2 пользователь Russell Keith-Magee написал: > > > On Thu, Mar 28, 2013 at 7:13 AM, Ivan >wrote: > >> &

ATOMIC_REQUESTS, cache invalidation and concurrent process

With ATOMIC_REQUESTS, after cache invalidation, the concurrent process can re-create cache old data, between deleting of cache and commit. Perhaps this problem should be solved by repeat cache deleting after commit. -- You received this message because you are subscribed to the Google Groups "

pychecker catches IndexError exception while importing /django/db/models/base.py

auth.models models Not sure if the last models that triggers the exception is the models file I ran pychecker on or another file? I have all my django env variables set up correctly and can do runserver, dbshell ,etc. Any ideas as to why pychecker on my models file would throw this exception in the

Re: pychecker catches IndexError exception while importing /django/db/models/base.py

sue, I'm importing Donation in admin.py using: from geni.control.models import Donation, and I don't have Donation registered anywhere else. So I'm not sure how to fix this problem either, except that I don't really care much about debugging the admin portion of the site so I

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

Malcolm Tredinnick wrote: > If all you want to do is change the widget, you can do that in the > form's __init__ method by updating self.fields["name"].widget, for > example. There's also a ticket waiting for check-in implementing this common usecase: http://code.djangoproject.com/ticket/9223 P

Re: Logging instead of connection.queries

Hello! I'd like to revive the discussion about handling debug SQL log since I don't feel we've come to any conclusion. To summarize: - Ticket [5415] deals with implementing signals upon SQL queries. Nobody had any objections to it and it helps in solving my original problem of logging. - Mal

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

Kevin Henry wrote: >> There's also a ticket waiting for check-in implementing this common >> usecase:http://code.djangoproject.com/ticket/9223 > > Thanks, the accompanying discussion is very interesting and on point. > But as someone there points out, why stop at widgets? Because customizing wid

Re: Replacing get_absolute_url, I am against it

drozzy wrote: > If it is going to be done I propose adding another function, and thus > have two possible functions on the model: > get_relative_url > get_absolute_url get_relative_url is rather misleading. The proper meaning of "relative" is a url relative to current url: "./some/hierarchy", "s

Re: media -> admin_media Prefix Change

drozzy wrote: > Yes, I Do, How about that he never replied to the Collin Grady's > commend about HOW it would break the code. > Seems like the ticket was never discussed but monopolized by a little > hush-hush discussion... Though I don't support this attitude I tend to agree on principle with d

Re: Replacing get_absolute_url, I am against it

Jacob Kaplan-Moss wrote: > * The fact that the returned URL is a string often means I end up > doing something like `obj.get_absolute_url().split('/')`. Objects are > better. I kind of disagree with the last sentence here. An object in place of a well-known native type (here, str) adds another a

Re: Replacing get_absolute_url, I am against it

Ivan Sagalaev wrote: > In the rare cases when I do need to split a URL into parts I just use > urlsplit: > > schema, domain, path, query, fragment = urlsplit(obj.url()) Oh... And for template authors we could just make 5 filters returning those parts: {{ ob

Re: media -> admin_media Prefix Change

drozzy wrote: > Sorry about the attitude, sometimes I think a bit too much of myself. > When do you think will get implemented? I'm not the one who decides :-). I've just raised another voice claiming that that decision may be worth reconsidering. --~--~-~--~~~---~--

Re: Replacing get_absolute_url, I am against it

Jacob Kaplan-Moss wrote: >>> schema, domain, path, query, fragment = urlsplit(obj.url()) > > That's not in any way intitutive for a new user in the way that > `obj.url().schema` is. After thinking of it a bit more I agree about new users. My main concern though was about not using an estab

Re: Replacing get_absolute_url, I am against it

Zachary Voase wrote: > If you take a look, you’ll notice that URLObject, being a subclass of > unicode, can be used *directly* within the template and it'll render > out to the URL without any magic. Beware! Using the word "magic" too loosely may infuriate certain core devs and they will sta

Re: Replacing get_absolute_url, I am against it

James Bennett wrote: > Except I can't help thinking this is an awfully arbitrary distinction > to draw. In effect you're saying that nearly every question about an > object should be answerable by interrogating it directly, *except* for > "what's a URL I can use for you?" May be I can explain thi

Re: Proposal for 1.2: built-in logging with django.core.log

Hi Simon, Simon Willison wrote: > 1. We'll be able to de-emphasise the current default "e-mail all > errors to someone" behaviour, which doesn't scale at all well. In a recent thread[1] on a similar topic Russel has also emphasized that we should improve documentation about doing logging. > 3.

#9886: HttpRequest refactoring

Hello everyone! Ticket [9886] is one of the things that I've been holding for 1.2 time frame to ask for some discussion since Jacob marked it DDN. This has started as a feature allowing to .read() directly from a request object. However this has lead to a rather nice refactoring removing a lo

Re: #9886: HttpRequest refactoring

Ivan Sagalaev wrote: > This comment[1] in the ticket is a summary of what had changed. Thanks > for looking! Forgot to add... There's no docs & tests changes in the patch yet. I'll add them after the decision if this looks good at all. --~--~-~--~~~

Re: #9886: HttpRequest refactoring

Jacob Kaplan-Moss wrote: > On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev > wrote: >> Ticket [9886] is one of the things that I've been holding for 1.2 time >> frame to ask for some discussion since Jacob marked it DDN. > > At first glance, you need docs and

Re: Proposal for 1.2: built-in logging with django.core.log

Vinay Sajip wrote: > Actually you don't need much in settings.py, and Django doesn't need > to grow any code of its own to "wrap" logging. You can either > configure logging programmatically (for which I use basicConfig, in > simple setups) or using a configuration file (ConfigParser-based, > full

Re: Proposal for 1.2: built-in logging with django.core.log

Ivan Sagalaev wrote: > Standard Python logging configuration has > a noticable gap between very simplistic basicConfig which configures > only a root channel and a verbose imperative definition of handler > objects, formatter objects and logger objects. Forgot one thing. As i

Re: Proposal for 1.2: built-in logging with django.core.log

Sorry for taking a bit long to respond. Looks like we aren't disagree much anyway but I had to get some thoughts off my chest :-). Vinay Sajip wrote: > It's similar to Django's support for, say, simplejson. I think it's > reasonable for Django to alias WatchedFileHandler so that it's > available

Re: Proposal for 1.2: built-in logging with django.core.log

Vinay Sajip wrote: > We should provide a configure_logging(dict) utility function which > takes a dict in an agreed format (such as Ivan's suggestion). Then in > settings.py users can invoke configure_logging(LOGGING) after > defining the configuration right there, in settings.py itself, or > obt

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

Benjamin Slavin wrote: > * Logging may need to come even earlier. If you truly want to log > everything, you'll want to run that code first. Is it really the case that we want to log everything? I believe that logging after initialization is enough. And for my example of a logging handler that

Re: #9886: HttpRequest refactoring

Jacob Kaplan-Moss wrote: > On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev > wrote: >> Ticket [9886] is one of the things that I've been holding for 1.2 time >> frame to ask for some discussion since Jacob marked it DDN. > > At first glance, you need docs and

Re: #9886: HttpRequest refactoring

Russell Keith-Magee wrote: > Any complete feature is potentially a candidate for > v1.2 - as long as you can convince a core developer to look into the > ticket. This is what I'm trying to do, yes :-). The ticket is assigned to Malcolm (and in fact it was created after we talked with him if such

Reversing URL for a view with namespaces

Hello! I've just stumbled upon a difficult to understand problem. I have an app that has an urlconf which is included in a project under a namespace: (r'^blog/', include('app.urls', namespace='blog')), This namespace allows things like {% url blog:article ... %} which is very nice. But

Re: Reversing URL for a view with namespaces

Russell Keith-Magee wrote: > On the 'missing something' front, reverse() now takes a 'current_app' > argument that gives context to the app lookup, which resolves the > ambiguity from the point of view of the reverse() function. I saw this one. It doesn't work in this case exactly beacuse of this

Re: Reversing URL for a view with namespaces

Russell Keith-Magee wrote: > Apologies for taking so long to get back to you on this. No problem :-) Have busy schedule myself :-) > For this last case - building a new app that you want to be namespace > aware - I think the Django admin already implements the model that > needs to be followed h

Re: Reversing URL for a view with namespaces

Ivan Sagalaev wrote: > Ahha! This is the catch I was missing. So in order for an app to place > itself generally in the "namespace-aware" category it should define a > function that will return a triple of (patterns, app_namespace, > instance_namespace) and document

Re: Conventions around plugable backends

On topic, I'm +0 on class-based approach. There's actually one passage that reminded me of something that I consider a small wart in a couple of places in Django: Russell Keith-Magee wrote: > Module-based configuration: > --- > > * The aesthetic of user-configuration op

Re: What do people think about the get_absolute_url proposal?

Mike Malone wrote: > On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee > wrote: >> 4. I share Mike's concern about using settings.SITE_ID to determine >> the current host, but I'm not sure I have any suggestions on how we >> could practically use request, short of encouraging the use of a >> te

Re: What do people think about the get_absolute_url proposal?

Mike Malone wrote: > Well, not really. It's making a way to generate a URL based on the > request object global. I agree that it's not ideal, but it's not the > same as just making the request object global. My main gripe is not globalness of a request object itself (I agree with "not ideal" here

Re: What do people think about the get_absolute_url proposal?

Michael Richardson wrote: > With these cases (the former more so than the latter) you are creating > URLs for an entirely separate project, not your own, essentially. Not "entirely separate". These are projects sharing much of the codebase, just having different SITE_ID in settings. Anyway there

Re: What do people think about the get_absolute_url proposal?

Mike Malone wrote: > In my opinion, using the Site module and settings files is damn > annoying. My point is that we better fix these annoyances than leave this way of doing things altogether. > I never use the Site module This is by itself is not the reason why it might be annoying. Django ac

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Alex Gaynor wrote: > Adding the ellepsis is as simple as: > > {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} Come on Alex, in what universe it qualifies as "simple"?! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: idea for using RequestContext by default

Russell Keith-Magee wrote: > I'm in complete agreement with Simon on this point. I fail to see the > benefit of decorators in this context. I can see one valid point that "render_to" guys have. Which is, incidentally, has nothing to do with the decorator syntax. An HttpResponse with an opaque st

Re: idea for using RequestContext by default

Russell Keith-Magee wrote: > Certainly - and Simon made exactly this proposal during the review of > the CSRF work. Simon even provided a sample implementation: > > http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1 Thanks! I keep missing nice things on django-dev@ due to many

Re: Model validation incompatibility with existing Django idioms

Tobias McNulty wrote: I regret and apologize that I'm arriving to this thread rather late. To support the tradition, I'm apoligizing for this too :-). Though it's funny how everyone thinks they're "late" on a couple-of-days-old thread :-). Anyway... I too would opt for an implementation tha

Re: Model validation incompatibility with existing Django idioms

Tobias McNulty wrote: I don't see why model validation should be bound up with forms at all. I'm not the one who designed it, so it's just me view. I think this is just useful: if you have a code validating, say, a CharField at the model level why not reuse it at the form level? What's impo

Logging format decision

Hello everyone! There was a discussion here some time ago about logging in Django that led to the ticket 12012 [1] where Simon has done most (all?) of the implementation. There is still a disagreement on the format of the configuration dict for it. Simon has implemented it from my ad-hoc pro

Re: Model validation incompatibility with existing Django idioms

Joseph Kocherhans wrote: # Run validation that was missed by the form. p.validate_fields(fields=['user', 'primary_contact']) p.validate_unique(fields=['user', 'primary_contact']) p.validate() Can this be shortcut to p.full_validate(fields=['u

Re: Logging format decision

Russell Keith-Magee wrote: That said - I really do want to see logging in Django's trunk. If we can sort out the details in the background and get a good implementation ready, it could easily be the first feature committed for v1.3. Agreed! I like Vinay's suggestion for exactly the reason you

Re: Logging format decision

Russell Keith-Magee wrote: You've also defined a production server that uses just two loggers - exception and info - for the entire server. Again, this isn't especially realistic - in practice, you have a large number of fine grained loggers for different parts of the system. In fact, most of o

Master/slave replication in multi-db era

Russell Keith-Magee wrote: There are some cases where this shouldn't happen - for example, in a master/slave setup. I'm tinkering with some code at the moment to control this sort of database allocation. Russel, can you share your ideas on the matter? I'm about to port (soon-ish) my replicatio

Re: Feedback requested: Multi-db database routing

Russell Keith-Magee wrote: class MasterSlaveRouter(object): def db_for_read(self, model, db=None): # Point all read operations to a random slave return random.choice(['slave1','slave2']) def db_for_write(self, model, db=None): # Point all write operations to the m

Re: [Python-Dev] PEP 391 Acceptance - Thanks!

Vinay Sajip wrote: Guido, That's great - thanks very much! I'll get on with integrating the PEP 391 implementation into trunk right away, and it should be in good time for 2.7/3.2. Thank you for your efforts! -- You received this message because you are subscribed to the Google Groups "Django

Backwards-incompat with CsrfViewMiddleware

Hello everyone! A couple of days ago we've noticed a (potentially big) backwards incompatibility that can bite users upgrading from 1.1 to 1.2. CSRF doc encourages users to enable CsrfViewMiddleware that will check all POST requests for csrf_token and then suggests to alter all HTML forms to

Re: Backwards-incompat with CsrfViewMiddleware

Luke Plant wrote: This case is slightly different because it is down to an interaction of a changed default setting with working code, but there will always be cases like that, and I think it is much better for developers to remember the general principle that they are responsible for whatever

Re: Backwards-incompat with CsrfViewMiddleware

James Bennett wrote: Perhaps that's why, in both the 1.2 alpha release notes and the draft for the final 1.2 notes, it's listed under a big heading titled "backwards-incompatible changes". As we say in Russia "Gee, I didn't notice the elephant" :-). I still think it would be useful to add an e

Hladame Django programatorov (Looking for Django developers - Slovakia)

We are looking for experienced Django developers for work in our office located in Eastern Slovakia (Presov). For more information please look here: http://gista.sk/index.php/o-splocnosti/ponuka-prace or send email directly to me. Thanks, -- Ivan Mincik Gista s.r.o. signature.asc Description

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

George Karpenkov wrote: http://code.djangoproject.com/ticket/13181 I'm -1 on complicating it this way. The ability to pass a callable for choices is covered by passing a generator. Am I missing something? -- You received this message because you are subscribed to the Google Groups "Django d

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

George Karpenkov wrote: Given your experience, the chances are that you're right, however, I don't see any way how we can pass a generator which will not be called until the form class is instantiated. Why should a call matter? The body of the generator is not executed until first iteration at

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On 05/26/2010 03:02 PM, Gustavo Narea wrote: Among many other things, one of the components alone provides solutions to some enterprise requirements for Django: * It’s now possible to run code at startup

Re: streaming patches reloaded

arthur debert wrote: >I have an app that uploads a 4mb file and is taking a ton of memory. >>From tickets 1484/1569 they are set as fixed, but I cannot find them on >django's source code. Are these patches active in trunk? If not, >anyones knows if they're working after the merge? Anyone using th

Re: Suggestion: Better slugifying of scandinavic characters

Malcolm Tredinnick wrote: >So either we're going to end up carrying around a fairly large mapping >table in the Javascript or we need a better solution. > > Looking at what Wordpress does at the link in the beginning of this thread (http://trac.wordpress.org/file/trunk/wp-includes/functions-f

Re: Suggestion: Better slugifying of scandinavic characters

everes wrote: >So any django application used slugs are no use for none-ascii-charcter >languages. > > Exactly. My point is that Django shouldn't try to solve this problem. But impossibility to make truly international slugs shouldn't stop Django to do it better for couple of languages in Eur

Re: streaming patches reloaded

arthur debert wrote: >Hi Ivan. > >Just to make sure I understand: >- after patching django I 've set: >STORE_UPLOAD_ON_DISK = True > >I am trying to use this on the admin. Any more steps I must take? > > Hm... I don't think it would help very much in admin

Re: unicode.. reject?

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 when it was proposed I should say that the more I think of it the more I'm afra

Re: Custom manipulators

Luke Plant wrote: >Has anyone tried to use Django's manipulators and forms for the case >where you only want a few fields to be editable, and the rest to keep >the original values? > I'm doing it very often. I have some frankenstein user model which is editable partly in one form, partly in an

Re: Custom manipulators

Luke Plant wrote: >Manipulator.get_validation_errors() ignores the 'follow' parameter, so >you get validation errors for fields that aren't included. > Just tested it and it shows that you don't. I have a required field switched off with "follow" that is not in the form. It doesn't give an erro

Re: unicode.. reject?

gabor wrote: >>Using this convention >>one can write international apps without worries since all messy things >>are made inside the framework. >> >> > >well, i would replace 'without worries' with 'good enough' :) > > Ok :-) >for example, i was building a very simple web-file-manager. y

Generalisation of exclude/QNot has broken QNot

I noticed today that in http://code.djangoproject.com/changeset/2997 there were some changes to QNot after that my code has broken. I was using Q() and QNot() to dynamically construct a search query like this: query = Q() if : query = query & Q() if : query = query & QNo

Re: Generalisation of exclude/QNot has broken QNot

Luke Plant wrote: >I think the basic assumption is that undocumented features and >functions can be changed without warning. > Absolutely! I'm not complaining :-). I'm just trying to get general idea of how it is supposed to be used. > You are of course free to >re-use any Django code, but you

Re: Generalisation of exclude/QNot has broken QNot

Luke Plant wrote: >Constructing the query once is pretty neat. I would suggest using your >original method (you use source control, right?), and then adding >QNot(Q(album__path__exact='')) > > Ah... That's the trick! Thanks :-) I certainly use source control but I won't use the old code since

Re: PROPOSAL: Manager.get_or_create()

Adrian Holovaty wrote: >Time and time again I have the following Django code: > >try: >obj = Person.objects.get(first_name='John', last_name='Lennon') >except Person.DoesNotExist: >obj = Person(first_name='John', last_name='Lennon', >birthday=date(1940, 10, 9)) >ob

Re: manipulator.save(data) doesn't return a object from database

Viktor wrote: >blabla = models.IntegerField(default=0, editable=False) > > editable=False means exactly that manipulator won't touch this field, this is why it's not updated with the value from data. --~--~-~--~~~---~--~~ You received this message because you a

Re: Improved FileField ideas?

Jay Parlar wrote: > So what I'm thinking, is to allow something like the following: > > class User(models.Model): > username = models.CharField(...) > avatar = models.ImageField(upload_to="users/" + self.username, > erase_old=True) > For "upload_to" case I think this will work: upl

Re: HttpResponseSendFile

SmileyChris wrote: > I don't want to go reopening the ticket, but couldn't this still be > useful functionality? > The regular HttpResponse already can serve files in some fashion: f = open(filename) return HttpResponse(f, mimetype='application/octet-stream') Here the file-like object

handler404 (and 500?) should use RequestContext

Currently the default handler404 view uses simple Context. This results that often people relying on passing their stylesheet URLs with context processors loose this for 404 pages (I have an app that is written entirely with generic views except a custom handler404 for the single purpose of ha

Re: handler404 (and 500?) should use RequestContext

Adrian Holovaty wrote: > We changed the default 404 and 500 views to use RequestContext a > couple of days ago, so you may not have seen that change. :) Ouch! Sometimes this Django thing changes too fast :-) Thanks! --~--~-~--~~~---~--~~ You received this message

Re: Generic Relationships/convert_post_data in forms

Max Battcher wrote: > Have you seen Ivan Sagalaev's tag model? It needs updating to support > the new GenericRelation (it currently uses a similar but proprietary > clas), I somewhat missed the whole discussion on generic relation though I get the general idea. Do they work

ManyToManyField looks broken

I'd like to draw some attention to ticket http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as it appeared after his checkin 3195). Basically ManyToMany relations don't work when you try to get related queryset from a model where ManyToManyField is defined. Or is it just

Re: ManyToManyField looks broken

odels). It looks like it's not related to the new ticket since it fails both before and after changeset 3195. > Are the tests failing for you, too, Ivan? No, tests are Ok (except some failures in default filters that I have patched locally, but it's not related... hopefully :-) ).

Re: ManyToManyField looks broken

Malcolm Tredinnick wrote: > I've just checked in r3202 which I believe fixes the root cause of #1796 > in a reasonably correct way. I think it also fixes #2232 for the same > reason. It does (just checked). Marking ticket fixed... Thank you very much, Malcolm and Russel and everyone else! --~--

Re: URL confs should take callables as well as strings

Malcolm Tredinnick wrote: > Another thing we need to document better here, because this claim is not > quite correct (didn't you help write this?). The patterns() function > returns a normal Python list. So you can just append successive calls to > patterns() to each other: > > urlpattern

Re: problem with revers lookup

Malcolm Tredinnick wrote: > It's not that we actually suck at fixing this. It's just that realiable > failures are hard to come by. Once we fix one and think we understand > the fix, it takes a good three or four hours for Ivan to break it again. Add the time differ

Re: Unicodification of Django

Jacob Kaplan-Moss wrote: > Just one > example is the issue of template encodings -- do we need to start > indicating that a certain template is UTF-8 or whatever? May be I don't understand what do you mean... But this problem is not related to internals being in unicode or not. Most templat

Re: Unicodification of Django

Bjørn Stabell wrote: > What if the patch required everything to be Unicode, meaning: > > * all programmers would have to become aware of Unicode to some extent > * all code would suffer the (minior) performance penalty of encoding > and decoding all text The second point is arguable. Currently

contrib.auth.login doesn't set request.user

First, a little context. My app uses cookie-based authorization as well as HTTP authorization (for download managers mostly). It worked as a middleware that sits after Django's auth middleware and tries to authorize a user by HTTP credentials if it's not authorized with cookies. It goes basica

Re: django-unicode conversion, first experiments, questions

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

Re: django-unicode conversion, first experiments, questions

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

Re: django-unicode conversion, first experiments, questions

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

Re: django-unicode conversion, first experiments, questions

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

Re: MS-SQL server LIMIT/OFFSET implementation

DanH wrote: > > Is someone working on MS-SQL support? > I would like to help if possible with the implementation and testing. Yes, testing is the main thing that holds it. The patch was developed sporadically and as far as I remember all the theoretical problems were known how to solve. It's j

Re: Django sprint / 0.95 release at OSCON

Adrian Holovaty wrote: > Most -- all? -- of the magic-removal stuff has settled down What about model inheritance? This is one feature that was before MR and never recovered after. I remember some people in django-users were forced to stay with pre-MR syntax because of it. I also remember that

User subclassing

James Bennett wrote: > Which I've never understood. Subclassing User, even when model > inheritance works again, will be probably the most difficult, least > efficient and least rewarding way of extending User... But nobody knows this beforehand. The feature is called "subclassing" and looks lik

Re: Model inheritance API

First of all: Malcolm, this looks damn cool and very well thought out! Thank you! Malcolm Tredinnick wrote: > --- > 2. "Pythonic" Inheritance > > ... > > (in the above classes, Animal > would have a foreign key reference to the Thing table, s

Re: after save() hook not called in admin?

James Bennett wrote: > While we're on the topic, the docs explicitly advise against doing > 'len' on a QuerySet because of the potential memory overhead of > loading all the objects, and recommend using the QuerySet's 'count' > method instead. Would it make more sense, then, to internally change >

Re: Any way to halt big file uploads?

Todd O'Bryan wrote: > Would it be better to expose the file-like object that comes with a > file upload, rather than reading the file's whole content into memory > (or into the server's file system, if the patch gets checked in)? > It's easy to retain backward compatibility by just having a

Re: bug in django.http.parse_file_upload?

Todd O'Bryan wrote: > But aren't backslashes legal characters in unix-like OSes, so that > the filename will get truncated if it has a backslash in it? You're right. But it's better to have nice filenames from Windows clients in most cases with a rare occasion of truncated filenames uploaded

Re: django unicode-conversion, beginning

First of all, Gabor, thank you very much for doing this! 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 can write a view > completely in unicode. > means: > - GET/POST contains uni

Re: If there was massive security hole found in Django, are there plans in place to deal with it?

James Bennett wrote: > One would hope that anyone who's using Django is subscribed to > django-users and/or watches the Django blog This would be less and less true as time goes because Django will spread beyond early adopters to a new forming local communities. For example there is russian Dja

Re: django unicode-conversion, beginning

Malcolm Tredinnick wrote: > I completely agree this is painful and normally I would punt. But my > crystal ball tells me that you will then get bug reports from Mr > Sagalaev, who is generally both very diligent in his debugging and likes > to use some language with a funny alphabet. If whatever y

Re: django unicode-conversion, beginning

gabor wrote: > hmmm.. are you sure that the situation with unicode-aware editors is so bad? > > could you name some non-unicode-aware editors? > for me it seems that from notepad through vim to eclipse everything does > unicode fine... Ok, I should rephrase it. Even if most editors do support u

  1   2   3   4   5   6   >