Re: Improving ForeignKeyRawIdWidget (raw_id_fields in admin)

[Stan]

On Wednesday, August 7, 2013 11:51:58 PM UTC+2, DrMeers wrote:
>
> On 13 June 2013 07:41, Simon Meers > wrote:
>
>> On 13 June 2013 03:33, > wrote:
>>
>>> I think that the usability of ForeignKeyRawIdWidget could be vastly 
>>> improved if the representation part of the widget (the object name, in 
>>> bold) were to be updated when a new object gets chosen. I think this could 
>>> be done relatively easily with a small change introducing little extra 
>>> complexity.
>>>
>> The handling of raw IDs, particularly in a comma-separated list for 
>> many-to-many relationships, is arguably the biggest user-facing "wart" in 
>> the current admin implementation. The sheer number of available related 
>> objects often makes listing the full set in a dropdown or other widget 
>> unfeasible, forcing developers to resort to the raw ID mechanism to a) 
>> improve efficiency in terms of database-querying and response/DOM-size, and 
>> b) make the selection interface manageable and allow 
>> searching/filtering/pagination/etc. Providing a textual representation of 
>> the object as per the standard widgets makes sense here.
>>  
>
> Julien Phalip has recently put a new patch together for this -- see 
> https://code.djangoproject.com/ticket/7028#comment:74 -- reviews would be 
> greatly appreciated.
>

Hi DrMeers,

As I commented  in 
the ticket #7028, this new patch needs some work. I tried to figure out a 
solution for inlines but there are too much ramifications for me.
Anyway, I think a better approach to the problem is a reusable app (usable 
inside and outside the admin). Into contrib or not.

There are some apps around : 
https://www.djangopackages.com/grids/g/auto-complete/
I have tested django-autocomplete-light because it got a lot of 
contributions and claimed to be production ready. Unfortunately it was 
broken when I tested it against one of my project (infamous 
UnicodeEncodeDecodeError exception). I should have tried to contribute to 
that very project but I choose to not. The main reasons being:

1. I am in a hurry for a #7028 remplacement. 
2. I need something reliable. 
3. I want to *pip install* in production, not to clone a fork of a git repo 
and *python setup.py install etc*.

So I started a *really* light app - django-yaaac - you can find on 
Githuband 
Pypi .
I can't say it is production-ready / stable, but it is ready for my 
productions !

Ticket #7028 should be closed in my opinion.

Cheers,

Stanislas.

 

-- 
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/10ee55c0-a0a8-4c6f-8303-a76f84b73afd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Model field metaclass magic (or lack thereof)

[Anssi Kääriäinen]

On Thursday, October 24, 2013 7:42:50 AM UTC+3, Russell Keith-Magee wrote:
>
>
> On Thu, Oct 24, 2013 at 12:08 PM, schinckel 
> > wrote:
>
>> Hi,
>>
>> I was wondering if there was any reason why fields such as
>> models.DateField() do not use the SubFieldBase metaclass
>> trick to ensure they always contain instances of the correct
>> class?
>>
>> I'm referring to the description from 
>> https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#modelforms-and-custom-fields
>>
>> I had a look though the tickets, but was unable to find any discussion on 
>> this.
>>
>> Is there a rationalé for not using this?
>>
>> Nothing specific that I'm aware of -- at a guess, I'd say it's an 
> accident of history. 
>
> DateField would have been one of the first fields written; generic tools 
> for end-users to define their own field types would have come later. At 
> that point, DateFields were a known entity with known behavior, so there 
> wasn't any need to factor in the SubfieldBase functionality.
>


There are also performance reasons. SubfieldBase's value conversion 
functionality is implemented as descriptor that calls the field's 
to_python(). As Model.__init__ uses setattr, this leads to at least two 
extra method calls for each field value assignment. Method calls are 
expensive in Python, so the end result is 2x slower Model.__init__. So, not 
worth it.

