Re: Django 1.4 roadmap
On Nov 26, 1:19 pm, Aymeric Augustin wrote: > On 24 nov. 2011, at 16:53, Marcob wrote: > > > I realize that this is a volunteer-based project, but I was wondering > > if you have any updates regarding the wiki page for the 1.4 roadmap? > > (https://code.djangoproject.com/wiki/Version1.4Roadmap) > > Hi Marco, > > Unlike previous releases, Django 1.4 didn't get a formal roadmap. So it will > contain the features currently listed in the release notes [1], plus those > that will be added before the release. Aymeric, thanks a lot! Btw this is ok for "what", but for just a really rough idea of "when" a roadmap would be great. You need a date to be late :-) Ciao. Marco. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
BitBucket has full git support btw. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Ax7zncVO2FYJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
My point was the social factor. I mean the GitHub community is quite bigger. It's not big issue if we're using mercurial instead of git. Sure, I prefer git, it's faster and stuff, but it's not a big deal, right now. Anyway, I'm trying to get into making the tests run and if I see some result from my work, will try to figure out some sync between github and bitbucket. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/RJymGD-0e68J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New feature: Defining fieldsets in form class (Ticket #17301)
2011/11/27 Mikołaj Siedlarek : > Hi, > I've just posted a new ticket with everything the feature proposal needs - > motivation, idea and actual implementation. > https://code.djangoproject.com/ticket/17301 > > It definitely needs some discussion, so please -- ask, discuss, criticize, > share some thoughts and one day, hopefully +1. :) Hi Mikołaj, You won't get any argument from me on this one. In my ideal world, Django's admin should just be a light customization of Django's native form capabilities, tied to some nifty model introspection logic. However, as currently implemented, there are plenty of features -- like fieldsets -- that are only available to admin forms. Refactoring this code out of admin, and into base forms is certainly something worth pursuing. Also worth keeping in mind is the intersection of this sort of refactoring with efforts to replace Django's form rendering with a template-based renderer. This was the subject of a Google Summer of Code project this year, and while it hasn't been merged to trunk, there's some obvious potential for overlap with any plans to introduce fieldsets into base forms. >From an quick inspection of your patch, you look like your on the right track -- you've certainly got all the right pieces (tests, docs, and what appears to be a solid initial implementation). The only thing that I would like to see is an attempt to eat our own dogfood -- i.e., to try and replace the admin's custom fieldset tools with this new capabilitiy. Dogfooding is an important step in demonstrating that you've got the API right; given that this is something that is being factored out of admin, actually using it in admin would be a good proof of that concept. Thanks for the great contribution! Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 roadmap
On Mon, Nov 28, 2011 at 5:05 PM, Marcob wrote: > On Nov 26, 1:19 pm, Aymeric Augustin > wrote: >> On 24 nov. 2011, at 16:53, Marcob wrote: >> >> > I realize that this is a volunteer-based project, but I was wondering >> > if you have any updates regarding the wiki page for the 1.4 roadmap? >> > (https://code.djangoproject.com/wiki/Version1.4Roadmap) >> >> Hi Marco, >> >> Unlike previous releases, Django 1.4 didn't get a formal roadmap. So it will >> contain the features currently listed in the release notes [1], plus those >> that will be added before the release. > > Aymeric, thanks a lot! > > Btw this is ok for "what", but for just a really rough idea of "when" > a roadmap would be great. > > You need a date to be late :-) Hi Marco, I can't disagree. We've been really bad at managing the 1.4 cycle. Members of the core team have stood up at two DjangoCons (EU and US this year) an expressed an interested in "faster" release cycles... and then we've managed to completely fail in delivering on that idea. I'd say we're certainly overdue for cutting an alpha and starting the release machinery rolling. What we're missing at this point is someone on the core team with the spare resources to manage the release process. Unfortunately, this is one of those areas where Django falls victim to being a volunteer project. None of the core team are paid to work on Django, so there's no workforce that we can compel to deliver on a timeline, and punishing volunteers isn't an especially a productive activity. So -- what we need is for someone in the core team who is able to find the resources in their schedule to commit to shepherding a release. Speaking for myself, I know that this almost certainly isn't going to be me -- my work life has got a lot more complicated since the 1.3 release. Any practical suggestions on how we can improve on this situation will be gratefully accepted. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New feature: Defining fieldsets in form class (Ticket #17301)
Hi Russel, My patch obviously was not posted to be merged into trunk in it's current state. It is meant to be a message "i'd like to do that, seriously". Now that I see general community support I can perfect it. There several more things I'd like to do, mainly: 1. "Dogfooding" (which is a great phrase I've never heard of :) my concept by modyfying admin; 2. `classes` option, just like the one in current admin fieldsets; 3. Several fields in one row, once again like in current admin; 4. Write some more documentation in my poor-English and ask someone nicely to translate it to real-English This features should be complete by the end of the week, and then we'll see. PS. If there's anyone willing to edit some really bad writing, please contact me. Thanks, Mikołaj -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/PuQPYmpFGqEJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
On Sat, Nov 26, 2011 at 1:33 AM, Vinay Sajip wrote: > I'm working on a port of Django to Python 3. I'm getting close, and in > terms of > test coverage pretty much almost there, but a few remaining test > failures are > eluding me, and I could probably use some help to speed things up. Hi Vinay, This is awesome work! Getting down to less than a dozen test failures is amazing progress. I don't have anything specific to add beyond that; I just wanted to let you know the core team (or, at least, this member of the core team) has seen your work, and is really encouraged that people are making serious inroads into making Django on Py3 a reality. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New feature: Defining fieldsets in form class (Ticket #17301)
2011/11/28 Mikołaj Siedlarek : > Hi Russel, > My patch obviously was not posted to be merged into trunk in it's current > state. > It is meant to be a message "i'd like to do that, seriously". Now that I see > general > community support I can perfect it. There several more things I'd like to > do, mainly: > > "Dogfooding" (which is a great phrase I've never heard of :) my concept by > modyfying admin; Apologies for the confusion. For those not familiar with the term: http://en.wikipedia.org/wiki/Eating_your_own_dog_food > `classes` option, just like the one in current admin fieldsets; > Several fields in one row, once again like in current admin; > Write some more documentation in my poor-English and ask someone nicely > to translate it to real-English Don't worry too much about this bit. The hard part of writing documentation is always the first draft, and coming up with a good set of examples to use in that draft. If you can get to a first draft that is roughly understandable (and the first draft you've got in your patch is certainly good enough), it can get cleaned up on editing when it is committed. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
Hi Vinay, Many thanks for your efforts so far, as you can imagine I have a few questions, both procedural and technical. I should note though that I haven't reviewed all your changes in detail yet, since they are.. massive :) I'm a bit concerned that you didn't get in touch with us before you started with the work, since tracking the changes would have been easier. FWIW, Martin von Löwis, Alex and me would be those you can ask if you need any further help, usually also on IRC in #django-dev. On 25.11.2011, at 18:33, Vinay Sajip wrote: > I'm working on a port of Django to Python 3. I'm getting close, and in > terms of > test coverage pretty much almost there, but a few remaining test > failures are > eluding me, and I could probably use some help to speed things up. > > I started with the features/py3k branch on the BitBucket Django mirror > (the one > at https://bitbucket.org/django/django), but whereas that was > approaching from > a point of view of running 2to3 over the Django codebase, I've > followed my > preferred strategy of aiming for a single codebase for 2.x and 3.x. > (This > strategy worked well for the virtualenv and pip ports which I did a > while ago.) Have you worked on top of the current py3k branch in SVN (which should be mirrored in the Mercurial repo)? Also, did you get in touch with Martin von Löwis who has previously spearheaded the porting efforts for a while and has been granted commit privileges to the py3k branch? I'm asking simply because I'm wondering how we should get your changes reviewed and committed to the official repo, it's a bit like facing a done deal. > I've updated the django.utils.py3 module to add whatever I needed, > gratefully > borrowing ideas from Benjamin Peterson's six project as needed. Aha, meaning that you've copied over parts of the six module? Would you (also as a way for helping out Django users later to port their code) recommend putting six completely in Django? We've previously done that with other libraries, e.g. unittest2. > I run the standard test suite on the codebase using Python 2.7.2 and 3.2.2 > (I'm > not supporting 3.0 or 3.1 - 3.2 is stable, 'callable' came back and is > liberally > used in Django, and I'm not sure it's worth bothering with support for > 3.0/3.1. Yeah, we've talked about that and don't consider 3.0 or 3.1 to be sensible to support in the future (given obvious bugs and/or lack of support from Python core). > The branch is available at > > https://bitbucket.org/vinay.sajip/django (features/py3k branch) > > Latest test result summaries are as follows: > > 2.7.2: ran 4229 tests in 301.690s > OK (skipped=71, expected failures=3) > > 3.2.2: Ran 4174 tests in 303.619s > FAILED (failures=6, errors=2, skipped=78, expected failures=2, > unexpected successes=1) > > I think these results are encouraging, and I hope you agree! I added 7 > skips, mostly these are due to different representations on 2.x and 3.x e.g. > u'foo' vs. 'foo'. Indeed they are, so the next step is to review them bit by bit and align it with the work done before your work. Ideally committing it to SVN. Jannis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
On Nov 28, 1:04 pm, Jannis Leidel wrote: > > I'm a bit concerned that you didn't get in touch with us before you > started with the work, since tracking the changes would have been > easier. FWIW, Martin von Löwis, Alex and me would be those you can > ask if you need any further help, usually also on IRC in #django-dev. > Well, it's only been about a week of elapsed time. I always start these sort of ports on an experimental-and-potentially-throwaway basis, and I didn't know until I started how things would progress - and well, once I was into it, I was just dipping in and out amidst doing other things, so I suppose I just focused on the task at hand rather than the big picture. > Have you worked on top of the current py3k branch in SVN (which should > be mirrored in the Mercurial repo)? Also, did you get in touch with > Martin von Löwis who has previously spearheaded the porting efforts > for a while and has been granted commit privileges to the py3k branch? Yes, I used the BitBucket repo and the features/py3k branch within that. I didn't contact Martin directly about this, as my approach is a little different to what he had started, in that Martin's approach is based on running 2to3 on the code to get new 3-friendly code, whereas my approach is to have a single codebase with runs on 2.x and 3.x. It's more than a small philosophical difference - I value the information that 2to3 gives, but it just acts as the driver for porting "by hand" with my standard development tools. > I'm asking simply because I'm wondering how we should get your changes > reviewed and committed to the official repo, it's a bit like facing a > done deal. Well, I undertook the approach you mentioned in the "Python 3 and you" thread back in September, which was to look at the features/py3k branch and focus on test failures. Of course I didn't use the py3ktest script (which involves the 2to3 pass), running just plain runtests.py instead. And it's only been a little over a week, so it can't be that hard to merge the changes assuming you agree with the approach. Even if you start over, it's still less than a person-week of effort, right? > Aha, meaning that you've copied over parts of the six module? Would you > (also as a way for helping out Django users later to port their code) > recommend putting six completely in Django? We've previously done that > with other libraries, e.g. unittest2. I have no strong views on using six directly as a dependency, and I've only used small parts of it (with_metaclass, reraise) directly. It's certainly not needed as a dependency - you can see that the django.utils.py3 module (which provides the functionality needed by Django) is pretty small. > Yeah, we've talked about that and don't consider 3.0 or 3.1 to be sensible to > support in the future (given obvious bugs and/or lack of support from Python > core). Good, that rhymes with my thinking on it :-) > Indeed they are, so the next step is to review them bit by bit and align > it with the work done before your work. Ideally committing it to SVN. Right, and I can provide some help with that (other work permitting). Possibly some work could be done to look at merging the default branch with the features/py3k branch, as a first step - presumably default tracks SVN trunk closely. The main thing is to see whether you are comfortable with the single codebase approach (requires some small additional discipline from developers to consider str/bytes issues carefully, do imports from utils.py3 where appropriate, etc. - nothing too onerous). Carl Meyer may be able to chime in with his experience re. pip/virtualenv, which were ported using the same approach a while ago, and have seen maintenance work and new releases since then. Also it's worth looking at the way metaclasses have been done in the port and to see if you can identify any issues. A lot of the changes are pretty mechanical, wrapping literals with u() and b() - nothing too contentious there. Escape character handling esp. in regexes is another area where closer inspection would be worthwhile. The test codebase contained a lot of Unicode literals (i.e. Unicode literals in the source code, which would have been encoded in UTF-8 in the files actually stored on disk) and I have converted these to use Unicode escapes, as this is more portable. Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
On Nov 28, 9:29 am, Kiril Vladimirov wrote: > My point was the social factor. I mean the GitHub community is quite > bigger. It's not big issue if we're using mercurial instead of git. Sure, I > prefer git, it's faster and stuff, but it's not a big deal, right now. Well, it's not as if there's a big team required, and presumably interested parties who can contribute will be subscribed to this list anyway. There probably isn't the kind of need for a lot of back-and- forth, given that the overall approach and some specific implementation decisions are acceptable to the core devs. > Anyway, I'm trying to get into making the tests run and if I see some > result from my work, will try to figure out some sync between github and > bitbucket. Great, we'd like to see what you find. Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New feature: Defining fieldsets in form class (Ticket #17301)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mikołaj, Thanks for your work on contributing to Django! I am a bit skeptical about defining form fieldsets in Python code, as they have no effect on server-side interpretation or validation of form data, they are purely an HTML/presentational issue. I think that in general we should be moving form presentation entirely into templates rather than adding more presentation-related attributes into Python code. There's already work begun on this via a Google Summer of Code project (see #15667 and #16922); there are some barriers to overcome (particularly performance issues with the template engine), but I think it's still the right approach for the long term. And the more form-presentation controls we add in Python code, the more difficult this transition becomes (because we end up with two conflicting methods of defining a forms layout). However, I can see some justification for simple fieldset definitions in the form definition, as a high-level way to group fields. This can allow more flexibility in defining custom reusable form layouts (via templates) that depend on having such field groupings. And it's clear that others want this feature: I won't stand in the way of it if another core developer wants to champion its inclusion. However, I feel quite strongly that even if we add this, we should NOT add the additional "classes" and "fields in a row" features that you mention. Fieldsets themselves are defensible as logical "structure" of the form - these additional features are getting into the arena of trying to fully define HTML layout of a form in Python code, which I think is fundamentally the wrong approach, and makes it more difficult for non-Python-programmer template authors to work with Django forms. Why should forms be an exception to the general rule that HTML and presentation belong in templates? I see the admin as the exception here, rather than as a model for how the forms library should work. The admin's purpose is to create generic customizable CRUD screens for arbitrary models; this is necessarily going to involve defining the available axes of presentation customization, and making it easy to do those particular customizations. That's a very specific use case; it means trading off flexibility for convenience in very simple customizations. That's an appropriate tradeoff for the admin to make in building on top of django.forms; it's not an appropriate tradeoff for django.forms, IMO. In sum: +0 to fieldsets in Python code, -1 to classes and rows defined in Python code. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7TwyAACgkQ8W4rlRKtE2eWiACgnT5afZXt7skGy66pIa4zDTrM kKkAoOoM/VIvJNPFMk0eaROh2DYT7/gv =SdfG -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
On 28.11.2011, at 18:08, Vinay Sajip wrote: > On Nov 28, 1:04 pm, Jannis Leidel wrote: >> >> I'm a bit concerned that you didn't get in touch with us before you >> started with the work, since tracking the changes would have been >> easier. FWIW, Martin von Löwis, Alex and me would be those you can >> ask if you need any further help, usually also on IRC in #django-dev. > > Well, it's only been about a week of elapsed time. I always start > these sort of ports on an experimental-and-potentially-throwaway > basis, and I didn't know until I started how things would progress - > and well, once I was into it, I was just dipping in and out amidst > doing other things, so I suppose I just focused on the task at hand > rather than the big picture. I see, that's absolutely fine, and to be honest, getting so much progress done is definitely a good problem to have :) >> Have you worked on top of the current py3k branch in SVN (which should >> be mirrored in the Mercurial repo)? Also, did you get in touch with >> Martin von Löwis who has previously spearheaded the porting efforts >> for a while and has been granted commit privileges to the py3k branch? > > Yes, I used the BitBucket repo and the features/py3k branch within > that. I didn't contact Martin directly about this, as my approach is a > little different to what he had started, in that Martin's approach is > based on running 2to3 on the code to get new 3-friendly code, whereas > my approach is to have a single codebase with runs on 2.x and 3.x. > It's more than a small philosophical difference - I value the > information that 2to3 gives, but it just acts as the driver for > porting "by hand" with my standard development tools. Ah, that makes sense, in fact your approach is much closer to what I remember doing when pip and virtualenv was ported. In that sense, I'm definitely fine with that. How much of that approach needs to be documented for end users is probably something we can deal with later. >> I'm asking simply because I'm wondering how we should get your changes >> reviewed and committed to the official repo, it's a bit like facing a >> done deal. > > Well, I undertook the approach you mentioned in the "Python 3 and you" > thread back in September, which was to look at the features/py3k > branch and focus on test failures. Of course I didn't use the py3ktest > script (which involves the 2to3 pass), running just plain runtests.py > instead. And it's only been a little over a week, so it can't be that > hard to merge the changes assuming you agree with the approach. Even > if you start over, it's still less than a person-week of effort, > right? Honestly, I'm not sure how hard the merge is, as I'm not sure how much changed. Martin could probably shed some light on it how he wants to deal with it (e.g. svnmerge.py or not). >> Aha, meaning that you've copied over parts of the six module? Would you >> (also as a way for helping out Django users later to port their code) >> recommend putting six completely in Django? We've previously done that >> with other libraries, e.g. unittest2. > > I have no strong views on using six directly as a dependency, and I've > only used small parts of it (with_metaclass, reraise) directly. It's > certainly not needed as a dependency - you can see that the > django.utils.py3 module (which provides the functionality needed by > Django) is pretty small. Fair enough, I just realized that's a discussion we need to have in a separate thread (~"What's the best approach for migrating Django projects from 2.X to 3.X?") that can be handled later in the porting process. When in doubt I would rather use a module like six that has community traction than writing our own though. >> Indeed they are, so the next step is to review them bit by bit and align >> it with the work done before your work. Ideally committing it to SVN. > > Right, and I can provide some help with that (other work permitting). > Possibly some work could be done to look at merging the default branch > with the features/py3k branch, as a first step - presumably default > tracks SVN trunk closely. The main thing is to see whether you are > comfortable with the single codebase approach (requires some small > additional discipline from developers to consider str/bytes issues > carefully, do imports from utils.py3 where appropriate, etc. - nothing > too onerous). Personally I'm fine with it, but as you say, it requires discipline (I broke pip more than once). But it's definitely something that needs some input from the other core devs, and probably a very good documentation of the dos and don'ts. > Carl Meyer may be able to chime in with his experience > re. pip/virtualenv, which were ported using the same approach a while > ago, and have seen maintenance work and new releases since then. Also > it's worth looking at the way metaclasses have been done in the port > and to see if you can identify any issues. A lot of the changes are > pretty mechanical, wrap
Re: Django 1.4 roadmap
On Nov 28, 4:40 am, Russell Keith-Magee wrote: > Any practical suggestions on how we can improve on this situation will > be gratefully accepted. Core has grown, but it seems to me there is a fair amount of cultural and procedural knowledge that more veteran core members have not yet transferred, due to understandable lack of personal bandwidth. Being able to commit to Django-the-codebase does not confer the same knowledge required to cut a release of Django-the-project. Perhaps if James Bennet could do a brain dump, in outline form, of the procedural steps of release on a wiki page to augment the more public focused: https://docs.djangoproject.com/en/dev/internals/release-process/ Determine if there is someone newer to core (or unfamiliar with the release process) who is interested in being mentored in the process. Open a call for current core devs to comment on what in-progress features they want to champion into 1.4 and get a rough self imposed due date. If those cluster nicely, use a soft average of those dates as the target release date for the alpha. Explicitly determine which core-dev will take ownership of which remaining release blockers. I have a few tickets I have in progress, and all I can do from my position, is do my best to prioritize them, and get the top ones wrapped up, rather than have all remain uncompleted. -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New feature: HTTP OPTIONS and improved HEAD for View
> Yeah, that implementation seems preferable. What was the reason for backing > it out? Not sure. What would be the procedure for getting this changed? Open a new ticket, I assume? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Allowing models to influence QuerySet.update
There was an old thread about this at https://groups.google.com/group/django-developers/browse_frm/thread/6e41ee7b08d50710/9cf6375d97bed499?lnk=gst&q=update+signal#9cf6375d97bed499 which fizzled out last summer with no conclusion. (I'd reply to that thread but google groups apparently won't let me reply to something that old.) The ticket is at https://code.djangoproject.com/ticket/13021 I want this feature for much the same reason as Dennis: while there were suggestions in the old thread about ways to avoid DRY in code that is fully under your control, there has "not yet [been] a suggestion that integrates with third party applications without modifying them". A new signal would provide a clean, easy way to do that - and would be easily understood and documented since it would fit the existing pattern of pre_save, pre_delete, etc. If this is going to be "wontfix", it'd be great to at least see that finalized on the ticket, and maybe a note in the docs that QuerySet.update() doesn't send any signals. Thanks, - PW -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
On Nov 28, 5:36 pm, Jannis Leidel wrote: > > Ah, that makes sense, in fact your approach is much closer to what I > remember doing when pip and virtualenv was ported. Right, since I did those ports originally :-) > Honestly, I'm not sure how hard the merge is, as I'm not sure how much > changed. Martin could probably shed some light on it how he wants to deal > with it (e.g. svnmerge.py or not). Sure. > Fair enough, I just realized that's a discussion we need to have in a > separate thread (~"What's the best approach for migrating Django projects > from 2.X to3.X?") that can be handled later in the porting process. When > in doubt I would rather use a module like six that has community traction > than writing our own though. There are areas where the current code needs to do metaclass-based checks, and that involves delving into the specifics of the implementation of with_metaclass. This being the case, I made a modified version of Benjamin's which uses "_DjangoBase" as the intermediate parent class. IMO we need this to distinguish from other classes implemented using with_metaclass from the official six package. > Personally I'm fine with it, but as you say, it requires discipline > (I broke pip more than once). But it's definitely something that needs > some input from the other core devs, and probably a very good > documentation of the dos and don'ts. Having good code coverage helps to spot these potential breakages well before a release (or even a checkin), and Django's extensive test suite is a boon in this regard. Though having worked through the tests, it doesn't seem like the DRY principle is followed as much as it could be ... for example, the same literals being used over and over again in copy/paste fashion, requiring patches in multiple locations to add u() and b() wrappers, for example. I didn't have time to rationalise this, as I was focused more on identifying and fixing failures and errors. Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: I've made good progress in porting Django to Python 3, and could use some help!
On Nov 28, 7:14 pm, Vinay Sajip wrote: > suite is a boon in this regard. Though having worked through the > tests, it doesn't seem like the DRY principle is followed as much as > it could be ... for example, the same literals being used over and > over again in copy/paste fashion, requiring patches in multiple > locations to add u() and b() wrappers, for example. I didn't have time > to rationalise this, as I was focused more on identifying and fixing > failures and errors. Ironically, I notice that I repeated myself in using "for example" twice in the above paragraph ;-) Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 roadmap
On Mon, Nov 28, 2011 at 6:40 AM, Russell Keith-Magee wrote: > So -- what we need is for someone in the core team who is able to find > the resources in their schedule to commit to shepherding a release. > Speaking for myself, I know that this almost certainly isn't going to > be me -- my work life has got a lot more complicated since the 1.3 > release. And that someone will be me. See my post here: http://www.holovaty.com/writing/back-to-django/ I plan on starting this next week. Is there a list somewhere of what needs to get done? If not, I can make it, but obviously it'd be great if that already existed. Adrian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: New feature: HTTP OPTIONS and improved HEAD for View
I assumed I needed the votes here to get going on that. In the past when I've started with a ticket I've been directed here to gather support first. -- Steven On Mon, Nov 28, 2011 at 11:59 AM, Jamie Matthews wrote: > > Yeah, that implementation seems preferable. What was the reason for > backing > > it out? > > Not sure. What would be the procedure for getting this changed? Open a > new ticket, I assume? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 roadmap
On 28 nov. 2011, at 21:33, Adrian Holovaty wrote: > And that someone will be me. See my post here: > http://www.holovaty.com/writing/back-to-django/ Awesome! > Is there a list somewhere of what needs to get done? > If not, I can make it, but obviously it'd be great if that already existed. I don't know how much you've followed the 1.4 development cycle, so please forgive me if I'm stating the obvious. No TODO list exists that I know of. However, a bunch of features have already been added. It'd be interesting if you reviewed the release notes and ensured nothing hurts your feelings. Then, if you're comfortable with this scope, I think we should start the release process as soon as possible. That's what the community expects. At least three core devs, including myself, have expressed their motivation to work on this release. We were just missing someone with enough experience to oversee the process. Best regards, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.4 roadmap
On Nov 28, 9:33 pm, Adrian Holovaty wrote: > On Mon, Nov 28, 2011 at 6:40 AM, Russell Keith-Magee > > wrote: > > So -- what we need is for someone in the core team who is able to find > > the resources in their schedule to commit to shepherding a release. > > Speaking for myself, I know that this almost certainly isn't going to > > be me -- my work life has got a lot more complicated since the 1.3 > > release. > > And that someone will be me. See my post > here:http://www.holovaty.com/writing/back-to-django/ Wow! Great news! If only I had been shut up a week more ;-) Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
