Re: #11675:Pyblic+Memcache changes, Draft #1

On Thu, Dec 2, 2010 at 4:50 PM, Jacob Burch wrote: > What I"m doing now (returning None) is already fairly magical. Isn't that broken? set(KEY, "a", timeout=100) set(KEY, "b", timeout=0) get(KEY) won't returning None from the set(..., 0) instead of sending the

Re: #11675:Pyblic+Memcache changes, Draft #1

Hi Jacob, On Thu, Dec 2, 2010 at 8:05 AM, Jacob Burch wrote: > > The problem is I can't think of a good way to force instant-expiring > sets in pylibmc. The only way to fake the response is to alter the > actual return value. 0 and all negative numbers, in pylibmc, set for

Re: proposal: abstract file upload/download handling

On Thu, Jun 24, 2010 at 4:24 AM, Waldemar Kornewald wrote: > FileField gets a new method prepare_upload() which takes the following > arguments: > * request > * upload_url: the target URL of the upload view > * private: should this be only privately accessibly or also

Re: 1.3: Start deprecating mod_python?

Hi again, > Jacob said: I'm +1e100 or so. > Russ said: +1. Now lives as http://code.djangoproject.com/ticket/13820 > > The only catch I can think of that hasn't been raised is the hotshot > profiling handler; it's currently dependent on the modpython handler. > I don't think there's a whole lot

Re: 1.3: Start deprecating mod_python?

Hi Anton, On Wed, Jun 23, 2010 at 10:13 PM, Anton Bessonov wrote: >> >>  * mod_wsgi is better in every way. > > And? Jinja2-Template Engine is every way better as Django Template Engine. > Drop DJango Template Engine and support Jinja2? Russell explained it, but mod_wsgi:

Re: Making WSGIHandler the only handler / mod_python support

Nice timing :) On Wed, Jun 23, 2010 at 11:22 AM, Gustavo Narea wrote: > > I'm going to work on some patches to improve WSGI support, and I found > something that, if changed, could make my patches and django.core.handlers > simpler... As well as make it possible to use

Re: 1.3: Start deprecating mod_python?

On Wed, Jun 23, 2010 at 11:31 AM, Jerome Leclanche wrote: > Agreed. mod_python was already "not recommended" for very long; now > it's dead, I don't see any reason to support it for three full release > cycles. I don't either, but I figured the deprecation policy[1] applies to

1.3: Start deprecating mod_python?

Hey folks, While people are throwing around 1.3 ideas... I think we should start the process of deprecating and removing support for mod_python. Why? * mod_wsgi is better in every way. * mod_python hasn't had a release since 2007, or a commit since 2008; it's a dead end. The Apache Foundation

Re: Process discussion: reboot

On Wed, Apr 21, 2010 at 10:18 AM, SmileyChris wrote: > ... And it seems like i'm reiterating the discussion about > http://code.djangoproject.com/wiki/TicketChangeHelp > > I'm advocating for the friendly text in the ticket page itself, as I'm > not sure that was

Re: Process discussion: reboot

On Wed, Apr 21, 2010 at 10:00 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Tue, Apr 20, 2010 at 4:49 PM, Robert Coup > <robert.c...@onetrackmind.co.nz> wrote: > >> I can write you a trac extension/patch - just didn't want to spend the >> time on it if

Re: Process discussion: reboot

On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss wrote: > I like this a lot. Especially the "your next steps" part - it makes it > very obvious what the next thing interested parties should do is. > > Could you start a wiki page with this stuff? Until we figure out how > to

Re: Process discussion: reboot

Hi all, On Tue, Apr 20, 2010 at 8:34 AM, Gabriel Hurley wrote: > When I finally did submit my first patch, I was terrified of getting > it wrong and having it rejected. I'd seen it happen on other tickets. > As a project, I'm sure we don't want any (even potential)

Re: Django Design Czar

I think it's important to be clear here - I envisage a design czar to act like a code committer: - encourage, review, and shepherd work to completion - assess different approaches to problems, and decide if necessary - get minor improvements and fixes make into trunk - make sure there's work

Re: Django needs for normal sequence of handlers for request processing

Hi Serg, (replying to the list) On Thu, Nov 26, 2009 at 4:09 AM, serg wrote: > > hmm.. yes. it's almost the same i mean. > but, all middlewares calls for each request... It's bad (imho). > also in 99.99% cases it wil be work nice... > thanks! > > This method {'filter_ip':True}

Re: Django needs for normal sequence of handlers for request processing

On Wed, Nov 25, 2009 at 11:08 PM, serg wrote: > > For example: you can already do something like this (middleware conditional on urls) via the view middleware mechanism. in urls: ... (r'^members/private/', include('members.private.urls'), {'filter_ip':True}), ... then the

Re: Exception emails in django.core.handlers.base

On Wed, Dec 17, 2008 at 11:15 AM, Jeremy Dunck wrote: > > Put this another way-- how do other people manage high-performance > exception mailing? Maybe I'm Doing It Wrong. Run postfix on the host server and have Django send errors to localhost. Then postfix queues it and

