Re: [ANNOUNCE] Django security releases issued (1.4.21, 1.7.9, and 1.8.3)
Tom's question got me thinking. Should non-ASCII numerals be allowed ?
import re
for x in ("10", "६"):
print("INT", int(x))
print("RE", re.match("^-?\d+\Z", x) is not None)
On Python 3 this returns True and True unless you add re.ASCII flag.
On 10 July 2015 at 12:32, Florian Apolloner wrote:
> In [1]: int(' 5 ')
> Out[1]: 5
>
> Cheers,
> Florian
>
> On Friday, July 10, 2015 at 12:00:20 PM UTC+2, tomv wrote:
>>
>> Out of interest what's wrong with casting to int and checking for
>> exceptions?
>>
>> This is the removed code:
>>
>> try:
>> int(value)
>> except (ValueError, TypeError):
>> raise ValidationError(_('Enter a valid integer.'), code='invalid')
>>
>> Does this match different strings than the new regex:
>> re.compile('^-?\d+\Z') ? Or is it more about performance, OverflowError etc?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/52e4d514-fe86-4867-a640-3484939dd882%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAEZs-EKrz1heUAoeJfA6GJ6Bg4t6kdH3d5F24UBykU2Y8WOFrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: should we close in-memory file-like objects (StringIO, BytesIO, etc.)?
Hello , If you do mean CPython test suite then it's probably not the best place to look at because the reference counting *is there* and those object will be closed at the end of test method. Django doesn't have this comfort when run with PyPy. That said, I wouldn't recommend using contextlib.closing() all over the place. StringIO seems to implement the context manager protocol just fine[1]. And in Python 3.4+ so does urlopen(). [1]: http://bugs.python.org/issue4039 On 3 July 2015 at 16:09, Andriy Sokolovskiy wrote: > My vision of that was to have clean code (even if these are few bytes). > Python allows to have memory leaks like this, without throwing warnings, > but if we know that we can close it, I think we should do that. > > We're usually writing new tests by copying logic from sibling test (if > new test need to do similar thing). > If that test have unclosed stream or file, new test likely also will not > close streams and files, so this old test is a "bad example", > which causing more unclean code. > > So, it question about code style than about bytes savings. > > On 7/3/15 16:59, Tim Graham wrote: >> Andriy proposed a patch to close objects like StringIO and BytesIO in >> our test suite [1]. I am not sure how much benefit this gives (frees "a >> few bytes of RAM" according to [2]) and it seems to add a lot of >> verbosity. Looking at Python's own test suite, it doesn't appear these >> objects are closed there (I spot checked BytesIO and StringIO). Any >> thoughts on this? >> >> [1] https://github.com/django/django/pull/4938 >> [2] https://github.com/django/django/pull/4248 >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send >> an email to django-developers+unsubscr...@googlegroups.com >> <mailto:django-developers+unsubscr...@googlegroups.com>. >> To post to this group, send email to django-developers@googlegroups.com >> <mailto:django-developers@googlegroups.com>. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/7579ee1c-ecc6-48d1-9002-733810e64754%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/7579ee1c-ecc6-48d1-9002-733810e64754%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/559697A3.2010002%40asokolovskiy.com. > For more options, visit https://groups.google.com/d/optout. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-ELtiFRdGEyeXcde8L315tXO-BkcGLPCEiTPFmNMS1BM9g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Any chances to see Django benefit from new Async features of Python 3.5 ?
Considering that PEP 492 is mostly about new syntax, it's not really possible to write code in the core that will work in earlier Python versions. Unless you wrap everything into some compatibility later, but that defeats the purpose of the PEP. Also, Django doesn't really have any asynchronous parts in the core. BR, Lucas On Saturday, June 20, 2015, Benjamin Melki wrote: > Hi, > are there any chances for a future Django version to benefit from new > built in Python async features ( https://www.python.org/dev/peps/pep-0492/ > ) ? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a9353635-0583-43b3-b8c1-d1aa68c8a951%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/a9353635-0583-43b3-b8c1-d1aa68c8a951%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-ELK1f%2BkYzxqU8JRQ2EVWi8Pc%3Dod_B%3D%2B8YWJpP4nvKjuQQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Any Windows users who could help setting up Jenkins slaves?
Hi, I can't devote much of direct work time right now, but I have quite a lot of (mostly bad) experience with Jenkins and Windows, including setting up Webdriver nodes. If you have any specific doubts/questions, feel free to contact me. BR, Łukasz On 30 April 2015 at 17:56, Markus Holtermann wrote: > Hey Tim, > > I haven't done it myself but if nobody else volunteers I'm up for the > challenge. > > /Markus > > On Thursday, April 30, 2015 at 5:49:27 PM UTC+2, Tim Graham wrote: >> >> It would be nice to add Windows support to our continuous integration. Do >> we have anyone with experience setting up Windows slaves for Jenkins who >> could help with this? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/9b713601-589d-4685-ab85-93f4fa8d9950%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-EK7jKrzksJhRDOuveO0ufHzczMkMC2dtP%2Bm6fhLqQ39Og%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [GSOC] Weekly update
On 4 August 2014 16:14, Daniel Pyrathon wrote: > Hi All, > > This has been resolved by using the ImmutableList datastructure > > https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629 > But why? What's the benefit over using a tuple? ImmutableList is not even a list, because it inherits from tuple. The only other use of this data structure I could find is in upload handlers and the rationale is that the field suddenly changes from mutable to immutable. I don't think your case is the same, as fields are always immutable. Also, if fields() is immutable, then so should concrete_fields(), etc. > > On Monday, August 4, 2014 2:44:38 PM UTC+2, Collin Anderson wrote: >> >> if we do really need a list, could we gain some performance by caching >> tuples and converting them to lists instead of caching lists? > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/f4795467-24c7-4a61-af78-1a5b1a16299d%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Łukasz Rekucki -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-E%2BPeTGXnQSuQPqqYiOC1zmNd8ZuweoOWm4rASwi14WFdA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Response Fixes
On 2 July 2014 21:14, Aymeric Augustin wrote: > 2014-07-02 15:36 GMT+02:00 Łukasz Rekucki : > >> It doesn't just alter it, but makes it conform to HTTP standard. > > > As usual, given a different set of expectations, auto-fix is auto-break. > > We recently removed two of the four unconditional response "fixes". > > The remaining ones are: > > - `fix_location_header`: at least for some people, it's an issue. That's > why we're having a discussion. > > - `conditional_content_removal`: there's a variety of scenarios where > it fails. For instance, if you have a reverse proxy in front of your app > that performs gzipping, to handle HEAD requests correctly, it must > get the response body, compress it, figure out its length, and add it > to the Content-Length header. > > That's why I believe the concept of unconditional response "fixes" in > itself is flawed. I'm not saying it isn't, but sadly they are already there. I just wanted to say, that I think this feature is not worth the potential breakage. I'm sure there are better ways to achieve this without using CGI or mod_wsgi. > > -- > Aymeric. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CANE-7mWfbz__6_18S9Ak098Byp9NuJLumvCy3YKbq6SXUbFtTQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- Łukasz Rekucki -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-EKVOkRrTD_awCOtaOXDTGnQD7v9HpWGDE5XAtTwTuUkPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Response Fixes
On 2 July 2014 15:42, Florian Apolloner wrote: > On Wednesday, July 2, 2014 3:36:22 PM UTC+2, Łukasz Rekucki wrote: >> >> It doesn't just alter it, but makes it conform to HTTP standard. While >> most browsers will accept relative urls, I don't think Django should >> sacrafice backwards compatibility for an arcane CGI feature. > > > Internal redirects are imo an important feature to support, maybe not by > default, but the response should be able to say "I know what I am doing". Sure and that's why Nginx has X-Accel-Redirect. The problem with this feature is that it requires using an (yet[1]) invalid value for an already HTTP header. Personally, I would workaround this by adding my own header like X-CGI-Forward and then make the CGI-Django wrapper override Location with its value if it's present. [1]: It seems the next version of HTTP 1.1 will allow non-absolute URLs, but obviously CGI applications won't be able to return them to the client because of this feature ;). > > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/19074151-e0eb-4925-90fe-9b1e5eedfd50%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Łukasz Rekucki -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-E%2Bqq7wmwrZomCQ9%3D0OUgxTrSZ__jCDkJa2%3DanAg6JTDNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Response Fixes
On Jul 2, 2014 2:09 PM, "Aymeric Augustin" < aymeric.augus...@polytechnique.org> wrote: > > I find it wrong to alter the response created by the developer unconditionally and not provide any escape hatch. It doesn't just alter it, but makes it conform to HTTP standard. While most browsers will accept relative urls, I don't think Django should sacrafice backwards compatibility for an arcane CGI feature. Therefore option 1 is my favorite. I'm proposing to documenting the backwards incompatibility in the release notes. > > It will only affect project that do not use CommonMiddleware. There are very few use cases for not using it. I expect that developers who made that choice will know why and be able to adjust for the change. > > -- > Aymeric. > > 2014-07-02 3:11 GMT+02:00 peter : > >> This is in reference to this ticket: https://code.djangoproject.com/ticket/17092 >> >> There is a patch there to fix the specific use case of needing to disable django's fix_location_header for certain responses in a CGI compliant environment. Because of the way that response_fixes work you can't just implement middleware to bypass them. So the patch in that ticket adds an attribute to the response object that allows that 'fix' to be bypassed when the handler processes the response. In that ticket aagustin brought up that this might be better fixed by removing response_fixes from the base handler and instead implementing them in common middleware making it easier to add/remove or customize on a project by project basis rather than adding attributes to the response object. >> >> Before going any further I wanted to see what the preferred approach would be. >> >> I see 4 options. >> >> 1) Remove the concept of response_fixes from base handlers entirely and re-implement what we currently have as middleware. This would break any customized handlers that may be relying on response_fixes as well as the current redirect behavior for projects that aren't using common middleware. >> >> 2) Leave response_fixes as a feature of handlers but move the fix_location_header functionality into middleware only breaking applications that aren't using common middleware. >> >> 3) Apply the patch as is, address any future problems with response_fixes as they come up. >> >> 4) Do nothing, projects that want the CGI compliant behavior can hack django. >> >> -- >> 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. >> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d7b08325-6809-4b63-a948-4963bd590d5d%40googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Aymeric. > > -- > 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. > To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANE-7mUjVR-uSZv-Du-p%3Dz%2BVF2LBdRKOjCEcX0_82qXe%3DWtzkg%40mail.gmail.com . > > For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-ELO-5ky47916wdg0bxfn50eCYjuktjTzNsa%3Dv%3DWy_vowA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Great Wall of DEP
Hi folks, Discussing DEPs on Github inside Pull Request comments seems like a really bad idea, because it excludes a whole bunch of people that are subscribed to this list (I always thought this was the sole purpose of this list). The best thing about PEPs is that they always get posted to python-dev in *full text* and the discussion happens there. The email thread then gets recorded inside the PEP so that 10 years later you can easily read the whole discussion. Github comments don't have this feature, really. Throwing in my 2 cents, Łukasz On 8 May 2014 14:21, Florian Apolloner wrote: > Hi, > > > On Thursday, May 8, 2014 2:13:52 PM UTC+2, Carl wrote: >> >> Just noticed this message, and the DEP PRs are still open a week later. >> >> >> Can someone shuffle this along, please? > > > We are in the final stages of 1.7, I personally would rather focus on that > first. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/1d33bd04-a509-4c34-8bfe-2e4df31a3add%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Łukasz Rekucki -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-EL_x6PB9jYe_OWDfQUYvV%3DH5jA52EBCeFM50xcY%2BLRMTA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Should there be a "is" comperator: {% if A is B %}?
On 11 April 2014 01:11, Gregor Müllegger wrote:
> Hi,
>
> thanks for your input. Unfortunatelly this would fail for int(0):
Not if you encode all values to strings before passing to the
template, so it's "0" instead of 0.
>
> {'value': 0} =>
>
> Gregor
>
>
> 2014-04-10 11:41 GMT+02:00 Tino de Bruijn :
>
>> Wouldn't this be easier?:
>>
>> {'required': "", 'name': 'fieldname'} => > />
>>
>> {% for name, value in attrs.items %} {{ name }}{% if value %}="{{ value
>> }}"{% endif %}{% endfor %}
>>
>>
>> Tino
>>
--
Łukasz Rekucki
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAEZs-EL%2BNqWuo-F6AkAWCBb5rn_7GKGXkfD35uyfF%2Bqbvss5Sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [GSOC] Shifting to Py.Test and Improving the Test Suite
On 6 April 2014 17:24, Andrew Pashkin wrote: > Some Pytest advocacy: > 1) Pytest has convenient tests collection options - you can just specify > folder to run all tests in it. It is also possible to filter tests by regex, > and select specific ones. Sounds good, but unittest's test discovery is not that bad and can be easily improved. > > 2) PyUnit: > > class MyTestCase(TestCase): > def test_something(self): >expected_content = ... >response = self.client(...) >self.assertEqual(expected_content, response.content) > > Pytest: > > def test_something(client): > expected_content = ... > response = self.client(...) > assert expected_content == response.content > > Pytest style is cleaner and complies PEP8. That is very subjective. Also, Python's standards library uses unittest, so it's hard to argue that Pytest is more in line with Python standard library recommendation (which what PEP8 is). > Assertions with assert are more readable. Again subjective and the magic involved in Pytest's "assertion introspection" is rather scary. And you still need custom methods/functions for non-trivial assertions like assertHTMLEquals or assertQuerysetEquals. > It is also possible to group tests, by placing them into class, without > subclassing something. True, but Python is not Java, so I never found that to be a problem. > 4) In Pytest it is possible to define setup functions for modules, classes > and specific tests. As in unittest: https://docs.python.org/2/library/unittest.html#class-and-module-fixtures > 6) pytest-xdist plugin provides parallel execution of tests. The hard part when running tests in parallel is usually how to manage shared resources (like the database - and no creating a new Oracle instance in every subprocess is a non-starter!). So while having some support for that is good, it's not something Django's test suite would get for free. > 5) Pytest also has fixture mechanism, which allows to use additional > resources in tests by specifying fixture names as an arguments (like client) > - it is good alternative to using setUp's and subclassing something. > 7) Pytest has features for writing parametrized tests. > These two features are actually something worth looking at (parametrized tests would allow cleaning up a lot of template tests), but I'm guessing that for the core developers to get convinced you'd have to show that this two will make a real difference (instead of focusing on the less important stuff mentioned earlier). Best regards, Lucas Rekucki -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-EJM6tGxYsihgebYWXgX5uX3OLaJnrFZR3J1LDqxSa2xQg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Enforce the use of a unicode string in settings.LANGUAGES
Hi everyone, First I'd like to say I got bitten by this in the past. What worries me the most in the original report is the TEMPLATE_DEBUG part. IMHO, this should fail loudly regardless of any debug settings. As for other stuff: On 22 January 2014 18:34, Ramiro Morales wrote: > I think you are onto something re: the fact that we don't make clear > that our ugettext*() functions fail to accept encoded literals with > characters outside ASCII under Python 2.x. even when the encoding > metadata is correct. I think everyone is forgetting that those are *u*gettext() functions and they work fine with any literals as long as the argument type is unicode, because that is the only type they know how to handle. The implicit bytes->text conversion in Python 2 makes this a little less obvious, but the expected argument type is in the name. IMHO, It would be better for everyone if ugettext_lazy() and friends fail immediately when given anything other then text (unicode on Python 2, str on Python 3), but it's probably too late for that now. At least until Python 2 support is dropped completely. -- Łukasz Rekucki -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-E%2BVZ-Hnnm_%3D3Mx9XGS-xX9AfZZMEkAbWukhJf9yk0nvmw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Ticket #21751 review requested
On 19 January 2014 09:12, Shai Berger wrote: > On Friday 17 January 2014 01:19:29 Michael Manfre wrote: >> In an effort to make Django a bit more explicit with regards to closing >> cursors when they are no longer needed, I have created ticket #21751 [1] >> with a pull request[2]. >> >> Most of the changes are straight forward and change the usage of a cursor >> so that it uses a context manager or closes the cursor in 'finally'. >> >> Example: >> >> # old pattern >> connection.cursor().execute(...) >> >> # changes to >> with connection.cursor() as cursor: >>cursor.execute(...) >> > > I think this is suboptimal, API-wise. Python destroys temporaries soon enough. You mean CPython, right? Considering that a DB cursor can also allocate resources in the DB itself, I think it's not a good idea to rely on GC here. Unfortunately, the pull request in question won't help in many cases due to the way how try: finally: works in generators[1]. > Is there a reason why we cannot arrange for a __del__ method to close the > cursor? Circular references anywhere? AFAIK, this is already the case as long as the wrapped cursor does it. [1]: https://bugs.pypy.org/issue736 -- Łukasz Rekucki -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEZs-EKQJAfZpoOq30mRy%2B_PxOGt%3DoFLt4H7W0CaNjyY%3DbpXqA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: django.test.client: Improper POST requests
Hi abh,
On 29 August 2013 23:11, abh2134 wrote:
> Hi all,
>
> Working with django.test.client.
>
> Running:
> response = self.client.post(url, {"message": "this is a message"}),
> content_type="application/json")
>
> The server receives:
> (Pdb) request.body
> "{'platform': 'ios', 'token': '123abc', 'uuid': 'abc123'}"
>
> ... which is NOT a valid JSON string. A proper JSON dictionary's keys/fields
> are enclosed by double-quotes, not single quotes. See: http://www.json.org/.
It's not a bug. As per documentation:
If you provide content_type (e.g. text/xml for an XML payload),
the contents of data will be sent *as-is* in the POST request, using
content_type in the HTTP Content-Type header.
This means that you're responsible for proper encoding the data
parameter into string/bytes. Otherwise Django will just cast the data
to bytes.
--
Łukasz Rekucki
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: django.utils.functional.cached_property
Hi, I have some minor nitpicks: 1. Unlike the standard @property, the current implementation of @cached_property doesn't allow for a docstring. 2. Calling `del obj.` before accessing the value or more then once in a row throws an AttributeError. Should I make a new ticket for that or just send a PR for the old one ? -- Łukasz Rekucki -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal/Discussion: url and template search using the directory structure of apps within django sites
On 30 May 2013 10:20, Jorge C. Leitão wrote: > > On Thursday, May 30, 2013 7:54:40 AM UTC+2, Shai Berger wrote: >> > > Why python allows nested apps? Python allows nested *modules* because namespaces are good. Also because without it you would have to wither write every module in a single file or invent some weird conventions. > What would be the reason for a developer to nest apps? For Python modules, plenty. For Django apps? I don't really see a one except for the sake of the namespace itself like django.contrib. But in this case django.contrib is not an application itself, it's more of a namespace package as defined in PEP 420. > should django allow this? Why it should not ? > why should django allow this? Because we're all consenting adults and you're free do to whatever you want. Django documents what is possible and some major pitfalls. There is no gain in *disallowing* this. Personally I wouldn't use this as it's counter-intuitive and works in exact opposite to Python's import mechanism which by default does an absolute search (since 3.x). Regards, Łukasz Rekucki -- 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: Remote participation in sprints
On 15 May 2013 20:29, Shai Berger wrote: > On Wednesday 15 May 2013, ptone wrote: > > On Wednesday, May 15, 2013 10:31:36 AM UTC-7, Daniele Procida wrote: > > > On Wed, May 15, 2013, Shai Berger > > > > > > > > >Will there be an effective way to do this while communicating with the > > > >developers present at the sprint? IRC? Google hangout? IM? > > > > > > #djangocon and #django-sprint on irc.freenode.net > > > > > Thanks, > > > > > Indeed, note that the bulk of the sprinting will be during Central > European > > Time, UTC +1, > > Aren't they using Daylight Saving Time? That would put them at UTC+2, > wouldn't > it? > Yes, we are ;) CEST is the correct time zone. -- 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: Perception of attitude in tickets
On 13 May 2013 11:12, Chris Wilson wrote: > Hi all, > > > On Mon, 13 May 2013, Russell Keith-Magee wrote: > > This isn't political equivocating. Its a genuine call to the community to >> tell us how we can make things better. >> > > If I may make a suggestion to be considered by the community: > > The status WONTFIX sounds awfully rude to me. It's like saying "That's a > pony and you can't have one, ever." It implies a terminal finality which > actually isn't meant in some cases, because it is possible (as we've seen) > and even sometimes recommended by a core developer, for a sufficiently > determined person to push for change on the mailing list and make it happen. > You can blame this on my lack of social skills, but I really don't see how it's rude. It's informative: in current state the issue won't be fixed. Yes, it is possible to change the status to Accepted, but only if new facts arise (i.e. change of ecosystem, change in design). Note that the current proposal for refresh() differs significantly from the original one and that's the reason for accepting, not a core dev's change of heart. You can't have *that* pony, but it doesn't mean you can have *any* ponies. > > Perhaps there's a case for a status like "DISCUSSION" or "NEEDINFO" when a > feature might be accepted if sufficient evidence for it comes to light, but > that evidence isn't there yet. > I fear it will end the same way as "Design Decision Needed" aka. Limbo. It's a really horrifying state where the issue is nor dead nor alive and lingers for all eternity causing even greater frustration for both the reporter and developers. > I think there is value in people "voting" for a feature on the ticket if > they don't feel up to arguing the case on the mailing list (which is a > trial by fire, and not for the faint hearted). Whoever is brave enough to > take up the issue on the mailing list can point to the number of votes on > the ticket as evidence for a desire for the feature, and hence its > usefulness. And voting on the ticket instead of here saves a lot of "me > too" noise on the mailing list. > In my experience, people will vote for issue without giving much thought about it because clicking on a webpage doesn't cost anything, while presenting reasonable arguments on a mailing list requires at least a little research. Also, you would need negative votes and I suspect that would probably cause even more tension then "WONTFIX" status. Although there is one major flaw in the voting system/tracker I sometimes see: -1 votes (setting WONTFIX is effectively a veto just like -1) without giving conditions for improvement to at least -0. Having a clear path of action (even a one that involves a lot of work) to convince the person vetoing your proposal is always better then just "No, I don't think it's useful". -- Łukasz Rekucki -- 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: Triaging: Close as needsinfo
Hi, On 11 May 2013 22:58, Shai Berger wrote: > In > other communities, I have usually seen "needsinfo" as a ticket state, > rather > than a reason for closing; such tickets are then closed later, if enough > time > has passed and no further info is received. > To me that's just giving false hope for people viewing that ticket. If the ticket is open, there's a reasonable expectation that there is some action you can take to make it progress, but you most likely you can't as only the reporter has the needed info. For bugs, "needsinfo" is almost identical to "cannot reproduce" (aka "worksforme") and I can't think of a reason to keep such a bug open. Of course, there are people who will take everything personal. Even if it's getting your ticket closed by a stranger on a public bug tracker. -- Łukasz Rekucki -- 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: Transforming django-admin.py to a shell script
On 1 March 2013 22:38, Alon Nisser wrote: > at least from my windows exprience with Django (yes, I know this isn't a > common use case, but still) the current django-admin.py and manage.py do > need python preface to run right (while inside a virtualenv) I'm not 100% sure if the Windows Python Launcher[1] works with virtualenv, but it most likely works with venv support in Python 3.3. It should also allow you to run Python scripts without the .py suffix Anyways, what kind of "shell" you had in mind? Batch ? Powershell ? Bash ?. [1]: http://blog.python.org/2011/07/python-launcher-for-windows_11.html -- 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: Charset for URL decoding (#19468)
On 18 December 2012 09:34, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > (complete version follows) > > Hello, > > I'm looking for some feedback on #19468 before making a decision. It's one > of the tickets that currently block the 1.5 release. > > Here's a summary of the problem. > > Django must decode environ['PATH_INFO'] to obtain request.path, where > decoding means : > 1 - URL-decoding to a bytestring > 2 - "charset-decoding" to an unicode string > > The question is : which charset should be used in step 2? > settings.DEFAULT_CHARSET or utf-8 (hardcoded)? > > I wonder if UTF-8 with "surrogates escape" error mode makes sense here. Python 3 uses it for decoding file-system paths, where it's not always possible to determine the charset. I think it's pretty much the same case. After all, the %-coded bytes can be some binary data that's not possible to reasonably decode with any charset. -- Łukasz Rekucki -- 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: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)
On 6 November 2012 00:48, Jordan Hagan wrote: > > From my count there are 8 people in this thread in support of the > functionality, and 2 people against it (1 at the time of my previous > message). There is also lots of other people that don't feel the need to join the thread as they feel their views are represented. Personally, I don't see any big advantage of having a yet another init method, but OTOH I already replaced Django's view hierarchy with my own, as I needed a more advanced data flow. -- Łukasz Rekucki -- 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: Admin UI improvement - actions displayed as buttons rather than drop-down list
Hi, Isn't this https://code.djangoproject.com/ticket/19235 ? Regards, Łukasz Rekucki -- 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: Django produce sql with table name different then specified in meta db_table
On 31 October 2012 21:46, Ian Kelly wrote: > On Wed, Oct 31, 2012 at 2:18 PM, Michał Nowotka wrote: >> >> But what is really buggy here is if i explicitly specify that this >> table is not managed django should respect db_table and not perform >> any truncation. That's all. > > > It won't truncate the name if you fully enclose it in quotes. Instead of: > > > db_table = 'schema_name\".\"table_name' > > Try: > > db_table = '\"schema_name\".\"table_name\"' > > This only works for unmanaged models. For managed models it results in an > error when it tries to create the sequence and trigger using syncdb. Why all the slashes ? Unless you specify r'' or make them double, they don't do anything! >>> '\"' == '"' True -- Łukasz Rekucki -- 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: Django produce sql with table name different then specified in meta db_table
On 31 October 2012 20:23, Shai Berger wrote: > This, almost worthy of being called an sql injection, can't be the right way > to achieve the goal. In fact, the Oracle backend (or even some higher, more > generic level) should have doubled those '"' characters to make them part of > the name. But -- save length issues -- the ploy succeeds: It seems none of the backends implement any form of quote escaping in their quote_name() methods. But is it actually possible to have a table in Oracle with a name containing a double quote? -- Łukasz Rekucki -- 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: Django produce sql with table name different then specified in meta db_table
On 31 October 2012 19:31, Michał Nowotka wrote:
> I would understand truncating but please take a look:
>
> class DefinedDailyDose(models.Model):
> #...
> class Meta:
> db_table = u'mnowotka\".\"defined_daily_dose'
> managed=False
>
> where the name is even longer
Don't want to be mean, but:
>>> len(u'mnowotka\".\"defined_daily_dose')
29
>>> len('mnowotka\".\"protein_therapeutics')
31
So no, that's not longer. It's exactly 2 characters shorter which is
enough not to fall into 30 char limit.
PS. I'm pretty sure you want to have:
db_table='"mnoworka"."defined_daily_dose"'
If the name is already quoted, Django won't alter it. OTOH, see issue
#18514 (which shouldn't be a problem if you have managed=False).
[1]: https://code.djangoproject.com/ticket/18514
--
Łukasz Rekucki
--
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: Update on localflavor move
On 16 October 2012 11:21, David Winterbottom wrote: > Here's another pull request for setting up testing, this time using tox as > per Russell's suggestion. > https://github.com/django/django-localflavor-gb/pull/2 > > AFAIK, tox requires the tests to be part of the package. Hence I moved > tests.py into the django_localflavor_gb package as well as a test settings > module. Using Django's testrunner also requires that the package has a > models.py so it is considered an app. Is is possible to use tox and the > django testrunner so that the test can be separate, and the package doesn't > require a models.py? That would be cleaner in my eyes. > > Feedback welcome of course. Hopefully this is a step in the right direction > for agreeing on a testing set-up for all the localflavors. > > On 16 October 2012 04:55, Mahdi Yusuf wrote: >> >> Hi, >> >> I have setup testing in a pull request here. >> >> If this solution is acceptable. I can duplicate the process on the other >> local flavours. >> >> I would appreciate feedback. >> >> -- >> Mahdi Yusuf If we include some form of a test runner in every localflvour, I suspect they will get out of sync quite quickly. Also, I don't think there is a good reason for duplicating code. Maybe we need something like django-localflavour-commons, which would include the test harness, packaging logic (then in setup.py you can just import it from there), etc. My first idea was to make it a submodule, but that would still require making a commit to all repos whenever we update the commons (althought, still simpler then applying the same patch everywhere). We could instead put it on PyPI and make all other packages always require it's latetest version. -- Łukasz Rekucki -- 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: URL dispatcher slow?
On 11 October 2012 10:20, Russell Keith-Magee wrote: > > And don't just say "Why are Django's URL resolvers slow?". Do some > profiling, and come back with an analysis of where the time is being > spent and/or wasted. FWIW, here's a link to a cProfile result for the mentioned benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows that we're calling get_language() 1.5mln times (read: for every pattern), so that's definitely going to slow down things. I'll try running the same with 1.3 and maybe 1.4 without the locale mixin and post if I find anything interesting. [1]: https://gist.github.com/3875701 -- Łukasz Rekucki -- 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: django.test.client.Client tests in Django development?
Hi everyone, After a quick peekat the code in get_user(), I'm curious is there any reason we currently don't flush the user's session (or at least remove the SESSION_KEY and BACKEND_SESSION_KEY) if the backend returns None for the user's id? I can't see how being able to hang on to an unauthorized session in hope it will become authorized again can be anything but a bug. Regards, Łukasz Rekucki -- 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: Breaking out localflavor
On 16 August 2012 23:42, Jacob Kaplan-Moss wrote: > On Thu, Aug 16, 2012 at 3:38 PM, Adrian Holovaty wrote: >> You mean like a magic import thing, right? > > Well, Python *does* have some namespace package support stuff. It's > something of a mess, with one implementation internally, another in > setuptools, and (IIRC) a new PEP that'll take hold in Python 3 and > clean things up. It's not only new, but it works (http://docs.python.org/dev/whatsnew/3.3.html#pep-420-namespace-packages) ;) On Fri, Aug 17, 2012 at 5:39 AM, Alex Gaynor wrote: > > > On Thu, Aug 16, 2012 at 9:38 PM, Russell Keith-Magee > wrote: >> >> >> I agree that this is certainly one way that we could address the >> problem. However, localflavor isn't just forms. Some of the packages >> (US in particular; and I think there's also a patch lurking for AU) >> have database models as well. I'd be inclined to keep the >> 'localflavor' moniker. > > I don't think that's correct, they have model *fields*, but no actual > models. I'm pretty sure everyone with South will still be pretty unhappy about updating all their migration files. -- Łukasz Rekucki -- 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 - style question
On 10 August 2012 18:56, Vinay Sajip wrote: > I think Option 2 is better, for the reasons you state. > How about wrapping those 3 lines of code into a class decorator (preferably named more explicit then StrAndUnicode) ? That would be at least a little DRY. -- Łukasz Rekucki -- 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: I think adding a "first" method to the QuerySet be useful.
On 3 July 2012 06:27, Maxime Haineault wrote:
> One of the common pitfall I come across way to often with novices is
> something like this:
>
> def getFirstUser():
> return User.objects.all()[0]
>
> It looks innocuous and often wont raise any exceptions in dev because you
> develop and test with data,
> so they slip easily in production.
>
> def getFirstUser():
> return User.objects.all().first()
>
> If the QuerySet is empty it should just return None instead of raising an
> exception.
>
> Other methods like .last() could probably also be useful, but getting the
> first element of a QuerySet
> is the pitfall I see the most often.
>
> Surprise Poney Quizz: which is the fastest way to get the first object of a
> QuerySet ?
>
> A) Using count:
>
> qs = User.objects.all()
> if qs.count() > 0:
> return qs[0]
> else:
> return None
>
> B) Convert to list:
>
> r = list(qs[:1])
> if r:
> return r[0]
> return None
>
>
> C) Using len:
>
> qs = User.objects.all()
> if len(qs) > 0:
> return qs[0]
> else:
> return None
>
> D) Try/except:
>
> qs = User.objects.all()
> try:
> return qs[0]
> except IndexError:
> return None
>
E) Use __bool__ which fetches only one batch (depends on DB):
qs = User.objects.all()
user = None if not qs else qs[0]
F) Use the iterator protocol
user = next(iter(User.objects.all()), None) # you can add LIMIT or
not, see Alex's comment
--
Łukasz Rekucki
--
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: Redesign of djangoproject.com?
On 24 May 2012 02:36, Ashraful Sheikh wrote: > Hi everyone, > > I saw this on HackerNews(news.ycombinator.com) and wanted to contribute. > Here is my mockup: http://i.imgur.com/dSMSJ.jpg > > With the design, I focused on keeping the look extremely clean, professional > and minimalistic. The content is based on that of the current site. The > mockup may seem a bit lacking in color, but adding eye-catching icons for > the features, and the screens for the "built with Django" section will add > sufficient color to liven up the design. On wider screens, the blog posts > will appear in a siderbar to the left of the features list. > > If you guys like it, email me at inl...@gmail.com, or reply here. You can > check out my previous work at madebyargon.com. Some of you may have seen the > redesign I did for VideoLAN (videolan.org) which receive a positive reaction > from the open-source community surrounding VLC. > You really might want to read this thread before posting any mockups - especially Russell's comments. Just to point out one problem: where is the "Code" or "File a bug" link ? If someone wants to contribute to Django in some way: code, doc fixes, translation, money for DSF, etc., the site should make it easy to find the necessary information for that to happen (like a link bug tracker, *link to github*, link to Transifex and a contact to DSF). "Download" is really not the most important link these days. Just my 2 cents. -- Łukasz Rekucki -- 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: Test reordering and TransactionTestCase cleanup
On 8 May 2012 14:22, Karen Tracey wrote: > On Mon, May 7, 2012 at 5:50 PM, Anssi Kääriäinen > wrote: >> >> I would like to just get rid of the sequence resets. Oracle doesn't do >> it currently, TestCase doesn't do it, and IMO assuming the IDs are >> going to start from 1 is an assumption one should not make. >> >> Objections to just getting rid of the sequence resets altogether (with >> the opt-in flag)? > > > I did not realize Django code was doing something explicit to reset > sequences during the database flush between TransactionTestCases, I thought > it just happened as a side-effect of the method used to clear the DB. Taking a quick look at the code, it is a side-effect in the sense that "manage.py flush" on PostgreSQL does that and TransactionTestCase uses exactly that command. Also, one might want to fix #10164 [1] first or the "reset_sequence" flag (which is missleading name for something that does an extra flush) will be a noop on SQLite. [1]: https://code.djangoproject.com/ticket/10164 -- Łukasz Rekucki -- 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: FYI: Trac downtime today
On 25 April 2012 17:52, Jacob Kaplan-Moss wrote: > You are (you're in the ticket triagers group). > I knew I'm in that group, but I'm quite sure I don't need access to stuff like "Manage Versions", "Manage Resolutions", "Manage Components", etc. to do triaging. Now that I know I have access to it, I'm scared I'll break something be accident ;) -- Łukasz Rekucki -- 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: FYI: Trac downtime today
On 25 April 2012 17:32, Jacob Kaplan-Moss wrote: > OK, done! Thanks for your patience. > > Jacob Am I supposed to see the "Admin" tab or did I just haven't noticed it before? -- Łukasz Rekucki -- 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: GitHub migration planning
On 19 April 2012 00:55, Donald Stufft wrote: > Github Issues are not flexible enough for Django. > That's rather a vague statement. Github issues are actually more *flexible* then Trac as you can define any set of tags for an issue. What Django could possibly want to have is a way to create extra constraints on the tags, but as a matter of fact, the current Trac instance doesn't do that! (you can have an issue with "tests needed" but without "patch needs improvement"). -- Łukasz Rekucki -- 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: Errors in tests
On 11 April 2012 13:37, Vinay Sajip wrote:
> The errors seem to be related to Aymeric's change in r17894. If I
> change
>
> def _reset_dicts(self, value=None):
> builtins = {'True': True, 'False': False, 'None': None}
> if value:
> builtins.update(value)
> self.dicts = [builtins]
>
> to the seemingly equivalent
>
> def _reset_dicts(self, value=None):
> value = copy(value or {})
> value.update({'True': True, 'False': False, 'None': None})
> self.dicts = [value]
>
> then the errors no longer occur.
I think this is even more correct, as the previous function allowed
for overriding "True" to something else. Although, that might break
somebody's template :)
As for the error, it's quite a puzzle. If update() tries to iterate
thru value, it means it's a non-empty sequence that's not a subclass
of dict, right? Did you manage to track what type of value it is?
There must be a bug somewhere else too.
--
Łukasz Rekucki
--
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
On 5 April 2012 19:45, Alex Ogier wrote:
>
>> >> class User(models.Model):
>> >> MALE = 0
>> >> FEMALE = 1
>> >> GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
>> >> gender = models.IntegerField(choices=GENDERS)
>> >>
>> >> def greet(self):
>> >> return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
>> >>
>>
>> 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.
>>
>> --
>> Łukasz Rekucki
>
> As attributes of the class object I'm pretty sure they are in scope. No
> NameErrors there.
>
That's not how it works. Code that executes when creating a new class
does not define a lexical scope. There is no such thing as "class
scope". Try it yourself:
http://ideone.com/xbr0q
--
Łukasz Rekucki
--
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
On 5 April 2012 09:45, Thomas Guettler wrote:
> Hi,
>
> I created a ticket, incl. patch
>
> https://code.djangoproject.com/ticket/18062
>
>
While the example itself is useful, I don't really think Django's
documentation should state obvious facts about Python, especially
false ones.
>
> Am 04.04.2012 18:41, schrieb Adrian Holovaty:
>>
>>
>> I don't see the immediate need for Yet Another Sub-framework, as
>> described in this proposal. This is what I normally do, and it works
>> fine:
>>
>> class User(models.Model):
>> MALE = 0
>> FEMALE = 1
>> GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
>> gender = models.IntegerField(choices=GENDERS)
>>
>> def greet(self):
>> return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
>>
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.
--
Łukasz Rekucki
--
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: Dropping django.utils.simplejson
On 30 March 2012 13:04, Alex Ogier wrote: > At the same time, I want to reiterate my support for option #1: not > deprecating the > module and leaving the shim in for the foreseeable future. If simplejson is > available on the system, and particularly if it has been compiled with C > extensions, then there is a significant performance gain to be had, so why > not continue to take advantage of that in all the places that django > serializes to json? I agree this is a valid concern and I think it should be mentioned in release notes. If you want more performance, then option #3 (anyjson) would actually be better, but I don't think it should be Django's concern to choose the best JSON package for you (we don't do that for XML). Instead, imho, Django should provide an ability to pass a custom JSON encode/decoder to all APIs that require it, so you can decide about it at the project level. -- Łukasz Rekucki -- 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.
Dropping django.utils.simplejson
Alex's comment on ticket #18013 reminded me of this. Is there any reason not to get rid of the Django's version of simplejson now that Python 2.6 always has the json module? I see three options here: 1) Remove Django's copy and only leave the simplejson/json fallback. 2) Above, plus deprecate "django.utils.simplejson" in 1.5 and remove it 1.6 3) Replace the code with anyjson, so it does something useful: http://pypi.python.org/pypi/anyjson What do you think ? -- Łukasz Rekucki -- 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: suggestion: Don't make the tag "url" dirty in Django1.5
On 27 March 2012 14:44, Łukasz Rekucki wrote: > On 27 March 2012 14:22, Shaggy wrote: >> >> and btw. is there repo for developing 1.5 with python3 support? >> > > AFAIK, not yet. There's a features/py3k branch, but I'm not sure if > it's up to date with Tarek's bitbucket repo. My bet is that py3k merge > will happen after the GitHub migration which everyone seems to be busy > with ;) This isn't my best day. First I don't notice the quotes in the example are misplaced, then I mix up Tarek Ziade with Vinay Sajip. Of course I meant this repo: https://bitbucket.org/vinay.sajip/django ; Sorry for the confusion :( --- Łukasz Rekucki -- 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: suggestion: Don't make the tag "url" dirty in Django1.5
On 27 March 2012 14:22, Shaggy wrote: > from where U have that info? Docs and Django 1.3 release notes: https://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-url-and-ssi > > and btw. is there repo for developing 1.5 with python3 support? > AFAIK, not yet. There's a features/py3k branch, but I'm not sure if it's up to date with Tarek's bitbucket repo. My bet is that py3k merge will happen after the GitHub migration which everyone seems to be busy with ;) -- Łukasz Rekucki -- 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: suggestion: Don't make the tag "url" dirty in Django1.5
On 27 March 2012 10:22, gs412 wrote:
> In Django1.5
>
>> {% url app_views.client %}
>
> will change to
>>
>> {% "url app_views.client" %}
>
>
> I think it is a stupid idea
Did you read the rationale for this change? How do you want to enable
passing context variables as view names? Did you notice that almost
everywhere in the template language literal strings are quoted?
Technical arguments usualy work better then calling things "stupid".
--
Łukasz Rekucki
--
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: Tagging 1.4 django release in Subversion
On 27 March 2012 03:01, Alex Gaynor wrote: > > > On Mon, Mar 26, 2012 at 9:00 PM, Łukasz Rekucki wrote: >> >> On 27 March 2012 02:44, Reinout van Rees wrote: >> > On 26-03-12 18:13, Florian Apolloner wrote: >> >> >> >> >> >> I'm also intrigued how you have a release tarball before you have >> >> tagged the release! >> >> >> >> It's magic :ş >> > >> > >> > Well, it is the kind of magic that gets you burned at the stake for >> > witchcraft :-) >> > >> >> That only means it must be effective ;) >> >> >> As for the GitHub migration, I noticed this little repo[1]. Are you >> collecting only major contributors or is it open for pull requests ? >> >> >> [1]: https://github.com/brosner/django-git-authors >> >> -- >> Łukasz Rekucki >> >> -- >> 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. >> > > As far as I understand, it's only needed for people with commits in the SVN > repo. (That is, commit authors, not patch contributors). > For a moment, I thought we could have some more of that magic and amend the commits in git, so that "author" would be the patch contributor and commit author would be the "committer". This should be possible in most cases, as you only need to map the "Thanks " to an email address and github should do the rest. > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -- > 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. -- Łukasz Rekucki -- 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: Tagging 1.4 django release in Subversion
On 27 March 2012 02:44, Reinout van Rees wrote: > On 26-03-12 18:13, Florian Apolloner wrote: >> >> >> I'm also intrigued how you have a release tarball before you have >> tagged the release! >> >> It's magic :ş > > > Well, it is the kind of magic that gets you burned at the stake for > witchcraft :-) > That only means it must be effective ;) As for the GitHub migration, I noticed this little repo[1]. Are you collecting only major contributors or is it open for pull requests ? [1]: https://github.com/brosner/django-git-authors -- Łukasz Rekucki -- 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: Status of issue 17758: dict ordering bugs
Hi, Thanks Aymeric for committing the ORM related fix. As Ramiro suggested, I created a separate ticket for the bug in dependency_order() function - #17954. While it's always nice to have more bugfixes, it doesn't qualify as a release blocker anymore. Looking forward to 1.4 final soon :) -- Łukasz Rekucki -- 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: Status of issue 17758: dict ordering bugs
On 22 March 2012 16:54, Aymeric Augustin wrote: > Le 22 mars 2012 13:22, Łukasz Rekucki a écrit : >> If the whole patch can't be merged, lets at least fix that bug[2]. Is >> there any work I can do to make it happen? >> [2]: >> https://github.com/lqc/django/commit/84dc450ec861e34de068fde891537f0481342ef7 > > Hi Łukasz, > > Let's try to get this fix in 1.4. Since the change in the tests isn't > significant, it boils down to replacing two `dict`s which > `SortedDict`s. Since a `SortedDict` is a subclass of `dict`, this > change looks safe. > > In a comment [1], you said: > >> there are a few places that relabel aliases and ruin the order, like >> QuerySet.change_aliases(). (...) I fixed this, by using change_map = >> SortedDict() in QuerySet.split_exclude. This should probably apply to all >> change_maps when working with aliases. > > This implies that your fix isn't complete, is it? Could you clarify? > Yes, sorry. It's complete in the sense, that it fixes this bug and I haven't been able to spot any other bugs by reading the code or doing tests. There is at least one other place that creates a "change_map" variable (or something similar), that is used to relabel aliases in a Q object (AFAIR), but it never uses it in a way that could be affected by ordering. My other concern is other similar structures (like alias_map or included_inherited_models). While I failed to find any dangerous uses, I'm not (yet, I hope) very comfortable with the ORM code, so I wouldn't trust myself on that 100%. OTOH, I didn't want to blindly change all the dicts to SortedDict. -- Łukasz Rekucki -- 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: Status of issue 17758: dict ordering bugs
On 22 March 2012 13:38, Ramiro Morales wrote: > 2012/3/22 Łukasz Rekucki : > > Maybe we should split these problem reports in their own tickets? > I can do it later today. There probably should be 3 tickets: the ORM bug, the dependency_order() bug and the test suite fixes (which can be split further into HTML, XML, JSON and urlencode() related stuff if needed). -- Łukasz Rekucki -- 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.
Status of issue 17758: dict ordering bugs
Hi, I got a sad message today, that it's most likely that issue #17758 won't go in to 1.4; While most of the problems addressed by this ticket are harmless, I really don't think it's a good idea to ship 1.4 without resolving the ORM bug. The hash randomization is a security fix. Right now, people upgrading to Python 2.6.8 or 2.7.3 will start randomly getting different results on some queries. If the whole patch can't be merged, lets at least fix that bug[2]. Is there any work I can do to make it happen? [1]: https://code.djangoproject.com/ticket/17758 [2]: https://github.com/lqc/django/commit/84dc450ec861e34de068fde891537f0481342ef7 -- Łukasz Rekucki -- 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: [GSOC 2012] Customizable serialization
On 20 March 2012 17:50, Piotr Grabowski wrote: > Hi, > > My name is Piotr Grabowski. I'm last year student at the Institute of > Computer Science University of Wrocław (Poland). I want to share with you > draft of my GSOC proposal. Hi, nice to meet you :) > > http://pastebin.com/ePRUj5HC IMHO, Sending the full text to the list would make it easier to comment on specific points. I like your approach in overall - mainly because I've been using a similar one for a few months now ;). Some comments after a quick read: 1) The Meta.structure things looks like a non-starter to me. It's a DSL inside a DSL. I'm also not sure what it actually does - you already have all those @attribute decorators, why repeat their names in some string? 2) Meta.fk_level - I don't think this is really useful (AFAIR, the previous GSOC had this and it wan't very well received). In 80% cases you know exactly which FKs you want to have on the model. If the related objects also have FKs, then either they are important or they can be omitted. Cutting off at some arbitrary depth doesn't feel right. In my code, I instead define "named" serializers for models and resolved them based on the "path". This way I can get different fields for "User related to Comment" and "User related to Task", while avoiding an infinite loop. 3) Did you thought about splitting the serialization process in two parts (dehydration + presentation)? This is what most REST frameworks do. First you serialize the objects into Python native types, then render it to any format. -- Łukasz Rekucki -- 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: authentication by email
On 9 March 2012 21:10, Tom Evans wrote: > 2012/3/9 Łukasz Rekucki : >> On 9 March 2012 17:46, Tom Evans wrote: >>> >>> Lets look at one isolated aspect. The User email field in d.c.auth is >>> too short. Emails can be up to 248 characters long, and d.c.auth only >>> allows 75. >> >> The latest RFC[1] actually specifies this as 256 *octets* with max of >> 64 octets for the local part and 255 octets for the domain name. So >> 248 *characters* would actually be incorrect and all the tedious and >> error prone fixing of every Django instance would just get wasted. >> > > Sorry, 248 was a typo. If you look at my earlier reply in this thread, > I had correctly stated the maximum length of an email address as 254 > *characters*. > > If you check two paragraphs later in the RFC that you linked to, you > would see confirmation of this: > > http://tools.ietf.org/html/rfc5321#section-4.5.3.1.3 > > You may also need to remind yourself what the definition of a path is. And RFC 3696 originally claimed it's 320. Even after errata it still says 256, but you are right that 254 is probably more correct. > > As all email headers are either 7 or 8 bit encodings, describing 254 > octets as 254 characters is perfectly valid. UTF-8 is an 8-bit encoding that doesn't map octets to characters, so no. But that's not really the point I wanted to make. My point is that this kind of things change and we should have tools to deal with that. We already have the exact same problem with IPv6 and contrib.comments, it's just people didn't noticed it yet as much. Doing this by hand every time isn't very effective. Django needs schema migrations. As for the "design page" that Joe mentioned, the GSOC description is a good start: https://code.djangoproject.com/wiki/SummerOfCode2012#Enhancedauth.user -- Łukasz Rekucki -- 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: authentication by email
On 9 March 2012 17:46, Tom Evans wrote: > > Lets look at one isolated aspect. The User email field in d.c.auth is > too short. Emails can be up to 248 characters long, and d.c.auth only > allows 75. The latest RFC[1] actually specifies this as 256 *octets* with max of 64 octets for the local part and 255 octets for the domain name. So 248 *characters* would actually be incorrect and all the tedious and error prone fixing of every Django instance would just get wasted. I don't really think this is a "fear of change" case. It's more of "we don't want to have to fix this again" thing. [1]: http://tools.ietf.org/html/rfc5321#section-4.5.3.1.1 -- Łukasz Rekucki -- 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: The model class should have default ``__cmp__`` method.
On 9 March 2012 06:15, Λlisue wrote: > I have the following codes for testing model and it's works correctly in > Django 1.3 + Python 2.7 without unittest2:: > > # in method of TestCase subclass --- > user1 = User.objects.create_user(username='user1', > email='us...@test.com', password='password') > user2 = User.objects.create_user(username='user2', > email='us...@test.com', password='password') > > self.assertItemsEqual(User.objects.all(), [user1, user2]) > #--- > > However the code raise ``AssertionError: Sequences differ: ...`` in > Django 1.3 + Python 2.6 or Django 1.3 + Python 2.7 + unittest2. (well > but I have no idea why the code above works with Django 1.3 + Python 2.7 > without unittest2) Since 1.3 Django ships with unittest2 library (see django.utils.unittest), so if there are no other versions of unittest2 installed, it will use that (which is a verbatim copy of unittest2==0.5.1). Python 2.7 seems to have a bit different implementation of that method, but it uses things like Counter. > > This happen because unittest2 or whatever does ``sorted(expected_seq)`` > in ``assertItemsEqual`` method but they don't know how to sort the > instances of model class. Actually, assertItemsEqual handles unorderable and unhashable items, if you take a look at it's source code. The py2.7 version should too. Didn't have time to check this, but it looks like a bug in unittest2. > To solve this problem, I simply add > ``__cmp__`` method to Model class like:: > > # somewhere but called after Django has correctly configured --- > from django.db.models import Model > > if not hasattr(Model, '__cmp__'): > Model.__cmp__ = lambda self, other: cmp(self._get_pk_val(), > other._get_pk_val()) > #--- > Apart from __cmp__ being deprecated, this isn't really correct even for testing (the model can have an UUIDField as it's pk instead of a sequential integer). For making assertions about QuerySets, there already is assertQuerysetEqual(), so -1 on adding __cmp__ to Model. -- Łukasz Rekucki -- 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: Django participation in Google Summer of Code 2012
On 8 March 2012 16:43, Aymeric Augustin wrote: > PEP 414 was accepted a few days ago. It's designed to make it easier to > support 2.6, 2.7, 3.3+ on the same codebase. > > I hope we'll take advantage of this new feature in Django; however, that > means a large update (if not a reboot) of the py3k branch. > Why would you want to do that, when the py3k is already working with unicode_literals ? That's a step backwards. -- Łukasz Rekucki -- 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: Revisiting multiline tags
On 26 February 2012 06:12, Yo-Yo Ma wrote:
> After Ned's message, I'm -0, because while I'm not fond of multi-line
> tags, I cannot offer a good alternative when it comes to multi-line
> "with" tags.
Let's not forget that until Django 1.3, {% with %} accepted only one
parameter forcing you to write nested {% with %}'s. We had a
discussion then and a more concise "x=..." syntax was chosen over "and
x as ...". The syntax was also added to blocktrans. This was to ease
those rare cases when you have to pass a few parameters to the {% with
%} and/or make an include with changed context. A year after, It turns
out the use cases aren't so rare anymore.
Now, if your blocktrans contains 10 variables and all have more then 2
dots in them, then maybe there are other reasons that it looks ugly
then lack of multi-line tags.
--
Łukasz Rekucki
--
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: Revisiting multiline tags
On 26 February 2012 05:55, Joe & Anne Tennies wrote: > While this would be a valid argument if Django templates only rendered HTML, > that is not the only thing it can be used to render. > The original poster gave a very good example of a text-based email. This is pretty much the only valid use-case: human-readable markup which cares about whitespace. But I don't see how multiline tags help here, as now you have a mix of text that does and doesn't care about whitespace, So when reviewing the template, you can't see the layout. > I could list lots of other formats in which white space must be followed to > even be useful (like .CSV). Please don't use templates to render CSV, that's like using regular expressions to parse XML. Most of data exchange and configuration file formats have libraries to serialize them. So no, that's not a use case. > I have used Jinja2 on multiple occasions to render C code that needed to be > code reviewed. While I have nothing against rendering C code with templates, I pity the person reviewing it - why would you force anyone to review auto-generated code? I'm -1 on this until someone actually provides a patch with no performance hit. Really, we know people fork Django for their private use. If this is such a big deal, we should have at least one person using this in production for a while now and have an excellent quality patch to show. -- Łukasz Rekucki -- 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: Revisiting multiline tags
On 24 February 2012 17:29, Łukasz Rekucki wrote: > With all the voting and aesthetic discussion, maybe let's get back to > technical details: > > On 24 February 2012 05:18, colinta wrote: >> 1) It's an easy fix. > > Maybe it is, I can only judge a specific patch, > >> 2) It's backwards compatible. > > Right now, tags are free to parse the tag contents any way they like. > You don't know if presence of EOF won't brake them or do we normalize > the EOF to spaces ? I meant EOL of course. -- Łukasz Rekucki -- 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: Revisiting multiline tags
With all the voting and aesthetic discussion, maybe let's get back to technical details: On 24 February 2012 05:18, colinta wrote: > 1) It's an easy fix. Maybe it is, I can only judge a specific patch, > 2) It's backwards compatible. Right now, tags are free to parse the tag contents any way they like. You don't know if presence of EOF won't brake them or do we normalize the EOF to spaces ? > 3) It has no impact on performance. Given 2) and no benchmark data, we don't really know. > 4) LOTS of people want it. > That's never a good argument. If it was such a big issue, that LOTS would either spam this list or fork Django long ago. With a clear BDFL veto, it's better to search for an alternate solution then waste everyone's energy on a bikeshed. -- Łukasz Rekucki -- 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: Django and dictionary ordering
On 24 February 2012 10:31, Paul McMillan wrote: > The official Django position on the Python hash randomization issue is > that this Python bug has been fixed in Python. Users of Django should > explicitly enable hash randomization for versions of Python below 3.3. > We'll probably make a formal announcement and writeup for how to do > this once the changes have trickled down into more general > distribution channels. Users who cannot enable randomization or cannot > patch their versions of Python are advised to limit the size of > requests and the number of allowed parameters per request in their > webserver to the smallest practicable value for their use case, and > strictly limit the maximum runtime of any given process. > > Any failures of the Django test suite which are caused specifically by > this randomization change are bugs. Tickets and patches are welcome. > > -Paul > Just run the testsuite latest Python 2.6.8 and -R option: Python 2.6.8rc1 (unknown, Feb 24 2012, 14:38:43) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin with following results: Ran 4613 tests in 822.943s FAILED (failures=39, errors=1, skipped=109, expected failures=2) It's a bare install, so there may be more within the skipped ones. Most look harmless and only needs updating the testcases, so it doesn't require specific order. Created ticket https://code.djangoproject.com/ticket/17758 - I think this should be a release blocker. -- Łukasz Rekucki -- 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: Discrepancy involving choices with ModelForm and Form
On 22 February 2012 08:43, Stuart Laughlin wrote: > Carl -- > > Thanks for the feedback! > > On Feb 21, 7:47 pm, Carl Meyer wrote: >> >> It's >> important that you can get full control at some level - if a blank >> option were automatically added to ChoiceFields, how would you propose >> that a developer remove it if they didn't want it? >> > > I would propose... > > my_form_field = forms.ChoiceField(choices=MY_CHOICES, > include_blank=False) > But what would be the label for this automatically generated blank choice and how do you change it ? I guess, you'll need an "empty_label" option [1]. So now we added two extra params which take literal values and gained zero functionality or readability. We could actually only have the empty_label thing and thus make it consistent with ModelChoiceField. But I still think this isn't a good idea, because "magically" adding extra stuff where the user doesn't expect that is bad. ModelForms is a different case, as it auto generates forms from models. That's pretty "magic" already, so an extra label shouldn't surprise you. [1]: https://docs.djangoproject.com/en/1.3/ref/forms/fields/#django.forms.ModelChoiceField.empty_label -- Łukasz Rekucki -- 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: Class-based view decorators
On 17 February 2012 20:22, Carl Meyer wrote: > >> The second is class_view_decorator, to apply classic view decorators >> to the newer class-based views: >> >> @class_view_decorator(never_cache) >> @class_view_decorator(login_required, login_url='/my-login') >> @class_view_decorator(permission_required, 'thing.change_thing') >> class MyView(View): ... > > Unfortunately, class decorators that create and return a dynamic > subclass cause infinite recursion if super() is used in a method of the > decorated class, because the name given as the first argument to super() > will actually refer to the subclass at runtime. This problem, and > alternative options, were discussed extensively in a thread here a few > months ago. > Just for reference, the ticket to track this is #14512 [1] - see the original thread, the thread about copying instead of subclassing and Jacob's proposal to unify it all. Here [2] you can find a testcase that demonstrates what Carl described. I can only add that after over a year of using the version which modifies the class in-place, my team never had trouble with that. The super() problem actually makes a great Python puzzle so it's easy to remember the dangers after solving it ;) [1]: https://code.djangoproject.com/ticket/14512 [2]: https://github.com/lqc/django/blob/cbvdecoration_ticket14512/tests/regressiontests/utils/decorators.py#L120 -- Łukasz Rekucki -- 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: Moving to ... Github vs Bitbucket
On 16 February 2012 18:27, Jacob Kaplan-Moss wrote: > Hi folks -- > > Please can we not have this argument? This is one of those holy wars > that can get really, really ugly and I'd like to nip it in the bud. > Sorry for fueling this up. Should have think a few times more before sending that. Also, it wasn't my intention to "bash bitbucket" or anything like that so sorry for that too. I'll just shut up now and let the silence hide this thread. -- Łukasz Rekucki -- 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.
Moving to ... Github vs Bitbucket
On 16 February 2012 16:02, Stan wrote: > > > On Feb 9, 1:49 pm, zalew wrote: >> > We're going >> > to solve that with our move to Git/GitHub, which will make it much >> > easier for people to fork and much easier for core developers to >> > integrate contributions. >> >> a bit offtopic: why nothttp://bitbucket.org?similar features, it's on >> python/django and already popular in django community. 1) I can't argue about popularity, because I have no data, but most Django applications I use come from github, so it's also quite popular. 2) I don't think Django should care if the collaboration tool runs python/django or java/grails as long as it's useful for developers. Anything beyond that is politics and that's what DSF might care about (I don't). 3) As for similar features... sometimes "similar" is not enough. I'm not a regular Bitbucket user, so I maybe just didn't discover that, but how can you add per line comments in patches on Bitbucket ? Without that, code reviews for non-trivial patches is a real PITA. -- Łukasz Rekucki -- 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: auth.User usernames
On 15 February 2012 23:57, Donald Stufft wrote: > > 1.5 would work as well ;) Sorry I sometimes speak before I think things > through, > thoroughly. django.auth in general is something that i'm interested in and I > want > to try and improve to be more flexible, I just hadn't though of a general > solution yet > and a "easy" (code wise) fix appealed in a shorter term "provide some > improvement" > sort of way. > AFAIR, the last consensus was to get some basic schema alternation API into Django (see the last GSOC), so that we can fix things like that. So the general solution would be doing that ;). Just changing it, helps new installations, but breaks old ones. PS. Since Facebook started generating fake addresses, 75 characters on the email field is also no good, so matching that doesn't solve anything ;) -- Łukasz Rekucki -- 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: Feature Request: Client side validation classes for forms
On 3 February 2012 22:03, Adrian Holovaty wrote: > On Fri, Feb 3, 2012 at 11:46 AM, Karthik Abinav > wrote: >> I was thinking about a feature that could be implemented. For common >> fields like username having only alphanumeric , or phone numbers having only >> numbers, a client side validation need not be written every time.Instead one >> could directly write something like, >> >> forms.CharField(validator = "usernamevalidation") >> >> in the forms definition and the client side validation for that field would >> automatically be taken care of by the validator class. This will save a lot >> of time while making large websites with lot of registration forms and in >> general be helpful to people who dont really know javascript and yet want >> some amount of frontend validation in place. > > I like the idea of having a JavaScript version of form validation. > Basically we could make a view class that takes a Form object in > __init__() and returns JSON of the errors in a consistent way -- this > would be very easy to do. Then we could provide some standard > JavaScript to parse that JSON and add the error messages to the > appropriate fields in the form in a consistent way. I don't get it. That would require sending the data to the server (right?), so it's not really client-side. I think http://www.dajaxproject.com/ does exactly that. What I would like to see instead is providing HTML5 attributes for standard fields and making it easier to add ones to custom ones. Some simple to implement ones are: "required", min/max for number fields, max_length for a textarea. Regular expression can be supported via "pattern" (with some code to translate them to JS regexp syntax). -- Łukasz Rekucki -- 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: Feature request: Unicode collation algorithm in django
2012/2/2 Łukasz Rekucki :
> On 2 February 2012 03:34, Anssi Kääriäinen wrote:
>>
>> Now, my proposed solution would be to have some way of doing:
>> SELECT name, ...
>> FROM authors
>> ORDER BY name collate 'fi';
>>
>> That some way might be something like
>> .order_by('name', collate='fi')
>> or maybe
>> .collate('fi').order_by('name')
>> and now collate would be in effect for filters (that is,
>> name__gte='e'), too.
>>
>
> The user should probably be able to specifiy the collation only for
> the fields he wants, as it most likely uses a different type of index
> and is more expensive then a standard ordering, so I like the
> .collate(name="fi") option (and a shortcut of .collate("fi") to apply
> to all text fields.
Just came to my mind, that we could just mimic the DBs and have a
Collate operator (like Q, F, Count, etc.) + maybe some defaults on the
model:
M.objects.order_by(Collate("name", "uca"))
M.objects.filter(name__gte=Collate('e', "fi"))
--
Łukasz Rekucki
--
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: Feature request: Unicode collation algorithm in django
On 2 February 2012 03:34, Anssi Kääriäinen wrote:
>
> Now, my proposed solution would be to have some way of doing:
> SELECT name, ...
> FROM authors
> ORDER BY name collate 'fi';
>
> That some way might be something like
> .order_by('name', collate='fi')
> or maybe
> .collate('fi').order_by('name')
> and now collate would be in effect for filters (that is,
> name__gte='e'), too.
>
The user should probably be able to specifiy the collation only for
the fields he wants, as it most likely uses a different type of index
and is more expensive then a standard ordering, so I like the
.collate(name="fi") option (and a shortcut of .collate("fi") to apply
to all text fields.
>
> Making Django's ORM do the above isn't the most trivial thing. And not
> all databases support collate clauses.
After a quick research, I think they actually do now (at least in
ORDER BY). MySQL[1] and SQLite[2] both have COLLATE, in Oracle we
could use NLSSORT()[3] which is something like locale.strxfrm.
>
> You can do the above with .extra() even now if your DB happens to
> support collations. Default collation for your database might also be
> an option for your particular problem. At least in PostgreSQL versions
> prior to 9.1 you have one collation for the DB, which you can set only
> at CREATE DB time.
>
[1]: At least since 5.0:
http://dev.mysql.com/doc/refman/5.0/en/charset-collate.html
[2]: SQLite doesn't support UCA by default, but lets you define any
collation:
http://docs.python.org/library/sqlite3.html#sqlite3.Connection.create_collation
[3]: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch9sql.htm#i1006311
--
Łukasz Rekucki
--
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: Feature request: Unicode collation algorithm in django
On 1 February 2012 20:27, Ed Hagen wrote: > Hi, > > Let me preface this request by saying that when it comes to django, > I'm an advanced beginner (so this might be a dumb request). > > The motivation for my request involved users of a django-based > database of international scholars who wanted their names sorted > "correctly." I explained that different languages sorted characters > differently, and therefore there was no single correct sort order, but > I promised to see if I could easily implement language-specific > orderings. What I found was that django seems to rely on the database > for this feature: > > https://docs.djangoproject.com/en/dev/ref/databases/#collation-settings > > which (if I've understood things correctly) makes sense for > performance reasons, but makes it more difficult to change things on > the fly, e.g., to provide language-specific ordering. Performance is the main concern here. Any query with ordering on a text field would have to fetch all results and sort it on the application side. It's just terrible. > > Using suggestions on this page: > > http://stackoverflow.com/questions/1097908/how-do-i-sort-unicode-strings-alphabetically-in-python > Weirdly enough, I was looking at this thread lately, trying to explain to a beginner, why Python doesn't provide an easy way to do this, which actually works :(. Summary of options: 1) Use PyICU - this would solve a lot of problems (some which Django already solves by itself). But it's quite a big dependency on an external package (written in C++, so I guess it won't run on PyPy, Jython nor App Engine). Django currently has no external dependencies and that's good :) 2) Use the "locale" module: it will work... if you have all the possible locales compiled on your OS... and you're not running on Windows... or using threads. AFAIK, switching locale is also quite slow. 3) Use some other listed libraries: none of them looks like maintained by authors. 4) Write UCA ourselves from scratch. This involves including 1.6MB collation table in Django. All those solutions of course, still have the problem of needing all the data on the application side. > I fixed things well-enough for my present purposes, but I thought it > would be useful to abstract this capability away from the database, > with django itself providing some version of the Unicode collation > algorithm: > > http://unicode.org/reports/tr10/ > > This might hook into django's internationalization and localization > features, and/or be accessible at a lower level, e.g., with a keyword > argument to, or variant of, "order_by". Could you describe your current solution in more detail? -- Łukasz Rekucki -- 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: End-user defined fields, how would you approach it?
First of all, this whole topic doesn't belong on django-developers in the first place as it's strictly a user question (I didn't see any proposal to change anything in the core, etc.). In the future, please post to django-users with question about using Django. On 29 January 2012 21:44, Etienne Robillard wrote: > On 01/29/2012 02:46 PM, John Hensley wrote: >> >> On Jan 29, 2012, at 1:52 PM, Etienne Robillard wrote: >> >>> On 01/29/2012 01:40 PM, Aymeric Augustin wrote: >>>> >>>> Hello Etienne, >>>> >>>> The three messages you posted in this thread aren't appropriate on this >>>> mailing list, both in terms of contents and tone. >>>> >>>> Please stay on topic, respect other members of the community, and if you >>>> don't have anything constructive to say, refrain from posting — even with a >>>> smiley. >>>> >>>> Thanks, >>>> >>> >>> They were just fine. Please stop trolling and respect the little freedom >>> of expression we still have. >> >> >> Etienne, >> >> I sympathize with you regarding the ever-decreasing civil liberties, I >> really do, but the django-developers list is not the place for this. If a >> core developer tells you that your messages aren't appropriate, the only >> correct response is, "Sorry, won't happen again." You've been asked >> repeatedly now to take the politics somewhere else. Please have the maturity >> and civility to do so. >> >> John >> > You're missing the point totally. > > The point is that as most as everyone on this list, we have the right to > discuss things which feels on topic with this list without being > discriminated for no reasons. > You're not discriminated - everyone is treated the same way here and judged only by their actions. By disobeying the rules of this list, you're disrespecting it's members. If you disagree with the rules of this community, you don't have to be part of it. Insulting it's core members surely doesn't help you convince us, that it's a good choice to accept your definition of "things which feels on topic with this list". -- Łukasz Rekucki -- 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: DoS using POST via hash algorithm collision
Dear django-developers, It seems that Django has now become the argument for NOT fixing this issue properly. Citing python-dev: > For example, in the Django test > suite, the HTML output is different at each run. Web browsers may > render the web page differently, or crash, or ... I don't think that > Django would like to sort attributes of each HTML tag, just because we > wanted to fix a vulnerability. We all know browsers won't crash and they will render the page exactly the same. I volunteer to fix any issues in the test suite (considering the hash changes also between 32-bit/64-bit Python, i'm not sure there are even any or we would get a report on that, wouldn't we ?). I think it's important for the Django core team to voice their opinion on this matter in python-dev. Thank you!, Łukasz Rekucki -- 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: Read only Test Was: Speeding up tests
On 17 January 2012 12:04, Thomas Guettler wrote: > Hi, > > same subject, but different content: > > we have a lot of tests which are read only. They don't modify the database > or > other files. I assume your code has a way of checking that the tests are really read only ? If yes, I would be interested. If no, then (sorry to say this), but the "read-only" part is only wishful thinking. -- Łukasz Rekucki -- 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: Clearing cache between tests (#11505)
> If I personally were given the choice between cache.clear() and nothing at > all, i'd take cache.clear() and be careful with it. But I'm not sure if the > rest of the community is willing to accept such a solution. Hence the > CLEAR_BETWEEN_TESTS flag as a compromise. But the flag doesn't solve the memcached issue, right? IMHO, it only adds to the false impression that you can have any control on what gets flushed by memcached. I also agree with Aymeric that not clearing cache state is a bug. Having a flag to fix/restore buggy behaviour seems weird. -- Łukasz Rekucki -- 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: deprecation vs removal
2011/10/2 Alexander Schepanovski :> Then when I upgrade django I'll just upgrade it and fix> any wrong calls, imports, monkey patches etc. Proper upgrading docs,> which you write anyway, will make it into a couple of days. The way it> is done now still requires that two days but also make me think about> separate deprecation concept, about what part of django is public and> what is not cause they have separate deprecation policies. It also> encourages me to sl I prefer to just run my test suite with warnings enabled and see where deprecated functions pop-up. The best part is that *I* choose when to spend time on getting rid of them and I don't have to do it all at once. I do this even with my own codebase. On 2 October 2011 07:48, Alexander Schepanovski wrote: > But even a common user, who himself doesn't hack into django may use > third-party libs that do: migration, automatic caching, any orm, form > and template extenders. And for the developers of that libs > deprecation is a waste not help, at least what it feels for me. For > common user this means he cannot upgrade until all hos libs upgraded > or he himself is forced into hacking them. > IMHO, it's exactly the opposite. If you remove the code right away, then I can't upgrade to the new version of Django, 'cause I have to wait for my 30 dependencies to upgrade or hack it my own. --- As for the naming, it's probably because i'm not a native speaker, but I always found the warning names logical. "PendingDeprecationWarning" warns you about something, that will be deprecated in the version. "DeprecationWarning" warns you that something *is* deprecated (as in old and useless), so it *may* be removed in any future version. Whether it is actually removed is another thing - Python itself has a long tradition of leaving some C API functions deprecated for indefinite period of time. So, to me, deprecation is the state right before removal. I would stay with "X will be deprecated in Django Y.Z" wording (which implies it may be removed in any (Y+m).(Z+1+n) n,m>=0 version). -- Łukasz Rekucki -- 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: Django test documentation example not respecting xUnit convention
On 21 September 2011 07:13, schinckel wrote: > It isn't 'enforced' by Python at a language level, but as dmoisset stated, > it makes the failure messages actually make sense: > "Expected 'foo', got 'bar'". > (paraphrasing failure message: don't have any failing tests to look at right > now. YAY! :) > Matt. My Python 2.7 says: self.assertEqual(result['active'], 2) AssertionError: 1 != 2 So, no. The message in Python is order agnostic. -- Łukasz Rekucki -- 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: Django test documentation example not respecting xUnit convention
On 21 September 2011 02:01, Russell Keith-Magee wrote:
>
> For what it's worth, I also think the "convention" is bass ackwards...
> you write "if variable == value", but you write "assertEqual(value,
> variable)"? Where's the consistency in that?
>
My guess is that the choice is somehow connected to Yoda conditions,
where you actually write:
if(5 == x) { ... }
to avoid assigning 5 to x by mistake. If you write all your conditions
like that, then the assert order makes sense.
But Python thankfully doesn't need any of that Jedi stuff.
--
Łukasz Rekucki
--
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: ManyRelatedManager with explicit intermediary model
On 20 September 2011 15:52, Roald de Vries wrote:
> Hi all,
>
> Is there a fundamental reason that I'm missing (other than "nobody's taken
> the trouble of writing it") that I can't do the following? If there isn't
> I'll create a ticket for it.
>
> class R(Model):
> user = ForeignKey(User)
> my_model = ForeignKey('MyModel')
> comment = CharField(max_length=100, blank=True)
>
> class MyModel(Model):
> users = ManyToManyField(User, through=R, null=True)
>
> m = MyModel.objects.create()
> u = User.objects.create_user('roald', 'downa...@gmail.com', 'password')
>
>
> # these things I can't do:
> m.users.add(u)
> m.users.add(u, comment='Blablabla')
>
> Cheers, Roald
>
I'm 100% sure there's *at least one* ticket for this. You just need to
search for it and you'll probably find the discussion of this too.
--
Łukasz Rekucki
--
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: RFC: "universal" view decorators
On 16 September 2011 10:17, Roald de Vries wrote: > On Sep 16, 2011, at 12:11 AM, Łukasz Rekucki wrote: >> >> As the ticket creator I feel obligated to reply :) > > Me (as the poster of the latest patch) too :) Nice to meet you. > >> Thinking about it now, it does look kinda ugly. It's mainly because I >> was focus on how to reuse existing decorators in CBV context. It >> shouldn't be to hard to make the "view_decorator" a meta-decorator >> (or a factory function as you call it) that turns login_required to >> something that is both a class and function decorator. Methods are >> still out-of-bounds for non-runtime introspection, but after almost 1 >> year of using CBV, I never needed to decorate a method. >> >> I would like to also comment on the new approach in that ticket. >> Making a shallow copy of a class is *MAGIC* to me. It breaks the basic >> invariant "issubsclass(decorator(A), A) == True". This is important if >> you're planing to use this as "B = decorator()(A)" (and you are, >> 'cause the whole point of not modifying the original class is to allow >> safely doing this), as you quickly end up with weird alternate >> hierarchies. So, please don't do that :) > > I agree that in an ideal world we'd have a better solution. On the other > hand, the cbv-decorator using inheritance just didn't work, and the one > using shallow copies does (if you don't use B=decorator()(A), indeed). The one that just alters the given class also works, has no magic and has the same limitation - dont' do "B = decorator(A)". Honestly, I never needed that, but I understand some people might. Also note, that the "super() problem" is fixed in Python 3, where super() determines the base class from the call frame instead of referencing a global variable. > > If this doesn't exist, then the view_decorator still has a right to live. > > So what would have to be created is a meta-decorator universal_decorator, > replacing or using view_decorator, such that > universal_decorator(login_required) is the actual universal decorator. This > would be applied to all django-decorators, but I think it would be good to > also allow applying universal_decorator to an already universal decorator, > such that: > > # after this... > login_required = universal_decorator(login_required) > # ... this will hold > assert login_required == universal_decorator(login_required) > > +1 -- Łukasz Rekucki -- 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: RFC: "universal" view decorators
On 16 September 2011 09:17, Jonas H. wrote: > On 09/15/2011 11:27 PM, Donald Stufft wrote: >> >> tl;dr; Using Mixins to add in functionality to a CBV makes way more sense >> then >> using a decorator which is essentially going to be doing the same thing as >> a >> mixing would, it just makes finding what is going on harder, makes >> customizing >> the decorator harder and/or uglier, and goes against the way functionality >> is >> currently added to a CBV. > > That sounds a lot better to me. > Surprisingly, I agree. Using decorators to *add functionality* is a bad idea. But `login_required` or `csrf_exempt` are not strictly functionalities. They're preconditions. They act exactly like any piece of middleware, but instead of applying them globally to all view, you can do it per-view. (My view_decorator intentionally uses as_view() instead of dispatch(), so that the decorators are called *before*, any view login is called). If you think about it this way, applying decorators to CBV makes a lot of sense. -- Łukasz Rekucki -- 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: RFC: "universal" view decorators
> I think the syntax should be something like:
>
> from django.contrib.auth.decorators import login_required,
> permission_required
>
> class ProtectedView(MyView):
> view_decorators = [login_required, permission_required('foo.can_do_bar')]
>
There was a similar proposal on this list before introducing CBV. It
didn't gain much love.
--
Łukasz Rekucki
--
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: RFC: "universal" view decorators
erent to even know to > look for method_decorator. > > #14512 proposes a adding another view-decorator-factory for decorating > class-based views, which would turn the above into:: > > @class_view_decorator(login_required) > class MyView(View): > ... > > This makes me less sad, but still sad. Factory functions. Ugh. > > I want @login_required to work for anything:: > > @login_required > class MyView(View): > ... > > class Something(object): > @login_required > def my_view(self, request): > ... > > @login_required > def my_view(request): > ... > > > Now, back in the day we somewhat had this: decorators tried to work > with both functions and methods. The technique turned out not to work > (see #12804) and was removed in [12399]. See > http://groups.google.com/group/django-developers/browse_thread/thread/3024b14a47f5404d > for the discussion. > > I believe, however, I've figured out a different technique to make > this work: don't try to detect bound versus unbound methods, but > instead look for the HttpRequest object. It'll either be args[0] if > the view's a function, or args[1] if the view's a method. This > technique won't work for any old decorator, but it *will* work (I > think) for any decorator *designed to be applied only to views*. > > I've written a proof-of-concept patch to @login_required (well, > @user_passes_test, actually): > > https://gist.github.com/1220375 > > The test suite passes with this, with one exception: > https://code.djangoproject.com/browser/django/trunk/tests/regressiontests/decorators/tests.py#L87. > I maintain that this test is broken and should be using RequestFactory > instead. > > Can I get some thoughts on this technique and some feedback on whether > it's OK to apply to every decorator built into Django? > > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- > 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. > -- Łukasz Rekucki -- 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: RFC: "universal" view decorators
2011/9/16 Łukasz Rekucki : > Hi, >> I believe, however, I've figured out a different technique to make >> this work: don't try to detect bound versus unbound methods, but >> instead look for the HttpRequest object. It'll either be args[0] if >> the view's a function, or args[1] if the view's a method. This >> technique won't work for any old decorator, but it *will* work (I >> think) for any decorator *designed to be applied only to views*. > > +1 on this. I would be a bit concerned about this vs. future > implementation of generator-based-views that allow some kind of > response streaming (is someone working on that?). Omit this part, It's late and I read HttpResponse by mistake ;), which of course doesn't make any sense. -- Łukasz Rekucki -- 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: RFC: "universal" view decorators
Hi, On 15 September 2011 22:44, Jacob Kaplan-Moss wrote: > > #14512 proposes a adding another view-decorator-factory for decorating > class-based views, which would turn the above into:: > > @class_view_decorator(login_required) > class MyView(View): > ... > > This makes me less sad, but still sad. Factory functions. Ugh. As the ticket creator I feel obligated to reply :) Thinking about it now, it does look kinda ugly. It's mainly because I was focus on how to reuse existing decorators in CBV context. It shouldn't be to hard to make the "view_decorator" a meta-decorator (or a factory function as you call it) that turns login_required to something that is both a class and function decorator. Methods are still out-of-bounds for non-runtime introspection, but after almost 1 year of using CBV, I never needed to decorate a method. I would like to also comment on the new approach in that ticket. Making a shallow copy of a class is *MAGIC* to me. It breaks the basic invariant "issubsclass(decorator(A), A) == True". This is important if you're planing to use this as "B = decorator()(A)" (and you are, 'cause the whole point of not modifying the original class is to allow safely doing this), as you quickly end up with weird alternate hierarchies. So, please don't do that :) > > I believe, however, I've figured out a different technique to make > this work: don't try to detect bound versus unbound methods, but > instead look for the HttpRequest object. It'll either be args[0] if > the view's a function, or args[1] if the view's a method. This > technique won't work for any old decorator, but it *will* work (I > think) for any decorator *designed to be applied only to views*. +1 on this. I would be a bit concerned about this vs. future implementation of generator-based-views that allow some kind of response streaming (is someone working on that?). > > I've written a proof-of-concept patch to @login_required (well, > @user_passes_test, actually): > > https://gist.github.com/1220375 > Did I already mention creating a subclass in the class decorator breaks super ;) [https://gist.github.com/643536] > Can I get some thoughts on this technique and some feedback on whether > it's OK to apply to every decorator built into Django? > It would be great to have that meta-decorator, so everyone else could upgrade their decorators just by decorating them. -- Łukasz Rekucki -- 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: Storing IP address as integer within database to remove need for full text search
On 18 July 2011 16:56, Cal Leeming [Simplicity Media Ltd] wrote: > Hi, > I have created a ModelField called RealIPAddressField. > It stores the IP address in integer form, meaning the lookups on large > tables are much faster: > http://djangosnippets.org/snippets/2493/ > @django-developers - Do you think there is any possibility of this getting > included into the core? >From a quick look, it doesn't seem to support IPv6 (which is a real problem in year 2011 when all IPv4 addresses are allocated). So I would be -1 on it. There is also the problem of signed int. PS. Cross-posting like this to django-users and django-developers is probably not a good idea as people on django-users will send emails here by accident. -- Łukasz Rekucki -- 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: Why does the test handler call sys.exit()?
On 27 April 2011 23:10, Shawn Milochik wrote: > > Core devs, I'm not a core dev, but I hope you'll find my answer useful ;) > > The problem is that the handler function [3] calls sys.exit() if there > are any test failures. Given that the function is already done at this > point, it seems redundant. > > I can just as easily go back to using subprocess, but it seems silly > to shell out of Python to call a Python function. Is there any reason > not to change this sys.exit() to a sys.stderr.write()? Yes, there is. By calling sys.exit(bool(failure_count)) you change the exit status of the process*. This is very useful in shell scripts: $ python manage.py test && echo "Report success by email" But I agree that the command shouldn't call this directly. Instead, it would be better for all commands to return a failure indicator** and the caller should call accordingly sys.exit() based on that. * Another reason is that commands should always use self.stderr, not self.stderr. I'm not sure all of them do, but they should :) ** An obvious thing would be True for success, False for failure, but bool(None) == False, so it wouldn't be backwards compatible. -- Łukasz Rekucki -- 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: Fixing makemessages for Javascript
On 19 April 2011 15:35, Jonathan Slenders wrote: > > Basically, when this works, the i18n catalog for javascript is no > longer required, even for external files. > https://github.com/citylive/django-template-preprocessor > Could you elaborate on that ? How does your application help me handle client-side translations ? -- Łukasz Rekucki -- 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: Fixing makemessages for Javascript
Ok, I created a ticket to track the Babel integration: http://code.djangoproject.com/ticket/15832 On 14 April 2011 21:47, Jannis Leidel wrote: > > I'm not convinced it's much more work, since we really only need to > replace the string extraction code in makemessages and the > compilation code in compilemessages with calls to the equivalent code > in Babel. There is already a simple message extractor in BabelDjango > [1] that is a port of django.utils.translation.templatize which would > only need to be updated to the current version in Django, given the > few differences [2]. I guess we can just do it and see how long it takes :) >> Should Django use Babel's locale interface (which >> would be slower/faster ?) or just the gettext part? > > The code in django.utils.translation.trans_real doesn't need to be > modified since it relies on Python's gettext module to load the > translations. By 'locale interface' I actually meant the CLDR. Django's "localflavor/**/formats.py" mostly duplicates information provided by Babel. -- Łukasz Rekucki -- 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: Fixing makemessages for Javascript
On 14 April 2011 18:30, Jannis Leidel wrote: > On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote: > >> I think I agree with Ned here: I can't see the downside to fixing it >> on the release branch. "It violates our policy" doesn't count IMO: >> it's *our* policy, and we get to break it if there's a good reason. >> Making translation in JavaScript work is a good reason as I see it. > > FTR I agree we have an issue here, I just disagree with the proposed fix. If > you think we can adopt Babel in the release branch, let's do it. Integrating Babel is much more work, then replacing the regexp hack with a lexer. There are also some decisions to make: do we bundle Babel with Django? Should Django use Babel's locale interface (which would be slower/faster ?) or just the gettext part? > >> Jannis: can you speak a bit more to why you're against fixing this for >> the 1.3 series? Is there a technical downside I'm missing? > > Again, I'm not convinced that Ned's patch solves the actual problem: Django > abusing the xgettext CLI tool to parse JavaScript files with its Perl lexer. > He proposes to convert the content of JavaScript files with a custom made > lexer to a format that xgettext can understand as "C" instead. This -- while > being a nifty piece of code -- seems like a hack to me. Which is why I > believe that such a code only adds more maintanance burden on us for the > already fragile i18n system and should be replaced with a proper JavaScript > parser. I agree that using xgettext like that is a hack, but it's a one that *can* work - and it works pretty well for Django's template language. Mostly because the translator uses a lexer. Using regular expression to "parse" JavaScript is a hack that's well... You're Doing It Wrong(tm). > So I've proposed to adopt Babel, which is a proven, widely used system that > implements many of the weird hacks we have in Django i18n cleanly in Python. > As a bonus it would allow us to get rid of a binary dependency that was > difficult to install on all platforms in the past anyway. I think no one denies that. I'll be happy to help with that**. But this probably won't happen today or tomorrow, so getting rid of one broken hack would be great. If the core team decides that integrating Babel in 1.3.1 is fine, then that's great news. If not, lets just make it work. > > In other words, technically we're speaking of a bikeshed that has some holes > in the roof and Ned is trying to fix them with new paint. IMHO, it needs to > be reconstructed instead. Whether we do this in the release branch or in > trunk I don't care. Following this metaphor, it's autumn, it's raining and the materials for a new roof won't be coming until late winter, so covering the bikes with a some tilt, so they don't rust might be a good idea :P **You mentioned talking to Armin Ronacher. Do you have any plan of action or something ? :) -- Łukasz Rekucki -- 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: Fixing makemessages for Javascript
On 14 April 2011 14:41, Ned Batchelder wrote: > Does anyone else have any opinions on a direction forward to fix this > problem? At the very least I'd like to make a doc patch for 1.3.1 that > explains the fragility. I'm +1 on fixing it now, rather then later. The regex approach was a bad idea in the first place and it never really worked - it's just that no one noticed. Babel integration is the ultimate goal, but that can't happen until 1.4, 'cause it's a new feature. I don't think this patch moves us away from that goal. It just fixes a long existing bug and doesn't touch any public APIs. I tested the patch on my code with good results. -- Łukasz Rekucki -- 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: Error importing template source loader when upgrading from r15883 to r16025
On 13 April 2011 18:37, lazyant wrote: > Hello, > > I have a small web site that was running happily with django r15883 > that I updated March 21st. > > Yesterday I upgraded to the latest version (r16025) and then I'm > getting an error that 505s my site: > > Error importing template source loader > django.template.loaders.filesystem.load_template_source: "'module' > object has no attribute 'load_template_source'" Well, function-based template loaders have been deprecated in Django 1.2; With recent release of Django 1.3, trunk is now 1.4 and they have been removed as documented here: http://docs.djangoproject.com/en/dev/releases/1.2/#class-based-template-loaders http://docs.djangoproject.com/en/dev/releases/1.2/#function-based-template-loaders You also should be getting DeprecationWarnings about this. If you're on python >= 2.7, try running "python -W manage.py runserver". -- Łukasz Rekucki -- 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: Fixing makemessages for Javascript
On 4 April 2011 23:15, Ned Batchelder wrote: > > I have a few questions you can help me with: > > 1. Is this the best path forward? Ideally xgettext would support Javascript > directly. There's code out there to add Javascript to xgettext, but I don't > know what shape that code is in, or if it's reasonable to expect Django > installations to use bleeding-edge xgettext. Is there some better solution > that someone is pursuing? It would be best to have xgettext allow pluggable parsers or/and rewritten in Python. Oh wait, it's called Babel ;). I was planning to refactor the `makemessages` command to enable custom parsers (My motivation is having a bunch of client-side templates written in a variant of Mustache or jQuery Templates). As babel already has an interface for that, integrating it into Django would be cool. Sure, it's a dependancy, but so is xgettext. > > 2. Is there some other badness that will bite us if we tell xgettext that > the modified Javascript is C? With a full Javascript lexer, I feel pretty > confident that we could solve issues if they do come up, but I'd like to > know now what they are. IMHO, it would be best to leave only gettext() calls and pad them with comments, so that line numbers match (the template converter does something similar, by replacing all other stuff with string like ). You can then choose C, Python or whatever :) > > 3. I know that lexing Javascript is tricky. I need help finding diabolical > test cases for my lexer (https://bitbucket.org/ned/jslex). Anyone care to > come up with some Javascript source that it can't properly find the regex > literals in? I'll give it a spin on my code :) Thanks for doing this! -- Łukasz Rekucki -- 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: Bug when generating sql for single (AND: (EverythingNode))
Hi Mikołaj, On 4 April 2011 19:46, trybik wrote: > Omg, I've just reviewed this bug, it's still there but this message is > completely confusing. A little correction: It's best to report bugs on the tracker. Otherwise, they'll die in infinite depths of everyone's mailboxes. > > On 25 Lut, 14:14, trybik wrote: >> Hi, >> >> when generating sql forWhereNoderepresented as (AND: >> (EverythingNode)), >> inhttp://code.djangoproject.com/browser/django/trunk/django/db/models/s... >> the empty variable will stay False, > > True of course (L88), not False... the point is that L105 will never > be reached because of treacherous 'continue' in L113. > >> thus throwing the EmptyResultSet >> further on (L120) and in consequence e.g. returning EmptyQuerySet on >> higher level. Imvho, in case of FullResultSet handling you're missing >> setting empty variable to True > > and here False, not True (between L104 and L105); removing L113 would > also do the trick in this case. It's still not very clear to me what problem are you describing. If you could produce a queryset that generates wrong SQL, it would clearify things. >> How one can get (AND: (EverythingNode))WhereNodeto be >> generated?http://code.djangoproject.com/browser/django/trunk/django/db/models/s... Good question. You can see it's generated in combine()[1], but I'm not sure how you can make a Query object with "self.where" attribute that would evaluate to False. [1]: http://code.djangoproject.com/browser/django/trunk/django/db/models/sql/query.py#L478 -- Łukasz Rekucki -- 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: uWSGI documentation
On 2 April 2011 13:23, James Pic wrote: > Hello everybody, > > Do you think uWSGI deserves a place in the official django documentation ? > > I think it should because it's easier, safer, faster and more secure > than flup or mod_wsgi. Also, it made my sysadmin life really easy and > that's something cool to share with the community. > > In this case, please consider the attached draft > (django/docs/howto/deployment/uwsgi.txt): it's not perfect and > probably not commitable as-is, but I am ready to listen to feedback > and improve it. Otherwise it'll just make another blog post. +1. More docs didn't hurt anybody. At least while there is someone to maintain them. > > What do you think ? > My first impression is that you're focusing too much on all those switches. That section got me totally lost. That should be simplified. Also, do I really need to type all that stuff? I probably won't be doing that on production, so showing how to place it in a configuration file would be better. I would also drop the whole "advantages" section. The purpose of the page is to show how to deploy a Django app on uWSGI, not compare it against other solutions. You also mention some features, but never show how to enable/use them which is confusing. PS. Do you think having a `runuwsgi` command similar to `runfcgi` would be useful ? -- Łukasz Rekucki -- 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: Suggestion: a new "nature" field in Trac
On 1 April 2011 12:03, Luke Plant wrote: > On 01/04/11 08:04, Julien Phalip wrote: > >> Updating the 1800 open tickets is a big task, and to avoid duplicating >> work I have set up a spreadsheet to coordinate our efforts: >> https://spreadsheets.google.com/ccc?key=0AoGUYlz9V54IdFQtbEpyZTctQzhhQTlfMWdmWGt2a3c&hl=en >> >> If you'd like to volunteer, please put your name next to the page >> numbers (18 pages x 100 tickets per page in total). Here's the list of >> open tickets ordered by ids: >> http://code.djangoproject.com/query?status=!closed&order=id > > > Great, thanks for organising this. I've done one page > > **Volunteers, use the batch modify plugin at the bottom of the reports > page** > > With this you can avoid sending out e-mails and changing the ticket > modified timestamp, and you can do lots at once from the report page. > > But will need the 'triager' permissions to do this. **Ask one of the > core devs for this.** > > I'm not sure what our exact process for deciding on 'triager' status is, > but I've added Julien and Łukasz already, at least for this work. You > may be removed again, but with all the great triaging work you've been > doing I imagine you ought to stay there. Thanks. I noticed the email after about 20 tickets, so sorry for all that emails. -- Łukasz Rekucki -- 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: Purpose of django.test.simple.reorder_suite
On 1 April 2011 00:58, Karen Tracey wrote: > 2011/3/31 Łukasz Rekucki >> >> I just started updating my custom TestSuiteRunner to Django 1.3 and it >> seems that reorder_suite() is broken. At least I think it is, because >> I wasn't able to deduce what it should do. >> >> In Django 1.2, the main effect that function was flattening the >> TestSuite so it only consists of TestCase instances. It no longer does >> that if the suite contains any unittest1.TestSuite instances (the >> "isinstance(test, unittest.TestSuite)" fails, 'cause unittest is >> unittest2 now). >> >> So my question is, does this function serve any other purpose then >> flattening the TestSuite or can fix it and rename to flatten_suite() ? > > Its purpose is to reorder the test suite so that all tests that use the > transaction rollback mechanism are run first. These tests are guaranteed to > clean up after themselves, and they do not do anything on entry to reset the > database to a known state (as TransactionTestCases do), so running them > after either any TransactionTestCase tests or after any doctests may result > in failures due to previously-run tests that did not clean up after > themselves. (This reordering is documented: > http://docs.djangoproject.com/en/1.3/topics/testing/#testcase). Thanks for explaining, it makes perfect sense. I actually remember reading that docs some time ago, but I guess it didn't stick to my memory. > If the function is no longer properly reordering things then it needs to be > fixed, however its name should not be changed; its reason for being is to > reorder, not flatten. I made a few tests and the ordering works fine, because django.TestCase can only be part of a TestSuite that comes from django.utils.unittest, so it will be flatten properly. Old unittest TestSuite will be treated as a plain TestCase, so it will be added after all django.TestCases, but won't be flatten. I guess it's a change in an undocumented behaviour, so it's not really a bug. I just added a flatten function on my end. Regards, Łukasz Rekucki -- 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.
Purpose of django.test.simple.reorder_suite
Hi, I just started updating my custom TestSuiteRunner to Django 1.3 and it seems that reorder_suite() is broken. At least I think it is, because I wasn't able to deduce what it should do. In Django 1.2, the main effect that function was flattening the TestSuite so it only consists of TestCase instances. It no longer does that if the suite contains any unittest1.TestSuite instances (the "isinstance(test, unittest.TestSuite)" fails, 'cause unittest is unittest2 now). So my question is, does this function serve any other purpose then flattening the TestSuite or can fix it and rename to flatten_suite() ? -- Łukasz Rekucki -- 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: switch to HTML5 for bundled templates
On 30 March 2011 06:55, Matt Harasymczuk wrote: > > Most of users has JS enabled browsers, if so, modernizr works. > Otherwise jQuery will not work either. Most is not all. Even now the admin will work without jQuery, but it won't work without modernizr if you put HTML5 tags in it. > > I can't remember when someone who has IE6 hit one of my django based > sites. > A) That doesn't mean no one needs to support it. B) As it was presented by now, there is nothing IE6 specific here. Newer versions of IE don't support HTML5 section either. I'm -1 on introducing a solution that "runs through a little loop in JavaScript to enable the various elements from HTML5". If someone wants to use it, they will. Adding it by default just to use a few `section` elements and maybe a `header` is a bad idea. Otherwise, +1 on changing the doctype and input elements' types. -- Łukasz Rekucki -- 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: State of X-Sendfile support?
On 25 March 2011 12:34, Thomas Guettler wrote: > Hi, > > I look at your example code. You need to name the webserver in the > code. That's not very nice. I guess it should be possible to > guess the webserver (apache vs nginx) by looking at request.META. > -1 on guessing anything, especially something that doesn't change. Also, a fairly common configuration is Apache behind an nginx proxy. In this setup, I want nginx will be the one serving static files, not Apache. -- Łukasz Rekucki -- 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: secret key from file...
On 21 March 2011 18:07, Matt Harasymczuk wrote: > Thats right, > there should be a secret_settings.py file with db credentials and > secret_key > also a warning that it should not be added to version control settings.py already has a warning: # Make this unique, and don't share it with anybody. I usually keep the generated default in VCS, so that anyone other team members don't have to put it in their localsettings.py. Staging and production servers have their own settings anyway, so it's not really a problem. I'm not sure what exactly are you proposing. Do you want to change the default project template or the docs ? -- Łukasz Rekucki -- 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.
