Re: Possible regression with serializers in 1.4

On 12.03.2012, at 08:19, Dan Fairs wrote: > Hi, > > I'm working on porting a large codebase to 1.4 (using the rc), and have run > into what appears to be a regression in the serializers. I wanted to run it > past some eyes here before I raise a ticket. > > The Python serializer's

Re: release blocker in 1.4rc2 ?

On 21.03.2012, at 04:56, s wrote: > Hi all, > I just opened https://code.djangoproject.com/ticket/17944, not sure it's > should be marked as release-blocker, please could some core-developer check > it ? > > The ticked has 1.4beta1 release, there is no rc2 in the list > I just added

Re: Test runner with search

On 14.06.2012, at 12:35, Chris Wilson wrote: > Hi all, > > I've made some improvements (in my view) to the DjangoTestSuiteRunner. I > got tired of having to remember my test class names and of typing so much: > > ./manage.py test binder.BinderTest.test_can_create_users > > This new version

Re: Test runner with search

On 16.06.2012, at 08:29, Russell Keith-Magee wrote: > On Thu, Jun 14, 2012 at 6:51 PM, Anssi Kääriäinen > wrote: >> On 14 kesä, 13:35, Chris Wilson wrote: >> >> A big +1 to easier running of single tests. I haven't checked

Re: Breaking out localflavor

On 16.08.2012, at 23:26, Adrian Holovaty wrote: > I'd like to move all Django localflavor code into a separate package, > distributed separately from Django the framework. +1 > PROPOSED SOLUTION > > I think it makes most sense for there to be country-specific packages, >

Re: Breaking out localflavor

On 16.08.2012, at 23:38, Russell Keith-Magee wrote: > On Fri, Aug 17, 2012 at 5:26 AM, Adrian Holovaty wrote: >> I'd like to move all Django localflavor code into a separate package, >> distributed separately from Django the framework. > > +1.

Re: Breaking out localflavor

On 16.08.2012, at 23:48, Łukasz Rekucki wrote: > On 16 August 2012 23:42, Jacob Kaplan-Moss wrote: >> On Thu, Aug 16, 2012 at 3:38 PM, Adrian Holovaty wrote: >>> You mean like a magic import thing, right? >> >> Well, Python *does*

Re: ModelForm.Meta.overrides

Simon, > A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm > violently -1 on the whole topic "meta programming form fields after they've > been instantiated", it's a mess. Yes it would be more DRY, but also much > harder to know how the hell the form fields are composed

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

On 28.09.2012, at 05:38, Dan Loewenherz wrote: > On Thu, Sep 27, 2012 at 4:13 PM, Carl Meyer wrote: > Hi Dan, > > On 09/27/2012 04:47 PM, Dan Loewenherz wrote: > > Just updated the ticket. > > > > As I commented, the heuristic for checking if a file has been

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

On 06.10.2012, at 19:48, Dan Loewenherz <d...@dlo.me> wrote: > Hey Jannis, > > On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel <lei...@gmail.com> wrote: > > On 30.09.2012, at 23:41, Dan Loewenherz <d...@dlo.me> wrote: > > > Many backends don't support

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

gt; > On Sat, Oct 6, 2012 at 10:48 AM, Dan Loewenherz <d...@dlo.me> wrote: > Hey Jannis, > > On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel <lei...@gmail.com> wrote: > > On 30.09.2012, at 23:41, Dan Loewenherz <d...@dlo.me> wrote: > > > Many backends don't

Re: proposal: post-collectstatic signal

On 11.11.2012, at 17:09, Justin Holmes wrote: > My sense is that there are a growing number of use cases, but the one that I > currently have in mind is for django-coldbrew. I want to be able to > compile all the coffeescript in a project during the collectstatic

Re: clarification of API backwards-compatibility policy

On Tue, Feb 19, 2013 at 10:56 PM, Carl Meyer wrote: > Hi, > > I was just about to tell someone on IRC that Django's > backwards-compatibility policy only applies to documented methods and > attributes (which is how I'd always understood it), but when I actually > went to look