Re: Dynamically Altering Settings

On Fri, Dec 5, 2008 at 4:12 AM, Kyle Fox <[EMAIL PROTECTED]> wrote: > > Thanks again. At this point I'm considering removing the Sites & > CurrentSiteManager from all of our apps entirely. Maybe I was overly- > optimistic about how Sites could be used; having to write a static > file just to

Re: Proposal: django.forms.SafeForm - forms with built in CSRF protection

On Wed, Sep 24, 2008 at 5:29 AM, Brian Beck <[EMAIL PROTECTED]> wrote: > > On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote: > > Could we just include something like a signed salt+timestamp > > +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because > > of the possibility of a

Re: would is_loggedin be better than is_anonymous?

On Thu, Jul 17, 2008 at 1:51 AM, Nathan Hoover <[EMAIL PROTECTED]> wrote: > I'll second that. I work for a large (unfortunately non-django) commercial > web property and we have the same basic set of states - anonymous, known, > and authenticated. I think it's pretty common. > Its not that hard

Re: Djangochatter [WAS: Django community aggregator and non-English posts]

On Sat, Jun 14, 2008 at 5:55 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > Well, I'd still like to be able to get feeds for keywords, too. For > instance, with all the file stuff I've been doing, I'm curious to know > what kinds of FileField problems people are dealing with. If I could > just

Re: django templates in javascript

On Sat, May 3, 2008 at 8:40 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Was looking into using javascript templates for client side html > creation but everything was so bloated until I found this: > http://www.devhd.com/item0002.htm. It does all the heavy lifting on > the server and

Re: django.contrib.sessions problems

On Mon, Apr 7, 2008 at 11:28 AM, Malcolm Tredinnick < [EMAIL PROTECTED]> wrote: > Realise that I am in agreement with you that logout (and possibly login, > I haven't worked through the implications there) should be changed to > clear the session by default. There's no strong reason not to do

Re: WSGI: IOError, same as mod_python?

On 16/01/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I will attempt to do more research. What makes this incredibly > frustrating is that I can't reproduce it by canceling an upload or > doing a reload in my browser. My first instinct was that as well, but > I couldn't seem to prove it.

Re: Better Support for static file serving via django

On 13/12/2007, Thomas Güttler <[EMAIL PROTECTED]> wrote: > How can you check that only authorized users can access > some files? > > Files which have a coresponding FileField in the model: How can > you test that only some people are allowed to see it? > > Apache can't do it. Or at least it would

Re: Better Support for static file serving via django

On 12/12/2007, Mike Scott <[EMAIL PROTECTED]> wrote: > I've been looking at how to better serve my static files for django sites, > and I'm particularly interested in things like Javascript handling. > > For example if we were to look at RoR, they have their include tags which can >

Re: An addendum to the escaping proposals

On 14/11/2007, Chris Green <[EMAIL PROTECTED]> wrote: > > > On Nov 10, 2007 8:58 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > Yeah, I'm not really sure what I mean, design-wise. I feel a little > > uncomfortable about requiring the csrf key all the time in form > > submissions, but I

Re: Choice lookups

> On 10/30/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > James, I think you've managed to hit (what I'd consider) the perfect > > stride there. You have to import Entry anyway, so by making your > > constants class attributes, you avoid the extra import requirement. > > It's not quite an enum,

Re: FileField question

On 29/10/2007, Justin Driscoll <[EMAIL PROTECTED]> wrote: > > To me having the two mutually-exclusive arguments sounds too much like > trying to fake static typing in a dynamic language. I don't see the > advantage of separate names for basically the same information provided in > different ways.

Re: FileField question

Presumably filename is optional, so only people who actually care will use it... with that in mind, personally I'd save the back-compat hassle and support upload_to (as it works now) as well as the callable. And make it clear in the docs that all it does is os.path.join() the two. It also might

Re: FileField question

On 23/10/2007, Marty Alchin <[EMAIL PROTECTED]> wrote: > > In response to some recent questions regarding FileField usage, I > thought about including a way to format the filename based on details > from the model instance itself. It's looking like it' be best to add > an argument to FileField,

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 18/09/2007, jedie <[EMAIL PROTECTED]> wrote: > > > On 17 Sep., 18:13, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > wrote: > > Now, a SSH/SFTP backend... that would rock. > > Yes, SFTP would be better than normal FTP. IMHO it needs some external > Libs to support this. FTP is in the standard python

Re: Visual recognition of Django website

On 18/09/2007, Justin Lilly <[EMAIL PROTECTED]> wrote: > > I personally would also like a favicon for the django sites. I took the > liberty of creating one using django's colors and fonts (stole the d from > the logo). > > http://www.flickr.com/photos/[EMAIL PROTECTED]/1397125183/ I created

Re: mod_python documentation issues

On 15/09/2007, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > As to not being able to post to tickets, I have always just used my > email address and it has worked. Ie., I do not have an account. The > ticket page says to use 'Your email or username' with an option of > creating a username only if

Re: Following OneToOne Relationships