If you want, it is easy to write a custom field subclass that just sets 
metaclass to SubfieldBase. I believe this approach will work for most 
fields.

 - Anssi

-- 
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/81c13a94-0d2c-4bc3-bfc1-827541d21223%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Unit tests error out with WinError 10013 in my Windows 7 machine with Python 3.3.2

[Antony J]

Hi,

Good morning.

Your help is needed:

I am relatively new to Django. After developing a Django app, I am trying 
to write my first patch for Django.

I checked out Django from github: VERSION = (1, 7, 0, 'alpha', 0).

When I run the unit tests with the command "python runtests.py", I get 6 
errors and 2 failures.
But in the Django Jenkins server, the builds are successful.

The error is: OSError: [WinError 10013] An attempt was made to access a 
socket in a way forbidden by its access permissions

I tried the following:

1) Ran a command prompt as administrator.
2) Added python.exe to firewall inbound rules.
3) There are some suggestions for this error in stack overflow:
http://stackoverflow.com/questions/2778840/socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in-a-way-forb
http://stackoverflow.com/questions/16908529/python-3-x-socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in

The first suggestion seem require code changes in Django, and the second 
suggestion seem require code changes in Python http/server.py.

But these suggestions do not seem right to me.

I am running a Windows 7 Enterprise OS (version 6.1) with Python 3.3.2 
32-bit version.

Is this a supported config to build Django?
Have any of you faced this error?

I appreciate any help that you can provide to solve the errors and failures.
Please find the error and failure tracebacks in the text file attached 
herewith.

Thanks,
Antony

-- 
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/8f23755c-be2b-4a24-a00e-aaaead7f78ab%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
==
ERROR: setUpClass (staticfiles_tests.test_liveserver.StaticLiveServerView)
--
Traceback (most recent call last):
  File "c:\Code\DjangoDev\django\tests\staticfiles_tests\test_liveserver.py", li
ne 35, in setUpClass
super(LiveServerBase, cls).setUpClass()
  File "c:\Code\DjangoDev\django\django\test\testcases.py", line 1138, in setUpC
lass
raise cls.server_thread.error
  File "c:\Code\DjangoDev\django\django\test\testcases.py", line 1039, in run
(self.host, port), QuietWSGIRequestHandler)
  File "c:\Code\DjangoDev\django\django\core\servers\basehttp.py", line 109, in
__init__
super(WSGIServer, self).__init__(*args, **kwargs)
  File "C:\Python33\lib\socketserver.py", line 430, in __init__
self.server_bind()
  File "c:\Code\DjangoDev\django\django\core\servers\basehttp.py", line 113, in
server_bind
super(WSGIServer, self).server_bind()
  File "C:\Python33\lib\wsgiref\simple_server.py", line 50, in server_bind
HTTPServer.server_bind(self)
  File "C:\Python33\lib\http\server.py", line 135, in server_bind
socketserver.TCPServer.server_bind(self)
  File "C:\Python33\lib\socketserver.py", line 441, in server_bind
self.socket.bind(self.server_address)
OSError: [WinError 10013] An attempt was made to access a socket in a way forbid
den by its access permissions

==
ERROR: setUpClass (admin_scripts.tests.StartProject)
--
Traceback (most recent call last):
  File "c:\Code\DjangoDev\django\django\test\testcases.py", line 1138, in setUpC
lass
raise cls.server_thread.error
  File "c:\Code\DjangoDev\django\django\test\testcases.py", line 1039, in run
(self.host, port), QuietWSGIRequestHandler)
  File "c:\Code\DjangoDev\django\django\core\servers\basehttp.py", line 109, in
__init__
super(WSGIServer, self).__init__(*args, **kwargs)
  File "C:\Python33\lib\socketserver.py", line 430, in __init__
self.server_bind()
  File "c:\Code\DjangoDev\django\django\core\servers\basehttp.py", line 113, in
server_bind
super(WSGIServer, self).server_bind()
  File "C:\Python33\lib\wsgiref\simple_server.py", line 50, in server_bind
