Re: ANNOUNCE: Django 1.4 released

[Shawn Milochik]

On 03/23/2012 04:08 PM, Andre Terra wrote:

Hooray!

Congrats to everyone involved, especially all that worked on bringing
timezone support to this increasingly amazing web framework.

I don't mean to nitpick but a minor detail in the release notes requires
some attention:

"Django does not support Python 3.x at this time. At some point before
the release of Django 1.4, we plan to publish a document outlining our
full timeline for deprecating Python 2.x and moving to Python 3.x."

Have we got a timeline yet?



I think this might be what they were referring to.

https://www.djangoproject.com/weblog/2012/mar/13/py3k/


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Mobile Login????

[Shawn Milochik]

On 02/27/2012 02:24 PM, relihkcin wrote:

Hey, has anyone developed a mobile login? i'm having issues. When i
load the login page into a  for my mobile app. It wont work. But
if i redirect it to webbrowser. it works. I'm still a couple months
new with django. Any help would be appriacted. thanks



Please elaborate on "it won't work." There's not much anyone can do but 
guess otherwise. Error messages and tracebacks are preferred.


Considering it works in a Web browser, it doesn't sound like Django has 
a problem at all.


My only random guess is some kind of CSRF issue, but I don't have any 
detail to support it.



--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Shawn Milochik]

On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  wrote:
>
> In the interest of making the wider community opinion heard, I too am +1 on 
> this, my feeling is exactly the same as Stephen.
>
> --

+1

I understand that a BDFL has spoken and this change isn't going to
happen. I hate to add to the noise, but since the argument from
popularity fallacy has been invoked, I feel the need to point out that
many of us didn't bother to weigh in because we didn't choose to add
to the noise. Especially after the case was so well-made by others --
it didn't seem necessary.

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: How do add ancillary, display-only data to each form in a formset?

[Shawn Milochik]

Instead of a formset, you can just put a bunch of forms in a list and 
iterate through them.


Why not use a ModelForm and just add your extra fields to it?

Also, there's nothing stopping you from adding an attribute to your 
model instances in your form. Then you can iterate through the objects 
in your template and use attributes from the instances and form fields 
conveniently.


Something like this:

thingies = []

for item in Thingy.objects.filter(...):
item.form = MyAwesomeForm(prefix = item.id)
thingies.append(item)

Then, in your template you can iterate through thingies and use {{ 
thingy.whatever }} or {{ thingy.form.checked }} when you like.



--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Forced password reset in django-admin

[Shawn Milochik]

On 06/29/2011 12:01 PM, Daniel Moisset wrote:

django.auth already provides a password reset mechanism, where users
can get a password reset link.

So, woudn't this work for you?:

1) Create users with a large random password. Destroy every copy of the password
2) Use the reset password feature with their email to force it to set
an initial value

That way you never send them actual passwords, and the only passwords
they can use are the ones they set.

all of this works with no additional support needed from django

D.



That would work, and I'd recommend using the provided 
set_unusable_password method instead of setting a random password for 
additional security.



--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

max_value bug (ticket #16306)

[Shawn Milochik]

https://code.djangoproject.com/ticket/16306

Would a core dev or two please give their opinion on this? I think it's
a bug and not a flaw in the documentation. As I read the docs it seems
plain that the max_value and min_value do what I think a reasonable
person would expect them to do. In fact, they do behave in that way when
set in the field "normally." So the fact that they do nothing when used
in an __init__ override of the form is a bug or, at best, a very
surprising behavior.

Thanks,
Shawn

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DecimalField allows float value as 'default'.

[Shawn Milochik]

http://code.djangoproject.com/ticket/16015

I've uploaded a patch, but changed the status to 'Design Decision Needed' 
from 'Accepted.'

The problem is that although my patch follows the existing convention and 
results in passing tests in Python 2.6, the Python core developers have made 
an important change to the way Decimal objects work -- they may now be 
instantiated with floats. This means that my patch introduces a failing test 
if Python 2.7 is being used.

The patch:
http://code.djangoproject.com/attachment/ticket/16015/16015_DecimalField_invalid_defaults.diff

As I mentioned in the comment I just added to the ticket, the current "bug" 
is more pedantry than something that causes errors for real users. So, I 
leave it to the core devs to suggest an improved patch method or marking it 
wontfix.

Thanks,
Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DecimalField allows float value as 'default'.

[Shawn Milochik]

On 05/12/2011 08:04 PM, Russell Keith-Magee wrote:


I suspect the answer will lie somewhere between get_prep_value() and
to_python() on DecimalField, but you'll need to do some code path
tracing to confirm. Looking at the code, I'm a little surprised that
it doesn't work as is...

Yours,
Russ Magee %-)


