Re: Python 3 and you
I may be willing to support this. I have 18 month's of Python
experience (mostly 2.4) and I have been out of work for a long time
due to illness, so a project like this may look good on my CV!
I have never been involved in an OS project before, though I am aware
of the guidelines.
At present the only machine I have available is a Windows Vista
laptop :-( Are there development/test servers available?
Cheers,
Richard
On Sep 14, 1:03 pm, Jannis Leidel wrote:
> Hi all,
>
> After last week's sprint I wanted to get you up-to-speed about the
> current state of porting Django toPython3.
>
> As some may be aware Martin von Löwis has been working on a port for
> a while [1] but only recently I've had the chance to meet with him and
> talk through the porting process.
>
> I'm not going to hide the fact that it'll be a long process, but I'm
> also convinced it's an important step for Django to make. I'm writing
> this in the hope to find volunteers to join the porting efforts.
>
> Goals
> -
>
> To allow Django to run onPython3there are several goals to achieve,
> some of which are our respsonsibility, some depend on 3rd party libraries
> we use internally and some left to the users that use Django to build
> their websites. It's my understanding that we can't solve everything
> at once, so take this with a grain of salt:
>
> - get Django to run onPython3
> - provide helpers and docs for porting Django-based projects
> - help out 3rd party projects we rely only to make the jump (if needed)
>
> Porting strategies
> --
>
> As you can imagine there are still quite a few open questions at
> the moment about specific porting problems but taking from the
> experience in thePythoncommunity I think we have a good general
> strategy.
>
> There are a few assumptions we're applying either because it's
> unrealistic or impossible to maintain as long asPython2.X is in
> use for the forseeable future; so these strategy *don't* work:
>
> - Create aPython3only port ("burning the bridges")
>
> This is outright a no-go since it would leave all thePython2.X
> projects in dead water. Instead we need to provide a migration
> path for them.
>
> - Maintaing a separatePython3branch ("dual releases")
>
> While this would allow for new projects to usePython3, I'm
> convinced this has the potential to split the community. It'd
> also be a major burden for the core team to maintain both
> branches. Instead we need a combined effort.
>
> So as a result of that the only viable option is to support both major
> versions ofPythonat the same time, with the same code base.
>
> Fortunately thePythoncommunity gained lots of experience in the past
> years to make this happen (e.g. Lennart Regebro's book [4]). There are
> also tools to ease the transition of Django and the Django-based
> projects. Some of which are:
>
> - six [3] -- a compatibility library that includes many (if not all)
> needed import proxies and utilities to prepare Django and Django-based
> projects to be ported toPython3.X. This only applies to API that
> isn't syntactically changed, but only moved or enhanced in3.X.
>
> - 2to3 [2] -- an extensible library which is able to translate the rest
> of thePython2 code to thePython3equivalent. For every Django
> specific feature that isn't covered by the default 2to3 "fixers" we can
> write our own if needed. It integrates with distutils (inPython3.X)
> and is able to convert Django at installation time. Installing Django
> withPython2 wouldn't trigger the translation process, of course.
>
> Code status
> ---
>
> During the sprint we've moved Martin's code from a Bitbucket clone to
> an own SVN branch:
>
> https://code.djangoproject.com/browser/django/branches/features/py3k/
>
> Some notable changes:
>
> - a modified ``setup.py`` which automatically calls 2to3 during installation
>
> - a ``py3ktest`` helper bash script which -- for now -- installs Django in
> a directory called "3k" in the same directory to trigger the translation
> fromPython2 toPython3code and then run the tests from the build
> directory directly because they are not part of the installation in "3k"
> because we don't include it. This script should be seen a temporary
> workaround till we've found a better way to run the tests (Could we use
> tox instead? [5]).
>
> - a new django.utils.py3 module which contains some helpers that are used
> throughout the code as a common API to ease the pain of maintaining a
> project that runs on bothPython2 and3. I expect it to grow in size
> while we port Django, but even then it may not be complete enough to
> be useful for Django-based user projects. Which is why I think Django
> should ship the "six" library [3] instead, on the long run ("six" has
> the advantage of being maintained by aPythoncore developer).
>
> A good overview of the current changes can be seen on Bitbucket:
>
> https://bitbucket.org/django/django/compare/features/py3k..def
Re: JsonField
On Sat, Nov 5, 2011 at 11:48 AM, Ric wrote: > this is my proposition to have custom data inside a model field > > a json data field, the code is simple as this, and it works with > lastest django release > The problem with something like this is that it is rarely a good idea to stick opaque data into the database that cannot then be queried upon. You may have a very good reason for doing this, but most of the time that it happens it ends up being a bad design choice. Adding this to core would suggest that bad design choices are a-ok in Django, which is why I expect many people are -0/-1 on this. If I had a vote, I'd be -1. Cheers Tom -- 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: Python 3 and you
On 11/07/2011 12:00 PM, richard.prosser wrote: I may be willing to support this. I have 18 month's of Python experience (mostly 2.4) and I have been out of work for a long time due to illness, so a project like this may look good on my CV! I have never been involved in an OS project before, though I am aware of the guidelines. At present the only machine I have available is a Windows Vista laptop :-( Are there development/test servers available? You don't need a Linux/Unix since Python/Django works on Windows. -- 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: JsonField
you say "is rarely a good idea", and that it is the only thing true. when, like my app, you need to handle document, real documents (like invoice, ddt, quotations) and other stuffs, it's a good practice to keep all in one table, separating only the things that you need to query, and leave a non relational field to handle evreything else. read http://guide.couchdb.org/ there are a lot of ideas that are simply brillant. one of this is the validation of the non relational data, and django has got a fantastic framework to validate data, so it would be grat to implement a custom non relational field that can be validated, and it's stored in one place, because for some applications the best design practice is to put all the data in one place, because the date is simply non relational. django should be able to handle this kind of situation, and please don't be arrogant. you don't like non relational data, but non relational db are growing, and maybe there is a reason. the reason is that relational data not always is the best answer. non relational data it's a tool, and in some situation it's the best practice. for me the first step it's to create a JsonField, than we can use validators to let the developers validate non relational data. On 7 Nov, 12:45, Tom Evans wrote: > On Sat, Nov 5, 2011 at 11:48 AM, Ric wrote: > > this is my proposition to have custom data inside a model field > > > a json data field, the code is simple as this, and it works with > > lastest django release > > The problem with something like this is that it is rarely a good idea > to stick opaque data into the database that cannot then be queried > upon. You may have a very good reason for doing this, but most of the > time that it happens it ends up being a bad design choice. > > Adding this to core would suggest that bad design choices are a-ok in > Django, which is why I expect many people are -0/-1 on this. If I had > a vote, I'd be -1. > > Cheers > > Tom -- 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: JsonField
On Tue, Nov 8, 2011 at 5:58 AM, Ric wrote: > you say "is rarely a good idea", and that it is the only thing true. > > when, like my app, you need to handle document, real documents (like > invoice, ddt, quotations) and other stuffs, it's a good practice to > keep all in one table, separating only the things that you need to > query, and leave a non relational field to handle evreything else. > > read http://guide.couchdb.org/ there are a lot of ideas that are > simply brillant. > > one of this is the validation of the non relational data, and django > has got a fantastic framework to validate data, so it would be grat to > implement a custom non relational field that can be validated, and > it's stored in one place, because for some applications the best > design practice is to put all the data in one place, because the date > is simply non relational. > > django should be able to handle this kind of situation, and please > don't be arrogant. > > you don't like non relational data, but non relational db are growing, > and maybe there is a reason. > > the reason is that relational data not always is the best answer. This is not in dispute. What is in dispute is that when you have non-relational data, you should be using a non-relational data store, not trying to stuff non-relational data into your relational store. Tom correctly summarized the argument against putting JSONField in trunk -- it's the wrong tool for the job. If you have non-relational data, you should be using a non-relational store. Alternatively, you should be exploiting the non-relational data structures inside a relational store (e.g., PostgreSQL's hstore). At a project level, Django has a responsibility to advocate for best practices. Using the wrong tool for the job isn't best practice. If you really do need a JSONField, Django gives you the abilty to add one yourself as an external dependency, and for my money, that's the right place for JSONField to live. 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: JsonField
Hallöchen! Tom Evans writes: > On Sat, Nov 5, 2011 at 11:48 AM, Ric wrote: > >> this is my proposition to have custom data inside a model field >> >> a json data field, the code is simple as this, and it works with >> lastest django release > > The problem with something like this is that it is rarely a good > idea to stick opaque data into the database that cannot then be > queried upon. [...] > > Adding this to core would suggest that bad design choices are a-ok > in Django, which is why I expect many people are -0/-1 on this. While I appreciate that Django core is supposed to enforce good design practices, one must be careful with that if some practice may have valid use cases. You cannot prevent the user from shooting in the foot anyway. While we make extensive use of the relational model in our project, I remembered to have a couple of JSON fields (though we don't have a field class them them so far), so I skimmed through our code to see why we did this. In our code, a JSON field is an application of the KISS principle. I see at least two valid use cases for such fields: 1. You say that you will never query for the content of a field. For example, we store user preferences in a JSON field. I'll never be interested in all users who set their page skin to "classic". (And if I would, I could still do a "manual" query or do the schema and data migration. This is okay as long as its probability is sufficiently small.) Moreover, in some cases, realising the JSON field explicitly in the relational model would have led to many tiny models. This may also be bad for performance, but it is certainly bad for readability and maintenance. 2. Dynamic typing. In one case, we simply don't know a priori how the data structure in the JSON field will look like. The Python code interprets its content depending on another field value of the model instance. The alternative would have been extensive use of multi-table inheritance. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