HTTPServer.server_bind(self)
  File "C:\Python33\lib\http\server.py", line 135, in server_bind
socketserver.TCPServer.server_bind(self)
  File "C:\Python33\lib\socketserver.py", line 441, in server_bind
self.socket.bind(self.server_address)
OSError: [WinError 10013] An attempt was made to access a socket in a way forbid
den by its access permissions

==
ERROR: setUpClass (file_storage.tests.FileLikeObjectTestCase)
--
Traceback (

Re: How do features get decided for a release?

[Cody Scott]

How do you decide which version to put a feature in?

Why wasn't migrations in 1.6?


On Thu, Oct 24, 2013 at 12:01 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Thu, Oct 24, 2013 at 10:45 AM, Cody Scott wrote:
>
>> I know that I can look at the 1.7 release notes to see what is to come in
>> the next release.
>>
>> How do django developers decide what features to work on?
>>
>> Is there a minimum time between releases?
>>
>> Is there a minimum quota for fixed bugs for a release?
>>
>> Is there ever a poll to see which features the community wants?
>>
>> Is there another way that developers get what the community wants?
>>
>
> Hi Cody,
>
> Django development -- like most open source development -- doesn't happen
> in the same way as commercial development. We don't sit down, decide
> features that we want, develop a plan, track progress against that plan,
> and deliver those features.
>
> We're an entirely volunteer driven organisation, and the thing about
> volunteers is that you don't have any carrots or sticks to drive the
> development process. I can't compel anyone to work on anything -- and if I
> punish people for not meeting my expectations, I'll probably find that my
> volunteers go away pretty quickly.
>
> Open source development means you have to recalibrate your thinking around
> how software gets developed.
>
> There isn't a minimum time between releases. We put out releases when we
> need to. We've historically put out point releases on a roughly annual
> timeframe, because that's matched our rate of development (and takes into
> account how much ; however, the 1.6 release is on track to be a 7 month
> development process.
>
> There isn't a minimum quota of bugs. The bugs that get fixed are the bugs
> that people provide patches for, and the core team can find sufficient time
> to review and commit.
>
> There isn't any sort of formal process for deciding what will be added.
> The features that are added are the features that volunteers feel
> sufficiently motivated to drive through the development process. Sometimes
> this means that features stay on the todo list for a long time, and
> sometimes it means that a feature goes from concept to completion in a
> matter of weeks.
>
> In essence, the community is getting *exactly* what it wants… in the sense
> that anyone who wants something bad enough is able to put in the time to
> develop a feature, and will drive it to completion.
>
> So - to answer the specific question -- Django 1.6 is about to be released
> (we just pushed our release candidate, which means the final is a matter of
> a week or so away). Django 1.7 is currently in feature development. The
> only features we can guarantee will be in Django 1.7 are those that we've
> already committed (most notably, migrations, and a couple of others that
> are listed in the release notes). I can take a guess at a couple of others
> that are *likely*, based purely upon the work that I myself am doing, and
> what I've heard other core team members talking about. However, until any
> of that code is committed, it's all speculative.
>
> Yours,
> Russ Magee %-)
>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/M6ny4k476dk/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAJxq84-agEjQE35sUUyj%3D4WKAnBbovaJKG8Ag6V35%2B%3DAdMBQBQ%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFUqbeCtP643hqk5TpP341xBdqiMxnpeAKhNSR%3DeoLXaF5mYJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: New middleware method for "universal" decoration

[Gavin Wahl]

I really like the idea of implementing this as a url pattern decorator.
This seems similar to Alex Gaynor's talk about everything being a view.
It's more flexible than a middleware because you can decorate any part of
the urls tree, such as the patterns for a single reusable app.

urls = decorate_recursively(login_required, patterns(...))

This is actually possible to implement today, see snippets like
https://djangosnippets.org/snippets/2532/. The code required is kind of
ugly, so I think it would benefit from an implementation in core.


