Re: Epydoc failed to generate documentation for Django 1.5

2013-04-03 Thread Kevin Veroneau 
Take a look at the generic views auto-generated docs from Epydoc(link in my 
post), it's definitely breathtaking.  Especially seeing how all the classes 
come together in a nice UML graph.  It really provides some prospective on 
how hard the core Django developer work and think over a process like CRUD 
and how to make it extendable.  it uses docstrings, which provide 
additional info on the classes and methods themselves.

On Wednesday, 3 April 2013 22:26:06 UTC-5, Jacob Kaplan-Moss wrote:
>
> On Wed, Apr 3, 2013 at 10:19 PM, Kevin Veroneau 
> > 
> wrote: 
> > Is this Epydoc error related to Epydoc or something that Django 
> shouldn't 
> > have done in it's source code? 
>
> It looks perhaps like something you'd need to fix -- the message about 
> settings.configure() indicates that you're loading code that requires 
> settings, but you haven't configured them -- but it's really hard to 
> say. 
>
> Ultimately though I think if you want to do this it's probably going 
> to be on you; I'd be quite against making any changes to Django to 
> accommodate tools like Epydoc. I'm quite skeptical about the value 
> that auto-generated documentation provides, so I'm going to encourage 
> any effort spent on documentation to be spent writing prose, not 
> trying to trick a machine into writing prose. 
>
> Jacob 
>

-- 
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: Epydoc failed to generate documentation for Django 1.5

2013-04-03 Thread Jacob Kaplan-Moss 
On Wed, Apr 3, 2013 at 10:19 PM, Kevin Veroneau  wrote:
> Is this Epydoc error related to Epydoc or something that Django shouldn't
> have done in it's source code?

It looks perhaps like something you'd need to fix -- the message about
settings.configure() indicates that you're loading code that requires
settings, but you haven't configured them -- but it's really hard to
say.

Ultimately though I think if you want to do this it's probably going
to be on you; I'd be quite against making any changes to Django to
accommodate tools like Epydoc. I'm quite skeptical about the value
that auto-generated documentation provides, so I'm going to encourage
any effort spent on documentation to be spent writing prose, not
trying to trick a machine into writing prose.

Jacob

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

Epydoc failed to generate documentation for Django 1.5

2013-04-03 Thread Kevin Veroneau 
Hello Django team,

  I was attempting to build documentation for Django 1.5, and it seems that 
Epydoc doesn't like something in the GIS contrib in the tests.py module.  
Here is the beginning of the error, see the attached text file for the full 
stacktrace:

| In 
/home/kveroneau/django15-env/lib/python2.6/site-packages/django/contrib/gis/management/
| commands/inspectdb.py:
| Import failed (but source code parsing was successful).
| Error: ImproperlyConfigured: Requested setting DATABASES, but 
settings are not configured.
|You must either define the environment variable 
DJANGO_SETTINGS_MODULE or call 
|settings.configure() before accessing settings. (line 1)
|   
  Error: Internal error during parsing 
(/home/kveroneau/django15-env/lib/python2.6/
 site-packages/django/contrib/gis/tests/__init__.py, line 84):
 'int' object is unsubscriptable

  I was able to successfully map out the generic class-based views with UML 
graphs too, you can see it live here:

http://epydoc.pythondiary.com/generic-views/

It really shows the complexity behind some of the class-based views Django 
has.  The next thing I wanted to attempt is to document the entire Django 
project using Epydoc to see how that would look.  Seeing these UML graphs 
is memorizing and very educational for when working with Django.

Is this Epydoc error related to Epydoc or something that Django shouldn't 
have done in it's source code?

Best Regards,
  Kevin Veroneau

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


  Error: Internal error during parsing 
(/home/kveroneau/django15-env/lib/python2.6/
 site-packages/django/contrib/gis/tests/__init__.py, line 84):
 'int' object is unsubscriptable
Traceback (most recent call last):
  File "/home/kveroneau/django15-env/bin/epydoc", line 13, in 
cli()
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/cli.py", line 
965, in cli
main(options, names)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/cli.py", line 
757, in main
exclude_parse=exclude_parse)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py",
 line 206, in build_doc_index
doc_pairs = _get_docs_from_items(items, options)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py",
 line 398, in _get_docs_from_items
item, doc_pairs[-1], options, progress_estimator)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py",
 line 602, in _get_docs_from_submodules
subpackage_dir, docs[-1], options, progress_estimator)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py",
 line 602, in _get_docs_from_submodules
subpackage_dir, docs[-1], options, progress_estimator)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py",
 line 600, in _get_docs_from_submodules
