Re: get_FOO_basename() for FileFields

herbert wrote: > as i said ... i want to use it in my templates I may recommend to create a general-purpose template filter: @register.filter def basename(filename): return os.path.basename(filename) and then use it as: {{ object.file|basename }} To me it feels very Djan

Re: Upcoming changes to the Django admin

Jacob Kaplan-Moss wrote: > Edit-inline is also going to be moved out into the admin declaration, Edit-inline was also useful outside of the admin, in manipulators. Are there any plans to have newforms handling this or this will become a purely admin functionality? --~--~-~--~~-

{% url %} for generic views (proposal)

Hello! I was lazily thinking about making {% url %} and "reverse" to work for generic views ("GV"). The main problem why reversing doesn't work for GV is that it relies on view's name to be unique while GVs obviously have the same name for many URLs (that makes them "generic"). Hence a signat

Re: {% url %} for generic views (proposal)

Jacob Kaplan-Moss wrote: > I've been thinking about this a bunch myself. I came up with some > ideas similar to yours, but so far they're just in my head. I'll try > to write 'em up, but in the time being I'd love to see you (or > someone) start hacking on some code! Ok! For the reference: http:

Re: newsessions

Michael Radziej wrote: > But something else must go wrong in your case, as the chance to get the > same session ids should be so tiny that you really shouldn't reports > from your users. Comments say that the random number generator is > seeded when the server process starts, and it's seeded with

Re: newsessions

Michael Radziej wrote: > Beginning with python2.4, the seed also uses os.urandom() when available, so > it starts to get safer. Uhm... But it still happens only once on first module import. So it's not safer at all. > I'm not sure whether it's a good idea to add periodic reseeding. Why not? I

Re: newsessions

ak wrote: > Ivan, although reseeding still not guarantees that there may be no > duplicates as INSERTing does, isn't it ? Yeah... I actually don't object to your approach at all, I'm just guessing why random numbers could become... u

Re: {% url %} for generic views (proposal)

Malcolm Tredinnick wrote: > I'd been slowly arriving at the same solution for a related set of > problems. I was going to whack in another optional (fourth) argument to > the tuple That was actually the second part of my proposal :-) >, but, you're right that a function call here makes things a

Re: {% url %} for objects

Adrian Holovaty wrote: > I'm a strong -1 on having generic-view-specific permalink functions > and template tags like this. This solution goes after the symptoms > rather than the fundamental problem, which is that the current reverse > URL implementation cannot handle multiple URL patterns for th

Re: {% url %} for generic views (proposal)

Malcolm Tredinnick wrote: > Extending the URL resolving system is easier if we have an object to > work with instead of a tuple for those entries. Ah, I see it. However let's make it a separate issue. I'm afraid that if we start solving "{% url %} for generic views" issue with the "urlpatterns

Re: {% url %} for generic views (proposal)

Malcolm Tredinnick wrote: > Relax, Ivan. Changing the call from a tuple to url(...) is a ten line > change in django/conf/urls/defaults.py. Uhmmm... Pardon me, what is the change you are taliking about? :-) I actually didn't mean any specific code changes, just was worried about t

Re: {% url %} for generic views (proposal)

Ivan Sagalaev wrote: > Uhmmm... Pardon me, what is the change you are taliking about? :-) Ok, I see now your post in this thread later. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers&qu

Re: newforms: better table markup

James Bennett wrote: > Another possible improvement would be -- since we're outputting XHTML > here -- to also include the wrapping around the > output, since the 'tbody' element is not implied in XHTML (though > we're not providing the wrapping , or the wrapping > in as_list(), which seems weir

Re: Slight (backwards-incompat) change to {% url %} tag

SmileyChris wrote: > Like you mentioned, it's quite a specific use-case for requiring a > variable in the {% url %} tag. To solve that case, just use > django.core.urlresolvers.reverse in your view and pass the url rather > than leaving it to the template to resolve. > > -0 I'm -0 on this too wi

Re: Slight (backwards-incompat) change to {% url %} tag