On Thu, Oct 17, 2013 at 12:19 AM, Anssi Kääriäinen
wrote:

> On Wednesday, October 16, 2013 8:36:05 PM UTC+3, Shai Berger wrote:
>
>> I think the middlewares have grown a little complicated, and I'd try to
>> avoid
>> adding functionality there. That said, the feature of universal
>> decoration
>> seems like it is worthwhile. I'd try to see if it can be added through
>> the
>> urls mechanism instead -- you'd get behavior that is more like a
>> decorator, in
>> the sense that decoration would happen only once.
>>
>
> I hacked together a branch where middlewares could define wrap_request and
> wrap_view methods in addition to all existing process_* methods. The
> wrap_request and wrap_view methods are call-through. It turns out that it
> will be impossible to both bubble up exceptions through wrap_* methods
> while also supporting current middleware semantics. Currently exceptions
> get converted immediately to 500 responses. Doing that and also raising the
> exception through the stack is obviously impossible.
>
> Allowing view wrapping in urls.py seems like a good solution. It would
> allow for what ATOMIC_REQUESTS does currently. And more - it would allow
> wrapping just part of your views, not all of them. Having the ability to
> apply permission_required to a collection of views from urls.py seems like
> a nice feature.
>
> That still leaves whole request wrapping into impossible to achieve state.
> Maybe guarantee that all process_response methods are ran even if some of
> the raise exceptions is enough?
>
> Currently there is no guarantee that all process_response methods get
> called. It seems that support for that would be fairly small backwards
> incompatible change. See:
> https://github.com/akaariai/django/commit/cc459994bb7899e744471dcb7ec034e6e1c310af.
> This would add a guarantee that if process_request is called, then matching
> process_response gets called, too. Notable there is still no guarantee that
> if process_response is called, then process_request was also called. But
> changing that isn't easy to do.
>
>  - Anssi
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/4TnXsONNEso/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/98bd7629-38f1-409e-b2c1-1a058ed3559e%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh1xghzzyOHKcgz8fawFzWEJunLu6AAbJfBYgCdH1tBkHg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How do features get decided for a release?

[Marc Tamlyn]

That's to do with the date a feature lands. Migrations isn't completely
feature complete or totally stable yet - squashing migrations actually
landed in the master branch this week.

When we release the beta, the version goes into feature freeze so only
minor bug fixes and any critical issues get merged into that branch - no
new features (like migrations).

With migrations being such a large project, Andrew deliberately waited
until the feature freeze to merge it so as to give people as long as
possible to find issues.

So short answer - there's normally no decision it's just a case of 'is it
before the date of the beta'.

Marc
On 24 Oct 2013 16:57, "Cody Scott"  wrote:

