Django participation in Google Summer of Code 2012

[Kushagra Sinha]

Are there plans for Django participating in this year's Google Summer of Code. The organization application deadline is on 9th March. I would love to participate as a student.

Thanks

--
Kushagra SInha

[Russell Keith-Magee]

On 07/03/2012, at 5:35 AM, Kushagra Sinha wrote:

> Are there plans for Django participating in this year's Google Summer of Code. The organization application deadline is on 9th March. I would love to participate as a student.
>

Yes, we are planning to apply as an organization.

If you're interested in doing a Django-based project, it's never too early to start working on your proposal; historically, the applicants that have been the most successful have started on their proposal (and their projects) long before the "official" application period. Obviously, we haven't got our 2012 SOC page up yet, but last year's page [1] will give you a few ideas -- especially if you focus on projects that haven't been completed, or were started on last year but still need some work to bring them to completion.

[1] https://code.djangoproject.com/wiki/SummerOfCode2011

Yours,
Russ Magee %-)

[Kushagra Sinha]

Thanks a lot for the reply.

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

--
Kushagra SInha

B. Tech. Part III (Pre-final year)

Indian Institute of Technology

Varanasi

Contact: +91 9415 125 215

[Russell Keith-Magee]

One quick update -- Django's 2012 GSoC wiki page is now up, at the somewhat predictable URL:

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

Yours,
Russ Magee %-)

[Vladimir Perić]

Hi,

On Mar 7, 10:08 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

> One quick update -- Django's 2012 GSoC wiki page is now up, at the somewhat predictable URL:
>
> https://code.djangoproject.com/wiki/SummerOfCode2012

I was also considering applying for as a GSoC student to Django this
summer, but I see that the "Python 3 porting" project has been removed
from the new list. Is there a reason for this? I'm really interested
in this project and Django does not yet support Python 3 (at least 1.4
doesn't). It's a bit hard to find information about the current state
of support, as there have been many efforts over the years, but as far
as I gather, the latest work was mentioned in this thread [1].

Last year, as a GSoC student I worked on porting SymPy [2] to Python
3, which I completed successfully (though there hasn't yet been a
release with Python 3 support); you can read my blog about it here[3].
As such, I feel I have sufficient experience to do the same with
Django -- SymPy is a similarly sized project, using many of the more
advanced Python constructs. If someone could confirm that porting to
python 3 is a possible project for this year, I will write a more
detailed introductory post about my experiences and ideas.

Thank you,

[1] http://groups.google.com/group/django-developers/browse_thread/thread/abede3685ad0302/573c1e0ff35e1ab7
[2] SymPy is a library for symbolic mathematics written in Python:
http://sympy.org/en/index.html
[3] http://vperic.blogspot.com/

>
> Yours,
> Russ Magee %-)
>
> On 07/03/2012, at 5:03 PM, Kushagra Sinha wrote:
>
> > Thanks a lot for the reply.
>

> > On Wed, Mar 7, 2012 at 5:02 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote:
>
> > On 07/03/2012, at 5:35 AM, Kushagra Sinha wrote:
>
> > > Are there plans for Django participating in this year's Google Summer of Code. The organization application deadline is on 9th March. I would love to participate as a student.
>
> > Yes, we are planning to apply as an organization.
>
> > If you're interested in doing a Django-based project, it's never too early to start working on your proposal; historically, the applicants that have been the most successful have started on their proposal (and their projects) long before the "official" application period. Obviously, we haven't got our 2012 SOC page up yet, but last year's page [1] will give you a few ideas -- especially if you focus on projects that haven't been completed, or were started on last year but still need some work to bring them to completion.
>
> > [1]https://code.djangoproject.com/wiki/SummerOfCode2011
>
> > Yours,
> > Russ Magee %-)
>
> > --
> > You received this message because you are subscribed to the Google Groups "Django developers" group.
> > To post to this group, send email to django-d...@googlegroups.com.
> > To unsubscribe from this group, send email to django-develop...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

[Florian Apolloner]

Hi,

Am Donnerstag, 8. März 2012 15:51:58 UTC+1 schrieb Vladimir Perić:

I was also considering applying for as a GSoC student to Django this
summer, but I see that the "Python 3 porting" project has been removed
from the new list. Is there a reason for this?

