Kevin
---------- Forwarded message ----------
From: Ian Bicking <ia...@colorstudy.com>
Date: Apr 17, 2006 11:39 AM
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
To: web...@python.org
Hi guys... looks like Google SoC is back on again. I'm hoping we get
some good web stuff going on, so people should start thinking. Also
there's two wiki pages where you can add project ideas:
http://wiki.python.org/moin/SummerOfCode and the somewhat out-of-date
(and needs cleaning) page from last year:
http://wiki.python.org/moin/CodingProjectIdeas
-------- Original Message --------
Subject: [Python-3000] Summer of Code preparation
Date: Mon, 17 Apr 2006 00:43:33 -0700
From: Neal Norwitz <nnor...@gmail.com>
We've only got a short time to get setup for Google's Summer of Code.
We need to start identifying mentors and collecting ideas for students
to implement. We have the SimpleTodo list
(http://wiki.python.org/moin/SimpleTodo), but nothing on the SoC page
yet (http://wiki.python.org/moin/SummerOfCode).
I can help manage the process from inside Google, but I need help
gathering mentors and ideas. I'm not certain of the process, but if
you are interested in being a mentor, send me an email. I will try to
find all the necessary info and post here again tomorrow. Pass the
word! I hope all mentors from last year will return again this year.
Can someone take ownership of drumming up mentors and ideas? We also
need to spread the word to c.l.p and beyond.
Thanks,
n
_______________________________________________
Web-SIG mailing list
Web...@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/dangoor%40gmail.com
--
Kevin Dangoor
TurboGears / Zesty News
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
You don't want my mentoring!
Mine either, but it would be nice to see some turbogears related stuff
happen. Some of the ideas I have had:
* Google/Yahoo/Whatever widget library: Would be nice to be able to
supply a widget with the appropriate account information and have
support for maps/adsense/whatever integration from inside turbogears.
At the upper limit of the idea it would essentially be "from mashup
import *".
* SQLObject schema interpreter: Reads pre-existing tables and generates
SQLObject classes based on their contents. Probably not possible to
make it 100% accurate, but it would be a nice headstart.
* Database schema versioning: Similar to Ruby on Rails migrate system.
Basically allow for alterations to be made to an existing database
according to migrate rules. This obviously would require that SQLObject
be capable of altering existing tables. (Is it? Has it always been able
to? I don't know)
* TurboGears documentation: Mwuhahaha mwuhahahaha the perfect inter^W
student project. Seriously though it could be a decent project if it
involved development work on Docudo.
Anyone else have ideas? Who wants to badger Kevin into seeing if he
will find/be a mentor for this?
How about creating a specification similar to our template protocol for
widgets and separate them from TG core. This would be beneficial to the
whole Python web community (and a step closer to a franken-framework
that not just kicks but pulverises ass ;)).
Cheers,
Simon
FWIW, I would be happy to mentor someone in an effort to make
SQLAlchemy support a reality in TurboGears. This would include:
finishing up ActiveMapper, improved support in TurboGears (widgets,
catwalk, etc), and potentially an SQLObject compatibility layer or
model converter utility.
Anyone else think that this is a good idea? Anyone else interested
in helping mentor such a thing?
--
Jonathan LaCour
http://cleverdevil.org
+1
I am also willing to (help) mentor TG-related projects.
Cheers,
Simon
Neat idea, and probably very simple. Stay tuned for my next screencast
(I know I've been promising this for a while, but things are finally
coming together. I was having some awful computer problems last week.)
> * SQLObject schema interpreter: Reads pre-existing tables and generates
> SQLObject classes based on their contents. Probably not possible to
> make it 100% accurate, but it would be a nice headstart.
Actually, SQLObject already has the fromDatabase option, which is
essentially the same thing.
> * Database schema versioning: Similar to Ruby on Rails migrate system.
> Basically allow for alterations to be made to an existing database
> according to migrate rules. This obviously would require that SQLObject
> be capable of altering existing tables. (Is it? Has it always been able
> to? I don't know)
I'd be more interested in seeing work on such a thing done for SQLAlchemy.
> * TurboGears documentation: Mwuhahaha mwuhahahaha the perfect inter^W
> student project. Seriously though it could be a decent project if it
> involved development work on Docudo.
I'm not sure what types of project Google goes for. We could certainly
have our own unpaid Summer of Code if there are willing students and
mentors!
Kevin
This would be very cool. I'd certainly provide some advice along the
way, but I don't have time for much more at the moment.
Kevin
I do think this would be good as well.
Kevin
I think this one would be pretty cool too, except I think what he's
talking about here is that *actual* code will be generated and put into
a .py file or to stdout. That way, it would be easy to incorporate
existing table designs into sqlobject and then tweak them by hand.
Also, although I haven't tried, I doubt it's smart enough to traverse
foreign keys and realize there are many-to-many or one-to-many
relationships.
The migration idea sounds really good too, I can't think of how many
times I had to add one or more columns.. haven't seen a better way then
doing a manual ALTER TABLE.
By the way, when you guys say "you wouldn't want me mentoring you," are
you just trying to do reverse psychology?
While on the topic of sqlobject, I wouldn't mind seeing a solution that
literally compiled python code into pl/python (for those dbs that
support it) or SQL queries, so that
[i for i in Model.select() if i.name = "Joe"] would translate to SELECT
* from model WHERE name = "Joe" instead of doing the whole select query
and filtering name out in python.
More data types would be useful too, Array comes to mind (its been ansi
for a while), perhaps other ones such as IP..
It could move towards having more ansi support in general, schemas
wouldn't hurt, perhaps (and they could be "prefixes" in non-schema
supporting dbs)
class MySchema(SQLObjectSchema):
class MyModel(SQLObject):
foo = ArrayCol()
addr = IPCol()
Yeah, there's lots of ways to improve SQLObject :).
Speaking of widgets, it also wouldn't hurt to generate KID-html from a
widget so you can do tweaking by hand. I think that would be very cool,
it takes almost no time to use a widget, but if you want something
custom you have to do it from the ground up -- so why not combine the
two?
For those thinking about how SQLObject can be better, I'd recommend
taking a look at SQLAlchemy and stretching where things can go *from
there*. SQLAlchemy needs:
1) an SQLObject compatibility layer
2) a layer that is as easy as SQLObject for the easy stuff
(ActiveMapper is almost there)
3) schema migration tools
It already takes care of some of the things that people want SQLObject to do.
> Speaking of widgets, it also wouldn't hurt to generate KID-html from a
> widget so you can do tweaking by hand. I think that would be very cool,
> it takes almost no time to use a widget, but if you want something
> custom you have to do it from the ground up -- so why not combine the
> two?
This was actually part of the original concept. I had imagined
something in the toolbox that would let you hand it a form definition
and get back the necessary Kid to drop into a template for full
tweaking. You can certainly edit the template for individual widgets,
but this route is more designer friendly because they have access to
the whole page.
(At a minimum, the Widget Browser should show you the template source
so that you can copy that into your code for modification).
Back on the subject of Summer of Code: there are some good ideas out
there. I would encourage people to specifically state "I'd like to be
a student participant" or "I'd like to be a mentor" and the types of
things you'd like to work on. If we can get the right people matched
up, we'll see if we can run everything through the PSF's sponsorship
in the Summer of Code.
Kevin
That's good, are we moving towards integrating SQLAlchemy with
TurboGears now? I remember a few months back it was just a completely
disjoint project. Is there some kind of support now, or is it still
"use with TG at your own risk?" I haven't tried SQLAlchemy, but it
seemed really powerful for what it does.
Though, I would still like to compile python into pl/python because it
means far less typing for the programmer ;).
> Back on the subject of Summer of Code: there are some good ideas out
> there. I would encourage people to specifically state "I'd like to be
> a student participant" or "I'd like to be a mentor" and the types of
> things you'd like to work on. If we can get the right people matched
> up, we'll see if we can run everything through the PSF's sponsorship
> in the Summer of Code.
I would like to be a participant! Who's interested? :-)
I'd like to be a student participant too. If I remember correctly from
last year, the PSF has a certain number of spots allocated, then
distributes those spots to the approved mentors, is that right?
It seems the deadline is very short for mentor signups this year (next
Monday?)
http://tinyurl.com/zcoby
I hope a lot of TG mentors have signed up :]
Steve
I hear that, but I'm not eligible :'( I skipped the Uni route and went straight in to work as a
software developer. I'm learning and expanding at a faster rate than any of my old school chums who
went to do CompSci, but I can't apply for SoC or an internship at Fog Creek :'(
I feel discriminated against :( And worse, it's the only reason I have to feel envious of my
(incredibly skint) Uni-going friends, and they're not even *considering* SoC!
Hm... I'll probably cheer up when I drive to work in my new peugeot tomorrow morning.
-Rob
I'm not sure what exactly the PSF has been given, but there are
certainly limits. Google *only* has 8 or 9 billion in cash.
> It seems the deadline is very short for mentor signups this year (next
> Monday?)
> http://tinyurl.com/zcoby
That's actually a deadline they've set for mentoring *organizations*,
not mentors. The PSF is all set already. I do think that we should
organize our mentors/students as quickly as possible to ensure that
the PSF's allotment doesn't get fully used up.
Kevin
SQLObject remains the current standard, but TurboGears supports
SQLAlchemy today and is heading in that direction. There are enough
people who have had use cases that SQLAlchemy fits better.
> > Back on the subject of Summer of Code: there are some good ideas out
> > there. I would encourage people to specifically state "I'd like to be
> > a student participant" or "I'd like to be a mentor" and the types of
> > things you'd like to work on. If we can get the right people matched
> > up, we'll see if we can run everything through the PSF's sponsorship
> > in the Summer of Code.
>
> I would like to be a participant! Who's interested? :-)
I believe Simon and Jonathan both mentioned an interest in mentoring,
and there may be one or two others. I don't know how many we might be
given, but we should see what we can get.
Kevin
On 4/20/06, Igor Murashkin <down...@gmail.com> wrote:
> That's good, are we moving towards integrating SQLAlchemy with
> TurboGears now? I remember a few months back it was just a completely
> disjoint project. Is there some kind of support now, or is it still
> "use with TG at your own risk?" I haven't tried SQLAlchemy, but it
> seemed really powerful for what it does.
SQLObject remains the current standard, but TurboGears supports
SQLAlchemy today and is heading in that direction. There are enough
people who have had use cases that SQLAlchemy fits better.
> > Back on the subject of Summer of Code: there are some good ideas out
> > there. I would encourage people to specifically state "I'd like to be
> > a student participant" or "I'd like to be a mentor" and the types of
> > things you'd like to work on. If we can get the right people matched
> > up, we'll see if we can run everything through the PSF's sponsorship
> > in the Summer of Code.
>
> I would like to be a participant! Who's interested? :-)
I believe Simon and Jonathan both mentioned an interest in mentoring,
and there may be one or two others. I don't know how many we might be
given, but we should see what we can get.
Kevin
I'd like to be a student participant. I see two possible ways where I
could work: either with widgets (adding them from 3rd party or
implementing from scratch) or SQL stuff. I think SQL stuff would be
more practical for me because it can be used even outside TurboGears.
Best regards,
Dalius
Thanks,
Igor
Participants can't sign up until May 1, anyhow. Hopefully by then,
I'll have a better handle on whether we've got mentors and slots from
the PSF.
Kevin