Combine localflavor apps again

Hi all, I'd like propose to combine all the django-localflavor-* packages - that were moved out of contrib a while ago - into a new "django-localflavor" package. None of the current maintainers would lose the commit bit. I'm ready to do the heavy lifting for that. Ever since the localflavor

Re: Combine localflavor apps again

On 21.05.2013, at 15:06, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > 2013/5/21 Jannis Leidel <lei...@gmail.com> > I'd like propose to combine all the django-localflavor-* packages - that were > moved out of contrib a while ago - into a new "d

Re: Combine localflavor apps again

On 21.05.2013, at 20:00, ptone <pres...@ptone.com> wrote: > > > On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote: > Hi all, > > I'd like propose to combine all the django-localflavor-* packages - that were > moved out of contrib a while ago - int

Re: Combine localflavor apps again

On 24.05.2013, at 19:28, Trey Hunner <t...@treyhunner.com> wrote: > On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote: > So what I propose to fix this is simple: > > - combine the localflavor packages into one Python package again, call it > django-loca

Re: Migrations, commands and syncdb

On 30.05.2013, at 20:03, Andrew Godwin wrote: > Hi everyone, > > I'm starting to plan out the commands for the new migrations stuff in Django, > and I've hit something of an impasse trying to decide which option to go for. > > Short background: South modified syncdb to

Status of localflavor recombination

Hi all, I'm writing you today to report on the status of the recombination of the localflavor app I've proposed a little while ago on the developer list: https://groups.google.com/d/topic/django-developers/vxCStIvpXc4/discussion To recap: we've handled the handover of the localflavor app to

Re: Status of localflavor recombination

Quick update: The maintainers of the non-Django localflavors (Greece and Lithuania) both agreed to join in, too! \o/ Best, Jannis On 09.06.2013, at 13:33, Jannis Leidel <lei...@gmail.com> wrote: > Hi all, > > I'm writing you today to report on the status of th

Re: Reconsider 20383: limited contexts for makemessages

On 05.07.2013, at 13:57, Ned Batchelder wrote: > On 7/4/2013 5:40 AM, Benjamin Wohlwend wrote: >> Hi, >> >> I recently hit a problem where I have to provide translations for a reusable >> app. In German (and most other languages, except English, it seems), there >>

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

On 14.07.2013, at 01:41, Ramiro Morales wrote: > Hi all, > > Ticket [1]8713 is tracking removing dependency of Django core on contrib > apps code. > > One of the action items enumerated there is the fact that > LiveServerTestCase makes use of django.contrib.staticfiles'

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

On 14.07.2013, at 15:16, Jannis Leidel <lei...@gmail.com> wrote: > > On 14.07.2013, at 01:41, Ramiro Morales <cra...@gmail.com> wrote: > >> Hi all, >> >> Ticket [1]8713 is tracking removing dependency of Django core on contrib >> apps co

Re: Deprecate FCGI support in Django 1.7

On 14.07.2013, at 21:17, Florian Apolloner wrote: > Hi, > > I'd like to get rid of everything FCGI-specific in Django sooner or later > (rather sooner). Flup isn't maintained since a long time and there is no > ticket tracker to report stuff. Graham pointed out that if

Re: Deprecate admindocs?

On 25.07.2013, at 14:29, Aymeric Augustin wrote: > Hello, > > I'd like to deprecate admindocs. Here are my reasons: > > 1) It's called the "documentation generator", but it only operates on > docstrings. This promotes the idea that docstrings are

[ANN] django-localflavor 1.0 release

Hi all, As proposed two months ago [1], I just released django-localflavor 1.0 with all "local flavors" recombined. This fixes the failed handover of the django.contrib.localflavor app to the broader community with the per-country django-localflavor-* apps before the Django 1.5 release. Those

Re: Proposal for 1.2: Improved URL system