subpackage_file, options, progress_estimator, pkg_docs))
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py",
 line 549, in _get_docs_from_module_file
filename=filename, context=parent_docs[1])
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 278, in parse_docs
process_file(module_doc)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 631, in process_file
lineno, comments, decorators, encoding)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 756, in process_line
return process_classdef(*args)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 1549, in process_classdef
class_doc.bases.append(find_base(base_name, parent_docs))
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 1624, in find_base
return parse_docs(name=str(base_var.imported_from))
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 219, in parse_docs
val_doc = _find(name)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 393, in _find
return _find(name[1:], module_doc)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 393, in _find
return _find(name[1:], module_doc)
  File 
"/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", 
line 378, in _find
module_doc = parse_docs(filename, context=p

Re: URLField should allow scheme to be empty

2013-04-03 Thread Alex Ogier 
After poking around a bit[1], it appears that URLFields are used almost
exclusively for canonical links to webpages, and are not typically used as,
say, the target of internal redirects, or resources that are loaded on a
page. In addition, it looks like the code from ticket 5331 that
automatically adds 'http://' that I referred to as a bug in Django was long
ago reverted[2]. So it seems counterproductive to do anything to disrupt
the current expectations of URLField users, which is that the field is an
absolute URL with scheme, host, the whole shebang. So I change my previous
+1 to a -1. If you want to have a field that allows relative or
scheme-relative URLs, creating your own field is the way to go.

Best,
Alex Ogier

[1]:
https://github.com/search?q=language%3Apython+URLField&ref=commandbar&type=Code
[2]:
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L1323


On Wed, Apr 3, 2013 at 7:38 PM, Atul Bhouraskar
wrote:

> As per RFC 3986 (see section 4, in particular 4.2) all of the following
> are valid:
>
> Absolute URI
> http://www.example.com/images/xyz.png
>
> Network path reference
> //www.example.com/images/xyz.png
>
> Suffix reference (frowned upon but valid?)
> www.example.com/images/xyz.png
>
> Absolute path reference
> /images/xyz.png
>
> Relative path references
> images/xyz.png
> ../images/xyz.png
>
> Should URLField allow all of them? Or do we need options to selectively
> allow/disallow URL components? Or maybe have AbsoluteURLField,
> NetworkPathURLField etc?
>
> Only an absolute URI is *always* relevant. Network path references (and
> relative path references) are only relevant in the context of a web page
> loaded in a browser (e.g. a URL to be rendered within the context of an
> email only makes sense if absolute).
>
> In any case (in my opinion) the URLField should not automatically add a
> missing http: - it should either reject the contents or allow it as per
> documented rules.
>
> Atul
>
>
> On 4 April 2013 07:26, Alex Ogier  wrote:
>
>> Don't add an option, it's not needed. URLs with blank schemas are valid,
>> it's just a bug that Django adds 'http://' in that case. So make a
>> ticket, +1 from me.
>>
>> Best,
>> Alex Ogier
>>
>>
>> On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo Martínez wrote:
>>
>>> I love it.
>>> If URLField has an option like "scheme_required=False" or something like
>>> that.
>>> No behaviour is the "correct", append or not append scheme. The option
>>> to our needs seems to be more correct.
>>>
>>> Regards,
>>>
>>>
>>> On Wed, Apr 3, 2013 at 5:14 PM, SteveB  wrote:
>>>
 How to avoid those browser warnings about mixing secure and insecure
 content on a web page?
 Wouldn't it be great to be able to specify a URL for a resource (be it
 a script, image, iframe etc.)  such that if the current page is insecure
 (using a http:// scheme) the content would be fetched using the same
 scheme?
 And when the current page is secure (using a https:// scheme) the
 resource would also be fetched as if it had a https scheme?

 Well you can, just leave out the scheme in the URL. That is, specify it
 as "//example.com/some/path/" and the browser will apply the same
 scheme as the parent page.

 Great! - But, it is not possible to specify a URL such as this in a
 Django URLField. Thanks to https://code.djangoproject.com/ticket/5331,
 a blank scheme will be cause the field verification to insert "http" as the
 scheme, and you lose the flexibility described above.
 It is currently not possible (in Django 1.5.1) to get a URLField
 validating with a blank scheme, so the ability to specify a URL for a
 resource which can be follow the scheme of the parent page is not possible.

 I content that the 5331 ticket may not have taken into account the
 flexibility which the empty scheme offers on web pages, and I urge that it
 be reconsidered.

 What do folks think?
 SB


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



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

Re: Remove download_url from setup.py

2013-04-03 Thread Waylan Limberg 
On Wed, Apr 3, 2013 at 7:46 PM, Russell Keith-Magee
 wrote:
>
> On Wed, Apr 3, 2013 at 5:29 PM, Donald Stufft  wrote:
>>
>> Just an idea.
>>
>> I think it might make sense to remove the download_url from setup.py. It
>> has caused problems in the past
>> (http://www.djangoproject.com/m/bad-installer.txt) and I don't think leaving
>> it there adds much value. It does however add yet another place that a
>> package releaser needs to update and makes `pip install Django` more
>> fragile.
>>
>> The only major benefit I can see is providing a download link on PyPI, but
>> given that there's a link right 40px or so to directly download from PyPI
>> and a giant green download button further up the page I think this benefit
>> is minimal.
>>
>> Thoughts?
>
>
> Responding mostly because nobody else has, not because I have any firm
> opinions on the topic.
>
> Logically, download_url strikes me as being bit odd - the package metadata,
> which you obtain by downloading the package, contains the definition for
> where to download the package. If the only purpose of the download_url
> declaration is to set the link on PyPI, and pip will install from PyPI's
> uploaded version of the package by preference, then I don't see any real
> benefit in having the download link.
>
> However, I'll completely defer to anyone with more experience with the
> internals of pip or setuptools/distribute/whateveritscalledthisweek.
>
> Russ %-)
>
>
>
> --
> 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.
>
>

If I'm not mistaken, the only part of the download url that changes
with each release is the version number -- which is referenced only a
few lines up. Why isn't the url dynamically created using version?
That's what I do for my projects and the problem has gone way for me.

--

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

-- 
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: Remove download_url from setup.py

2013-04-03 Thread Russell Keith-Magee 
On Wed, Apr 3, 2013 at 5:29 PM, Donald Stufft  wrote:

> Just an idea.
>
> I think it might make sense to remove the download_url from setup.py. It
> has caused problems in the past (
> http://www.djangoproject.com/m/bad-installer.txt) and I don't think
> leaving it there adds much value. It does however add yet another place
> that a package releaser needs to update and makes `pip install Django` more
> fragile.
>
> The only major benefit I can see is providing a download link on PyPI, but
> given that there's a link right 40px or so to directly download from PyPI
> and a giant green download button further up the page I think this benefit
> is minimal.
>
> Thoughts?
>

Responding mostly because nobody else has, not because I have any firm
opinions on the topic.

Logically, download_url strikes me as being bit odd - the package metadata,
which you obtain by downloading the package, contains the definition for
where to download the package. If the only purpose of the download_url
declaration is to set the link on PyPI, and pip will install from PyPI's
uploaded version of the package by preference, then I don't see any real
benefit in having the download link.

However, I'll completely defer to anyone with more experience with the
internals of pip or setuptools/distribute/whateveritscalledthisweek.

Russ %-)

-- 
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: Kickstarter for Django Admin?

2013-04-03 Thread Jason Kraus 


On Sunday, March 31, 2013 9:46:59 AM UTC-7, Serge G. Spaolonzi wrote:
>
>
> On Sat, Mar 30, 2013 at 7:20 PM, Victor Hooi 
> > wrote:
>
>>
>> From the existing projects, we can draw two clear requirements that 
>> people want:
>>
>>- Changing the look and feel - I'm not sure what Django core's 
>>feelings on it, but there seems to be a feeling from the community that 
>> the 
>>look of the current Django Admin is somewhat dated? Also, any new admin 
>>should probably be responsive, and work on mobile or non-desktop devices, 
>>if that's possible. 
>>
>> Personally I dont see the default design a problem because it can be 
> customized with external CSS, although the design shipped with django can 
> be changed, I support the idea of having the admin templates clean, 
> non-coupled to the design and javascript independent.
>
> I think the HTML in the templates should be coded independently from the 
> design, there are some structural mistakes more important than the design, 
> I have sent a ticket related to this here: Ticket #18511 (
> https://github.com/django/django/pull/180)
>
>
>>- More customisations -  a lot of people want to create dashboards 
>>around the admin, add new sections/tabs, or move things around - the 
>>current Admin doesn't have much scope for that, or it's not easily 
>>accessible. 
>>
>> I would like to see a RESTful api to the admin methods and bigger 
> separation between the views and the templates, in a way that the admin 
> could be operated from anywhere (android for example). 
> Currently the admin app is website interface to CRUD operations, I think 
> the admin app could be improved and turned into a CRUD engine independent 
> of the presentation that exposes a interface that could be implemented or 
> extended from any presentation form (android, html, rest calls).
>

A RESTful api with a separate template client is exactly what hyperadmin 
aims to do: https://github.com/zbyte64/django-hyperadmin
I've played around with bolting on an emberjs client or having an admin 
powered by django templates and both options can and do work. It pretty 
much works as you describe, a CRUD engine operates independently of the 
presentation layer but for this to work reasonably links themselves must be 
communicated so that filtering, sorting, etc can easily be represented by a 
variety of clients. If you don't like the client you can choose or build 
another one without having to re-implement the admin operations and logic.

The focus on HATEOAS also allows for No-SQL storages (
https://github.com/zbyte64/django-hyperadmin-dockitresource) to be used by 
the same clients because the functionality emitted by the document store is 
described as links. If you want more functionality exposed then it is a 
matter of getting your resource to emit the proper links.


> Regards
>
> -- 
> Serge G. Spaolonzi
> Cobalys Systems
> http://www.cobalys.com
>

-- 
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: URLField should allow scheme to be empty

2013-04-03 Thread Atul Bhouraskar 
As per RFC 3986 (see section 4, in particular 4.2) all of the following are
valid:

Absolute URI
http://www.example.com/images/xyz.png

Network path reference
//www.example.com/images/xyz.png

Suffix reference (frowned upon but valid?)
www.example.com/images/xyz.png

Absolute path reference
/images/xyz.png

Relative path references
images/xyz.png
../images/xyz.png

Should URLField allow all of them? Or do we need options to selectively
allow/disallow URL components? Or maybe have AbsoluteURLField,
NetworkPathURLField etc?

Only an absolute URI is *always* relevant. Network path references (and
relative path references) are only relevant in the context of a web page
loaded in a browser (e.g. a URL to be rendered within the context of an
email only makes sense if absolute).

In any case (in my opinion) the URLField should not automatically add a
missing http: - it should either reject the contents or allow it as per
documented rules.

Atul


On 4 April 2013 07:26, Alex Ogier  wrote:

> Don't add an option, it's not needed. URLs with blank schemas are valid,
> it's just a bug that Django adds 'http://' in that case. So make a
> ticket, +1 from me.
>
> Best,
> Alex Ogier
>
>
> On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo Martínez wrote:
>
>> I love it.
>> If URLField has an option like "scheme_required=False" or something like
>> that.
>> No behaviour is the "correct", append or not append scheme. The option to
>> our needs seems to be more correct.
>>
>> Regards,
>>
>>
>> On Wed, Apr 3, 2013 at 5:14 PM, SteveB  wrote:
>>
>>> How to avoid those browser warnings about mixing secure and insecure
>>> content on a web page?
>>> Wouldn't it be great to be able to specify a URL for a resource (be it a
>>> script, image, iframe etc.)  such that if the current page is insecure
>>> (using a http:// scheme) the content would be fetched using the same
>>> scheme?
>>> And when the current page is secure (using a https:// scheme) the
>>> resource would also be fetched as if it had a https scheme?
>>>
>>> Well you can, just leave out the scheme in the URL. That is, specify it
>>> as "//example.com/some/path/" and the browser will apply the same
>>> scheme as the parent page.
>>>
>>> Great! - But, it is not possible to specify a URL such as this in a
>>> Django URLField. Thanks to https://code.djangoproject.com/ticket/5331,
>>> a blank scheme will be cause the field verification to insert "http" as the
>>> scheme, and you lose the flexibility described above.
>>> It is currently not possible (in Django 1.5.1) to get a URLField
>>> validating with a blank scheme, so the ability to specify a URL for a
>>> resource which can be follow the scheme of the parent page is not possible.
>>>
>>> I content that the 5331 ticket may not have taken into account the
>>> flexibility which the empty scheme offers on web pages, and I urge that it
>>> be reconsidered.
>>>
>>> What do folks think?
>>> SB
>>>
>>>
>>>  --
>>> 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.
>>>
>>>
>>>
>>
>>
>>
>> --
>> juanpex
>>
>>  --
>> 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.
>>
>>
>>
>
>  --
> 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.
>
>
>

-- 
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: Django Core mentorship list

2013-04-03 Thread Jeremy Dunck 
Ahem:
[1] https://groups.google.com/forum/?fromgroups#!forum/django-core-mentorship

:)


On Wed, Apr 3, 2013 at 11:44 AM, Jeremy Dunck  wrote:
> Hey all,
>   I've just created django-core-mentorship[1] with founding members
> including Carl Meyer, Jacob Kaplan-Moss, Simon Charette, and Russell
> Keith-Magee.
>
>   Modeled after pythonmentors.com, the intention is to help more
> people make the leap from using django to contributing to it.  It is a
> complement to django-developers, where most members are already quite
> experienced with django and development in general.
>
>   django-core-mentorship will consist just of people interested in
> learning to contribute, or members of django-core who are interested
> in helping those people succeed.  We'll have a Code along the lines of
> pythonmentors as well, but for now, I hope this email will suffice.
>
>   If you ever see conversation on this list where you feel a new
> contributor is being turned away (or turned off) by the existing
> django-developers discussion, please direct them to
> django-core-mentorship.
>
>   If you've considered contributing to Django but haven't felt
> welcome, this list is for you.

-- 
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: URLField should allow scheme to be empty

2013-04-03 Thread Alex Ogier 
Don't add an option, it's not needed. URLs with blank schemas are valid,
it's just a bug that Django adds 'http://' in that case. So make a ticket,
+1 from me.

Best,
Alex Ogier


On Wed, Apr 3, 2013 at 4:24 PM, Juan Pablo Martínez wrote:

> I love it.
> If URLField has an option like "scheme_required=False" or something like
> that.
> No behaviour is the "correct", append or not append scheme. The option to
> our needs seems to be more correct.
>
> Regards,
>
>
> On Wed, Apr 3, 2013 at 5:14 PM, SteveB  wrote:
>
>> How to avoid those browser warnings about mixing secure and insecure
>> content on a web page?
>> Wouldn't it be great to be able to specify a URL for a resource (be it a
>> script, image, iframe etc.)  such that if the current page is insecure
>> (using a http:// scheme) the content would be fetched using the same
>> scheme?
>> And when the current page is secure (using a https:// scheme) the
>> resource would also be fetched as if it had a https scheme?
>>
>> Well you can, just leave out the scheme in the URL. That is, specify it
>> as "//example.com/some/path/" and the browser will apply the same scheme
>> as the parent page.
>>
>> Great! - But, it is not possible to specify a URL such as this in a
>> Django URLField. Thanks to https://code.djangoproject.com/ticket/5331, a
>> blank scheme will be cause the field verification to insert "http" as the
>> scheme, and you lose the flexibility described above.
>> It is currently not possible (in Django 1.5.1) to get a URLField
>> validating with a blank scheme, so the ability to specify a URL for a
>> resource which can be follow the scheme of the parent page is not possible.
>>
>> I content that the 5331 ticket may not have taken into account the
>> flexibility which the empty scheme offers on web pages, and I urge that it
>> be reconsidered.
>>
>> What do folks think?
>> SB
>>
>>
>>  --
>> 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.
>>
>>
>>
>
>
>
> --
> juanpex
>
>  --
> 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.
>
>
>

-- 
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: URLField should allow scheme to be empty

2013-04-03 Thread Juan Pablo Martínez 
I love it.
If URLField has an option like "scheme_required=False" or something like
that.
No behaviour is the "correct", append or not append scheme. The option to
our needs seems to be more correct.

Regards,

On Wed, Apr 3, 2013 at 5:14 PM, SteveB  wrote:

> How to avoid those browser warnings about mixing secure and insecure
> content on a web page?
> Wouldn't it be great to be able to specify a URL for a resource (be it a
> script, image, iframe etc.)  such that if the current page is insecure
> (using a http:// scheme) the content would be fetched using the same
> scheme?
> And when the current page is secure (using a https:// scheme) the
> resource would also be fetched as if it had a https scheme?
>
> Well you can, just leave out the scheme in the URL. That is, specify it as
> "//example.com/some/path/" and the browser will apply the same scheme as
> the parent page.
>
> Great! - But, it is not possible to specify a URL such as this in a Django
> URLField. Thanks to https://code.djangoproject.com/ticket/5331, a blank
> scheme will be cause the field verification to insert "http" as the scheme,
> and you lose the flexibility described above.
> It is currently not possible (in Django 1.5.1) to get a URLField
> validating with a blank scheme, so the ability to specify a URL for a
> resource which can be follow the scheme of the parent page is not possible.
>
> I content that the 5331 ticket may not have taken into account the
> flexibility which the empty scheme offers on web pages, and I urge that it
> be reconsidered.
>
> What do folks think?
> SB
>
>
>  --
> 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.
>
>
>



-- 
juanpex

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

URLField should allow scheme to be empty

2013-04-03 Thread SteveB 
How to avoid those browser warnings about mixing secure and insecure 
content on a web page?
Wouldn't it be great to be able to specify a URL for a resource (be it a 
script, image, iframe etc.)  such that if the current page is insecure 
(using a http:// scheme) the content would be fetched using the same scheme?
And when the current page is secure (using a https:// scheme) the resource 
would also be fetched as if it had a https scheme?

Well you can, just leave out the scheme in the URL. That is, specify it as 
"//example.com/some/path/" and the browser will apply the same scheme as 
the parent page.

Great! - But, it is not possible to specify a URL such as this in a Django 
URLField. Thanks to https://code.djangoproject.com/ticket/5331, a blank 
scheme will be cause the field verification to insert "http" as the scheme, 
and you lose the flexibility described above.
It is currently not possible (in Django 1.5.1) to get a URLField validating 
with a blank scheme, so the ability to specify a URL for a resource which 
can be follow the scheme of the parent page is not possible.

I content that the 5331 ticket may not have taken into account the 
flexibility which the empty scheme offers on web pages, and I urge that it 
be reconsidered.

What do folks think?
SB


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

Django Core mentorship list

2013-04-03 Thread Jeremy Dunck 
Hey all,
  I've just created django-core-mentorship[1] with founding members
including Carl Meyer, Jacob Kaplan-Moss, Simon Charette, and Russell
Keith-Magee.

  Modeled after pythonmentors.com, the intention is to help more
people make the leap from using django to contributing to it.  It is a
complement to django-developers, where most members are already quite
experienced with django and development in general.

  django-core-mentorship will consist just of people interested in
learning to contribute, or members of django-core who are interested
in helping those people succeed.  We'll have a Code along the lines of
pythonmentors as well, but for now, I hope this email will suffice.

  If you ever see conversation on this list where you feel a new
contributor is being turned away (or turned off) by the existing
django-developers discussion, please direct them to
django-core-mentorship.

  If you've considered contributing to Django but haven't felt
welcome, this list is for you.

-- 
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: Django 1.5.1 released

2013-04-03 Thread Jacob Kaplan-Moss 
On Tue, Apr 2, 2013 at 11:02 PM, Russell Keith-Magee
 wrote:
> In short, no - Twitter isn't a particularly reliable source for updates.
> Someone in the core team will usually tweet about the release, but since
> it's hard to share logins to a single Twitter account, and the person who
> owns Django's twitter account won't always be involved in formally cutting
> the release, we sometimes drop the ball.

Actually, in theory we've got hootsuite set up to automatically tweet
stuff posted to the blog. However, in practice it seems to break, and
it hasn't updated in about two weeks. I'm looking into fixing it, and
we'll try to keep a better eye on it ferm here on out.

But yeah, as Russ says -- the announce list is going to be the most
reliable. The number of things that could break about the blog ->
hootsuite -> twitter flow make it rather unreliable.

Jacob

-- 
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: Django 1.5.1 released

2013-04-03 Thread Josh Cartmell 
That makes sense, thanks for the explanation and the pointers to the
best sources of information.  I never realized the Django announce
mailing list existed, it will serve my purposes perfectly as I'm sure
it's intended to!

Regards,
Josh

On Apr 2, 9:02 pm, Russell Keith-Magee 
wrote:
> Hi Josh,
>
> In short, no - Twitter isn't a particularly reliable source for updates.
> Someone in the core team will usually tweet about the release, but since
> it's hard to share logins to a single Twitter account, and the person who
> owns Django's twitter account won't always be involved in formally cutting
> the release, we sometimes drop the ball.
>
> Our official channels are the django-announce mailing list, and Django's
> blog. If you're looking for guaranteed notification, those two channels are
> guaranteed to receive notification.
>
> Yours
> Russ Magee %-)
>
>
>
>
>
>
>
> On Wed, Apr 3, 2013 at 12:10 AM, Josh Cartmell  wrote:
> > Thanks for the release!
>
> > Kind of random question, but this seems like the best place to ask
> > it.  I used to use Twitter mobile notifications to keep up with Django
> > releases, but I've noticed that the last three releases (since 1.4.4)
> > have not been announced on Django's Twitter.  Is this just an over-
> > site, or is Twitter no longer a good place to keep up with Django
> > releases.
>
> > Thanks,
> > Josh
>
> > On Mar 28, 2:02 pm, Jacob Kaplan-Moss  wrote:
> > > Hi folks --
>
> > > We've just released Django 1.5.1, a bug fix release that cleans up a
> > > couple issues with last month's 1.5 release.
>
> > > The biggest fix is for a memory leak introduced in Django 1.5. Under
> > > certain circumstances, repeated iteration over querysets could leak
> > > memory - sometimes quite a bit of it.
>
> > > For more details, see our announcement:
>
> > >    https://www.djangoproject.com/weblog/2013/mar/28/django-151/
>
> > > Thanks for using Django!
>
> > > Jacob
>
> > --
> > 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 athttp://groups.google.com/group/django-developers?hl=en
> > .
> > For more options, visithttps://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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Kickstarter for Django Admin?

2013-04-03 Thread Val Neekman 
The beauty of kickstarter is that people speak with their wallets. If a
project doesn't have a merit, then no one would pitch in and that would be
the end of the project.

Django admin is a great tool. In my projects I use it for quick view and
edits so I don't have to fallback to command line or SQL. Mind you, that I
have put extensive checks and validation around it to ensure I don't have a
booboo.

I think a nicer admin (more modern and feature rich) would encourage
newcomers to pick up Django as their main framework and
that in-turn injects fresh blood into the community.

Imagine a Django-Admin that could turn Django into a replacement
of Wordpress in 5 minutes? (not a perfect example, but you get what I mean)

Can't wait for "new" South  ...

Val








On Wed, Apr 3, 2013 at 10:35 AM, Felipe Prenholato wrote:

> I have a point about kickstarter powered projects. Anyone can send one,
> but in my opinion only projects extensively discussed here with a complete
> roadmap can have success. Actually I think that it also should have
> mentors, like GSOC, while aproved by community via money.
>
> Also, Andrew proposal is something that will impact (for good) on life of
> every Django developer. Every Django developer with even very small
> projects use South today. About admin, my self as superuser of my projects
> don't use it very much, and never used any re-skin.
>
> Of course I'm +1 to improvements on admin, but I'm sure that we have
> points where we can improve much more with help of kickstarter, as example
> improvements on ORM, NoSQL databases integration, Form Templates (
> https://code.djangoproject.com/wiki/SummerOfCode2012#FinishingoffFormTemplates
> ).
>
> It isn't in any way criticism to your idea Victor, but I fear that
> everyone want to start your own project to Django in that kickstarter model.
>
> Bests,
>
> Felipe 'chronos' Prenholato.
> Linux User nº 405489
> Home page: http://devwithpassion.com | http://chronosbox.org/blog
> GitHub: http://github.com/chronossc/ | Twitter:
> http://twitter.com/chronossc
>
>
> 2013/4/1 Amirouche Boubekki 
>
>>  For the former - I believe there was already discussions on that sort
 of thing on this board?

 There's a wiki page with some notes as well:

 https://code.djangoproject.com/wiki/AdminNext

>>>
>>> There's a world of difference between "some notes" and "a clear plan and
>>> direction" :-)
>>>
>>
>> Hopefully 2013.djangocon.eu Idan's 
>> talkwill clear things up.
>>
>> --
>> 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.
>>
>>
>>
>
>  --
> 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.
>
>
>

-- 
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: URL dispatcher fallthrough?

2013-04-03 Thread Jacob Kaplan-Moss 
I think it's esoteric enough that mentioning it in the docs doesn't
seem like it's worth the distraction. But the wiki's, um, a wiki... so
feel free to edit!

Jacob

On Wed, Apr 3, 2013 at 9:07 AM, Felipe Prenholato  wrote:
> Jacob, I know that Django don't refer to third party packages in docs, but
> is possible to have something in doc or wiki (and doc linking to wiki) about
> this url helper (and possible others)? I ask because I see functionality
> proposed by this thread and by your app good enough to be cited in some
> place close to official docs.
>
> Felipe 'chronos' Prenholato.
> Linux User nº 405489
> Home page: http://devwithpassion.com | http://chronosbox.org/blog
> GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc
>
>
> 2013/4/2 Jacob Kaplan-Moss 
>>
>> On Tue, Apr 2, 2013 at 4:49 AM, David Danier 
>> wrote:
>> > This is somethign that does not need to be inside Django core. So why
>> > not just start an thirt party app implementing the proposal?
>>
>> I did just that: https://pypi.python.org/pypi/django-multiurl.
>>
>> Turns out it takes a fair bit of spelunking inside the guts of the
>> urlresolver, but ends up being a fairly short bit of code. Give it a
>> shot, let me know if it works for your usecase(s).
>>
>> Jacob
>>
>> --
>> 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.
>>
>>
>
> --
> 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.
>
>

-- 
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: Kickstarter for Django Admin?

2013-04-03 Thread Felipe Prenholato 
I have a point about kickstarter powered projects. Anyone can send one, but
in my opinion only projects extensively discussed here with a complete
roadmap can have success. Actually I think that it also should have
mentors, like GSOC, while aproved by community via money.

Also, Andrew proposal is something that will impact (for good) on life of
every Django developer. Every Django developer with even very small
projects use South today. About admin, my self as superuser of my projects
don't use it very much, and never used any re-skin.

Of course I'm +1 to improvements on admin, but I'm sure that we have points
where we can improve much more with help of kickstarter, as example
improvements on ORM, NoSQL databases integration, Form Templates (
https://code.djangoproject.com/wiki/SummerOfCode2012#FinishingoffFormTemplates
).

It isn't in any way criticism to your idea Victor, but I fear that everyone
want to start your own project to Django in that kickstarter model.

Bests,

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2013/4/1 Amirouche Boubekki 

>  For the former - I believe there was already discussions on that sort of
>>> thing on this board?
>>>
>>> There's a wiki page with some notes as well:
>>>
>>> https://code.djangoproject.com/wiki/AdminNext
>>>
>>
>> There's a world of difference between "some notes" and "a clear plan and
>> direction" :-)
>>
>
> Hopefully 2013.djangocon.eu Idan's 
> talkwill clear things up.
>
> --
> 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.
>
>
>

-- 
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: URL dispatcher fallthrough?

2013-04-03 Thread Felipe Prenholato 
Jacob, I know that Django don't refer to third party packages in docs, but
is possible to have something in doc or wiki (and doc linking to wiki)
about this url helper (and possible others)? I ask because I see
functionality proposed by this thread and by your app good enough to be
cited in some place close to official docs.

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2013/4/2 Jacob Kaplan-Moss 

> On Tue, Apr 2, 2013 at 4:49 AM, David Danier 
> wrote:
> > This is somethign that does not need to be inside Django core. So why
> > not just start an thirt party app implementing the proposal?
>
> I did just that: https://pypi.python.org/pypi/django-multiurl.
>
> Turns out it takes a fair bit of spelunking inside the guts of the
> urlresolver, but ends up being a fairly short bit of code. Give it a
> shot, let me know if it works for your usecase(s).
>
> Jacob
>
> --
> 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.
>
>
>

-- 
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: Django 1.5 using a cached HttpResponse with WSGI has an empty body

2013-04-03 Thread SteveB 
I created a ticket for this problem: 
https://code.djangoproject.com/ticket/20187

-- 
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: Django 1.5 using a cached HttpResponse with WSGI has an empty body

2013-04-03 Thread SteveB 
Hi Aymeric,

Thanks for your reply.
Actually I'm just using a memory cache for the response, so I'm not 
pickling it.

My thoughts are:

   1. The __iter__ method of a HttpResponse should create an instance of a 
   separate iterator class to iterate over the container. It should not return 
   self. The iterator class instance can return self in it's own __iter__ 
   method. This, I think, would get around the issue raised in 
   https://code.djangoproject.com/ticket/13222.
   2. I accept that StreamingHttpResponse instances can only be iterated 
   once, and are therefore not suitable for caching. That's something that my 
   application can handle.

Do you think this would work OK?

I'll create a ticket to track this.
Thanks,
Stephen

On Tuesday, 2 April 2013 20:03:49 UTC+1, Aymeric Augustin wrote:
>
> On 25 mars 2013, at 18:02, SteveB > 
> wrote: 
>
> > I suspect this is a bug. Any thoughts? 
>
> Yes, it's annoying, all the more since Django exposes response.content as 
> an attribute. 
>
> > This works, but makes my code dependent on the internals of the 
> HttpResponse class, which isn't great. Any better ideas? 
>
> I assume you're pickling the response to cache it. We could define a 
> __getstate__ method to remove _iterator from what's pickled, like this: 
>
> def __getstate__(self): 
> state = self.__dict__.copy() 
> state.pop('_iterator', None) 
> return state 
>
> Could you file a ticket so we don't lose track of this problem? 
>
> -- 
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Remove download_url from setup.py

2013-04-03 Thread Donald Stufft 
Just an idea.

I think it might make sense to remove the download_url from setup.py. It has 
caused problems in the past (http://www.djangoproject.com/m/bad-installer.txt) 
and I don't think leaving it there adds much value. It does however add yet 
another place that a package releaser needs to update and makes `pip install 
Django` more fragile.

The only major benefit I can see is providing a download link on PyPI, but 
given that there's a link right 40px or so to directly download from PyPI and a 
giant green download button further up the page I think this benefit is minimal.

Thoughts?

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail