survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)
While mucking with the refactoring of adodbapi, I included a patch fixing a bug when storing data into columns of type "adGUID". I had not been really aware that SQL Server has a dedicated data type for UUID until that ticket surfaced. Then I started thinking about the column in one of my CDC data tables which contains text which always contains "uuid:" followed by a long hexadecimal looking string. I am pretty sure it was once a primary key, but pending something like ticket 19463 I don't use it as such. Nevertheless, it started me thinking... When I read data columns written in native decimal or date-time formats, I make the db-api module emit good, proper Python decimal.decimal and datetime.datetime objects. It would not take much effort to perform a similar action when I see that the incoming column is of the Windows type "adUUID" -- I could emit an instance of the "uuid" class. Is that a good idea, or a bad idea? -- Vernon Cole -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
On 13 kwi 2013, at 23:48, Brantley Harris wrote:
> It would be extremely easy to implement
Such a statement suggests that the you didn't really think the problem through.
Few things are "extremely easy to implement", especially in a framework with
years of legacy projects in the wild.
> and would lead to vastly better code across new projects, including a simpler
> way of writing rest style interfaces:
>
> url('^objects/$', 'views.create_object', methods=['post', 'put'],
> name='create_object'),
> url('^objects/$', 'views.get_objects', name='list_objects'),
How would you implement a reverse() variant having this functionality in?
Does get_objects respond to DELETE as well?
If create_objects raises Http404, do we continue traversing the urlconf? What
about reverse() in that case?
> I will gladly implement the code required for this, but don't wish to do so
> if it's going to be quashed, which is why I bring it up here.
Often you can find tricky edge cases and other obstacles only through an
implementation effort. Realistically, no-one will agree to merge a
functionality based only on a vague mailing list post. Working code wins
arguments, as they say. Alternatively, a careful up-front design document (this
is what the core Python team does with PEPs).
--
Best regards,
Łukasz Langa
WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
On Sun, Apr 14, 2013 at 4:56 AM, Łukasz Langa wrote:
> On 13 kwi 2013, at 23:48, Brantley Harris wrote:
>
> > It would be extremely easy to implement
>
> Such a statement suggests that the you didn't really think the problem
> through. Few things are "extremely easy to implement", especially in a
> framework with years of legacy projects in the wild.
Which is why I bring up the idea, to hear if anyone has some gotchas or
implementation advice.
>
> > and would lead to vastly better code across new projects, including a
> simpler way of writing rest style interfaces:
> >
> > url('^objects/$', 'views.create_object', methods=['post', 'put'],
> name='create_object'),
> > url('^objects/$', 'views.get_objects', name='list_objects'),
>
> How would you implement a reverse() variant having this functionality in?
>
Reverse deals only with the url, not the method. Two names "create_object"
and "list_objects" would now point to the same url. Of course the urls
could change at some point and the urls could diverge, but since you've
already separated the two views by name, you don't have to do any more work.
> Does get_objects respond to DELETE as well?
>
Yes, it's the fall through, accepts all methods just as a url does in
Django now.
> If create_objects raises Http404, do we continue traversing the urlconf?
> What about reverse() in that case?
>
No, since Django does not do this with any other urls.
>
> > I will gladly implement the code required for this, but don't wish to do
> so if it's going to be quashed, which is why I bring it up here.
>
> Often you can find tricky edge cases and other obstacles only through an
> implementation effort. Realistically, no-one will agree to merge a
> functionality based only on a vague mailing list post. Working code wins
> arguments, as they say. Alternatively, a careful up-front design document
> (this is what the core Python team does with PEPs).
>
>
I've brought the topic up for discussion, I'm not looking to see it
pre-approved for merging.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
On 13/04/13 22:48, Brantley Harris wrote:
> There's a line in the django URL Dispatcher documentation that is pretty
> weird:
>
> The URLconf doesn’t look at the request method. In other words, all
> request methods – POST, GET, HEAD, etc. – will be routed to the same
> function for the same URL.
>
>
> Well, why? Most modern web frameworks allow you to specify the method
> in the routing configuration, Django seems to be an exception in this
> respect.
>
> It would be extremely easy to implement, and would lead to vastly better
> code across new projects, including a simpler way of writing rest style
> interfaces:
>
> url('^objects/$', 'views.create_object', methods=['post', 'put'],
> name='create_object'),
> url('^objects/$', 'views.get_objects', name='list_objects'),
>
>
> This has come up many times before and been swatted down for various
> reasons. One is that it could be implemented with a one-off dispatcher,
> as in:
>
> url('^objects/$', create_or_list(list=get_objects,
> create=create_object), name='create_or_list_objects')
>
>
> But this is overly complex for what should be a simple configuration,
> forces one to create the same name for the url, and worse, creates a
> level of indirection breaking the abstraction up; or in other words
> you're trying to do route configuration, why not do it in the place
> you're already doing route configuration?
>
> The other argument is that you can do this with Class Based Views. I
> don't believe this is a good argument as one would have to utilize Class
> Based Views to get this basic functionality. In fact CBV's, only really
> solve two common issues, one is the boilerplate inherit in forms, and
> the other method routing. But the proposed solution to method routing
> is simpler and better.
You don't have to use Django's CBVs to get this functionality - you can
write your own, avoiding anything you dislike about them.
One reason for not doing this kind of despatch is that handling for
different HTTP methods often involves a lot of common code. The classic
form workflow would become longer, more complicated and/or less DRY if
it was implemented using two functions instead of one:
https://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view
So, I would disagree that dispatching on HTTP verb would lead to vastly
better code - it could easily make things worse.
However, this is not an argument against having the *option* to do
method-name dispatching in the URLconf - I can see that there are valid
use cases for that.
Regards,
Luke
--
Environmentalists are much too concerned with planet earth. Their
geocentric attitude prevents them from seeing the greater picture
-- lots of planets are much worse off than earth is.
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
On Sun, Apr 14, 2013 at 2:40 PM, Luke Plant wrote: > One reason for not doing this kind of despatch is that handling for > different HTTP methods often involves a lot of common code. The classic > form workflow would become longer, more complicated and/or less DRY if > it was implemented using two functions instead of one: > > https://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view > > So, I would disagree that dispatching on HTTP verb would lead to vastly > better code - it could easily make things worse. > > Form handling seems like the only common place that a view would want to handle different methods coming in, most of the time it makes much more sense to break up the view into one for each HTTP Method. In essence, what we're doing is creating our own mini-dispatch in the view and it's clumsy most of the time and leads to less RESTful layouts. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)
On Sun, Apr 14, 2013 at 7:03 PM, VernonCole wrote: > While mucking with the refactoring of adodbapi, I included a patch fixing > a bug when storing data into columns of type "adGUID". I had not been > really aware that SQL Server has a dedicated data type for UUID until that > ticket surfaced. Then I started thinking about the column in one of my CDC > data tables which contains text which always contains "uuid:" followed by a > long hexadecimal looking string. I am pretty sure it was once a primary > key, but pending something like ticket 19463 I don't use it as such. > Nevertheless, it started me thinking... > > When I read data columns written in native decimal or date-time formats, I > make the db-api module emit good, proper Python decimal.decimal and > datetime.datetime objects. It would not take much effort to perform a > similar action when I see that the incoming column is of the Windows type > "adUUID" -- I could emit an instance of the "uuid" class. > > Is that a good idea, or a bad idea? > I'm not entirely sure what you're asking here. Jacob has already given the green light to a UUID field. We're just waiting for an appropriate patch. So if you want to support UUID types, that's the first step -- but it's unrelated to the development of an Django ADO database backend. The decision to emit an instance of a UUID class is a function of the pyDB-API layer, so that's something to take up with whoever is responsible with the Python ADO bindings. Again, it's not a Django DB backend question. PEP249 doesn't mention UUID types, however, so I'm not sure what the appropriate behaviour would be. Have I missed the point of what you're asking? Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[GSoC 2013] Improving code quality
Hi, After looking through proposed ideas for the current GSoC i found 2 issues related close to the code quality which I'm interested in. These are: 1. Best practices Updates 2. Improved error reporting Both tasks are a different but they are very closely related just to code quality which if very important especially in projects in size of Django ;). I will try to suggest that maybe merging them into one little bigger task would be better idea. I'll explainin characteristics of these. Take the second one as a first. This project will require trying to reproduce some bugs and fix some error handling in order to allow other developers to fix their bugs more easily. I think that trying to analyse code, predict all scenarios and write all expected messages seems like impossible task. It's better to fix tasks already reported by users. So here comes the list https://code.djangoproject.com/wiki/BetterErrorMessages. Unfortunately (or rather fortunately) I found many of the issues from "error handling" are outdated. On the other side it would be good to review that list and possibly fix that wrong messages but ... do you think that fixing few error handlers is enough for 2-month project? The first one will require to know best practices and then rewrite/update some code to follow them. I think that this could be continuous task, and the finish of this task if very blurred. Common sense tells me that we should start with refactoring from "the worst" code then current worst and keep doing until all project will be up to current best practices. When the big project is being developed constantly there always be some code that need refactoring. My idea would be to fix issues from bad "error messages list" which is definitely achievable and then start to refactoring few functionalities of Django that very needs it. To make the second part more achievable and precise, I should choose few particular functionalities the I'd like to take care of. This approach will allow to fix particular bugs reported by users. Moreover fixing simpler bugs is usually easier to start with project. Then having bigger knowledge i could refactor some code. Do you think that it's reachable to do that in described way? Or maybe better stick to the idea of taking just 1 of this projects and spend some more time on it? If you for example know that there are much work needed with code refactoring, maybe it would be better to take precisely this project and leave the other. On the other side if there are more places that are poorely handled then it could be better to take into consideration this one. Thanks, Damian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSoC 2013] Improving code quality
On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki wrote: > Hi, > > After looking through proposed ideas for the current GSoC i found 2 issues > related close to the code quality which I'm interested in. These are: > > >1. Best practices Updates >2. Improved error reporting > > Both tasks are a different but they are very closely related just to code > quality which if very important especially in projects in size of Django > ;). I will try to suggest that maybe merging them into one little bigger > task would be better idea. I'll explainin characteristics of these. > > Take the second one as a first. This project will require trying to > reproduce some bugs and fix some error handling in order to allow other > developers to fix their bugs more easily. I think that trying to analyse > code, predict all scenarios and write all expected messages seems like > impossible task. It's better to fix tasks already reported by users. So > here comes the list > https://code.djangoproject.com/wiki/BetterErrorMessages. Unfortunately > (or rather fortunately) I found many of the issues from "error handling" > are outdated. On the other side it would be good to review that list and > possibly fix that wrong messages but ... do you think that fixing few error > handlers is enough for 2-month project? > > The first one will require to know best practices and then rewrite/update > some code to follow them. I think that this could be continuous task, and > the finish of this task if very blurred. Common sense tells me that we > should start with refactoring from "the worst" code then current worst and > keep doing until all project will be up to current best practices. When the > big project is being developed constantly there always be some code that > need refactoring. > > My idea would be to fix issues from bad "error messages list" which is > definitely achievable and then start to refactoring few functionalities of > Django that very needs it. To make the second part more achievable and > precise, I should choose few particular functionalities the I'd like to > take care of. This approach will allow to fix particular bugs reported by > users. Moreover fixing simpler bugs is usually easier to start with > project. Then having bigger knowledge i could refactor some code. > > > Do you think that it's reachable to do that in described way? > Or maybe better stick to the idea of taking just 1 of this projects and > spend some more time on it? > I think that if you do a detailed analysis, you'll find that *both* projects could easily fill a full GSoC semester. Take the first project -- the wiki is there as a documented list of known problems, not a comprehensive list of all problems. A comprehensive audit of everywhere that Django internally catches and re-raises exceptions, and how the stack track from those exceptions are exposed, would *easily* consume 12 weeks. However, we're not going to accept a project proposal that has a schedule of "audit code for 12 weeks". We're going to need you to do some initial exploration and give us a more detailed list of the sorts of problems you're going to look at. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: The threat of the incompletely initialized django instance
On Saturday, April 13, 2013 5:03:16 PM UTC-7, Russell Keith-Magee wrote: > > > On Sat, Apr 13, 2013 at 11:53 PM, Pakal > > wrote: > >> Hello, >> >> since version 1.2, there has been no changes about this issue, which >> still bothers me: >> https://code.djangoproject.com/ticket/14916 >> >> In summary, the django dev server loads models.py of every INSTALLED_APP, >> and thus (somehow) ensures proper initialization of models and signals. >> >> But in production, web servers do NOT load more than the strict minimum >> required by the requests they serve, so it opens the door to very subtle >> and deadly bugs, where the first requests of every new django process might >> miss a good part of the whole workflow, because miscellaneous "hooks" have >> not been registered properly. >> Doesn't this advocate a global import of all installed_apps' models.py, >> at process setup ? >> >> And more generally, people have no idea where to put their django setup >> code, so there are tons of forum threads and workarounds about this, using >> mod_wsgi's start script, or code in urls.py/settings.py, or even >> dedicated on-shot middelwares ( >> http://www.allbuttonspressed.com/projects/django-autoload). >> Wouldn't it be worth offering a place, in a project and/or in each django >> app, which will be called AFTER all models/signals are initialized, but >> BEFORE the first request is served ? Same behaviour as the "fake >> middleware" trick, but without its ugliness. >> > > The reason there hasn't been any update to ticket #14916 is that it has > been closed as a duplicate of #3591. Which it is. > > The ticket title may not make this obvious, but if you read the full > ticket history and/or search for #3591 on mailing lists, you'll quickly > find mention of an "app refactor". The purpose of the app refactor is to > provide a wrapper object that can encompass application-specific > configuration -- including things like application startup logic and signal > registration -- and to provide a guaranteed and consistent order for > startup. > > There are some draft patches floating around for the app refector; as I > understand it, the code was *almost* ready to be merged for 1.5, but there > were some last minute concerns, so it was postponed. I don't think there > have been any major discussion since then. > The work continues. Jannis and I continue to work on this project - and a set of defined "startup" hooks are one of the key features. The work will be scaled back in scope from some of the past ideas floated on #3591, some were technically not feasible, and others can be added in with later additions. At the DjangoCon sprints in Sept Russ and I did a big review of the branch that I had worked on last summer. There were some productive conversations with other core devs at that time. More details to follow hopefully in the following weeks-months. -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Request method in urls.py
I agree, I think there are use cases for both types of dispatch, and it seems clean and well-defined to make a route that is valid for only a subset of HTTP methods. I guess there are a few corner cases to think about, for example should Django's url resolver start returning 405s instead of 404s when it's just the method that doesn't match? But that kind of stuff is easily worked out. I like the syntax too, a list passed as a kwarg to the url() function. So +1 from me. On Sun, Apr 14, 2013 at 4:29 PM, Brantley Harris wrote: > On Sun, Apr 14, 2013 at 2:40 PM, Luke Plant wrote: > >> One reason for not doing this kind of despatch is that handling for >> different HTTP methods often involves a lot of common code. The classic >> form workflow would become longer, more complicated and/or less DRY if >> it was implemented using two functions instead of one: >> >> https://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view >> >> So, I would disagree that dispatching on HTTP verb would lead to vastly >> better code - it could easily make things worse. >> >> > Form handling seems like the only common place that a view would want to > handle different methods coming in, most of the time it makes much more > sense to break up the view into one for each HTTP Method. In essence, what > we're doing is creating our own mini-dispatch in the view and it's clumsy > most of the time and leads to less RESTful layouts. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)
Russ: I am not entirely sure what I am asking, either, but your answer has already helped. Indeed, PEP 249 is silent about support of UUID feilds, because it was written too long ago. It is also silent about support of decimal and datetime fields for the same reason. You have just taught me why we (meaning myself and other db-api authors) need a new, updated PEP. As for "whoever is responsible" -- that's me! I am the guy who maintains the Python ADO module. I am in the middle of an effort to upgrade that module specifically for django's benefit. My problem is that I have so little experience as a _user_ of django that I'm not a good judge of what we (meaning other django users) really need. I feel like a guy who doesn't know how to drive designing a new car. That's why I am asking so many off-the-wall questions to this group. I need someone to say: "No, we really need the steering wheel to stay where it is... Now if you can do something about needing one foot for the gas, and one foot for the brake, and one foot for the clutch in order to start on a hill -- we could really use THAT," So, if I were to add direct UUID support to adodbapi, it might eventually get included in a new PEP, and eventually picked up by the likes of psycopg. No guarantees, but it would be a start. My present project is to make a way for Linux users to have a door into ADO. That ought to help to gain some traction for django-mssql, which is why I am here. I have been seeing a use for this for ages -- but am now working for a company who needs to have the feature working -- about three weeks ago. If I mention that the UUID field I am working with happens to be in a record of collected data points which I also need to put on a map in geo-django, which does not work with django-mssql (yet, and I am still learning geo-django) you have an idea why I need wise advice whenever I can get it. Thank you. You are helping eHealth Africa to put an end to polio. So -- is it worth my time to muck with direct database api support of uuid fields? Where am I in relation to: "Now is better than never. Although never is often better than *right* now."? -- Vernon -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