Hi LeafStorm, > Okay, I guess I can live with that. Maybe, if I can write a patch > implementing this in a completely backwards-compatible way, I'll > propose it again for a later version (earlier in the release cycle). In the meantime you might want to have a look at Surlex, Cody Soyland's

Re: Advocacy for Email-01 (email backends)

>>> I'm keen to see a resolution to this problem. To that end, I'm >>> interested in hearing specific criticisms or concerns with the >>> current backend proposal. I'm also interested in any alternate >>> approaches to this problem. > > Amusingly it appears that since Jannis got his

Call for review: i18n-improvements

Hi, I'd like to invite everyone to review the patch that contains most of Marc Garcia's i18n-improvements GSoC branch. The latest patch is attached to ticket 7980 [1] or can be found in my i18n branch on Github [2]. The tickets in question are: #1061 Start week day on calendar #2203

Re: Call for review: i18n-improvements

Hi Russell, Thanks for the review :) > * The DEFAULT_TIME_INPUT_FORMATS strings have been removed from the > forms/fields.py module. I know they are no longer required, but they > were previously public symbols. I suspect we need to leave them in, > but mark them as deprecated in docs. Ideally,

Re: r11964 and PendingDeprecationWarning

Hi Luke, > pinging Jannis - did you see this? Can you have a look at my > suggestion? Mea culpa, this is indeed an issue and I like your solution of using lazy(), since the *_INPUT_FORMATS tuples are only used for iteration. Maby just an odd idea but what happens if someone monkey patched

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

Am 18.01.2010 um 22:26 schrieb Luke Plant: > Hi Harro, > >> Hmm I guess I'll just have to keep on hacking django then.. >> because that 1% case is something I keep running into for every >> project in one way or another. >> And if it was designed for most apps, why was the row level >>

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

Am 18.01.2010 um 22:57 schrieb Alex Gaynor: > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel <jan...@leidel.info> wrote: >> >> Am 18.01.2010 um 22:26 schrieb Luke Plant: >> >>> Hi Harro, >>> >>>> Hmm I guess I'll just have t

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

> As you say - anonymous users are by definition not *authenticated*, > but that does not be that they are not *authorised*. Permissions is > about authorisation, not authentication, and Harro had some good > examples where you want to control authorisation for non-authenticated > users in a

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

Am 19.01.2010 um 16:10 schrieb Luke Plant: > On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote: > >>> I think the best argument in favor of it is using permissions >>> with reusable applications. Say I have a wiki application I >>> write, I don't kn

Django Sprint at sublab in Leipzig, Germany, Jan 23-24 2010

Hi all, We'll be holding a Django development sprint at sublab [1] in Leipzig, Germany on January 23-24 (this saturday and sunday), starting at 10:00 AM (UTC+1). The purpose of this sprint is to finish minor features before the complete feature freeze on January 26, as scheduled on the roadmap

Re: Translation patch and the I18N mailinglist

Am 25.01.2010 um 23:06 schrieb TiNo : Hi, I posted a message [1] to the Django I18N list on the 28th of December. Apparently, it is also the last message to that list. Is the I18N list dead? No, the mailing list isn't dead :) Jannis -- You received this message

Re: 1.2 beta?

