Re: selecting app for syncdb
On 23 maj 2013, at 00:52, Shai Berger wrote: > If I'm not mistaken, there are some problems with the latest released version > (0.7.6) FWIW, the latest released version is 0.8 as of earlier today: https://pypi.python.org/pypi/South -- 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: Combine localflavor apps again
On 21 maj 2013, at 14:51, Jannis Leidel wrote: > - combine the localflavor packages into one Python package again, call it > django-localflavor > - give all the individual country maintainers also access to that package > - have a central documentation, e.g. django-localflavor.readthedocs.org > - update the Django docs to point to that package > - ask the maintainers of the 7 already released packages to point to the > newly created django-localflavor > > What do you think? +1 This will make handling backwards compatibility easier, especially by having a central deprecation policy on outdated or invalid data in separate localflavors. Users have the right to know when compatibility might break and when a fix is going to get deployed. Such a combination will also enable users to use a flavor that lacks a formal maintainer. Just $0.02 from the just-proclaimed django-localflavor-pl maintainer. -- 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 15 kwi 2013, at 11:21, Aymeric Augustin wrote: > Not every feature has to be supported via keyword arguments in the URLconf. > Many are expressed through decorators. > > The URL dispatcher might have been designed differently in the first place, > but the current version appears to work quite well and I'm not convinced we > need to change it in this regard. Make that a -0! Well, updating the documentation would solve the issue IMHO. Does that work for you, Brantley? -- 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 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Stephen Burrows w dniu 5 kwi 2012, o godz. 07:41:
> I generally like this idea, except for the implicit integer ids based
> on declaration order.
Thanks for your input. I will add the ability to explicitly set .id values for
each Choice in the next release.
> As people have said, it seems like just asking
> for data corruption.
Fair enough, although that does not match my experience.
> I'd much rather see implicit character ids based
> on the attribute name of the choice, analogous to django fields.
>>> class Gender(Choices):
... m = Choice("male")
... f = Choice("female")
... n = Choice("not specified")
...
>>> Gender(item=lambda c: (c.name, c.desc))
[(u'm', u'male'), (u'f', u'female'), (u'n', u'not specified')]
> Will you be making this project available as a third-party app?
pip install dj.choices
--
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer
IT Infrastructure Department
Grupa Allegro Sp. z o.o.
http://lukasz.langa.pl/
+48 791 080 144
--
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: Ticket for Docs improvement Was: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Łukasz Rekucki w dniu 5 kwi 2012, o godz. 10:03:
> I' sure you meant:
>
> def greet(self):
>return {self.MALE: 'Hi, boy', self.FEMALE: 'Hi, girl.'}[self.gender]
>
> Unless you defined MALE/FEMALE as globals too :) Otherwise you'll get
> a NameError.
Also, a minor diversity note: in real life gender choice is not binary.
--
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer
IT Infrastructure Department
Grupa Allegro Sp. z o.o.
http://lukasz.langa.pl/
+48 791 080 144
--
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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48: > +1 to what Adrian says. Thanks for your input! :) > On two occasions now I've had to do serious debugging on implementations done > by other people who used a technique not dissimilar to what Łukasz proposes. > In both cases, while the inheritance and better control structures were nice, > the issue was that if you give people enough rope to hang themselves, they > will. Can you elaborate on that a bit? Even if the proposal is rejected in the end, I might use your experience to at least make the rope less deadly. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Adrian Holovaty w dniu 4 kwi 2012, o godz. 18:41: > Also, the fact that we *don't* have a sub-framework for this lets > people do whatever they want -- including using the dj.choices module. > So I am -1 on including this in Django proper. Thank you for your feedback. As you're one of the BFDLs for the project, that basically closes the proposal as rejected, am I right? -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Tom Evans w dniu 4 kwi 2012, o godz. 18:40:
> The class definition grates. When we say things like:
>
> class Gender(Choices):
>male = Choice("male")
>
> That says to me that Gender.male is mutable. Ick.
Thanks for your feedback. Do model and form field definitions say that as well?
It's true that I could have block users from mutating the value but "we're all
consenting adults here", right?
> There is no easy way by inspecting the code to see what choice a value
> of 7 equates to any-more.
True, the same goes for spotting errors with manual numbering when there are
many values.
> Do the choices start from 0 or do they start
> from 1, as inferred by the examples (Why? What is wrong with 0?).
> Repetition isn't good, but ambiguity is worse.
It's a matter of aesthetics and as such it's totally subjective. I made the
values start from 1 so that the first Choice.Group can have value 0 and not -1
which looks ugly.
> This grouping system just seems destined for data loss/confusion. If I
> want to split a group in two, the enums in the new group change
> values! That is not a good approach, and was not necessary with the
> old system.
I can't see how they have to.
> If I had a vote, I'd be strongly -1 on
> any proposal with this sort of grouping, it seems dangerous and wrong.
Can you elaborate on what is dangerous about them?
> Finally, the proposal seems to concentrate solely on choices as an
> enum. The proposal completely ignores that choices can be almost any
> kind of value, eg:
>
> MALE="m"
> FEMALE="f"
> UNKNOWN="?"
> GENDER_CHOICES = (
>(MALE, "Male"),
>(FEMALE, "Female"),
>(UNKNOWN, "Unknown"),
> )
>
> this would be an entirely appropriate choices for a CharField.
Using code in my proposal:
>>> class Gender(Choices):
... m = Choice("male")
... f = Choice("female")
... n = Choice("not specified")
...
>>> Gender(item=lambda c: (c.name, c.desc))
[(u'm', u'male'), (u'f', u'female'), (u'n', u'not specified')]
--
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer
IT Infrastructure Department
Grupa Allegro Sp. z o.o.
http://lukasz.langa.pl/
+48 791 080 144
--
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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Daniel Sokolowski w dniu 4 kwi 2012, o godz. 17:52: > The choice filtering could come in handy and in the end I don't see why this > can't co-exist with django's standard way. > > WAY 4: Nice but very verbose. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Thomas Guettler w dniu 4 kwi 2012, o godz. 15:55: > since most people have something like this in their code, a better solution > should require > only some additional characters. Thank you for your feedback. I disagree since it wouldn't address any of the original concerns from the proposal. Most importantly, reducing redundancy and creating a canonical place for storing information of a specific concept. > I think it is better if choices must be set explicit, not > implicit (auto-increment). As Dan Poirier pointed out, setting an explicit .id on a single Choice will let you do that. > Here is my solution, which is similar to way3 in your proposal. Doesn't support groups, uses the tuple-galore syntax, still leaves you with redundancy of having to first define available options and later building a choice dictionary. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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: Proposal: upgrading the choices machinery for Django
Wiadomość napisana przez Dan Poirier w dniu 4 kwi 2012, o godz. 14:08: > One nice addition would be to specify explicitly what .id a particular > Choice should have. It would be useful in converting existing code that > might not have chosen to number its choices the same way this proposal > does by default. It looks like you could use Choices.Group(n-1) to make > the next choice defined use id=n, but that's not very elegant. Right. The ability to explicitly set the .id on a single choice is useful. The only reason it's not already there is that I didn't want to write my own `makemessages`. Then again I might do just that. My proposal is based on a working implementation because I didn't want to fall into bikeshedding on what could have been theoretically implemented. What we need now to push things forward is a list of +1, +1 if ..., +0, +0 if ..., -1, "how dare you?!" from a bunch of people. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 -- 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.
Proposal: upgrading the choices machinery for Django
~~~
Yes, it is. It grew out of a couple of projects I did over the years, for
instance `allplay.pl <http://allplay.pl/>`_ or `spiralear.com
<http://spiralear.com/en/>`_. Various versions of the library are also used by
my former and current employers. It has 100% statement coverage in unit tests.
Has anyone evaluated it yet?
I have shown this implementation to various people during PyCon US 2012 and it
gathered some enthusiasm. Jannis Leidel, Carl Meyer and Julien Phalip seemed
interested in the idea at the very least.
Why not use an existing Django enum implementation?
~~~
The most popular are:
- `django-choices <http://pypi.python.org/pypi/django-choices>`_ by Jason Webb.
The home page link is dead, the implementation lacks grouping support,
internationalization support and automatic integer ID incrementation. Also,
I find the reversed syntax a bit unnatural. There are some tests.
- `django-enum `_ by Jacob Smullyan. There is
no documentation nor tests, the API is based on a syntax similar to
namedtuples with a single string of space-separated choices. Doesn't support
groups nor internationalization.
Why not use a generic enum implementation?
~~
The most popular are:
- `enum <http://pypi.python.org/pypi/enum>`_ by Ben Finney (also a rejected `PEP
<http://www.python.org/dev/peps/pep-0354/>`_) - uses the "object
instantiation" approach which I find less readable and extensible.
- `flufl.enum <https://launchpad.net/flufl.enum>`_ by Barry Warsaw - uses the
familiar "class definition" approach but doesn't support internationalization
and grouping.
Naturally, none of the generic implementations provide shortcuts for Django
forms and models.
Why not use namedtuples?
This doesn't solve anything because a ``namedtuple`` defines a type that is
later populated with data on a per-instance basis. Defining a type first and
then instantiating it is already clumsy and redundant.
Do you have a field like ``ChoiceField`` but holding characters?
Not yet but this is planned.
I don't like having to write ``Choice()`` all the time.
~~~
You can use a trick::
class Gender(Choices):
_ = Choices.Choice
male = _("male")
female = _("female")
not_specified = _("not specified")
Current documentation for the project uses that because outside of Django core
this is necessary for ``makemessages`` to pick up the string for translation.
Once merged this will not be necessary so **this is not a part of the
proposal**. You're free to use whatever you wish, like importing ``Choice`` as
``C``, etc.
--
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer
IT Infrastructure Department
Grupa Allegro Sp. z o.o.
http://lukasz.langa.pl/
+48 791 080 144
--
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: Wrong JOIN with nested FKs
Wiadomość napisana przez Russell Keith-Magee w dniu 3 paź 2011, o godz. 16:07: > 1) Build your own experience with the internals of the ORM. As part > of this learning process, document what you learn -- we would very > much like to have better documentation of the internals of Django's > ORM, but writing that documentation takes time. > How would you like to see that done? I find this interesting, if only to see how suitable would increasing support for multiple inheritance be. -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. -- 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.