Malcolm Tredinnick wrote: > I thought all those discussion had been settled. There didn't seem to be > any serious technical objections to named urls -- which both Adrian and > I thought were a good approach -- so that's now in the tree. Which are > still the open issues? I remember of asking Adr

Re: newforms and unicode/bytestrings

Malcolm Tredinnick wrote: > I applaud Adrian's attempts to be unicode-aware from the get go, but > it's also cost a bit of sleep lately trying to debug things. Having > spent most of my free time over the last three days looking at this > exact set of problems, I'm beginning to think we should jus

Re: newforms and unicode/bytestrings

Adrian Holovaty wrote: > I'm 100% for that. Let's do it. If you think a branch would be better > for this, we can make that happen, too. Yes, that would be handy. Malcolm asked about 'git' and 'cogito' which, I assume, has something to do with automated patch control but I never seen that :-).

Re: newforms and unicode/bytestrings

Malcolm Tredinnick wrote: > Do you use git or cogito? I can put my repository up if you want to play > along at home over the weekend. I guess I could also make it subversion > accessible, although that will take more than the three minutes a git > repository would (still, git -> subversion isn't

DATABASE_CHARSET

Hello everyone! Malcolm has introduced DATABASE_CHARSET in changeset 4971[1] in a unicode branch. If I remember correctly this setting was needed if we have out internals in byte strings. But if internals are in unicode we (theoretically) can feed them as utf-8 or even in pure unicode to a da

TEMPLATE_CHARSET

from developers who we are forcing effectively recode all their template files (and may be change text editors etc.) May be a TEMPLATE_CHARSET setting will be useful? -- Ivan Sagalaev, trading charset settings for food --~--~-~--~~~---~--~~ You received this me

Re: DATABASE_CHARSET

Malcolm Tredinnick wrote: > The only reference to DATABASE_CHARSET in that changeset was an > accidental leftover in the postgresql (psycopg1) backend. That was an > error. I removed it in r4972. :-) Great! --~--~-~--~~~---~--~~ You received this message because y

Re: TEMPLATE_CHARSET

Malcolm Tredinnick wrote: > I'm not so much worried about the one-off conversion (after all, it's > for those peoples' benefit that we're doing this) as much as filesystems > that store in a particular encoding by default. There's no reliable, > non-expensive way to automatically detect the file

Re: TEMPLATE_CHARSET

Gabor Farkas wrote: > but what i don'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. This is in many cases an emotional issue. Developers get

Re: Django is really starting to muddle MVC, and it has me concerned

Jeremy Dunck wrote: > While I agree that choices is model-y, +1. I actually thought that this (displaying CharField with choices as a type="text") was an obvious bug :-). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Gro

Re: unicode-branch: string handling

Michael Radziej wrote: > gettext('blablabla %s blablalba') % \ > "utf8 bytestring with funny ää chars" > > If gettext returned unicode, python would decode the utf8 encoded > bytestring, again using ASCII as default encoding -> exception galore ;-) I believe we should teach people to start usi

Re: A shortcut for django.core.urlresolvers.reverse

Matt Riggott wrote: > from django.core.urlresolvers import reverse > > def absolute_url(viewname, *args, **kwargs): > return reverse(viewname, args=args or [], kwargs=kwargs or {}) As far as I can tell you don't need 'or []' and 'or {}' since they will be [] and {} already when

Re: Changing django.contrib.auth to make passwords optional

Simon Willison wrote: > I'm working on a new component for my Django OpenID package which will > provide support for associating one or more OpenIDs with a > django.contrib.auth User. As part of this, I want to include the > ability to register for a new user account using an OpenID instead of > a

Re: Changing django.contrib.auth to make passwords optional

Mikhail Gusarov wrote: > Because generation of random password is an ugly workaround. Your solution > requires long comment which explains to the reader of code, why do random > password is needed in first place. A comment in my code is about username part, not password :-). I would indeed be gl

Re: Changing django.contrib.auth to make passwords optional

Simon Willison wrote: > The problem with using a random password is that you can't answer the > question "does this account have a password set?". I need to be able > to answer that question because my OpenID implementation allows users > to associate mupltiple OpenIDs with a single account. I wan

Re: Design Query: How to handle transition to "FloatField version 2"