Russell,

Thanks for the comments. I did dig into the code after my last e-mail 
and I'm starting to understand how it works. It may be where you say, 
and I see why it's definitely not a case of overriding the __init__ 
function.


The reason it is so liberal in accepting values at the moment is that 
get_default function, which turns the default value into unicode before 
returning it. I have a patch half-done (or so). Frustratingly, when I 
try checking to see if f.has_default(), it returns True even if it's a 
NOT_PROVIDED object. If I import NOT_PROVIDED into the validation and 
check if "f.default is NOT PROVIDED" then it works. I'll report back 
when I'm further along.


Shawn


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DecimalField allows float value as 'default'.

[Shawn Milochik]

On 05/11/2011 08:00 PM, Russell Keith-Magee wrote:

On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik<sh...@milochik.com>  wrote:

Someone on django-users just commented that they set a default value on a
DecimalField as a float, and were surprised when they were unable to create
a queryset using a float to find records.

I searched Trac for the terms 'DecimalField default' and didn't see anywhere
that this was brought up before.

Should there be a validator added to the DecimalField that checks whether
decimal.Decimal(default) is a valid operation if default isn't NOT_PROVIDED?
Or maybe an override to __init__ in DecimalField that calls super().__init__
then does this test.

Currently, it appears that this works because the value of 'default' is
coerced to unicode by Field's get_default(). This results in an invalid
value (float) being treated as valid for a DecimalField.

If DecimalField is accepting anything other than a DecimalField (or a
string, for historical reasons -- but that's true of any Field) under
*any* circumstances (default, new field value, etc), then it should be
raising an error. A float can't be reliably converted to a Decimal,
because you don't have guaranteed precision.

If this hasn't already been reported, then it should be. I have a
vague recollection of something about DecimalField defaults coming up
in the last year or so (either on Trac or Django-dev), but that could
just be a random pre-coffee neuron firing... I'll defer to anyone who
has actually done the Trac search :-)

Yours
Russ Magee %-)



I've opened a ticket:
http://code.djangoproject.com/ticket/16015

I'd like to work on it. To have the best chance of my patch being 
accepted, what's the best way to approach this? I believe the best thing 
is to check that Decimal(value) works or raise a TypeError, and the 
place would be to override __init__ in DecimalField, call the 
super().__init__, and then do this check.


Thanks,
Shawn

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

DecimalField allows float value as 'default'.

[Shawn Milochik]

Someone on django-users just commented that they set a default value on 
a DecimalField as a float, and were surprised when they were unable to 
create a queryset using a float to find records.


I searched Trac for the terms 'DecimalField default' and didn't see 
anywhere that this was brought up before.


Should there be a validator added to the DecimalField that checks 
whether decimal.Decimal(default) is a valid operation if default isn't 
NOT_PROVIDED? Or maybe an override to __init__ in DecimalField that 
calls super().__init__ then does this test.


Currently, it appears that this works because the value of 'default' is 
coerced to unicode by Field's get_default(). This results in an invalid 
value (float) being treated as valid for a DecimalField.


Shawn


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

old patches, 15064, 15595

[Shawn Milochik]

http://code.djangoproject.com/ticket/15064
http://code.djangoproject.com/ticket/15595

Hi. Just wondering if someone could take a look at these. It's been two 
weeks since the last activity, and already one of them had a merge 
conflict with trunk, so I just updated it.


If there's a problem with either one please let me know.

Thanks,
Shawn

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging view errors

[Shawn Milochik]