> How do you decide which version to put a feature in?
>
> Why wasn't migrations in 1.6?
>
>
> On Thu, Oct 24, 2013 at 12:01 AM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>>
>> On Thu, Oct 24, 2013 at 10:45 AM, Cody Scott wrote:
>>
>>> I know that I can look at the 1.7 release notes to see what is to come
>>> in the next release.
>>>
>>> How do django developers decide what features to work on?
>>>
>>> Is there a minimum time between releases?
>>>
>>> Is there a minimum quota for fixed bugs for a release?
>>>
>>> Is there ever a poll to see which features the community wants?
>>>
>>> Is there another way that developers get what the community wants?
>>>
>>
>> Hi Cody,
>>
>> Django development -- like most open source development -- doesn't happen
>> in the same way as commercial development. We don't sit down, decide
>> features that we want, develop a plan, track progress against that plan,
>> and deliver those features.
>>
>> We're an entirely volunteer driven organisation, and the thing about
>> volunteers is that you don't have any carrots or sticks to drive the
>> development process. I can't compel anyone to work on anything -- and if I
>> punish people for not meeting my expectations, I'll probably find that my
>> volunteers go away pretty quickly.
>>
>> Open source development means you have to recalibrate your thinking
>> around how software gets developed.
>>
>> There isn't a minimum time between releases. We put out releases when we
>> need to. We've historically put out point releases on a roughly annual
>> timeframe, because that's matched our rate of development (and takes into
>> account how much ; however, the 1.6 release is on track to be a 7 month
>> development process.
>>
>> There isn't a minimum quota of bugs. The bugs that get fixed are the bugs
>> that people provide patches for, and the core team can find sufficient time
>> to review and commit.
>>
>> There isn't any sort of formal process for deciding what will be added.
>> The features that are added are the features that volunteers feel
>> sufficiently motivated to drive through the development process. Sometimes
>> this means that features stay on the todo list for a long time, and
>> sometimes it means that a feature goes from concept to completion in a
>> matter of weeks.
>>
>> In essence, the community is getting *exactly* what it wants… in the
>> sense that anyone who wants something bad enough is able to put in the time
>> to develop a feature, and will drive it to completion.
>>
>> So - to answer the specific question -- Django 1.6 is about to be
>> released (we just pushed our release candidate, which means the final is a
>> matter of a week or so away). Django 1.7 is currently in feature
>> development. The only features we can guarantee will be in Django 1.7 are
>> those that we've already committed (most notably, migrations, and a couple
>> of others that are listed in the release notes). I can take a guess at a
>> couple of others that are *likely*, based purely upon the work that I
>> myself am doing, and what I've heard other core team members talking about.
>> However, until any of that code is committed, it's all speculative.
>>
>> Yours,
>> Russ Magee %-)
>>
>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/M6ny4k476dk/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAJxq84-agEjQE35sUUyj%3D4WKAnBbovaJKG8Ag6V35%2B%3DAdMBQBQ%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegrou

Related manager remove() and clear() methods - backwards incompatible changes

[Anssi Kääriäinen]

Somewhat long post ahead - jump to the list in the end of post to see the 
backwards incompatible changes.

Ticket #21169 deals with a bunch of different related manager improvements. 
Some are bug fixes, some are there to make related manager methods work 
consistently and finally the ticket's original issue is solved. That is 
custom related manager's possible filters are taken in account when 
removing or clearing the relation. These changes affect .clear() and 
.remove() of ManyToManyField, GenericForeignKey and reverse ForeignKey 
fields. The .add() methods aren't dealt with in the ticket.

A proposed patch is available from 
https://github.com/django/django/pull/1685

I'll start with the ticket's actual issue. Currently, if you have a custom 
related manager which has default filtering (say, .filter(deleted=False) in 
get_queryset()), that limitation isn't taken in account when clearing the 
relation or when removing items from the relation. In short, you can remove 
items from the relation even if they aren't visible in obj.relation.all(). 
There is one exception to this, that is reverse foreign key's.clear() did 
take the filtering in account.

There are two bug fixes in the proposed patch. First, some of the related 
manager methods used multiple data modifying queries without using 
transactions. Second, symmetric m2m.clear() has a concurrency issue - it 
was possible that just other side of a symmetric relation got cleared, but 
the other half was left in place.

Consistency issues are:
  1) Some of the methods used consecutive save or delete calls, some used 
bulk deletion or direct update() calls.
  2) As mentioned earlier, most of the manager methods didn't respect 
related manager's default filtering. Now they all do that.
  3) Due to usage of different style of operations in the methods, 
sometimes signals were sent, sometimes not.

The actual changes fall mainly in two categories. First, use bulk 
operations always, and just one bulk operation per remove() and clear() 
call. This takes care of transaction and concurrency issues, as well as 
making the API consistent. The other category of changes is applying 
default filtering to those bulk operations. Notably in some cases 
(especially symmetric m2m with custom filtering) this means using complex 
subqueries. I wonder if some databases will choke on those subqueries.