Malcolm Tredinnick wrote: > (3) Find another name for the new, genuine FloatField. Problem > is, "FloatField" is a really good name. All other names I can > think of are longer or non-Pythonic (e.g. NumericField only > makes sense if you think "SQL", not "Python").

Re: runtest.py slowdowns?

Russell Keith-Magee wrote: > It happened around mid January, as a result of the tests that use > fixtures. Every time a fixture test is executed, it flushes the > contents of the database. Flushing is a slow operation. Unfortunately, > it's also a necessary operation for those tests. > > I agree

new-admin branch vs. FCGI

I'm have a problem when using django new-admin branch with FastCGI. Admin site is unusable. When I'm try to add(change is ok) new flatpage, django dies... it connects to pgsql, locks something and do nothing... :( With mod_python and devel server all ok. But my hosting provider can't install a

Tree structure

I'm need to manage catalog of products in my site with multilevel structure. How can I'm create model, which can have parents of same type as model?.. something like that: class Category(meta.Model): name = meta.CharField(maxlength=500) parent = meta.ForeignKey(Category) def __rep

Re: new-admin branch vs. FCGI

Robert Wittams пишет: > This seems very strange. All that flatten_data should do here is convert > the fields of the object to a database... How did you work out that this > is where it sleeps? I'm try to add "raise PermissionDenied" before and after this string. Before it works fine. After - not

Re: Ditch pluralisation entirely

Eugene Lazutkin пишет: > "Simon Willison" <[EMAIL PROTECTED]> wrote > in message news:[EMAIL PROTECTED] > >>Pluralisation is a nice idea in theory, but in practise it causes more >>problems (in terms of confusion over whether something is singular or >>plural) than it solves. > > > +1 >

Re: Magic removal stuff...

Robert Wittams пишет: > The way that it works now, everything is standard python resolution, > object creation, with the single addition that attributes get to poke at > the class if they want to. > > Anyway, the following look perfectly reasonable and clear to me: > > class Something(Model): >

Re: Proposal: django.models.core/auth should be regular apps

Ian Holsman пишет: > Hi. > I'm using packages. > I think it is a good place to put stuff like package-specific preferences. > > ie.. the preference of the text markup you would like > (bbcode/markup/textile) is stored against the 'text' package. > > if you like delicious/furl/digg is stored ag

Re: magic-removal table name pluralization

Adrian Holovaty пишет: >>In the magic-removal branch most traces of automatic pluralization >>have been removed, but the table names are still pluralized by >>default. I don't think they should be. Is this just a change that's >>meant to happen, but hasn't yet? I seem to remember a thread where >

Re: magic-removal table name pluralization

hugo пишет: >>expressing an opinion. See http://www.djangoproject.com/ >>documentation/contributing/#deciding-on-features for a bit more on >>how we use voting in the Django community. > > Actually rereading that stuff, I think it would be useful to have a > list somewhere where you list people

Re: subdomain specific settings file - new idea

Daniel Poelzleithner пишет: > Amit Upadhyay wrote: > >>Hi, >> >>Wish you all a very happy and fruitful new year! >> >>Djando URL resolution causes some problem with applications hosted in >>different subdomains. Consider www.example.com >>and blog.example.com

Proposal: Django should support unicode strings

I think that Django should support(use only) python unicode strings. For example, at this time django can't capitalize russian strings, when site charset is utf-8...

Re: Proposal: Django should support unicode strings

Maniac пишет: > > Ivan Fedorov wrote: > >> I think that Django should support(use only) python unicode strings. >> >> For example, at this time django can't capitalize russian strings, when >> site charset is utf-8... >> >> > There is a pat

Re: Proposal: Django should support unicode strings

Antonio Cavedoni пишет: >> The patch to #914 is just sitting there because there is no comment >> from the core devs on it - but I think we should do either the >> unicodefication or the patch from #914, with my preference being the >> unicodefication. > > > I’m +1 on the full unicodefication a

Re: Magic - removal branch .. is the API stable yet?

Adrian Holovaty пишет: On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: Is there any reason subtyping and field descriptors need to happen on magic-removal? Could we just test/merge magic-removal and create a new branch for those tasks? Is there anything else but those two tasks left?

Jinja Template Engine

What is Jinja? Jinja is a text-based template language similar to cheetah and Smarty. The syntax and parts of the code where taken from the django template. http://wsgiarea.pocoo.org/jinja/ --~--~-~--~~~---~--~~ You received this message because you are subscribe

Re: {% recurse %} Tag

Armin Ronacher ÐÉÛÅÔ: > Hiho :-) > > Yesterday I tried to implement a sitemap with jinja and i encountered a > missing tag :-) The {% recurse %} tag. > > So whats this all about? A small example is here: > http://wsgiarea.pocoo.org/trac/browser/jinja/trunk/unittests/tec/recurse.py > > The gener