Am 26.01.2010 um 12:30 schrieb Florian Apolloner: > I am far away from beeing a commiter, but would like to get some > thoughts about the AnonymousUser permission checks written down (I'll > keep it short to not hijack this thread): By the time I moved > permission checks to the backends I didn't

Re: Manage CSS/JS files in admin views.

Hi Jedie, > In my own project i already have jQuery saved in my own media dir and > i added in my own /admin/base_site.html file. So in some admin views i > have two jQuery included. Isn't Django's media handling capable to help in case you want to use your own version of a JavaScript file

Re: Refining Django admin look proposal

Am 05.02.2010 um 12:03 schrieb Dave Jeffery: > Sorry to completely hijack this thread but would django-mobileadmin be > considered for inclusion to trunk (during the 1.3 timeline)? iPhones and > other mobile devices are getting pretty prolific and I love having the mobile > admin site

Re: admin javacripts

Am 19.02.2010 um 15:31 schrieb Javier Guerra: > On Fri, Feb 19, 2010 at 6:32 AM, Rajeev J Sebastian > wrote: >> On Thu, Feb 18, 2010 at 8:09 PM, Rob Hudson wrote: >>> While certain parts of the admin are (or will be) using jQuery >>> (widgets, etc.)

Summer of Code 2010: students wanted!

Hello everyone, As you may already know, Django was accepted as one of the participating projects of this year's Google Summer of Code. I'll be running the program as administrator again this year, so feel free to get in touch with me if you have questions or problems. For those who aren't

Re: GSoC: App Loading

>>> For the record - I don't think the "multiple versions of a single app" >>> problem is one worth solving. I'm not even convinced it can be solved >>> at all, for all the reasons Florian identified, and then some. >> >> I agree, but IIRC it was quoted as one reason why this feature was >> left

Re: GSoC: App Loading

Am 07.04.2010 um 13:40 schrieb Russell Keith-Magee: > On Mon, Apr 5, 2010 at 5:35 AM, Arthur Koziel wrote: >> Hi, >> I’m going to apply for GSoC with the goal of refactoring the app loading >> [0]. I’ve been looking at Django’s current app loading implementation >>

Re: Static media handling - ticket 12323

Am 27.05.2010 um 17:23 schrieb Luke Plant: > A Django 1.3 proposal. It is a pretty small feature/change in some > ways, but needs some discussion. > > = Motivation = > > This is intended to make it easier to cope with the distinction > between user provided media and developer provided

Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

> To me that would be a nice feature addition. It does, however, bring > into question the fact that a widget, intending to be used on the > public side, would depend on jQuery for its UI. Is Django ready to go > there? Or would an admin-only autocomplete widget be preferred? The jQuery based

Re: Static media handling - ticket 12323

Am 28.05.2010 um 01:27 schrieb burc...@gmail.com: > Hi all, > >> - a media files path resolver -- following a similar directory structure as >> the app templates loader (/media/ vs. /templates/) >> - build_static -- a mangement command that'll collect media files from apps >> from various

Re: Static media handling - ticket 12323

Am 30.05.2010 um 05:54 schrieb BrettH: > +1 on Option 2. > > I have written a basic deployment app (not quite ready for release > yet) that deploys a virtualenv for each version of your project, > roughly equivalent to Google App Engine. I specifically need to split > out the USER_MEDIA so that

Re: Why are admin actions not available as buttons in the change view?

Hi Flo, > I am just wondering why the admin actions are only available through > the dropdown in the changelist and not as buttons in the change view > of the object - this is a much requested feature (see > http://code.djangoproject.com/ticket/5412 and >

Re: Regression problem on admin date format

Am 13.07.2010 um 01:35 schrieb Russell Keith-Magee: >> On Sun, Jul 11, 2010 at 10:36 AM, Antoni Aloy wrote: >>> Hi, >>> >>> I have confirmed the bug with other non speaking people and I have >>> sent an e-mail to django-i18n group to point out the problem. >>> >>> I

Re: proposal: abstract file upload/download handling

Am 19.08.2010 um 01:50 schrieb Waldemar Kornewald: > No comments means it's still not good enough and I'll never get it > into an acceptable shape? :) No, in that case we would tell you :) It's much more likely that nobody had time yet (in the last 3 days) to look at your patch thoroughly.

Re: #12012 Logging: request for comments