On 06/09/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Can anyone come up a reason that OneToOne fields should not be > optionally automatically followed? Anyone for this support? > If one of the reasons for storing data separately is "update and select patterns", wouldn't it make sense

Re: Amazon S3 Integration

On 09/08/07, Fabien Schwob <[EMAIL PROTECTED]> wrote: > Yes, but my idea was to use boto in django-amazon. The goal (in my > mind) is to provide a layer around boto to Django : > > * A S3FileField around boto.s3 > * A django_amazon.generics.views.process_payment(request, amount) > around a future

Re: Amazon S3 Integration

On 09/08/07, Fabien Schwob <[EMAIL PROTECTED]> wrote: > > I'm trying to integrate S3 support into my Django app using > > http://code.djangoproject.com/wiki/AmazonSimpleStorageService for > > now. > > > > I would like to improve the code so that it might be officially > > integrated into Django

Re: schema evolution (new and improved)

On 08/08/2007, Derek Anderson <[EMAIL PROTECTED]> wrote: > > > i have had this exact situation happen to me before. (rolling out a > change, then another change reversing it) actually several times. i > have NEVER had a scenario where client Y says "can you please make sure > i lose my data?" >

Re: Breaking out Django templates into a standalone library

On 08/08/2007, James Bennett <[EMAIL PROTECTED]> wrote: > > > On 8/8/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I'd ideally like the Django installer to detect if django.template was > > already on the system, and drop Django into the same spot. As far as > > versioning, Django should check for

Re: Shared memory across processes

Marty Alchin wrote: > Regardless though, I think Jacob makes the best point so far: Django's > cache system is robust enough to handle it if you pick a decent > backend. And if there's a need to make the built-in options more > robust, we can deal with that when the need arises. > What about

[gis] lazy-geometries/planning

GIS people, There don't seem to be any plans around how the gis branch is getting to its goals. For instance, the lazy geometries patch in 4322 is way off track now we have support for ogr geometries. I'm happy to write code/docs/tests, but it helps if i can see a little way into the future

Re: Proposal: post_create signal

Benjamin Slavin wrote: > On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote: > >> So the post_create signal would be triggered *after* the transaction was >> committed? The patch in 2154 certainly doesn't handle that case. >> > > That's

Re: Proposal: post_create signal

Benjamin Slavin wrote: > Forest already mentioned not knowing if the object persistence will be > successful. Fair enough :) > In many cases using transactions will rollback any > changes that happen if a problem pops-up later (assuming those changes > are in the database). > So the

Re: Proposal: post_create signal

Ben Schwarze wrote: > Due to this process, I was looking for a way fetch a signal after the > creation of an object. > Currently Django has the pre_save and post_save signals that will be > send before and after saving the object. But there seems to be no way > to determine whether an object has

Re: Custom field _post_create_sql()

Malcolm Tredinnick wrote: > GIS guys, any particular reasons for the approach you took? -- laziness? > economy? "it works, dammit!"? technical reason against the above? > In PostGIS, the AddGeometryColumn() function needs to be run separately after the create table. It adds the geometry field

Re: Field.contribute_to_class and contrib fields

Marty Alchin wrote: > Well yeah, I didn't mean have it be just a file object with no other > details. I was meaning it'd be a custom object that would have those > attributes, but also had standard file methods that lazily called file > system operations as necessary. Something like this: > >

Re: Field.contribute_to_class and contrib fields

Robert Coup wrote: > Jeremy Dunck wrote: > >> In the gis work, we'd like to contribute a fair bit of additional >> functionality to GIS fields and models with GIS fields. >> >> So far, field contributions seem to be largely done by adding >> attributes to

Trac component for GIS branch?

Hi powerful-ones, Any chance of getting a Trac component created for the django.contrib.gis stuff? Cheers Rob :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: Field.contribute_to_class and contrib fields

Jeremy Dunck wrote: > In the gis work, we'd like to contribute a fair bit of additional > functionality to GIS fields and models with GIS fields. > > So far, field contributions seem to be largely done by adding > attributes to the model, such as FileField's get_%s_url. > > I think this approach

Re: Type coercion in Django

Justin Bronn wrote: > >From GEOSGeometry it is simple to retrieve WKT and HEX, e.g., 'g.wkt' > or 'g.hex'. However, KML is implemented by PostGIS and can only be > retrieved if you do "SELECT AsKML(the_geom)" on the database end. > Further, GML (ancestor to KML, another OGC standard) and SVG can

Re: Type coercion in Django

Russell Keith-Magee wrote: > On 4/19/07, jbronn <[EMAIL PROTECTED]> wrote: > >> The GIS branch (GeoDjango) is interested in type coercion. >> Specifically, PostGIS returns geometries as hex strings to the client >> -- it would be preferable to have this come into the model as either a >>

Re: Sorry...

Russell Keith-Magee wrote: > The branches are all independent, and depending on how active the > branch is, a branch may not be up to date with the trunk, let alone > other branches. If one branch were to cleanly merges into another, I > would be extremely surprised - doubly so for the more