Re: Django sprint at PyCon

Jacob Kaplan-Moss wrote: >You can find those topics and notes from our meeting today >at http://code.djangoproject.com/wiki/PyConSprint06. > > What counts as "crash-level bugs" and "outstanding patches"? I still care very much for Postgres thread-safety ticket (#900). Seeing that Eugene will c

Ouputting data stream

I'm starting to build an application where I need to output large files to the user in chunks to control download speed and to know if the download has succeeded. Django's HttpResponse object treats response as a single string in memory and doesn't allow such things. I plan to modify it to be

Re: Solving multithreading issues with database backends

Eugene Lazutkin wrote: >I just posted patches (trunk and magic) for *Subj*. You can find details >here: http://code.djangoproject.com/ticket/1442. It supersedes tickets >#463, #900, and #1237. The fix was inspired by ticket #1268. > > "class DatabaseWrapper(local)" looks nice :-) Though it ma

Re: Solving multithreading issues with database backends

Ivan Sagalaev wrote: >However this patch revealed pretty nasty show-stopper bug: we leak >connections somewhere. For even a simple view that does only a single >select connection is opened, then closed and then opened again and never >closed. > Found it. Both modpython.py a

Re: Solving multithreading issues with database backends

Eugene Lazutkin wrote: >If I understood you correctly, you proposes to introduce new >USING_THREAD_POOL setting. If it is set, we don't close connection >hoping that it is going to be reused, if the thread itself was reused >for other request. It leaves the connection open until thread dies and >

Re: Solving multithreading issues with database backends

Ivan Sagalaev wrote: >It's not at all that simple in practice > I just recalled one more thing. Cheap pooling (by just not closing connections) wouldn't let you control separately lifetime and quantity of Apache child processes and open db connections. And this is usually ne

Re: Finalizing descriptor implementation

hugo wrote: >I would be +1 on this. Especially since transactions are already in >m-r, so we won't have to worry about multiple save points playing havoc >with our database connection. > I'd say -1. For it's not about database it's about what is expected behavior. Currently I'm never sure what c

Start of week in Admin's calendar

Hello! I was porting javascript calendar from Admin into my application and enhanced it a bit with new boolean pref switching start of week to Monday. To submit this to Django I want to hook this pref somehow to i18n settings but have no idea where it should be and how it's better done in Dja

Re: Character set support for MySQL et al

Geert Vanderkelen wrote: >Since this is probably going to be needed for all DBMS out there, >what about a DATABASE_ENCODING setting which will set the character >set for the connection? > > There is already a ticket with such thing: http://code.djangoproject.com/ticket/952 (even with a pta

Re: Proposal: Move all auth code to django.contrib.auth

Joseph Kocherhans wrote: >Authentication pieces are currently spread out through a bunch of >different modules. I propose that they all move to >django.contrib.auth. I think this will make it easier to understand >where the essential pieces are. > I'm just 1 day after lurking among all these :-)

Streaming uploads to temp files

There is a ticket for making Django not to eat entire file upload in memory http://code.djangoproject.com/ticket/1484 I have it basically working using cgi.FieldStorage which stores POSTed files in temp files. request.FILES items now are classes inherited from dict that have file['file'] retur

Re: Streaming uploads to temp files

Malcolm Tredinnick wrote: >Some number of megabytes per chunk (10, maybe). You are going to execute >a lot of loops and consequent data copying if you are doing multiple >passes per megabyte of data. > > This is the whole point -- to make it in small chunks (but not very small) to conserve mem