On 25.09.2010, at 08:16, Russell Keith-Magee wrote: > Hi all, > > I've just uploaded a first draft at a patch introducing logging into > Django [1]. I'm calling for feedback on this patch. > > [1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff > > This patch is

Re: #12012 Logging: request for comments

On 26.09.2010, at 14:45, Florian Apolloner wrote: > Hi, > > On Sep 25, 1:25 pm, Jannis Leidel <jan...@leidel.info> wrote: >> Given the fact that the current implementation of the app cache does quite a >> few hoops to make it possible to implicitely import the mode

Re: [Contact form] change Ukrainian locale

On 29.09.2010, at 15:44, Jeremy Dunck wrote: > Oleksandr, > I've forwarded this to django-developers@googlegroups.com which is > the more appropriate forum. > > Please join that list to participate in the discussion. > > On Wed, Sep 29, 2010 at 8:31 AM, wrote: >>

Re: Translating Django's documentation

On 13.10.2010, at 04:56, Jacob Kaplan-Moss wrote: > On Tue, Oct 12, 2010 at 9:32 PM, Russell Keith-Magee > wrote: >> There are a bunch of modifications that we want to make to >> docs.djangoproject.com, and providing support for other languages is >> part of those

Re: Translating Django's documentation

On 13.10.2010, at 11:52, Ian Lewis wrote: > On Wed, Oct 13, 2010 at 4:58 PM, Jannis Leidel <jan...@leidel.info> wrote: > > Do you have this uploaded somewhere where I can take a look at it? We will > probably be doing a translation sprint here around the end of next mon

Re: contrib.staticfiles app concerns

Ian, > I thought about this too and had a long thread on Twitter with jezdez about > staticfiles. It occurred to me that adding more apps to contrib was kind of a > bad idea. I know "everyone" uses admin etc. but I was of the understanding > that contrib apps are optional apps for django but

Re: contrib.staticfiles app concerns

> Is staticfiles supposed to put "app/static/style.css" into > "/style.css" or "/app/style.css"? Currently it behaves > like the latter, but if it should behave like Django's templates we > need to fix the code. The latter is correct. E.g. files from apps (/static/*) will be collected at the

Re: staticfiles defaults broke my site

On 02.11.2010, at 03:55, Carl Karsten wrote: > I am not completely sure what is going on, but pretty sure the new > staticfiles thing is colliding with my existing > > urlpatterns += patterns('', > (r'^static/(?P.*)$', 'django.contrib.staticfiles.views.serve', >{'document_root':

Re: Ticket #7817: Extending "with" and "include" tags.

On 03.11.2010, at 12:01, burc...@gmail.com wrote: > Hi Jannis, > > On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel <jan...@leidel.info> wrote: >> On 27.10.2010, at 09:46, SmileyChris wrote: >> >>> On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com>

Re: contrib.staticfiles settings suggestion

On 04.11.2010, at 00:55, Brian Neal wrote: > On Nov 3, 4:12 am, Jannis Leidel <jan...@leidel.info> wrote: >> >> No, MEDIA_* and STATICFILES_* settings aren't the same, the former is for >> user generated content (like file uploads), the latter for general stati

Re: Ticket #7817: Extending "with" and "include" tags.

On 10.11.2010, at 09:20, Gabriel Hurley wrote: > In a fit of coincidental timing, I was just being frustrated by this > very issue with inclusion tags today. I'm +1 on supporting kwargs with > "=". It is in fact *more* familiar to someone who works with HTML to > be able to assign attributes in

Re: Ticket #7817: Extending "with" and "include" tags.

On 10.11.2010, at 11:09, Luke Plant wrote: > On Sun, 2010-10-31 at 16:59 -0700, SmileyChris wrote: >> On Oct 29, 2:22 pm, Russell Keith-Magee >> wrote: >>> If we can introduce the terse syntax while maintaining the old syntax >>> (including the analogous change in

Re: Ticket #7817: Extending "with" and "include" tags.

On 18.11.2010, at 16:04, Luke Plant wrote: > On Wed, 2010-11-10 at 11:34 +0100, Jannis Leidel wrote: > >> Not really, I'm -1 on this and gave a different proposal that doesn't >> get rid of an existing paradigm and would solve the issues for me >> (+0). > > OK,

Re: Backends for i18n in a contrib app - #14974

On 28.12.2010, at 12:32, Marinho Brandao wrote: > But I'd like to suggest that we could make a backend system, like we > have for many other components of the framework. So the developers > could choose between gettext and database or create their own > backends, with their dynamic sollutions.

Re: Backends for i18n in a contrib app - #14974

>> The big issue I see here (at least from what I understand) is that content >> translation and translation of UI elements >> are completely different stories due to the way those content types differ >> in structure and storage. Adding a >> backend system implies having a common API, but I

Re: Backends for i18n in a contrib app - #14974

On 28.12.2010, at 18:33, Marinho Brandao wrote: > Are you happy translating very long "django.po" without can just split > it in many files or just database records stored in cache? It gets the job done, yeah. For complex translations I've used Pootle and Transifex, both of which can

Re: Need advice on ticket #14928 (manage runserver does not allow host name as address)

On 31.12.2010, at 00:25, Łukasz Rekucki wrote: > Hi, > > I'm not sure about resolution for this ticket[1]. Initially this looks > like a regression. On the other hand, it was never documented that > "runserver" accepted anything other than an IP:port pair. > > I don't know how many people

ANN: Translations of Django move to Transifex

Hi all, I'm very happy to announce today the move of Django's own translation efforts to a hosted platform based on the Open Source project Transifex: http://www.transifex.net/projects/p/django/ It will make it easier to submit updates for the 63 translations Django currently has, lower the

Re: ANN: Translations of Django move to Transifex

Am 21.01.2011 um 22:24 schrieb Aljoša Mohorović: > On Fri, Jan 21, 2011 at 9:27 PM, Jannis Leidel <lei...@gmail.com> wrote: >> If there are any questions, please don't hesitate to ask :) > > how will 1.3 release be handled? > should translators use transifex for 1.3 relea

Re: "sl" as language code for slovenian translation incorrect?

On 07.03.2011, at 09:30, Gregor Müllegger wrote: > I just discovered some oddity in the naming of the "sl" (SL - > slovenian) locale. The company I'm currently working for has in-house > translations of some of their apps into the slovenian language and > they use the ISO code "si" (SI) -- which

Re: Trac components cleanup

On 28.03.2011, at 07:56, Julien Phalip wrote: > Now that 1.3 has been released (yay!), I'm reviving this thread to see > if we can make Trac a little more efficient on our way to 1.4. I'll > try to summarise what's been suggested so far in regard to improving > and clarifying the "Component"

Re: Fixing makemessages for Javascript

On 04.04.2011, at 23:15, Ned Batchelder wrote: > Last week I re-encountered the problems with using makemessages on Javascript > files, and lost a couple of half-days to trying to figure out why some of my > translatable messages weren't being found and deposited into my .po files. > After

Re: Fixing makemessages for Javascript

On 09.04.2011, at 16:14, Ned Batchelder wrote: > I've created two patches implementing this strategy, and attached them to > ticket http://code.djangoproject.com/ticket/7704. Thanks Ned, but I'm a bit confused, I thought we agreed that Babel should be the way to go, since adding an own

Re: Fixing makemessages for Javascript

reasonable well, being one of the developers of the latter. > 3) Are there other opinions about the two paths forward? Are there other > options? Not as far as I can see. > I would like very much to get this problem solved. > > --Ned. > > On 4/4/2011 6:42 PM, Jannis Leidel wro

Re: Fixing makemessages for Javascript

On 09.04.2011, at 17:32, Ned Batchelder wrote: > On 4/9/2011 10:43 AM, Jannis Leidel wrote: >> On 09.04.2011, at 16:14, Ned Batchelder wrote: >> >>> I've created two patches implementing this strategy, and attached them to >>> ticket http://code.djangoproje

Re: Fixing makemessages for Javascript

On 14.04.2011, at 15:01, Łukasz Rekucki wrote: > On 14 April 2011 14:41, Ned Batchelder wrote: >> Does anyone else have any opinions on a direction forward to fix this >> problem? At the very least I'd like to make a doc patch for 1.3.1 that >> explains the fragility. >

Re: Fixing makemessages for Javascript

On 14.04.2011, at 14:41, Ned Batchelder wrote: > Does anyone else have any opinions on a direction forward to fix this > problem? At the very least I'd like to make a doc patch for 1.3.1 that > explains the fragility. Yeah, a doc patch sounds like a good plan. Jannis -- You received this

Re: Translation catalog for localflavor must be loaded manually

On 14.04.2011, at 15:36, Fidel Ramos wrote: > On Apr 14, 1:52 pm, Ramiro Morales wrote: >> On Thu, Apr 14, 2011 at 7:51 AM, Fidel Ramos wrote: >>> I included some fields from localflavor.es.forms in a project, and >>> expected the error messages to

Re: Fixing makemessages for Javascript

On 14.04.2011, at 15:54, Ned Batchelder wrote: > On 4/14/2011 9:26 AM, Jannis Leidel wrote: >> On 14.04.2011, at 14:41, Ned Batchelder wrote: >> >>> Does anyone else have any opinions on a direction forward to fix this >>> problem? At the very least I'd l

Re: Fixing makemessages for Javascript

On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote: > I think I agree with Ned here: I can't see the downside to fixing it > on the release branch. "It violates our policy" doesn't count IMO: > it's *our* policy, and we get to break it if there's a good reason. > Making translation in JavaScript

Re: Fixing makemessages for Javascript

On 14.04.2011, at 20:09, Łukasz Rekucki wrote: > On 14 April 2011 18:30, Jannis Leidel <lei...@gmail.com> wrote: >> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote: >> >>> I think I agree with Ned here: I can't see the downside to fixing it >>> on the

Re: deprecation of AUTH_PROFILE_MODULE

On 02.05.2011, at 19:22, Carl Meyer wrote: > On 05/02/2011 11:38 AM, Jeremy Dunck wrote: >> Given a blank slate, what would Auth look like these days? And can we >> work towards that? > > Now, why you gotta get all constructive and forward-thinking and stuff? ;-) > > Here's my list of core

Re: PatchHammer 40,000

Hi all, After having gotten almost 100 emails from patchhammer via Trac in under a minute, I'd like to suggest to be a bit less hammer-y and let actual humans review the patches instead of doing the patch apply check. In my experience attached patches usually only need little modification to

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

On 06.05.2011, at 10:21, Russell Keith-Magee wrote: > On Fri, May 6, 2011 at 3:38 PM, fabian.topfstedt > wrote: >> Hi Eduardo, >> I will definitely write and attach proper tests, but I think there is one >> decision to make first: Are hanging URLFields problem enough

RFC: #12417 - Support for signing (including secure cookies)

Hi all, This is in continuation to Simon's previous efforts about adding tools for easy signing, including secure cookies ([1], [2]). Stephan (who is working on #9200 [3] -- improving the wizard in contrib.formtools) and me just updated the patch attached to ticket #12417 [4] with the

Re: Continued work on a django.contrib.formtools.wizard replacement

On 11.05.2011, at 20:35, David Durham wrote: > On Mon, Apr 25, 2011 at 11:09 AM, Stephan Jäkel wrote: >> Hi everybody, >> >> I want to continue the discussion on the replacement of >> django.contrib.formtools.wizard (previous discussions can be found here: >>

Re: RFC: #12417 - Support for signing (including secure cookies)

On 12.05.2011, at 01:05, Luke Plant <l.plant...@cantab.net> wrote: > On 11/05/11 20:20, Jannis Leidel wrote: >> Hi all, >> >> This is in continuation to Simon's previous efforts about adding tools >> for easy signing, including secure cookies ([1], [2]). >&g

Re: RFC: #12417 - Support for signing (including secure cookies)

On 12.05.2011, at 01:05, Luke Plant wrote: > On 11/05/11 20:20, Jannis Leidel wrote: >> Hi all, >> >> This is in continuation to Simon's previous efforts about adding tools >> for easy signing, including secure cookies ([1], [2]). >> >> Stephan (w

Re: RFC: #12417 - Support for signing (including secure cookies)

n reviewing this standard with cryptographic > security in mind. Fair enough. Jannis 1: http://tools.ietf.org/html/draft-jones-json-web-signature-02#section-7 > > On Wed, May 11, 2011 at 4:05 PM, Luke Plant <l.plant...@cantab.net> wrote: >> On 11/05/11 20:20, Jannis Leidel w

Re: Resetting settings under test

On 13.05.2011, at 15:52, akaariai wrote: > On May 13, 3:41 pm, Jeremy Dunck wrote: >> In general, the TestCase does a good job of cleaning up the >> environment (resetting the DB, etc.), but I've run across an edge case >> that might be worth putting upstream. >> >> I have a

Re: Resetting settings under test

On 17.05.2011, at 17:41, Jeremy Dunck wrote: > On Fri, May 13, 2011 at 10:10 AM, Jannis Leidel <lei...@gmail.com> wrote: > ... >> I've added something related the other day in changeset 16165. >> > > Following up here, Jannis added a patch to a

Re: Resetting settings under test

On Tue, May 17, 2011 at 6:42 PM, Jeremy Dunck <jdu...@gmail.com> wrote: > On Tue, May 17, 2011 at 11:01 AM, Jannis Leidel <lei...@gmail.com> wrote: >>> I was looking more for transaction rollback semantics -- rather than >>> overriding (and then restoring

Re: RFC: #12417 - Support for signing (including secure cookies)

On 13.05.2011, at 07:33, Paul McMillan wrote: > Baseconv is a clever bit of work. It should probably be using our full > base64 charset. We could also shave some digits in the time-limited > output there by subtracting from a more recent fixed value than the > unix epoch, the way the password

Re: RFC: #12417 - Support for signing (including secure cookies)

On 18.05.2011, at 20:19, Jannis Leidel wrote: > On 13.05.2011, at 07:33, Paul McMillan wrote: > >> Baseconv is a clever bit of work. It should probably be using our full >> base64 charset. We could also shave some digits in the time-limited >> output there by subtra

Re: Fixing makemessages for Javascript

On 15.04.2011, at 15:25, Ned Batchelder wrote: Hi Ned, > As you say, Jannis has suggested that a Babel-based solution isn't that much > work. But that work hasn't been done yet. I don't know how much work it is. > It's going to be a larger change to the code base than my patch is, at least

RFC #9200 -- Refactored form wizard

Hi all, Stephan and me are now happy with the latest patch for ticket #9200 which refactors the form wizard in the formtools contrib app to use class based views and the new secure cookies as one of the supported storage backends (a session backend being the other).

Re: RFC #9200 -- Refactored form wizard

> All in all this is fine to go in as far as I'm concerned, but I do > have a few nitpicky things that'd be nice to fix: > > * There's a bunch of code in formtools/wizard/__init__.py (the legacy > wizard, right?). Generally I dislike having a bunch of code in > __init__.py and I thought we were

Re: RFC #9200 -- Refactored form wizard

On 01.06.2011, at 01:37, Luke Plant wrote: > On 30/05/11 10:15, Jannis Leidel wrote: >> Hi all, >> >> Stephan and me are now happy with the latest patch for ticket #9200 >> which refactors the form wizard in the formtools contrib app to >> use class based views

Re: Fixing makemessages for Javascript

On 03.06.2011, at 04:15, Ned Batchelder wrote: > On 5/29/2011 5:40 AM, Jannis Leidel wrote: >> On 15.04.2011, at 15:25, Ned Batchelder wrote: >> >> Hi Ned, >> >>> As you say, Jannis has suggested that a Babel-based solution isn't that >>> much

  1   2   3   >