Django already has a working py 3 port, although I am not sure how much work is left, but the tests pass to my knowledge. You can search the ml about py 3, that should give you an overview.

cheers,
florian

[Joe & Anne Tennies]

There's a branch... somewhere (bitbucket or github I believe) that supports both 2.x and 3.x. It's mostly done at this point. It got done just before the 1.4 lockdown, but it was too much risk to take on that late in the release cycle. It does pass most of the tests at this point (I believe all that 2.x did).

I have no control over the release cycle, but I'd assume it's quite likely 1.5/2.0 will be 3.x compatible as well, unless a showstopper is found.

Joe & Anne Tennies
ten...@gmail.com

[Karen Tracey]

On Thu, Mar 8, 2012 at 10:29 AM, Joe & Anne Tennies <ten...@gmail.com> wrote:
> [snipped] It's mostly done at this point. It got done just before

> the 1.4 lockdown, but it was too much risk to take on that late in the
> release cycle.

Also it's more cleanly done if we can drop support for Python 2.5,
which argued for targeting Django 1.5 (and dropping Python 2.5 support
in that release).

Karen

[Aymeric Augustin]

PEP 414 was accepted a few days ago. It's designed to make it easier to support 2.6, 2.7, 3.3+ on the same codebase.

I hope we'll take advantage of this new feature in Django; however, that means a large update (if not a reboot) of the py3k branch.

--
Aymeric.

[Łukasz Rekucki]

On 8 March 2012 16:43, Aymeric Augustin

Why would you want to do that, when the py3k is already working with
unicode_literals ? That's a step backwards.

--
Łukasz Rekucki

[Carl Meyer]

I agree with Łukasz; I support PEP 414 in general, but I'm not at all
convinced that it makes sense to use it for Django's port, given that we
already have a working port using the unicode_literals approach.

Carl

[Ian Clelland]

On Thursday, March 8, 2012, Aymeric Augustin <aymeric....@polytechnique.org> wrote:
> PEP 414 was accepted a few days ago. It's designed to make it easier to support 2.6, 2.7, 3.3+ on the same codebase.

(finishes reading)
Ugh. I'm starting to expect "PEP 499: In a last-ditch effort to encourage developers to adopt Python 3, it is declared that Python 3.9 will be exactly identical, in syntax and semantics, to Python 2.6.7"

> I hope we'll take advantage of this new feature in Django; however, that means a large update (if not a reboot) of the py3k branch.

Sarcasm aside, the only thing that this PEP does is force us to consider the minimum "starting version" of Python 3 that we want to support. If we declare that Django 1.5 will run on Python 3.2+, then we can ignore this PEP, and continue to use the u() and b() functions in the py3k branch, until 3.2 support is one day deprecated.

On the other hand, if we can say that Django 1.5 will only support Python 3.3+, then there will never be a version of Django that needs to run on 3.2, and we can remove those functions from the py3k branch. Not really a reboot, just one transformation that can now be removed. (probably giving us a few % speed improvement)

I don't think we should base the decision on this PEP, though. More important factors are probably the release schedule for 3.3 (August?) and how that meshes with the 1.5 development cycle, as well as vendor support for, and availability of, Python 3.3. Right now, there are a lot of people with access to long-term vendor-supported Python 3 environments, but nobody has 3.3. If we say that you can't upgrade to Python 3 until you can get a full 3.3 environment, how will that affect the usefulness of support in Django 1.5?

Ian 

[Carl Meyer]

Hi Ian,

On 03/08/2012 08:40 AM, Ian Clelland wrote:
> On Thursday, March 8, 2012, Aymeric Augustin
> <aymeric....@polytechnique.org

> <mailto:aymeric....@polytechnique.org>> wrote:
>> PEP 414 was accepted a few days ago. It's designed to make it easier
> to support 2.6, 2.7, 3.3+ on the same codebase.
>
> (finishes reading)
> Ugh. I'm starting to expect "PEP 499: In a last-ditch effort to
> encourage developers to adopt Python 3, it is declared that Python 3.9
> will be exactly identical, in syntax and semantics, to Python 2.6.7"

Let's please not rehash this discussion here, it was already beaten to
death on the python-dev mailing list.