Usage of bulk operations will result in changing how signals work. For 
example reverse foreign key .remove() used multiple save() calls, and thus 
signals were sent for each .save(). .clear() used an update() operation, 
and so no signals were sent. The .remove() is changed to use .update(), 
too, so no signals any more in that case. The .add() method was left alone 
- it is possible to still add items that are out of the related manager's 
domain. This is consistent with QuerySet .create() and .delete() - you can 
create items outside the current query's domain, but delete naturally 
applies the query's filters to the operation.

Loic Bistuer has written a patch that addresses all of these issues. The 
list of issues and changes he has written is worth reading. See comment: 
https://code.djangoproject.com/ticket/21169#comment:9

The problem here is that the above changes *will* result in backwards 
compatibility problems for some users. The problems have a possibility to 
be data-corruption issues. The exact working of these methods isn't 
documented so I am proposing to use this as a loophole to avoid backwards 
compatibility rules.

This is a nasty problem to solve. If we leave things as they are, the API 
will remain inconsistent. If we fix these issues, it is impossible to have 
a deprecation period for these changes. Even a check command seems hard to 
write.

The actual bug fixes will need to be done. It is possible to fix the bugs 
without doing backwards incompatible changes. But having a consistent 
related manager experience would of course be nice...

I am slightly in favour of doing these changes. If somebody has good ideas 
how to add deprecation periods to these changes I am all ears.

Here is the full list of changes that potential for breaking user code:
  - If related object's default manager has default filtering, then 
.remove() and .clear() will not clear those items that are filtered out.
  - Reverse ForeignKey .remove() will not use .save() - it will use 
.update() - so no model save signals, and overridden model.save() is 
missed, too.
  - GFK.remove() and GFK.clear() will use queryset.delete()  - so 
model.delete() is not called anymore (signals are sent in this case as 
QuerySet.delete() does that).

Loic's list of fixes & changes is also a good summary of this ticket: 
https://code.djangoproject.com/ticket/21169#comment:9

 - Anssi

-- 
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..

Re: Unit tests error out with WinError 10013 in my Windows 7 machine with Python 3.3.2

[Sam Lai]

Do you have anything running on port 8081 (running netstat will tell you)?

I just ran Django's test suite on my machine (Windows 7, Python
3.3.2), from the trunk cloned an hour ago, and it completed mostly
without an issue (there's a UnicodeDecodeError but that's likely
because it's printing a character to stdout that isn't supported by
the Windows console codepage).

Can you move this discussion over to django-users (just post your
reply with the rest of the email chain over there)? I don't think it's
an issue with Django itself.

On 25 October 2013 02:46, Antony J  wrote:
> Hi,
>
> Good morning.
>
> Your help is needed:
>
> I am relatively new to Django. After developing a Django app, I am trying to
> write my first patch for Django.
>
> I checked out Django from github: VERSION = (1, 7, 0, 'alpha', 0).
>
> When I run the unit tests with the command "python runtests.py", I get 6
> errors and 2 failures.
> But in the Django Jenkins server, the builds are successful.
>
> The error is: OSError: [WinError 10013] An attempt was made to access a
> socket in a way forbidden by its access permissions
>
> I tried the following:
>
> 1) Ran a command prompt as administrator.
> 2) Added python.exe to firewall inbound rules.
> 3) There are some suggestions for this error in stack overflow:
> http://stackoverflow.com/questions/2778840/socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in-a-way-forb
> http://stackoverflow.com/questions/16908529/python-3-x-socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in
>
> The first suggestion seem require code changes in Django, and the second
> suggestion seem require code changes in Python http/server.py.
>
> But these suggestions do not seem right to me.
>
> I am running a Windows 7 Enterprise OS (version 6.1) with Python 3.3.2
> 32-bit version.
>
> Is this a supported config to build Django?
> Have any of you faced this error?
>
> I appreciate any help that you can provide to solve the errors and failures.
> Please find the error and failure tracebacks in the text file attached
> herewith.
>
> Thanks,
> Antony
>
> --
> 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/8f23755c-be2b-4a24-a00e-aaaead7f78ab%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABxbXqVcPxX6e5jrevAiPXoMJbD4%2BPv6is%3DFVtDjXjDFwynrYg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Unit tests error out with WinError 10013 in my Windows 7 machine with Python 3.3.2

