Hi Tom, On 16 mai 2012, at 19:22, Tom Evans wrote: > Even with this optimization, if I access the session_key of a session > object, it should be apparent that I want the session id of the > current session. If that means that the session must be saved in order > to determine what that session id is, then that is what should happen.
When you access the id of an unsaved model, it's apparent that you want the id of the model, but the model isn't saved and you get None. > I believe in POLA, and to me it is astonishing that a valid session > does not have an session id when queried, even temporarily. In my opinion, the current behavior obeys the principle of least surprise: 1) Saving the session as a side effect of accessing its session_key attribute would be very surprising. And generally there's no way to get the session_key without saving the session — you need an atomic create-if-not-exist operation to avoid collisions. 2) As I said above, sessions behave exactly like Django models in this situation. > You had clearly grasped that this was a change that could easily break > peoples code. I'd like to know why that information was not relayed > into the release notes, or anything about the volatility of session > keys added to the docs. > > Even though I don't like the API, if it had been in the relnotes, I > wouldn't have spent half a day hunting through the relnotes, docs and > finally diffs to determine what had changed and produce a test case, I > would simply have been able to update the places that refer to session > id to ensure that they existed before use. I'm sorry that you wasted so much time on this problem and I understand your frustration. I admit I underestimated how many people relied on this attribute being a string: this is the second thread on this topic. The reason why I considered this a bug fix and not a backwards-incompatible change is simple: session_key is an internal API, and internal APIs are subject to change without notice. Well, since then, I added a bit more information in the docs, so it's drifting towards becoming a public API. Maybe we should document its behavior fully and make it a public, stable API. When I committed the fix, I couldn't find many legitimate uses for accessing session_key directly — except for writing a custom session backend, but when you start doing this sort of things, you're generally aware of the risks. 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.