Re: Streaming uploads to temp files

Ivan Sagalaev wrote: >With streaming to temp files it takes about a second. > Looks like I was wrong. It appears that cgi.FieldStorage stores content in temp files only when uploaded parts have Content-length set. But browser doesn't set it and FieldStorage reads data with rea

Re: Streaming uploads to temp files

Ivan Sagalaev wrote: >Looks like I was wrong. > And again :-( > It appears that cgi.FieldStorage stores content >in temp files only when uploaded parts have Content-length set. But >browser doesn't set it and FieldStorage reads data with readline() and >stores it in

Re: Streaming uploads to temp files

Ivan Sagalaev wrote: >Then it's not that much irrelevant :-). I'll make a setting for chosing >type of a storage but not for chunk size. > > I've submitted a patch. It even looks faster than email.Message even without disk storage. Can anyone please

Re: Streaming uploads to temp files

luca wrote: >I'm sure you did but just for the record take a look at cherrypy >approach on this: http://www.cherrypy.org/wiki/FileUpload > > They do exactly the same thing: parse uploaded data with cgi.FieldStorage that streams them to a temp file. In fact there is still a problem with this a

Re: Start of week in Admin's calendar

Adrian Holovaty wrote: >I think the best (and simplest) way to hook this into Django would be >a setting. > Yes. And how to access settings.py from js? > Something like FIRST_DAY_OF_WEEK = 1. > > "1" being what, Monday or Sunday? :-) I named it "weekStarstOnMonday" to avoid this confusion. Is

Re: Start of week in Admin's calendar

Christopher Lenz wrote: >In that case, how would you make this dependent on the locale of the >remote user? > > I also thought that this should be tied to i18n. I'm still not familiar how this is exposed in js, could anyone give any guidance where to look? --~--~-~--~~--

Re: proposal: endif, endfor etc assume whatever follows in tag is comment

Eugene Lazutkin wrote: >I think that original idea is cleaner: {% endif start_process %}. > > It doesn't let you specify a general comment in the body of template: {% tree %} {# Custom tag drawing a tree #} --~--~-~--~~~---~--~~ You received this message becau

Re: Validation-aware models: First stab

Gábor Farkas wrote: >or have a new constructor, that takes a dictionary of strings: > >def myview(request): > try: > m = MyModel( request.POSTDATA) > m.save() > except SomethingFailedError: > //handle it > > I also proposed something like th

Re: Streaming uploads to temp files

Istvan Albert wrote: >And by the way, thanks for the nice patch Ivan. I'm (re)writing an >application to Django and would have never done so had there not be >this hope that this issue will be settled properly. > > Then you will like another one :-). This week I&#

HttpResponse with file-like objects

I'm working on a patch (actually I use it for about a week locally) that allows one to put an iterator as a content for HttpResponse. This is intended primarily for large file-like objects that are fed to the user incrementally without reading entirely into memory. This also allows to invent s

Re: HttpResponse with file-like objects

Thanks for the reply, Malcolm! Malcolm Tredinnick wrote: >A relatively minor point: I would prefer to leave something like this >method in place, since otherwise everybody has to implement it >themselves if they care about HTTP compliance. The problem is the >Accept-Charset header in the HTTP re

Re: HttpResponse with file-like objects

Ivan Sagalaev wrote: >I'll create a ticket with a patch later today. I somehow missed that >looking at the code may help people understand things :-) > > Here it is: http://code.djangoproject.com/ticket/1569 Patches both for trunk

Re: HttpResponse with file-like objects

Istvan Albert wrote: >2. I'm commenting here as an outsider, but looking at the patch it >seems that the _is_string attribute is unnecessary, all it seems to be >used only to forbid certain methods, > Yes, this is its intention. > like writing, but why not let them >happen? > > As I already an

Re: HttpResponse with file-like objects

Istvan Albert wrote: >but it is not an arbitraty iterator one is writing to, it is the the >HttpResponse, why couldn't it handle new content being added just >because some content is present as an interator? once it exhausts the >original iterator it could continue on (if new content was added af