>> I hope we'll take advantage of this new feature in Django; however,
> that means a large update (if not a reboot) of the py3k branch.
>
> Sarcasm aside, the only thing that this PEP does is force us to consider
> the minimum "starting version" of Python 3 that we want to support. If
> we declare that Django 1.5 will run on Python 3.2+, then we can ignore
> this PEP, and continue to use the u() and b() functions in the py3k
> branch, until 3.2 support is one day deprecated.

Note that the current version of Vinay's port (since it was updated to
account for dropping Python 2.5 support post-1.4) does not use u() and
b() functions, it uses "from __future__ import unicode_literals". This
means that the only place string wrappers are needed is in the few
places where a "native string" is needed ("str" on both Python 2 and 3).
Vinay posted numbers to python-dev indicating that there is no
measurable performance overhead in the current port.

> On the other hand, if we can say that Django 1.5 will only support
> Python 3.3+, then there will never be a version of Django that needs to
> run on 3.2, and we can remove those functions from the py3k branch. Not
> really a reboot, just one transformation that can now be removed.
> (probably giving us a few % speed improvement)
>
> I don't think we should base the decision on this PEP, though. More
> important factors are probably the release schedule for 3.3 (August?)
> and how that meshes with the 1.5 development cycle, as well as vendor
> support for, and availability of, Python 3.3. Right now, there are a lot
> of people with access to long-term vendor-supported Python 3
> environments, but nobody has 3.3. If we say that you can't upgrade to
> Python 3 until you can get a full 3.3 environment, how will that affect
> the usefulness of support in Django 1.5?

I think the fact that the next Ubuntu LTS will include Python 3.2, and
it won't be possible to make use of PEP 314 on Python 3.2 without
install-time-transformation hacks, is a strong argument in favor of
sticking with a working unicode_literals port rather than reworking it
to use PEP 314.

Carl

[Aymeric Augustin]

2012/3/8 Carl Meyer <ca...@oddbird.net>

Note that the current version of Vinay's port (since it was updated to
account for dropping Python 2.5 support post-1.4) does not use u() and
b() functions, it uses "from __future__ import unicode_literals". This
means that the only place string wrappers are needed is in the few
places where a "native string" is needed ("str" on both Python 2 and 3).

I had missed that. Sorry, please disregard my previous message.

--
Aymeric.

[Ian Clelland]

On Thu, Mar 8, 2012 at 8:48 AM, Carl Meyer <ca...@oddbird.net> wrote:

Hi Ian,

On 03/08/2012 08:40 AM, Ian Clelland wrote:
> On Thursday, March 8, 2012, Aymeric Augustin
> <aymeric....@polytechnique.org

> <mailto:aymeric....@polytechnique.org>> wrote:
>> PEP 414 was accepted a few days ago. It's designed to make it easier
> to support 2.6, 2.7, 3.3+ on the same codebase.
>
> (finishes reading)
> Ugh. I'm starting to expect "PEP 499: In a last-ditch effort to
> encourage developers to adopt Python 3, it is declared that Python 3.9
> will be exactly identical, in syntax and semantics, to Python 2.6.7"

Let's please not rehash this discussion here, it was already beaten to
death on the python-dev mailing list.

 

I have no doubt that it was; I'm afraid I haven't been following that list very closely recently.

(And you're right, it's way-OT for django-dev)

 

>> I hope we'll take advantage of this new feature in Django; however,
> that means a large update (if not a reboot) of the py3k branch.
>
> Sarcasm aside, the only thing that this PEP does is force us to consider
> the minimum "starting version" of Python 3 that we want to support. If
> we declare that Django 1.5 will run on Python 3.2+, then we can ignore
> this PEP, and continue to use the u() and b() functions in the py3k
> branch, until 3.2 support is one day deprecated.

Note that the current version of Vinay's port (since it was updated to
account for dropping Python 2.5 support post-1.4) does not use u() and
b() functions, it uses "from __future__ import unicode_literals". This
means that the only place string wrappers are needed is in the few
places where a "native string" is needed ("str" on both Python 2 and 3).
Vinay posted numbers to python-dev indicating that there is no
measurable performance overhead in the current port.

That's great -- That was from the post that came in over the holidays; I'll definitely have to get back on testing that.

--
Regards,
Ian Clelland
<clel...@gmail.com>