On 05/10/2011 04:52 PM, Michael Blume wrote:
A developer can currently do this pretty easily with middleware by 
setting a process_exception method. We could provide some contrib 
middleware for logging exceptions, but I don't see any need to bring 
this into core.


-Mike



Mike,

You and someone on django-users both told me about process_exception, 
which I had been unaware of. It looks perfect for what I need.


Thanks,
Shawn


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

logging view errors

[Shawn Milochik]

I think this is something I'd like to open up a ticket for, but first I 
want to see whether it's already possible, or is overruled by existing 
design decisions.


Desire:
Now that logging is built into Django, I think that any time there is an 
exception in a view a logging.exception message should be sent.


Currently, if you create a logging handler to handle 'django' or 
'django.request' there is no 'logging' call for the exception.


Justification:
Without this, a developer would have to needlessly complicate all views 
with exception handlers or apply a decorator universally across all 
views to ensure that this information (including the stack trace, which 
comes for free with logging.exception) is logged.


Use cases:

1. For a view accessed via AJAX, if there is an error in a view a 500 
(or a 403 for a missing CSRF token) error will occur, but nothing is 
logged and there is no obvious way to figure out what broke. This is 
mainly useful during development.


2. In production, it would be helpful to be able to check the log for 
these errors to preemptively fix bugs.


Thank you for your time.

Shawn


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: deprecation of AUTH_PROFILE_MODULE

[Shawn Milochik]

Since it wasn't stated explicitly in that last wish-list, I'd like to 
add: No assumption that the primary key is an integer.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Why does the test handler call sys.exit()?

[Shawn Milochik]

On 04/27/2011 05:30 PM, Alex Gaynor wrote:



This is needed so that the process will exit with the correct status 
code.  Note that this doesn't prevent you from calling it, you just 
need to catch the SystemExit exception.


Alex




Alex,

That's perfect. I tried to catch the exception before and it didn't 
work. I didn't know that SystemExit came from a different base class 
than Exception, but after you mentioned it I searched and found this:


http://docs.python.org/library/exceptions.html#exceptions.SystemExit

Thanks for the education.

Shawn

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Why does the test handler call sys.exit()?

[Shawn Milochik]

Core devs,

I've written a script which monitors my project path for changes with
pyinotify [1] and automatically runs my test suite each time I save a
Python file.

I was doing this by calling subprocess, but someone helpfully pointed
me towards call_command[2]. However, this breaks my script, which is
using a loop that's baked into pyinotify's Notifier class.

The problem is that the handler function [3] calls sys.exit() if there
are any test failures. Given that the function is already done at this
point, it seems redundant.

I can just as easily go back to using subprocess, but it seems silly
to shell out of Python to call a Python function. Is there any reason
not to change this sys.exit() to a sys.stderr.write()?

Thanks for your time.

Shawn

[1] https://github.com/seb-m/pyinotify
[2] 
http://docs.djangoproject.com/en/dev/ref/django-admin/#running-management-commands-from-your-code
[3] 
http://code.djangoproject.com/browser/django/trunk/django/core/management/commands/test.py

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Review request: 15064, DJANGO_SETTINGS_MODULE environment variable ignored in runserver.

[Shawn Milochik]

Thanks for the info and feedback on the patches today. I'll stop
spamming the list.

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Review request: 15064, DJANGO_SETTINGS_MODULE environment variable ignored in runserver.

[Shawn Milochik]

Patch with tests attached to ticket.

http://code.djangoproject.com/ticket/15064

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Updated patch for 15661 (LogEntry objects have no unicode method)

[Shawn Milochik]

http://code.djangoproject.com/ticket/15661

Cleaned up at Jacob's suggestion.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Small doc patch for review.

[Shawn Milochik]

http://code.djangoproject.com/ticket/15595

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Two small tickets, please review.

[Shawn Milochik]

I've submitted two (very) small patches. They're my first submissions,
so let the constructive criticism flow freely. I'd like to contribute
to Django more than I have (mostly django-users help), so any advice
that'll help me ease into the role is welcome. I've read the
contribution docs, but it's always possible I've made a mistake.

