Re: floating point django.VERSION element versus adding another element to the tuple
Hello, What is the meaning for the serial number in version_info? Is it some kind of build number? Sorry for the dumb question. :) Anyway, I would be happy for having (major, minor, micro, release_level) tuple as Django version info. Regards, Valts. On Fri, Apr 18, 2008 at 9:52 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-04-18 at 13:28 -0500, James Bennett wrote: > > On Fri, Apr 18, 2008 at 1:21 PM, Jacob Kaplan-Moss > > <[EMAIL PROTECTED]> wrote: > > > That said, I think I agree with Steve's idea of ripping of > > > sys.version_info: we've already stolen so much process from Python > why > > > not add to this list? > > > > The main reason I didn't do that is simply that Python goes a lot more > > fine-grained than I'd ever expect Django to; things like the "micro" > > version number, for example, don't really feel like they'd fit the > > release "schedule" we've traditionally maintained. If it makes lives > > simpler, though, I'll go for it; I just hope nobody ever asks why > > we're not using the microversion ;) > > > > > > Aren't we? Isn't 0.96.1 already using a micro version? Major = 0, > minor = 96, micro = 1. Obviously, that's not where it lives now, > because it doesn't fit in the tuple, but if django goes with a 5-tuple > instead of a 3-tuple, it would be pretty silly to have something like > (0, 96.04, 0, 'final', 0), wouldn't it? > > Cheers, > Cliff > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
This all mostly makes sense. But there's one flaw (which I've described twice below) that has caused problems on other projects and I suspect will be a source of confusion with Django, too. A lot of our userbase aren't the most experienced people in the world at extracting the necessary information for a big report, so this isn't merely bike shedding... On Fri, 2008-04-18 at 12:46 -0500, James Bennett wrote: [...] > SVN checkouts > = > > For an SVN checkout, the elements of the ``django.VERSION`` tuple are: > > 1. The most recent major version released at the time of the specific >SVN revision being checked out. > > 2. The most recent minor version released at the time of the specific >SVN revision being checked out. > > 3. The modifier 'svn', indicating an SVN checkout, where '' is >the revision of the checkout from the repository. > > So, for example, if you do an SVN checkout of revision 31337 and, at > the time of that revision, the most recent major version was 3 and the > most recent minor version was 14, then VERSION in your checkout will > be:: > > (3, 14, 'svn31337') One modification to (2): I prefer the system we use now (and that a lot of other projects use) that right after a release, the minor version is bumped. So if you're using a subversion checkout after 0.96 is released, it *never* say "0.96" it's always 0.97-pre or something like that. It makes it very clear that it is NOT the 0.96 release in any fashion (unless I've checked out from the 0.96-bugfixes branches, in which case it is 0.96-something). In order to keep the first two components as numbers, you could make the last component be "pre" for anything before the release plus the subversion number, or nothing if the subversion information isn't available, which is becoming more and more common as a lot of us use other version control systems to interact with subversion -- it's kind of stupid that I keep seeing "svn-None" in the version info. The implied logic here is that anybody using some "other" version system is going to be able to work out the corresponding subversion changeset on their own. But I doubt that's too challenging; if you played in the advanced sandpit, you must be able to use the advanced-level buckets and shovels. > Why this is a good thing > > > How to do the version tuple is mostly a bikeshed argument. Ultimately, > three things matter in deciding how to handle it: > > 1. The BDFLs/core dev team are OK with it. > > 2. The system used is consistent. > > 3. The system used is easy to parse into human-readable formats. So my above argument adds: 4.The system reduces the chance of confusion to a minimum. If somebody "easily parses" (0, 96, svn142) into something related to an 0.96 release when it's actually an 0.97-pre release (in today's notation), it's a fail. Being able to differentiate between trunk and, say, 0.96-bugfixes branch is also important. So I'd prefer to bump the minor version right after each release. As a practical matter, systems that use the previous release number plus appendages for their latest code have turned out to be harder to test in code in my experience, too. It becomes quite fiddly to test that you want "the latest final release, but nothing afterwards" because there's no guarantee that the "beyond the latest release" versions sort after the "latest release" version tuple. Malcolm -- On the other hand, you have different fingers. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: SVN Milestones
If 1.0 is soon then I can handle the wait. It's just a PITA right now because .96 is so old, and trunk is so vast. Many people use trunk, but don't update continuously (as it is trunk after all). So you end up with a bunch of people in the midst of "why doesn't this work", or "why is it clean_data?" :) On Apr 18, 10:50 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I am in agreement on waiting to release a 1.0 beta, however keeping > track of tickets for the milestones of merging qs-rf and nfa(and those > are deffinately milestones) would be very handy, right now in order to > follow those one needs to play around with keywords(for example qs-rf > tickets are taggged qs-rf, except for ones that are fixed, which are > tagged qs-rf-fixed), this quickly becomes difficsult to track, post qs- > rf, nfa it would also be helpful to track 1.0 tickets(those referenced > on the VersionOneFeatures wiki page. Just my thoughts. > > On Apr 18, 11:59 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > > > On Wed, Apr 16, 2008 at 6:47 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > > Can we start setting some milestones so SVN stops being SVN :) > > > > E.g. a .97 release, or .96.2 or something. > > > My preference would be to finish up newforms-admin and > > queryset-refactor, then release a 1.0 beta. Given that SVN has a > > number of tricky/backwards-incompatible changes (everything-Unicode > > and template auto-escaping), it'd be less of a hassle in the long term > > if we included all of those changes in one big release. > > > Adrian > > > -- > > Adrian Holovaty > > holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
On Fri, 2008-04-18 at 13:28 -0500, James Bennett wrote: > On Fri, Apr 18, 2008 at 1:21 PM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: > > That said, I think I agree with Steve's idea of ripping of > > sys.version_info: we've already stolen so much process from Python why > > not add to this list? > > The main reason I didn't do that is simply that Python goes a lot more > fine-grained than I'd ever expect Django to; things like the "micro" > version number, for example, don't really feel like they'd fit the > release "schedule" we've traditionally maintained. If it makes lives > simpler, though, I'll go for it; I just hope nobody ever asks why > we're not using the microversion ;) > > Aren't we? Isn't 0.96.1 already using a micro version? Major = 0, minor = 96, micro = 1. Obviously, that's not where it lives now, because it doesn't fit in the tuple, but if django goes with a 5-tuple instead of a 3-tuple, it would be pretty silly to have something like (0, 96.04, 0, 'final', 0), wouldn't it? Cheers, Cliff --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
On Fri, Apr 18, 2008 at 1:21 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > That said, I think I agree with Steve's idea of ripping of > sys.version_info: we've already stolen so much process from Python why > not add to this list? The main reason I didn't do that is simply that Python goes a lot more fine-grained than I'd ever expect Django to; things like the "micro" version number, for example, don't really feel like they'd fit the release "schedule" we've traditionally maintained. If it makes lives simpler, though, I'll go for it; I just hope nobody ever asks why we're not using the microversion ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
As far as I'm concerned, this is firmly in the domain of release manager duties. IOW, whatever James wants gets an automatic +1 from me. That said, I think I agree with Steve's idea of ripping of sys.version_info: we've already stolen so much process from Python why not add to this list? Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
J. Cliff Dyer wrote: > As you said, it's a bikeshed argument, so I'm not going to push hard on > this, but I do want to put one thing out for discussion. There is some > value in making versions increase in sort order, so you can do "if > django.VERSION > target:". If 'final' were changed to 'release', this > would work. 'beta' < 'rc' < 'release' < 'svn'. > > Just a thought. > > And to throw a wrench into everything, including my own thought, what > would branch versions look like in your scheme? > > Cheers, > Cliff > > > On Fri, 2008-04-18 at 12:46 -0500, James Bennett wrote: > >> And because lately we've been doing various specification-type things, >> I'd like to propose (with release manager hat firmly planted on my >> head) that going forward we do things in the following fashion. >> >> >> Format of ``django.VERSION`` >> >> >> ``django.VERSION`` is a 3-tuple, of the form:: >> >> (major-version, minor-version, modifier) >> >> >> Packaged releases >> = >> >> In a packaged release, the elements of the ``django.VERSION`` tuple >> are: >> >> 1. The major version tree from which the release is packaged. >> >> 2. The minor version the package represents. >> >> 3. A modifier indicating the release status of the package. >> >> The modifier may take any one of the following four forms: >> >> 1. 'beta'; this is a beta leading up to a final release, and '' >>represents the number of the beta release; the first beta for 1.0, >>for example, would be (1, 0, 'beta1'), the second beta for 1.0 >>would be (1, 0, 'beta2'), etc. >> >> 2. 'rc'; this is a release candidate leading up to a final release, >>and '' represents the number of the release candidate; the first >>release candidate for 1.0, for example, would be (1, 0, 'rc1'), the >>second release candidate for 1.0 would be (1, 0, 'rc2'), etc. >> >> 3. 'final'; this is the packaged release of a specific version of >>Django, and represents a stable, tested version to which the Django >>project commits support per the support/security policy. Django 1.0 >>would, for example, be (1, 0, 'final'), Django 1.1 would be (1, 1, >>'final'), etc. >> >> 4. 'p'; this is a bugfix and/or security release for a prior >>version of Django, released in accordance with the support/security >>policy. The first such release for Django 1.0 would be (1, 0, >>'p1'), the second such release for Django 1.0 would be (1, 0, >>'p2'), etc. >> >> >> SVN checkouts >> = >> >> For an SVN checkout, the elements of the ``django.VERSION`` tuple are: >> >> 1. The most recent major version released at the time of the specific >>SVN revision being checked out. >> >> 2. The most recent minor version released at the time of the specific >>SVN revision being checked out. >> >> 3. The modifier 'svn', indicating an SVN checkout, where '' is >>the revision of the checkout from the repository. >> >> So, for example, if you do an SVN checkout of revision 31337 and, at >> the time of that revision, the most recent major version was 3 and the >> most recent minor version was 14, then VERSION in your checkout will >> be:: >> >> (3, 14, 'svn31337') >> >> >> Why this is a good thing >> >> >> How to do the version tuple is mostly a bikeshed argument. Ultimately, >> three things matter in deciding how to handle it: >> >> 1. The BDFLs/core dev team are OK with it. >> >> 2. The system used is consistent. >> >> 3. The system used is easy to parse into human-readable formats. >> >> The above system meets (2) and (3) -- it offers a version tuple in a >> consistent format, and one which is easy to turn into a human-readable >> string like "Django 3.2", "Django 1.4-beta3" or "Django >> 2.18-svn28183". >> >> The only question is whether it meets (1). Thoug Without wishing to turn this into a long-drawn-out discussion, why be willfully different from Python itself? From 2.0 on there's been a standard of sorts in sys.version_info: """*version_info* A tuple containing the five components of the version number: major, minor, micro, releaselevel, and serial. All values except releaselevel are integers; the release level is |'alpha'|, |'beta'|, |'candidate'|, or |'final'|. The |version_info| value corresponding to the Python version 2.0 is |(2, 0, 0, 'final', 0)|. New in version 2.0. """ No biggy, but if everyone stuck to the same versioning rules it would be worth building in core functionality to handle the version data, in so far as it needs handling. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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
Re: floating point django.VERSION element versus adding another element to the tuple
As you said, it's a bikeshed argument, so I'm not going to push hard on this, but I do want to put one thing out for discussion. There is some value in making versions increase in sort order, so you can do "if django.VERSION > target:". If 'final' were changed to 'release', this would work. 'beta' < 'rc' < 'release' < 'svn'. Just a thought. And to throw a wrench into everything, including my own thought, what would branch versions look like in your scheme? Cheers, Cliff On Fri, 2008-04-18 at 12:46 -0500, James Bennett wrote: > And because lately we've been doing various specification-type things, > I'd like to propose (with release manager hat firmly planted on my > head) that going forward we do things in the following fashion. > > > Format of ``django.VERSION`` > > > ``django.VERSION`` is a 3-tuple, of the form:: > > (major-version, minor-version, modifier) > > > Packaged releases > = > > In a packaged release, the elements of the ``django.VERSION`` tuple > are: > > 1. The major version tree from which the release is packaged. > > 2. The minor version the package represents. > > 3. A modifier indicating the release status of the package. > > The modifier may take any one of the following four forms: > > 1. 'beta'; this is a beta leading up to a final release, and '' >represents the number of the beta release; the first beta for 1.0, >for example, would be (1, 0, 'beta1'), the second beta for 1.0 >would be (1, 0, 'beta2'), etc. > > 2. 'rc'; this is a release candidate leading up to a final release, >and '' represents the number of the release candidate; the first >release candidate for 1.0, for example, would be (1, 0, 'rc1'), the >second release candidate for 1.0 would be (1, 0, 'rc2'), etc. > > 3. 'final'; this is the packaged release of a specific version of >Django, and represents a stable, tested version to which the Django >project commits support per the support/security policy. Django 1.0 >would, for example, be (1, 0, 'final'), Django 1.1 would be (1, 1, >'final'), etc. > > 4. 'p'; this is a bugfix and/or security release for a prior >version of Django, released in accordance with the support/security >policy. The first such release for Django 1.0 would be (1, 0, >'p1'), the second such release for Django 1.0 would be (1, 0, >'p2'), etc. > > > SVN checkouts > = > > For an SVN checkout, the elements of the ``django.VERSION`` tuple are: > > 1. The most recent major version released at the time of the specific >SVN revision being checked out. > > 2. The most recent minor version released at the time of the specific >SVN revision being checked out. > > 3. The modifier 'svn', indicating an SVN checkout, where '' is >the revision of the checkout from the repository. > > So, for example, if you do an SVN checkout of revision 31337 and, at > the time of that revision, the most recent major version was 3 and the > most recent minor version was 14, then VERSION in your checkout will > be:: > > (3, 14, 'svn31337') > > > Why this is a good thing > > > How to do the version tuple is mostly a bikeshed argument. Ultimately, > three things matter in deciding how to handle it: > > 1. The BDFLs/core dev team are OK with it. > > 2. The system used is consistent. > > 3. The system used is easy to parse into human-readable formats. > > The above system meets (2) and (3) -- it offers a version tuple in a > consistent format, and one which is easy to turn into a human-readable > string like "Django 3.2", "Django 1.4-beta3" or "Django > 2.18-svn28183". > > The only question is whether it meets (1). Thoughts? > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: SVN Milestones
I am in agreement on waiting to release a 1.0 beta, however keeping track of tickets for the milestones of merging qs-rf and nfa(and those are deffinately milestones) would be very handy, right now in order to follow those one needs to play around with keywords(for example qs-rf tickets are taggged qs-rf, except for ones that are fixed, which are tagged qs-rf-fixed), this quickly becomes difficsult to track, post qs- rf, nfa it would also be helpful to track 1.0 tickets(those referenced on the VersionOneFeatures wiki page. Just my thoughts. On Apr 18, 11:59 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On Wed, Apr 16, 2008 at 6:47 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > Can we start setting some milestones so SVN stops being SVN :) > > > E.g. a .97 release, or .96.2 or something. > > My preference would be to finish up newforms-admin and > queryset-refactor, then release a 1.0 beta. Given that SVN has a > number of tricky/backwards-incompatible changes (everything-Unicode > and template auto-escaping), it'd be less of a hassle in the long term > if we included all of those changes in one big release. > > Adrian > > -- > Adrian Holovaty > holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
And because lately we've been doing various specification-type things, I'd like to propose (with release manager hat firmly planted on my head) that going forward we do things in the following fashion. Format of ``django.VERSION`` ``django.VERSION`` is a 3-tuple, of the form:: (major-version, minor-version, modifier) Packaged releases = In a packaged release, the elements of the ``django.VERSION`` tuple are: 1. The major version tree from which the release is packaged. 2. The minor version the package represents. 3. A modifier indicating the release status of the package. The modifier may take any one of the following four forms: 1. 'beta'; this is a beta leading up to a final release, and '' represents the number of the beta release; the first beta for 1.0, for example, would be (1, 0, 'beta1'), the second beta for 1.0 would be (1, 0, 'beta2'), etc. 2. 'rc'; this is a release candidate leading up to a final release, and '' represents the number of the release candidate; the first release candidate for 1.0, for example, would be (1, 0, 'rc1'), the second release candidate for 1.0 would be (1, 0, 'rc2'), etc. 3. 'final'; this is the packaged release of a specific version of Django, and represents a stable, tested version to which the Django project commits support per the support/security policy. Django 1.0 would, for example, be (1, 0, 'final'), Django 1.1 would be (1, 1, 'final'), etc. 4. 'p'; this is a bugfix and/or security release for a prior version of Django, released in accordance with the support/security policy. The first such release for Django 1.0 would be (1, 0, 'p1'), the second such release for Django 1.0 would be (1, 0, 'p2'), etc. SVN checkouts = For an SVN checkout, the elements of the ``django.VERSION`` tuple are: 1. The most recent major version released at the time of the specific SVN revision being checked out. 2. The most recent minor version released at the time of the specific SVN revision being checked out. 3. The modifier 'svn', indicating an SVN checkout, where '' is the revision of the checkout from the repository. So, for example, if you do an SVN checkout of revision 31337 and, at the time of that revision, the most recent major version was 3 and the most recent minor version was 14, then VERSION in your checkout will be:: (3, 14, 'svn31337') Why this is a good thing How to do the version tuple is mostly a bikeshed argument. Ultimately, three things matter in deciding how to handle it: 1. The BDFLs/core dev team are OK with it. 2. The system used is consistent. 3. The system used is easy to parse into human-readable formats. The above system meets (2) and (3) -- it offers a version tuple in a consistent format, and one which is easy to turn into a human-readable string like "Django 3.2", "Django 1.4-beta3" or "Django 2.18-svn28183". The only question is whether it meets (1). Thoughts? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
On Fri, Apr 18, 2008 at 11:41 AM, Andrew D. Ball <[EMAIL PROTECTED]> wrote: > Look at what happens when I ask Django what version number it has (this is > from release 0.96.1): Honestly, for future releases I'd personally like to stick to a pattern of (major, minor, modifier) So if we release 1.0, say, and there's a security bug that requires a point release, instead of trying to make it be (1, 0, 1) I'd really prefer it being (1, 0, 'p1'). But this is a bikeshed problem. For the 0.96.1 release and other something.something.something releases in the past, tough luck: existing releases are forever frozen. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: SVN Milestones
On Wed, Apr 16, 2008 at 6:47 PM, David Cramer <[EMAIL PROTECTED]> wrote: > Can we start setting some milestones so SVN stops being SVN :) > > E.g. a .97 release, or .96.2 or something. My preference would be to finish up newforms-admin and queryset-refactor, then release a 1.0 beta. Given that SVN has a number of tricky/backwards-incompatible changes (everything-Unicode and template auto-escaping), it'd be less of a hassle in the long term if we included all of those changes in one big release. Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
floating point django.VERSION element versus adding another element to the tuple
>From my blog post on this topic [ http://tinyurl.com/4fw9u6 ]: Look at what happens when I ask Django what version number it has (this is from release 0.96.1): == [EMAIL PROTECTED]:~$ python Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import django >>> django.VERSION (0, 96.094, None) >>> type(django.VERSION[1]) 094 is not 0.1, which cannot be represented exactly in a finite length floating point representation for any radix that is a power of 2, if I understand correctly. I should be seeing (0, 96.1, None) or, better yet, (0,96,1). == What's the third element of the tuple supposed to be? How about making the tuple's value something like (0, 96, 1) for (major_version, minor_version, patch_level) or something like that (probably with a better name than patch_level, I don't know exactly what the Django semantics are for the different parts of the versio number). Any thoughts? Peace, Andrew -- === Andrew D. Ball <[EMAIL PROTECTED]> software developer, American Research Institute, Inc. http://www.americanri.com/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Initial values for ModelForms with additional fields
On Fri, 2008-04-18 at 11:47 -0400, Jay Wineinger wrote: > I realize that you can do it with initial. I was asking (unclearly, > evidently) if there would be any value to changing django to work in > that way. One way to do any given thing is enough. Your method isn't really anysaving in typing or clarity and it would make the underlying code a lot more complex. Not worth it. Regards, Malcolm -- For every action there is an equal and opposite criticism. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Initial values for ModelForms with additional fields
I realize that you can do it with initial. I was asking (unclearly,
evidently) if there would be any value to changing django to work in
that way.
Jay
[EMAIL PROTECTED] wrote:
> This question should be directed to django-users, this group is for
> django development, not support.
>
>
>
> class MyModel(models.Model):
> field_a =
> field_b =
>
> class MyModelForm(forms.ModelForm):
> field_c = ...
>
> class Meta:
> model = MyModel
>
> mymodel = MyModel()
> mymodel.field_a = "A"
> mymodel.field_b = "B"
> myform = MyModelForm(instance=mymodel, initial={ 'field_c': 'C'} )
>
>
>
> On Apr 18, 2:40 am, shadfc <[EMAIL PROTECTED]> wrote:
>
>> I posed this question on IRC and was told to direct it here because it
>> might be "interesting".
>>
>> I created a ModelForm with additional fields which aren't present on
>> the model. Now, I want to use this form to edit an instance of the
>> model, but there doesn't seem to be a way set the additional fields
>> via the bound instance. Simple example of what I was thinking:
>>
>>
>> class MyModel(models.Model):
>> field_a =
>> field_b =
>>
>> class MyModelForm(forms.ModelForm):
>> field_c = ...
>>
>> class Meta:
>> model = MyModel
>>
>> mymodel = MyModel()
>> mymodel.field_a = "A"
>> mymodel.field_b = "B"
>> mymodel.field_c = "C"
>> myform = MyModelForm(instance=mymodel)
>>
>>
>> Printing myform would fill the widgets for field_a,
>> field_b, field_c with "A", "B", and "C", respectively.
>>
> >
>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Initial values for ModelForms with additional fields
I posed this question on IRC and was told to direct it here because it might be "interesting". I created a ModelForm with additional fields which aren't present on the model. Now, I want to use this form to edit an instance of the model, but there doesn't seem to be a way set the additional fields via the bound instance. Simple example of what I was thinking: class MyModel(models.Model): field_a = field_b = class MyModelForm(forms.ModelForm): field_c = ... class Meta: model = MyModel mymodel = MyModel() mymodel.field_a = "A" mymodel.field_b = "B" mymodel.field_c = "C" myform = MyModelForm(instance=mymodel) Printing myform would fill the widgets for field_a, field_b, field_c with "A", "B", and "C", respectively. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Initial values for ModelForms with additional fields
This question should be directed to django-users, this group is for
django development, not support.
class MyModel(models.Model):
field_a =
field_b =
class MyModelForm(forms.ModelForm):
field_c = ...
class Meta:
model = MyModel
mymodel = MyModel()
mymodel.field_a = "A"
mymodel.field_b = "B"
myform = MyModelForm(instance=mymodel, initial={ 'field_c': 'C'} )
On Apr 18, 2:40 am, shadfc <[EMAIL PROTECTED]> wrote:
> I posed this question on IRC and was told to direct it here because it
> might be "interesting".
>
> I created a ModelForm with additional fields which aren't present on
> the model. Now, I want to use this form to edit an instance of the
> model, but there doesn't seem to be a way set the additional fields
> via the bound instance. Simple example of what I was thinking:
>
>
> class MyModel(models.Model):
> field_a =
> field_b =
>
> class MyModelForm(forms.ModelForm):
> field_c = ...
>
> class Meta:
> model = MyModel
>
> mymodel = MyModel()
> mymodel.field_a = "A"
> mymodel.field_b = "B"
> mymodel.field_c = "C"
> myform = MyModelForm(instance=mymodel)
>
>
> Printing myform would fill the widgets for field_a,
> field_b, field_c with "A", "B", and "C", respectively.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