[Marc Tamlyn]

As this is about running the Django teat suite in order to try to write a
patch it does belong on this mailing list.

I don't have any concrete ideas what's wrong - but it does look like all
your issues are related to running the LiveServer (selenium) tests.
Something bound to a certain port already is likely the culprit, or some
sort of version mismatch. Is your code running in a virtual python
environment? I don't like selenium tests should run by default so of you
set yourself up a virtualenv where selenium isn't installed but your Django
checkout is then you shouldn't get these tests running. This may be the
difference Sam was seeing.

In any case, if the patch you were looking to write is not related to this
area of the tests, I suggest you try just running the tests on the area you
know works (and your new tests) or ignoring the failures.

Alternatively, spin up a Linux VM ;)

Marc
On 25 Oct 2013 00:18, "Sam Lai"  wrote:

> Do you have anything running on port 8081 (running netstat will tell you)?
>
> I just ran Django's test suite on my machine (Windows 7, Python
> 3.3.2), from the trunk cloned an hour ago, and it completed mostly
> without an issue (there's a UnicodeDecodeError but that's likely
> because it's printing a character to stdout that isn't supported by
> the Windows console codepage).
>
> Can you move this discussion over to django-users (just post your
> reply with the rest of the email chain over there)? I don't think it's
> an issue with Django itself.
>
> On 25 October 2013 02:46, Antony J  wrote:
> > Hi,
> >
> > Good morning.
> >
> > Your help is needed:
> >
> > I am relatively new to Django. After developing a Django app, I am
> trying to
> > write my first patch for Django.
> >
> > I checked out Django from github: VERSION = (1, 7, 0, 'alpha', 0).
> >
> > When I run the unit tests with the command "python runtests.py", I get 6
> > errors and 2 failures.
> > But in the Django Jenkins server, the builds are successful.
> >
> > The error is: OSError: [WinError 10013] An attempt was made to access a
> > socket in a way forbidden by its access permissions
> >
> > I tried the following:
> >
> > 1) Ran a command prompt as administrator.
> > 2) Added python.exe to firewall inbound rules.
> > 3) There are some suggestions for this error in stack overflow:
> >
> http://stackoverflow.com/questions/2778840/socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in-a-way-forb
> >
> http://stackoverflow.com/questions/16908529/python-3-x-socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in
> >
> > The first suggestion seem require code changes in Django, and the second
> > suggestion seem require code changes in Python http/server.py.
> >
> > But these suggestions do not seem right to me.
> >
> > I am running a Windows 7 Enterprise OS (version 6.1) with Python 3.3.2
> > 32-bit version.
> >
> > Is this a supported config to build Django?
> > Have any of you faced this error?
> >
> > I appreciate any help that you can provide to solve the errors and
> failures.
> > Please find the error and failure tracebacks in the text file attached
> > herewith.
> >
> > Thanks,
> > Antony
> >
> > --
> > 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/8f23755c-be2b-4a24-a00e-aaaead7f78ab%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABxbXqVcPxX6e5jrevAiPXoMJbD4%2BPv6is%3DFVtDjXjDFwynrYg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H79SXu_fN8CH3S-5B3fSvvn%2B8%2B390g1Y7rLG2qaEFXOQ%40mail.gmail.com.
For 

[ANNOUNCE] Django 1.4.9 and Django 1.5.5 released

[James Bennett]

These are minor bugfix releases, so not particularly urgent to upgrade.
Details and release notes are available from the blog post:

https://www.djangoproject.com/weblog/2013/oct/24/bugfix-releases/

-- 
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/CAL13Cg8v_YiT_Ut1Vb5h6kXxrUGgpD1oDrWsbrE5Pv3YFe%3DCng%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.