http://code.djangoproject.com/ticket/15661

http://code.djangoproject.com/ticket/15876

Thanks,
Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Single Table Inheritance

[Shawn Milochik]

On Tue, Mar 29, 2011 at 2:21 PM, Carl Meyer  wrote:
> Hi Shawn,
>
> What you've outlined here is certainly possible (and yes, you'd need to
> subclass the ModelBase metaclass). I haven't looked at the abstract
> inheritance stuff recently, but I think there would be some alternative
> ways for the abstract base to know about its children that wouldn't
> require the metaclass assignment. However: getting the list of
> subclasses is (less than) half the battle; the trickier part is giving
> the ORM the capability to do UNION queries on similar tables, so you can
> get results from multiple tables in a single QuerySet.

Carl,

Thanks for the explanation. That does make sense and I see where it
gets really tricky when you delve into the ORM.

I'm not proposing a change to Django itself or suggesting that this
should be a standard practice. I do think that this is a fairly clean
solution for an individual to use to solve this problem if they have
it.

They can create a custom manager on the abstract class that would
return an iterable, perhaps using itertools.chain() of the querysets.

It depends on what they expect to do with the output of this custom
manager, and they'd obviously lose the ability to treat this output as
a queryset by using additional sorts & filters and such. But if the
goal is to be able to get instances from all subclasses at once then
this is a viable solution, FWIW.

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Single Table Inheritance

[Shawn Milochik]

Hopefully someone on the core dev team can let me know if this is
possible in Django. If so, it will solve this problem.
I am not familiar with custom metaclass stuff done within models.Model.

1. Create a custom metaclass as described in "Pro Python," page 124.

2. Add this metaclass to the abstract model.

This would allow the base-class to be aware of its subclasses and have
a class method that returns a queryset of them.

Further detail:
This simply amounts to creating a list object in the abstract base
class. Each time a subclass is instantiated, that class is added to
the parent class's list. That's all. That list could be used in a
custom manager to get the desired queryset.

What I don't know is how nicely this will play with the existing
metaclass work in Django. It seems that a metaclass can be easily made
by subclassing the one used for models.Model instead of the default
'type,' but this is beyond my experience level. Is this a reasonable
approach?

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Brute force attacks

[Shawn Milochik]

I have an immediate interest in this discussion. One of my company's
Django apps was recently subjected to an external risk assessment team
audit. They found the fact that three invalid password attempts didn't
lock out the user to be completely unacceptable.

Granted, this is something that I should have applied myself, and if
it were automatically part of Django it would frustrate many
developers because it would inconvenience their users.

However, considering it's an OWASP concern, and likely a wheel which
will be reinvented repeatedly, I would like to see it in Django. I am
willing to put my time into the effort. If Rohit and his team end up
taking on the project I will coordinate with them to see how I can
help.

It seems that any implementation of this would require another value
for settings.py, and I know that's something not done lightly. Also,
the thread referred to above discusses throttling, whereas the
"recommendation" provided to us by the auditors was user lockout
requiring administrator activity (human intervention) to unlock.

So the next question is whether the core dev team is interested in
discussing configurable lockout (number of attempts and human
intervention or timeout to release the lock), throttling, or both.
Then, how to best go about it.

Incidentally, I'll be at PyCon if anyone wants to get together after
hours to work on this during the main days (I won't be at the
sprints).

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: post messages to facebook wall

[Shawn Milochik]

I shouldn't have replied previously on this list. I didn't realize which list 
you'd e-mailed.

This list is ONLY for the developers of Django itself.

Please take your question to the django-users list:
http://groups.google.com/group/django-users?hl=en

Nobody will answer your question here.

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: post messages to facebook wall

[Shawn Milochik]

http://lmgtfy.com/?q=django+facebook+api



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Suggested Modification To HttpResponse (and therefore render_to_response)

[Shawn Milochik]

This probably should have been brought up in django-users first, asking if it's 
possible. 

See safestring.mark_safe():

http://docs.djangoproject.com/en/dev/ref/utils/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Problem with validating ModelForm

[Shawn Milochik]

