Re: Python 3 port - now available on GitHub
On May 25, 12:51 pm, Vinay Sajip wrote:
> The single codebase port of Django to Python 3 is now available on
> GitHub [1]. Recent core changes have been merged, and the test results
> are available at [2].
>
> Summary:
>
> 2.7.2: Ran 4734 tests in 540.793s - OK (skipped=112, expected
> failures=3)
> 3.2.2: Ran 4688 tests in 524.807s - OK (skipped=120, expected
> failures=2, unexpected successes=1)
>
> Recent tests only cover the SQLite backend and were run on Linux. Help
> with testing other DB backends (and the GIS functionality) would be
> much appreciated!
>
> Regards,
>
> Vinay Sajip
>
> [1]https://github.com/vsajip/django/tree/django3
> [2]https://gist.github.com/1373553
Both Oracle and MySQL fail to run because of this error (on both 2.7
and 3.2):
File "/home/akaariai/Programming/django/tests/django/db/backends/
mysql/compiler.py", line 2, in
from django.utils.itercompat import izip_longest
ImportError: cannot import name izip_longest
I get the following error when running the tests on any database on my
setup (Ubuntu 12.04, Python 3.2):
Traceback (most recent call last):
File "/home/akaariai/Programming/django/tests/regressiontests/
test_runner/tests.py", line 197, in
test_option_name_and_value_separated
self.assertNoOutput(err)
File "/home/akaariai/Programming/django/tests/regressiontests/
admin_scripts/tests.py", line 164, in assertNoOutput
self.assertEqual(len(stream), 0, "Stream should be empty: actually
contains '%s'" % stream)
AssertionError: 335 != 0 : Stream should be empty: actually contains
'b'\'import warnings\' failed; traceback:\nTraceback (most recent call
last):\n File "/home/akaariai/Programming/python3/lib/python3.2/
warnings.py", line 6, in \nimport linecache\n File "/home/
akaariai/Programming/python3/lib/python3.2/linecache.py", line 10, in
\nimport tokenize\nImportError: No module named tokenize
\n''
I used this to install my setup:
# sudo apt-get install python3 python3-dev virtualenv
# virtualenv -p python3 --distribute python3
# source python3/bin/activate
# pip install psycopg2
# run tests...
Am I missing some dependency?
PostgreSQL seems fine on 2.7 for the reduced test set ran
(introspection transactions inspectdb fixtures queries extra_regress
prefetch_related test_runner aggregation_regress). On 3.2 I get this
additional error:
Traceback (most recent call last):
File "/home/akaariai/Programming/django/tests/django/test/utils.py",
line 203, in inner
return test_func(*args, **kwargs)
File "/home/akaariai/Programming/django/tests/modeltests/
prefetch_related/tests.py", line 378, in test_child_link_prefetch
self.assertIn('authorwithage', connection.queries[-1]
['sql'].lower())
File "/usr/lib/python3.2/unittest/case.py", line 889, in assertIn
if member not in container:
TypeError: Type str doesn't support the buffer API
I do not have any GIS installations available on this machine.
- Anssi
--
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 Thursday, May 24, 2012 3:57:26 PM UTC+2, Andre Terra wrote: > > Hi Ashraful, > > First of all, thank you for contributing with your ideas for this project. > Your mockup is one of the most aesthetically pleasing so far IMHO but there > are some issues that need addressing before it could be replace the current > design. > > Since the mockup to feedback ratio in this thread seems distant from 1 at > the moment, I wanted to contribute to the discussion, so please bear with > me. > > I really like your overall use of whitespace, especially right at the top. > My first thought after seeing the design is that it doesn't feel cluttered, > and this is my biggest issue with the current layout. But the more I looked > into it, the more I noticed key areas are missing. > > Russel has mentioned several times that djangoproject.com is not only for > developers. We need to "sell" the project to sponsors who provide publicity > and financial support, and managers who can foment adoption of our most > loved framework in design shops around the globe and corporate environments > seeking modern solutions to everyday challenges. > > It could be argued that developers themselves don't need a "download" > button. Django is hosted on at least half a dozen platforms and the ways to > access these are also greatly diverse. I'm one of those who believe that > familiarity with python packages and VCS tools are paramount to the success > of Django developers, so pip and git are probably more relevant in today's > world than tarballs. > > We also need to do address how Django relies on the community to prosper, > and anyone can contribute. Users can submit tickets, developers can patch > code, newbies can write docs and many more. This also needs to stand out in > the layout. > > I like your use of silver and to be honest, it goes with green much better > than our current beige, whilst looking more professional, clean and modern. > I see no reason for keeping *everything* silver, however. Surely we could > include a dash of green in the middle and bottom section, don't you agree? > > I also don't think the blog posts are layed out in a particularly elegant > way. There's no telling what the most recent post is, and laying them out > on a grid seems like a waste of valuable space. Perhaps you could split > that into a main area on the left and additional, less prominent info on > the right? > > A lot of the previous mockups made great suggestions on addition content > that you could incorporate, like videocasts for example. > > Last but not least, I don't get the logo. It's not that it doesn't look > good, but it simply doesn't fit Django. The framework is not in any way > related to chatting, so the speech bubble feels out of place. As for the > icons, they're somewhat random and fail to illustrate what the project is > about. > > "The web framework for perfeccionists with deadlines" is a very abstract > concept. If we can't come up with a concrete drawing of that vision, we > should at least be inspired to design a conceptual and abstract piece that > resonates with the notions of "framework", "perfeccionism", and > "deadlines". Django's most admired strength is how it manages to solve the > trade off between robustness and complexity in a seemingly natural way, and > we should convey that. > There is a clear consensus about the Pony not fitting here. Almost every project use something from the nature as a logo (a whale, an apple, a leaf, an elephant etc). This is way too boring ! I suggest a good and rock-solid anvil. > Before getting back to work, take a look at the previous mockups and the > criticism that followed. There's a lot to be learned from what others did > well, and it might also help you avoid the same pitfalls. > > > Cheers, > André Terra > > -- Sent from my phone, please excuse any typos. -- > > > On May 23, 2012 9:38 PM, "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. >> >> Thanks. >> >> On Saturday, April 28, 2012 2:05:27 PM UTC+6, Russell Keith-Magee wrote: >>> >>> Hi Dana, >>> >>> I completely agr
Python 3 port - now available on GitHub
The single codebase port of Django to Python 3 is now available on GitHub [1]. Recent core changes have been merged, and the test results are available at [2]. Summary: 2.7.2: Ran 4734 tests in 540.793s - OK (skipped=112, expected failures=3) 3.2.2: Ran 4688 tests in 524.807s - OK (skipped=120, expected failures=2, unexpected successes=1) Recent tests only cover the SQLite backend and were run on Linux. Help with testing other DB backends (and the GIS functionality) would be much appreciated! Regards, Vinay Sajip [1] https://github.com/vsajip/django/tree/django3 [2] https://gist.github.com/1373553 -- 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: ModelForm enforces its version of save_m2m
It's definitely possible for users to support commit=False. If you call form.save(commit=False), you can then store form.save_m2m in a temporary variable, define a new save_m2m function, and then call the old function from the new. Here's sort of an example: https://github.com/pculture/mirocommunity/blob/31688f2/localtv/user_profile/forms.py#L76. Does it a little differently, but the same result. --Stephen On Tuesday, May 22, 2012 2:53:00 AM UTC-7, is_null wrote: > > Hello everybody, > > Currently, Django ModelForm enforces it's local version of save_m2m: > > https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76 > > > As a result, users who want to overload save_m2m can not support > commit=False: > https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/contrib/generic_m2m.py#L50 > > > Wouldn't it be great if users could overload save_m2m ? > > If you agree, I volunteer to do the ticket and pull request. Else I'll > leave my hack in my app :( > > Regards > On Tuesday, May 22, 2012 2:53:00 AM UTC-7, is_null wrote: > > Hello everybody, > > Currently, Django ModelForm enforces it's local version of save_m2m: > > https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76 > > > As a result, users who want to overload save_m2m can not support > commit=False: > https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/contrib/generic_m2m.py#L50 > > > Wouldn't it be great if users could overload save_m2m ? > > If you agree, I volunteer to do the ticket and pull request. Else I'll > leave my hack in my app :( > > Regards > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/V9VRuLelOfEJ. 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: make auth login view more dynamic
I already said cbvs are the better option however as you said some solutions require custom views, it seems to me persistent login and registration widgets while an anonymous user instance is present are common practice (ie coming from à context processor) it felt repetitive to keep bending views for such à common thing :-) Thanks for raising the bigger picture tho :-) Op 25 mei 2012 om 08:36 heeft Florian Apolloner het volgende geschreven: > Hi Hedde, > > On Thursday, May 24, 2012 3:08:22 PM UTC+2, Hedde van der Heide wrote: > @Florian, The other context variables should be dynamic aswell. > > No they shouldn't be made dynamic at all (none of them!) -- As Andy suggested > CBV are a way better option. > > I don't agree with your template logic. Django always seems to pass this > 'form' name in, which is a problem when you have a page with multiple forms > coming form django itself (for example: registration and auth). > > But those two forms never end up in the same template, so there is no > possibility of a clash etc, login goes to /registration/login.html, > registration iteself to /registration/somethingelse.html. And if you really > send them to the same template you can't use the builtin views and have to > write a new view yourself either way... > > Cheers, > Florian > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/pcVmO4x9Sv0J. > 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.