Re: HttpResponse with file-like objects

Istvan Albert wrote: >suppose one wants to return content created by two generators ... they >could wrap it themselves into a single one but why not write it both to >the response and let that iterate thru each, > > What if they want three? :-). I should say that it's still looking theoretical

Re: Connections not being closed in m-r

Jacob Kaplan-Moss wrote: >Now, it's not that closing these connections at the end of each >request is bad per se, but it is the case that creating new >connections to PostgreSQL is actually pretty expensive, and so >reusing connections gives a small but measurable performance >increase. >

Re: Connections not being closed in m-r

Jacob Kaplan-Moss wrote: >It's not pooling per se; it's persistent connections. What happens >is that when the request ends the Apache process isn't gc'd so the >connection stays open. When the next request comes in to the same >child, the connection is reused. > > How can this work? Dj

Re: Connections not being closed in m-r

Adrian Holovaty wrote: >Django has closed the database connection on every request for as long >as I remember. The very first open-source version had it -- >http://code.djangoproject.com/browser/django/tags/notable_moments/ipo/django/core/handler.py#L32 >-- and we had that db.db.close() for every

Re: Connection pooling

JP Farias wrote: >Hmmm... Some question come to my mind now... > >1. Does django uses only one connection for the whole process? > >2. Does it open and close a connection once for every request? > > The second is true. >3. Can django handle many requests at once (multi-threaded or something >e

Re: Reverse URL lookup implementation

Adrian Holovaty wrote: >Ideally there'd be a template-tag interface to this. Something like: > >{% link 'path.to.month_view' 2005 'apr' %} >{% link 'path.to.person_view' state='il' name='adrian' %} > > It's unbelievable :-). I was thinking about it just 15 minutes ago but only with 'ur

"Streaming" patches