Please post your question to the django-users mailing list. This list is for 
developers of Django itself.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Calling remote API

[Shawn Milochik]

Oops. Sorry for replying here. I didn't realize what list this was. 

Original poster: Please post to the django-users list. This one is for the 
development of Django itself, not users of Django

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Calling remote API

[Shawn Milochik]

What's wrong with urllib2.urlopen()?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.2 release candidate available

[Shawn Milochik]

> 
> You are however allowed to start earlier if you buy Russ and Karen a
> drink, they deserve thanks for all the hard work they've put in.
> 
> Alex

Where's the PayPal donation link for this?

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Low-Hanging Fruit

[Shawn Milochik]

Thanks, this advice is incredibly helpful, and your response is encouraging.

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

[Shawn Milochik]

I think that there is frustration on the part of the core dev team because 
people are (intentionally or not) demanding more and more of their time in the 
form of feature requests without understanding what the costs are and what 
resources exist.

There is frustration on the part of some Django users who would like to 
contribute but feel that anyone not in the core dev team is a third-class 
citizen with a tiny voice, and think that spending any time working on a ticket 
is slightly less likely to be worthwhile than writing an iPhone app and hoping 
Apple approves it for the App Store.

In my opinion, the problem lies not at either end, but in the middle. The way 
Trac is currently being used allows anyone at all to give tickets a status that 
the individual may not actually have the understanding to judge. To compensate 
for this, the core developers are each forced to rely on one another and their 
own small circle of lieutenants (as Linus does) to know whose code to actually 
take the time to evaluate. 

Ideally, people who want to contribute to Django should be able to adopt any 
open ticket in the bug tracker, work on it (with any necessary communication 
with this list), and see their work accepted if it's done well. At present this 
is not the case.

A potential solution is to treat bug tracker permissions a bit more like the 
"commit bit," where accepting bugs would be limited to people who understand 
both the process and the direction/vision of Django. This would cost time, but 
could alleviate the frustration on both sides and ultimately result in more 
work getting done, not least because more people would be encouraged to 
participate.

These are just my thoughts based mostly on the demoralizing thread Jacob is 
addressing with this one. I have also found it demoralizing, because it makes 
me feel like it's not worth aspiring to contribute to Django because there are 
too many obstacles. Some of Russell's comments do counter that sentiment, but 
it still seems like there is no way to have any confidence about what to work 
on without having the insight of a core developer. Again, this is all my 
opinion and I could be way off.

Shawn


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Low-Hanging Fruit

[Shawn Milochik]

Karen,

Thanks very much. I appreciate the response.

I'll have a look into this (not to discourage anyone else from trying to beat 
me to it), and post to this list if I can shed light on this issue.

Shawn


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Low-Hanging Fruit

[Shawn Milochik]

This is partially inspired by the thread that won't die: "High Level Discussion 
about the Future of Django."

I want to contribute something back to Django. Specifically, I've already paid 
for my hotel and flights for DjangoCon 2010 and I'm definitely going to stay 
for the sprints. However, since I've only worked with Django and never on 
Django, I'd like to have some level of familiarity before then. Preferably, I'd 
like to handle a few tickets, both familiarizing myself with the process and 
getting in-depth knowledge of the small slices of Django's internals required 
to do so. Otherwise I probably won't be much use at the sprints.

Since looking at a ticket in Trac doesn't indicate whether it passes the 
filters mentioned in Russell's talk (i.e. not good for Django's design, wrong 
direction) and I haven't been part of the Django community long enough to know 
intuitively, I'd just like a little head start on being able to contribute 
something of value to Django.

So, I'm asking for anyone in the core (or close to it) to specifically point 
out any low-hanging fruit. This may seem on the face of it to be asking for 
others to waste time they could be spending supporting proven, trusted Django 
contributors. However, I think it's not, because I'm asking someone who already 
knows what's coming up in the queue to take a minute or two to say, off of the 
top of their head, "These specific tickets are worth working on." In the long 
run, this will actually benefit the core because (at least) one more developer 
will be contributing to Django.

Given the current state of the work on 1.2, this can easily wait for 1.2 to be 
released. 

Thanks,
Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.