On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers wrote:

On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers wrote:

...

Hi all,

It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html.

We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor.

We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful.

So far we've only got one primary mentor (thanks Chuck!), most core devs do not seem to have the bandwidth this year. If there are other people interested in mentoring please let me know. If not, then it looks like we're not participating this year.

Hi all, an update on GSoC'13. We do have enough mentoring power after all; NumPy/SciPy is now registered as a participating project on the PSF page: http://wiki.python.org/moin/SummerOfCode/2013 Prospective students: please have a look at http://wiki.python.org/moin/SummerOfCode/Expectations and at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular note that we require you to make one pull request to NumPy/SciPy which has to be merged *before* the application deadline (May 3). So please start thinking about that, and start a discussion on your project idea on this list. Cheers, Ralf

On Mon, Apr 1, 2013 at 2:27 PM, Todd wrote:

On Mon, Apr 1, 2013 at 1:58 PM, Ralf Gommers wrote:

...

On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers wrote:

...

On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers wrote:

...

Hi all,

It is the time of the year for Google Summer of Code applications. If we want to participate with Numpy and/or Scipy, we need two things: enough mentors and ideas for projects. If we get those, we'll apply under the PSF umbrella. They've outlined the timeline they're working by and guidelines at http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html.

We should be able to come up with some interesting project ideas I'd think, let's put those at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with enough detail to be understandable for people new to the projects and a proposed mentor.

We need at least 3 people willing to mentor a student. Ideally we'd have enough mentors this week, so we can apply to the PSF on time. If you're willing to be a mentor, please send me the following: name, email address, phone nr, and what you're interested in mentoring. If you have time constaints and have doubts about being able to be a primary mentor, being a backup mentor would also be helpful.

So far we've only got one primary mentor (thanks Chuck!), most core devs do not seem to have the bandwidth this year. If there are other people interested in mentoring please let me know. If not, then it looks like we're not participating this year.

Hi all, an update on GSoC'13. We do have enough mentoring power after all; NumPy/SciPy is now registered as a participating project on the PSF page: http://wiki.python.org/moin/SummerOfCode/2013

Prospective students: please have a look at http://wiki.python.org/moin/SummerOfCode/Expectations and at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular note that we require you to make one pull request to NumPy/SciPy which has to be merged *before* the application deadline (May 3). So please start thinking about that, and start a discussion on your project idea on this list.

Cheers, Ralf

_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev

There were a number of other ideas in this thread:

http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html

Thanks Todd. Your idea 5 is pretty much what Nathaniel just detailed out, it's on the ideas page now. That should enable idea 1 as well. The other idea that got some positive feedback was 3: http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065710.html. If you or someone else could make that a little more concrete, we can put that up. Ralf

On Tue, Apr 2, 2013 at 8:10 PM, Todd wrote:

On Tue, Apr 2, 2013 at 8:12 PM, Ralf Gommers wrote:

...

On Mon, Apr 1, 2013 at 2:27 PM, Todd wrote:

...

There were a number of other ideas in this thread:

http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html

Thanks Todd. Your idea 5 is pretty much what Nathaniel just detailed out, it's on the ideas page now. That should enable idea 1 as well. The other idea that got some positive feedback was 3: http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065710.html. If you or someone else could make that a little more concrete, we can put that up.

For 3:

With structured arrays, you can access them by name (key) in a manner identical to dictionaries:

y = x['f']

It also has a method for accessing the list of names (keys):

x.dtype.names

This should be maintained for backwards-compatibility, but these methods should also be added:

x.keys -- returns a list of field names x.values -- returns a list of views into the array, one for each structure x.items -- returns a list of tuple containing name/structure pairs (the structures being a views) x.iterkeys/itervalues/iteritems -- returns an iterable over the corresponding objects (should not be available in python 3) x.viewkeys/viewvalues/viewitems -- the same as the corresponding item, since they always return views (should not be available in python 3) x.has_key -- tests if a field name is present (should not be available in python 3, should use "key in x.keys()") x.get -- get a field by name, returning a default array (an empty array by default) if not present x.update -- copy values into the matching key from another structured array, a dict, or list of key/value tuples. Unlike dicts this will only work for keys that are already present.

Documentation should probably be updated to have these as the default ways of interacting with structured arrays, with the old methods deprecated. "Names" should also probably be renamed "keys" for compatibility with dicts.

I'm concerned that this will be 1 week of coding + 2 months of arguing over whether it's actually a good idea to add all these methods to every ndarray, whether it makes sense to have "views" for ndarrays, what should be done with "in", can/should we really rename "names", etc. Maybe I'm just pessimistic, but it isn't as much a slam-dunk obviously-the-right-thing improvement as some things. (Also I have no idea what the other comment about compact dicts that Ralf referred to above meant.) Handling such debates is a super-important part of OSS coding, but probably the worst thing to put on the critical path of a GSoC project. (Actually I guess I may be guilty of this myself, if anyone is worried about that dtype proposal speak up now... I think it can be done without serious compatibility breaks.) -n