PyCon 2013 is current accepting proposals. I'm looking forward to helping review the proposals.
So, what proposals would *I* like to see?
Anything science related, especially bio and chemistry and neuroscience stuff
Anything health related
Anything homestead related - how do you use Python in your home, your garden, your office, your private hobby, knitting, weaving, ...
How Python is being/or could be used in the office and support areas (HR, Marketing, Admin Assistants, Finance)
Anything with robots
Anything about Making stuff
Anything about GAE
Hacking your fitness with Python
Accessibility how-tos
HCI
Here's where to submit your proposal
I'm planning on proposing a talk on "Hello GAE" - an overview for folks who haven't used it before. Also a "You can be a speaker at PyCon!" session for folks who are considering being a speaker in 2014 but don't know how to start.
I know there will be plenty of my favorite speakers at PyCon - we're starting to get proposals from some of you already. I'm especially interested in getting proposals from a wide variety of new folks. Entrepreneurs, web designers, interaction designers, chemists, rocket scientists, secretaries, WHO (you know who you are!), fitness geeks, women, people of color, neuroscientists, and anybody else I've never heard speak at PyCon before.
Showing posts with label python. Show all posts
Showing posts with label python. Show all posts
Thursday, August 23, 2012
Friday, March 4, 2011
We want you!
to volunteer at PyCon!
Come meet the speakers and chair a session, or be a runner!
Sign up at http://us.pycon.org/2011/schedule/sessions/
Other volunteer opportunities remain - Sign up at http://us.pycon.org/2011/volunteer/onsite/ to help out.
If you're attending PyCon, please volunteer. Remember, PyCon is a volunteer-run, community-based conference. That means you!
Come meet the speakers and chair a session, or be a runner!
Sign up at http://us.pycon.org/2011/schedule/sessions/
Other volunteer opportunities remain - Sign up at http://us.pycon.org/2011/volunteer/onsite/ to help out.
If you're attending PyCon, please volunteer. Remember, PyCon is a volunteer-run, community-based conference. That means you!
Saturday, December 11, 2010
Consider the tuple...
I remember learning Python and wondering what a tuple was for. Why wouldn't you just use a list? Or a dict?
What I've come down to is a few thoughts such as:
1) if I want sortable items, use a list. (list.sort in Python is way fast!)
2) if I want to use an item as a key and find the related info (value), put the key/value pair into a dict.
3) if I want to have possibly-heterogenous-but-related items in a specific unchangeable order, consider a tuple.
Tuples can often be overlooked as a data structure in Python - but can be really useful for things like x,y coordinates or GPS coordinates or timestamps or addresses. It's important to have them in order - you don't want to mix up the x and the y, or the hour and the minutes. You can't do much *to* tuples, they have no methods and are immutable(unchangeable), although you can search in them with in. If you have a tuple that needs something changed, you'll just have to replace it with a new tuple.
Of course, a kewl thing in Python is that you can mix and match. You can have a list of tuples. Or a dict of tuples. Tuples are really useful as keys in a dict, because they're immutable, unlike lists. So, for example, you could have a dict, with keys that are tuple of gps coordinates, and values of a place name at that location, or a house price at a particular address, or you can use "in" to find all the keys that have, say, Sunnyvale, as the name of the city, and find out some value related to Sunnyvale.
Lists and dicts get all the press in Python, because they're really useful and fast. But tuples are pretty awesome in their own way...
EDIT to add examples:
In a list mylist = [2,1], if you call mylist.sort() you get [1,2]. If 2,1 is a coordinate point, then sorting it to 1,2 is a REALLY BAD THING and could lead to really bad bugs.
OTOH: mytuple = 1,2 and you call mytuple.sort(), you get an error because (1,2) is not sortable. This is a GOOD THING, leading it to be usable as a hash (key) in a dict, and for identifying specific things.
A list has no business being coerced to a tuple in order to act as a key in a dict. I think that's an abuse of list. You'd be better off thinking of tuples as a record in a database. "213 1st Street" means nothing when sorted in a list ['1st', '213','Street'), but means everything when left as a tuple ('213', '1st', 'Street') as it should be. Tuples are great for data - when the position *means* something, not just an "ordering". People ask, "why don't you just have named field". A phone number doesn't really need named fields for the 800 to mean something and for it to be important that it not have its order rearranged. Take the following two tuples: (408,555,1212) and (555,408,1212). If you treat them just as lists, you could end up sorting them and they'd be "identical". But they're not identical - they're phone numbers for completely different parts of the country and the structure is meaningful. Which means, tuples would be appropriate here, and that structure is what makes them good as keys.
What I've come down to is a few thoughts such as:
1) if I want sortable items, use a list. (list.sort in Python is way fast!)
2) if I want to use an item as a key and find the related info (value), put the key/value pair into a dict.
3) if I want to have possibly-heterogenous-but-related items in a specific unchangeable order, consider a tuple.
Tuples can often be overlooked as a data structure in Python - but can be really useful for things like x,y coordinates or GPS coordinates or timestamps or addresses. It's important to have them in order - you don't want to mix up the x and the y, or the hour and the minutes. You can't do much *to* tuples, they have no methods and are immutable(unchangeable), although you can search in them with in. If you have a tuple that needs something changed, you'll just have to replace it with a new tuple.
Of course, a kewl thing in Python is that you can mix and match. You can have a list of tuples. Or a dict of tuples. Tuples are really useful as keys in a dict, because they're immutable, unlike lists. So, for example, you could have a dict, with keys that are tuple of gps coordinates, and values of a place name at that location, or a house price at a particular address, or you can use "in" to find all the keys that have, say, Sunnyvale, as the name of the city, and find out some value related to Sunnyvale.
Lists and dicts get all the press in Python, because they're really useful and fast. But tuples are pretty awesome in their own way...
EDIT to add examples:
In a list mylist = [2,1], if you call mylist.sort() you get [1,2]. If 2,1 is a coordinate point, then sorting it to 1,2 is a REALLY BAD THING and could lead to really bad bugs.
OTOH: mytuple = 1,2 and you call mytuple.sort(), you get an error because (1,2) is not sortable. This is a GOOD THING, leading it to be usable as a hash (key) in a dict, and for identifying specific things.
A list has no business being coerced to a tuple in order to act as a key in a dict. I think that's an abuse of list. You'd be better off thinking of tuples as a record in a database. "213 1st Street" means nothing when sorted in a list ['1st', '213','Street'), but means everything when left as a tuple ('213', '1st', 'Street') as it should be. Tuples are great for data - when the position *means* something, not just an "ordering". People ask, "why don't you just have named field". A phone number doesn't really need named fields for the 800 to mean something and for it to be important that it not have its order rearranged. Take the following two tuples: (408,555,1212) and (555,408,1212). If you treat them just as lists, you could end up sorting them and they'd be "identical". But they're not identical - they're phone numbers for completely different parts of the country and the structure is meaningful. Which means, tuples would be appropriate here, and that structure is what makes them good as keys.
Tuesday, September 29, 2009
Why women don't talk enough
So, the call for proposals for PyCon is out and has been out for some time. It's been circulated around. I've personally sent it to a number of women's lists I'm on. So, why don't I see any proposals from women yet? (Besides mine...)
Some reasons I've heard when I've asked women friends over the years about why they haven't proposed a talk:
a. I don't have time
None of us have enough time. I know we women have a lot of "extras" that we do every day and hobbies tend to fall by the wayside. I'm a full-time student at Stanford, with a husband, a house, 2 cats, and a teenager who doesn't want to do his homework. If I can submit a proposal, so can you.
b. I don't know enough
No one knows everything. And if you're closer to the n00b level, you'll understand what a n00b needs to hear better than an expert. Which brings us to:
c. There are experts/package creators there
Even if the creator is there, they may not be speaking, or they may be so deep into the package that they have no idea what real users of the package actually have trouble with and need to know. You do. So tell the rest of us about it. It's okay to have talks about the same package at two different levels!
d. I only use Python for this limited weird niche:
There are a lot of people interested in how to use Python for niches, and the more niches that presenters explore, the more the rest of us learn about the rich breadth of our favorite language.
e. I'm scared to speak in public:
PyCon is one of the friendliest, most tolerant conferences out there. We're all just a bunch of fellow enthusiasts: you're speaking to friends. So get out there and teach us all about something Pythonic that you love. Trust me, before I speak, not only do my knees shake, my *cheeks* shake! (It's hard to speak when your cheeks are shaking - try it sometime. ;-) But people at Pycon are ON YOUR SIDE - they *WANT* you to succeed. So, it's okay if you're a little shaky at the beginning. They'll be polite and listen anyways, because they want to hear about what you're presenting on. And once you've started, you'll be okay. Trust me on this.
So women of Python - please submit your proposals. Don't let the guys have all the fun and glory. I want to see *you* on stage at PyCon!
http://us.pycon.org/2010/conference/proposals/
Some reasons I've heard when I've asked women friends over the years about why they haven't proposed a talk:
a. I don't have time
None of us have enough time. I know we women have a lot of "extras" that we do every day and hobbies tend to fall by the wayside. I'm a full-time student at Stanford, with a husband, a house, 2 cats, and a teenager who doesn't want to do his homework. If I can submit a proposal, so can you.
b. I don't know enough
No one knows everything. And if you're closer to the n00b level, you'll understand what a n00b needs to hear better than an expert. Which brings us to:
c. There are experts/package creators there
Even if the creator is there, they may not be speaking, or they may be so deep into the package that they have no idea what real users of the package actually have trouble with and need to know. You do. So tell the rest of us about it. It's okay to have talks about the same package at two different levels!
d. I only use Python for this limited weird niche:
There are a lot of people interested in how to use Python for niches, and the more niches that presenters explore, the more the rest of us learn about the rich breadth of our favorite language.
e. I'm scared to speak in public:
PyCon is one of the friendliest, most tolerant conferences out there. We're all just a bunch of fellow enthusiasts: you're speaking to friends. So get out there and teach us all about something Pythonic that you love. Trust me, before I speak, not only do my knees shake, my *cheeks* shake! (It's hard to speak when your cheeks are shaking - try it sometime. ;-) But people at Pycon are ON YOUR SIDE - they *WANT* you to succeed. So, it's okay if you're a little shaky at the beginning. They'll be polite and listen anyways, because they want to hear about what you're presenting on. And once you've started, you'll be okay. Trust me on this.
So women of Python - please submit your proposals. Don't let the guys have all the fun and glory. I want to see *you* on stage at PyCon!
http://us.pycon.org/2010/conference/proposals/
Wednesday, August 5, 2009
On Python and diversity
After Kirrily's OSCON Keynote, several of us had some great hall discussions and lunch discussions on the topic of women in opensource. As a result of the discussion, Aahz, a fellow pythonista, posted a call for diversity and created a new list for Python users to discuss improving diversity in the Python community.
So far, we've had a great discussion - lots of respectful participation from people of varying viewpoints. I'm so proud to belong to a community that cares about this topic (not just women in opensource, but all forms of diversity) and is taking steps to address it. I've always loved the Python community for its welcoming, friendly, accessible nature. I am also aware that, like most Open Source projects, (and indeed, the tech field in general) there is room for improvement in the diversity of our membership, committers, and officers.
If you're interested in Python and want in on the discussion, the new list is at http://mail.python.org/mailman/listinfo/diversity
Join us in working to make the Python community even better than it already is!
So far, we've had a great discussion - lots of respectful participation from people of varying viewpoints. I'm so proud to belong to a community that cares about this topic (not just women in opensource, but all forms of diversity) and is taking steps to address it. I've always loved the Python community for its welcoming, friendly, accessible nature. I am also aware that, like most Open Source projects, (and indeed, the tech field in general) there is room for improvement in the diversity of our membership, committers, and officers.
If you're interested in Python and want in on the discussion, the new list is at http://mail.python.org/mailman/listinfo/diversity
Join us in working to make the Python community even better than it already is!
Friday, June 19, 2009
Working with excel from Python
A new site for gathering up-to-date information about with Excel files in Python. Working with Excel Files in Python
It has links to tutorials and modules, and even a googlegroups mailing list. Looks useful for anyone who has to work with Excel from Python.
It has links to tutorials and modules, and even a googlegroups mailing list. Looks useful for anyone who has to work with Excel from Python.
Thursday, August 21, 2008
SciPy conference
I'm at the SciPy conference today. I didn't sign up, but Alex gave a keynote and I got to ride on his coattails. (Although I'm being hit up for presenting in the future...)
Alex talked about the problems of black boxes and that "abstractions leak". He gave some nice examples of why you want to understand at least a couple of levels lower than the abstraction you're using (eg., statistical packages won't fix sample bias problems).
The next speaker after break talked about graphing networks - a package called NetworkX. This was a really gorgeous graphing package that looked like it has a really simple, usable API. I particularly liked that in the examples, they used
rather than the usual "from blah import *". It's important, particularly in tutorials and FAQs, imho, to SHOW where all the functions you're using live. Explicitly showing all the dots makes it clear where these things live. Using import * hides that. My compliments to the NetworkX people for not hiding things.
One of the use-cases they mentioned at the beginning was for synchronizing oscillations, and I immediately thought of neo-cortical neural synchronization, which they mentioned at the end when they demo'd their oscillation synchronizer.
NetworkX has a very pretty gallery of graphs to show some of its possibilities. Check it out if you have any graphing or complex network modeling needs.
The next talk was on intervals. It harked back to Alex's talk, which was amusing. Pay attention to your numbers - including the algorithms and packages you're using to calculate things. It was fun to watch - it reminded me how much I actually *like* math. (I was the geek who used to solve quadratic equations for fun.) I'm not so good with trig and logs (although I've gotten better). Anyways - I really enjoyed the intervals talk - it was fun to see a purely mathematical coding talk; it's pretty rare.
We're going to have to head out this afternoon to the airport. If I catch any more presentations, I'll post about them.
Social-wise, the SciPy people were very nice. We got picked up at the airport, driven to our hotel, and they took us to dinner. This morning, breakfast included *protein* (Yay!) not just carbs. And I got to meet another Minnesota girl - who's now working in neuroscience down at Berkeley. We're going to get together when we're back.
In short - I've really enjoyed being here and I plan to attend SciPy in the future. If you are into scientific uses of Python at all - I encourage you to attend.
Alex talked about the problems of black boxes and that "abstractions leak". He gave some nice examples of why you want to understand at least a couple of levels lower than the abstraction you're using (eg., statistical packages won't fix sample bias problems).
The next speaker after break talked about graphing networks - a package called NetworkX. This was a really gorgeous graphing package that looked like it has a really simple, usable API. I particularly liked that in the examples, they used
import networkX as NX rather than the usual "from blah import *". It's important, particularly in tutorials and FAQs, imho, to SHOW where all the functions you're using live. Explicitly showing all the dots makes it clear where these things live. Using import * hides that. My compliments to the NetworkX people for not hiding things.
One of the use-cases they mentioned at the beginning was for synchronizing oscillations, and I immediately thought of neo-cortical neural synchronization, which they mentioned at the end when they demo'd their oscillation synchronizer.
NetworkX has a very pretty gallery of graphs to show some of its possibilities. Check it out if you have any graphing or complex network modeling needs.
The next talk was on intervals. It harked back to Alex's talk, which was amusing. Pay attention to your numbers - including the algorithms and packages you're using to calculate things. It was fun to watch - it reminded me how much I actually *like* math. (I was the geek who used to solve quadratic equations for fun.) I'm not so good with trig and logs (although I've gotten better). Anyways - I really enjoyed the intervals talk - it was fun to see a purely mathematical coding talk; it's pretty rare.
We're going to have to head out this afternoon to the airport. If I catch any more presentations, I'll post about them.
Social-wise, the SciPy people were very nice. We got picked up at the airport, driven to our hotel, and they took us to dinner. This morning, breakfast included *protein* (Yay!) not just carbs. And I got to meet another Minnesota girl - who's now working in neuroscience down at Berkeley. We're going to get together when we're back.
In short - I've really enjoyed being here and I plan to attend SciPy in the future. If you are into scientific uses of Python at all - I encourage you to attend.
Friday, March 28, 2008
PyCon 2008
Pycon was fun. I met a bunch of women from devchix and had dinner together. I gave my talk (and survived... yay). There's a link to some videos from PyCon2008 here:http://www.youtube.com/user/pycon08
including my talk on "to RE or not to RE".
including my talk on "to RE or not to RE".
Tuesday, November 6, 2007
They're not "short adults"
Great post on introducing kids to programming that reminds us to not treat kids like "short adults" and gives a great set of suggestions of ways to introduce a kid, from html to scratch to RUR-PLE. I love that Ned starts by talking about finding out what the kid is interested in. Too many folks forget this part when trying to introduce a new person to programming - wiift (what's in it for them).
Thursday, October 18, 2007
python!
I'm seeing Python in so many places today.
The Numenta guy's application is built in python. (It says so on the side.)
and a lot of the "fix CS1" programs are starting to use Python to introduce CS to people from diverse backgrounds, providing fun, accessible learning of concepts. Using Python to make "gateway" classes instead of "gatekeeper" courses is useful to increase the diversity of students taking and staying in these intro classes. "but wait" says the CS hardcore geek - "What about the lower levels and pointers and recursion and all the hard stuff people need to learn". PYthon isn't "dumbing it down" and these classes that are being produced are providing learning without having to do it dryly. For example, people in class decide they need to have a function call itself and ask how to do that - this way they learn recursion because they have a use-case.
The Numenta guy's application is built in python. (It says so on the side.)
and a lot of the "fix CS1" programs are starting to use Python to introduce CS to people from diverse backgrounds, providing fun, accessible learning of concepts. Using Python to make "gateway" classes instead of "gatekeeper" courses is useful to increase the diversity of students taking and staying in these intro classes. "but wait" says the CS hardcore geek - "What about the lower levels and pointers and recursion and all the hard stuff people need to learn". PYthon isn't "dumbing it down" and these classes that are being produced are providing learning without having to do it dryly. For example, people in class decide they need to have a function call itself and ask how to do that - this way they learn recursion because they have a use-case.
Anna
Official GHC 07 Blogger You may comment on this blog
by visiting *GHC bulletin board*.
Subscribe to:
Posts (Atom)