May I kindly ask some attention (especially commiters' :-) ) to a pair of tickets that enable uploading and downloading large files: http://code.djangoproject.com/ticket/1484 - request part http://code.djangoproject.com/ticket/1569 - response part I use them both on a daily basis in two project

Re: "Streaming" patches

Maniac wrote: >I just saw that Adrian has now commited the "response" part so unified >patch is not needed anymore. I'll update "request" patch for new lines >count (and try to fix code styling issues as I keep writing it wrong >:-( ). > > Done --~--~-~--~~~---~--~-

Re: Multiple Authentication Backends (updated)

Joseph Kocherhans wrote: >The authentication api has been simplified into 5 functions in >django.contrib.auth.utils > >authenticate(request) >Returns a user if valid credentials were found in the request. > >login(request, user) >Persist a user id and a backend name in the session. This way a use

Re: SlugField utf-8 support

James Bennett wrote: >Even when I copy/paste that URL (which I had to do, because my >web-based email client didn't recognize that the Cyrillic portion of >it was part of the URL) into Firefox, the URL encoding turns >"çÌÁ×ÎÁ_ÓÔÒÁÎÁ" into >"%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D1%80%

Re: Media support enhancement

Victor Kropp wrote: >I'm a student from Saint-Petersburg, Russia. > Hi! :-) >2. Improve ImageField. It should allow deleting files > Note, that there is an old ticket about this: http://code.djangoproject.com/ticket/369 and it's wontfixed. So it might be hard to persuade core devs to include t

Generic object_list with a filter

Currently generic view "object_list" can't filter the list by some parameter in an URL. In other words this doesn't work: (r'articles/tags/(?P[a-z]+)/', 'django.views.generic.list_detail.object_list', {'queryset': Article, 'slug_field': 'tags__slug'}) One solution is to use "obj

Re: End-user defined fields, how would you approach it?

t; > The model that requires custom fields is for example Person. They > might want a custom field to store address, blood type, or any other > thing. > > MANY THANKS in advance! Have a nice sunday! > Bernardo Pires > Bernardo, Hello. For other options checkout this guid

Re: End-user defined fields, how would you approach it?

On 01/29/2012 09:16 PM, Etienne Robillard wrote: > > >>> For other options checkout this >>> guide:http://stackoverflow.com/a/7934577/497056 >>> >>> Best regards, >>> Ivan Kharlamov > > Probably a really mediocre reference assuming its o

Re: End-user defined fields, how would you approach it?

On 01/29/2012 09:39 PM, Etienne Robillard wrote: > On 01/29/2012 12:31 PM, Ivan Kharlamov wrote: >> On 01/29/2012 09:16 PM, Etienne Robillard wrote: >>> >>> >>>>> For other options checkout this >>>>> guide:http://stackoverflow.com/a/7934

Re: Revisiting multiline tags

On 02/24/2012 01:29 PM, Chris Northwood wrote: > A +1 from me too, I've really felt the pain on this when doing i18n > templates, I understand the aesthetics, but the aesthetics of > obscenely long tags is also bad imo... > > On 24 February 2012 09:23, Shawn Milochik wrote: >> On Fri, Feb 24, 201

Re: Redesign of djangoproject.com?

ded) fixing issues, so when you make a repo, please let us know, so I can follow the project. Thanks for the grate job in advance! Ivan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develo

Re: Must a Django Database Support Migrations?

wing the Zen of Python and making migrations the "one obvious way to do it" and turning them off the not obvious way. Ivan On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin wrote: > > My thoughts in brief on this: > > - Database backends don't support mig

Re: #717 (If-Modified-Since checked for exact match) should be fixed

On 09/22/2010 12:13 PM, Luke Plant wrote: On Tue, 2010-09-21 at 11:40 -0700, julianb wrote: Uuh, so what's with this? Nothing happened with the ticket and no further comments here either... :( I accepted it on Trac, please see my comments there. Also, you mentioned about the 'condition decora

Re: ANN: Improving our decision-making and committer process

Hello Jacob and everyone. On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote: Starting today, we're going to be making some minor but significant changes to the way the Django core committer team "does business." That's about time :-). Congratulations and thank you! I have a comment and a sugges

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 01:40 AM, Chuck Harmston wrote: In my world, the "accepted" status should only be used in one circumstance: when a person is actively developing under or maintaining a patch for the ticket. It's an indicator that someone has taken ownership of a ticket, to prevent duplication of eff

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 03:46 AM, Russell Keith-Magee wrote: Accepted tickets can be: * Purely accepted, indicating that someone has verified that the problem exists, but not how to solve it * Accepted with a patch that is wrong in some way (e.g., fixing the symptom, not the problem) * Accepted wi

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 01:22 PM, Russell Keith-Magee wrote: So, let me be clear on what you're proposing: you acknowledge that the triage process is backlogged. Your proposal is to put extra workload onto the core team - the one group that is already a bottleneck in the process. Pretty much. I just don'

Refactoring and file-like interface for HttpRequest

Hello everyone! During a sprint before 1.2 I was proposing to commit my ticket [9886] that deals with adding a .read() method to HttpRequest. Adrian suggested that it was too late then and it's better to bring it up during 1.3 cycle. So here it is. Basic summary of changes is in the first co

Re: Refactoring and file-like interface for HttpRequest

On 10/02/2010 01:54 AM, Jacob Kaplan-Moss wrote: On Fri, Oct 1, 2010 at 4:46 PM, Ivan Sagalaev wrote: During a sprint before 1.2 I was proposing to commit my ticket [9886] that deals with adding a .read() method to HttpRequest. Adrian suggested that it was too late then and it's bett

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/20/2010 11:51 PM, Mikhail Korobov wrote: #12815 is about introducing TemplateResponse. Is the patch with 'render' shortcut returning just HttpResponse acceptable? I think that TemplateResponse is less useful after class-based views make their way into trunk so 'render' shortcut shouldn't bo

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 01:39 AM, Mikhail Korobov wrote: 1. Developer writes a view and want to reuse it (e.g. change the context). My assumptions was: a) Class based views are now the recommended way to write reusable views This is where our views differ. I have to admit that I didn't follow closely t

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 11:10 AM, James Bennett wrote: Django cares about whether your views meet the following criteria: 1. Is a callable object. 2. When called, accepts an instance of HttpRequest as its first positional argument. 3. When called, returns an instance of HttpResponse or raises an exception

<    1   2   3   4   5   6   >