From mark at microenh.com  Fri Jan  4 18:09:53 2008
From: mark at microenh.com (Mark Erbaugh)
Date: Fri, 04 Jan 2008 12:09:53 -0500
Subject: [CentralOH] Ubuntu Dapper (6.06) / Python 2.51
Message-ID: <1199466593.10745.26.camel@notebook>

I'm trying to install Python 2.5.1 on my Ubuntu Dapper machine. The
repositories for Dapper have Python 2.4.3.

I downloaded the source tarbell, ran ./configure and make.  All went
okay (I think).  It created a python executable file in the make
directory and launching that brings up the Python 2.5.1 interpreter. If
I launch   Lib/idlelib/idle.py from the make directory IDLE runs.

However, if I run sudo checkinstall to build and install a .DEB package,
it get a lot of errors:

/usr/bin/install -c -m644 ./<x> /usr/local/lib/python25/<x>
/usr/bin/install: setting permissions for /usr/local/lib/<x>: No such
file or Directory and the installation eventually aborts.

<x> represents a file name.

I've checked and the files it is trying to install exist at the source
location.

If I manually execute /usr/bin/install (as superuser), the command
completes without error and the file is installed with the appropriate
permissions at the right place.

I also tried running the ./config --prefix /usr to try and have it
install files in /usr rather than /usr/local as the default Python 2.4
install in Dapper was in /usr rather than /usr/local. I still got the
same No Such File or Directory messages.

Is this just a makefile that checkinstall can't process or do I have
something set up wrong. I've used checkinstall to build packages for
other projects where the instructions are ./configure, make and make
install.

Second question.  Python 2.5.1 comes with the latest version of Ubuntu
(Gutsy - 7.10). However, the python executabe file that I built on my
Dapper workstation is over 3 MB in size. The executable python file in
Gutsy is only about 1.1 MB.  Am I building with some additional
information that I don't need?

Thanks,
Mark


From wam at cisco.com  Fri Jan  4 21:45:45 2008
From: wam at cisco.com (William McVey)
Date: Fri, 04 Jan 2008 15:45:45 -0500
Subject: [CentralOH] Ubuntu Dapper (6.06) / Python 2.51
In-Reply-To: <1199466593.10745.26.camel@notebook>
References: <1199466593.10745.26.camel@notebook>
Message-ID: <1199479545.6839.45.camel@tardis.cisco.com>

On Fri, 2008-01-04 at 12:09 -0500, Mark Erbaugh wrote:
> However, if I run sudo checkinstall to build and install a .DEB package,
> it get a lot of errors:
> /usr/bin/install -c -m644 ./<x> /usr/local/lib/python25/<x>
> /usr/bin/install: setting permissions for /usr/local/lib/<x>: No such
> file or Directory and the installation eventually aborts.

Based on what the error message is stating (No such file or directory),
I'm thinking the target directory /usr/local/lib/python25 (or perhaps
even /usr/local or /usr/local/lib) are not created. The install tool
doesn't by default create interleaving directories needed for
installation. That requires the -D option to be given. Perhaps your
Makefile or installation instructions skipped over the making of the
directories. This can happen for example if the install target of the
makefile depends on the target directories, and those directories could
be tied to rules that explicitly go through an "install -d" process. I
don't know why trying to install with checkinstall wouldn't resolve
these dependencies, when it should be doing a 'make install', but that
appears to be the case. You might want to do a "make -n install" to see
what make would try to do if it were running without being under the
control of checkinstall.

> If I manually execute /usr/bin/install (as superuser), the command
> completes without error and the file is installed with the appropriate
> permissions at the right place.

Hmm, so that would seem to indicate the directories are already properly
created. I don't know much about the inner workings of checkinstall, but
does it drop the installed files into a chroot'ed or fakeroot'ed
hierarchy as it's building the package file?

> I also tried running the ./config --prefix /usr to try and have it
> install files in /usr rather than /usr/local as the default Python 2.4
> install in Dapper was in /usr rather than /usr/local. I still got the
> same No Such File or Directory messages.

My first gut instinct is to try and figure out exactly which files or
directories the install tool is complaining about. You make be able to
discover this using strace (consider setting your Makefile's INSTALL
definition to 'strace -f -e trace=file /usr/bin/install -c'). This will
generate a lot of output, so you may want to redirect stderr to a file
that can be searched.

> Is this just a makefile that checkinstall can't process or do I have
> something set up wrong. I've used checkinstall to build packages for
> other projects where the instructions are ./configure, make and make
> install.

Well, it certainly does sound like an issue with checkinstall and not
python per-se. If you do a 'make install' does everything get installed
properly?

> Second question.  Python 2.5.1 comes with the latest version of Ubuntu
> (Gutsy - 7.10). However, the python executabe file that I built on my
> Dapper workstation is over 3 MB in size. The executable python file in
> Gutsy is only about 1.1 MB.  Am I building with some additional
> information that I don't need?

Your binary probably has debugging symbols still in the objects files.
These are generally removed by 'install' when run with the '-s' option,
or using the standalone tool 'strip'. 

  -- William


From brian.costlow at gmail.com  Wed Jan 16 14:49:15 2008
From: brian.costlow at gmail.com (Brian Costlow)
Date: Wed, 16 Jan 2008 08:49:15 -0500
Subject: [CentralOH] Python & PHP Programmer needed.
Message-ID: <89d8b1b00801160549r1a62b725l545672a1fcdad115@mail.gmail.com>

Hi All,

My employer, Vertis Inc., is hiring a full-time Python developer to work on
a number of projects, including projects using the Django and Twisted
frameworks.

There's also PHP work involved, customizing and extending the 'WebNative
Portal' application from Xinet.
www.xinet.com

Full details here:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&jobid=231854&company_id=15759

Note that the position is mostly telecommuting, and while we'd like someone
local to our Irving, TX facility, we're open to completely remote developers
(in the continental US) for the right person.

On a personal note, if we find that person somewhere in Columbus,
Cinncinati, Dayton (or even Cleveland or Pittsburgh, PA,) that's a lot less
flying time for me. I'm the hiring manager, and work in a home office in
Pataskala, OH.

You can email questions about the job directly to me, but you must apply and
send resumes through the link. Corp HR won't let me accept them directly.

Regards,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/mailman/private/centraloh/attachments/20080116/fd810c92/attachment.htm 

From bmintern at gmail.com  Wed Jan 16 22:28:16 2008
From: bmintern at gmail.com (Brandon Mintern)
Date: Wed, 16 Jan 2008 16:28:16 -0500
Subject: [CentralOH] A simple class to provide named fields
Message-ID: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>

I often have a use for a dictionary where the key references a small
collection of data, perhaps 2 or 3 pieces of information. One example
I have now is a caching dictionary which holds a filename mapped to
the file type (as relevant in my application) and the contents of the
file. There are basically two ways to do this:

1. Simply use a tuple which holds the two pieces of information in a
special order. This makes it easy to throw the data into the
dictionary, but then referencing that data requires the use of [0] and
[1] indexes all over the place, requiring the coder to keep it all
sorted out. Pity be to the person who has to come back and maintain
this code later, which lhas "files[filename][0]" all over the place.

2. Create a small class with named data. This makes the code look much
nicer (e.g. "files[filename].type"), but it means that for every small
collection I have to create such a class, a class simply for naming
some data fields, when I have no need for any of the other class
capabilities like methods. I find myself reluctant, therefore, to do
this everywhere I should.

Some time ago, I came up with an elegant solution to this problem, one
that I thought I would share. If anyone else has used or seen
something like this, I would love to hear about it. If it's not
something that you have in your personal toolbox (and it's not some
builtin function/library that I'm simply missing), I highly suggest
checking it out, because it has encourage much better-looking code on
my part.

The idea was to create a class which made the fulfillment of (2) have
as little initial overhead as possible. Here is what I came up with:

class Fields:
    """
    A class intended to provide a simple interface for creating objects
    with named fields. That is, instead of returning a tuple and indexing
    it or writing a unique class, you can simply do something like:
    a = Fields(x=1, y=2)
    a.x # 1
    a.y # 2
    """
    def __init__ (self, **kwargs):
        for name, value in kwargs.iteritems():
            self.__dict__[name] = value


And that's it! The docstring explains it quite clearly, I think. That
simple 4-line class has made my code so much cleaner that I thought
I'd share it with anyone who might be interested. Now I can use code
like the following without hesitation.

# assume fh is an open handle to a file containing text "bar"
files[filename] = Fields(type="foo", contents=fh.read())

<snip>

files[filename].type # "foo"
files[filename].contents # "bar"

Happy coding,
Brandon

From steven_h at acm.org  Thu Jan 17 00:06:47 2008
From: steven_h at acm.org (Steven Huwig)
Date: Wed, 16 Jan 2008 18:06:47 -0500
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
References: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
Message-ID: <D19216EB-9007-4597-92D4-7CCFDB6AFFCB@acm.org>


On Jan 16, 2008, at 4:28 PM, Brandon Mintern wrote:
>
> class Fields:
>     """
>     A class intended to provide a simple interface for creating  
> objects
>     with named fields. That is, instead of returning a tuple and  
> indexing
>     it or writing a unique class, you can simply do something like:
>     a = Fields(x=1, y=2)
>     a.x # 1
>     a.y # 2
>     """
>     def __init__ (self, **kwargs):
>         for name, value in kwargs.iteritems():
>             self.__dict__[name] = value
>

I like it! My only suggestion would be to name it "Record" instead of  
"Fields", following the description at http://en.wikipedia.org/wiki/ 
Record_(computer_science).

-- Steve

From wam at cisco.com  Wed Jan 16 23:57:26 2008
From: wam at cisco.com (William McVey)
Date: Wed, 16 Jan 2008 17:57:26 -0500
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
References: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
Message-ID: <1200524247.7835.66.camel@tardis.cisco.com>

On Wed, 2008-01-16 at 16:28 -0500, Brandon Mintern wrote:
> Some time ago, I came up with an elegant solution to this problem, one
> that I thought I would share. If anyone else has used or seen
> something like this, I would love to hear about it.

I have something similar:
        
        class Container(object):
                """A generic object that initializes its attributes from the init params
        
                If a subclass defines a 'params' iterable at the class definition level,
                only those parameters will be assigned and extra keyword arguments will
                raise a NameError. Failure to provide a field specified by the
                subclass' params list will result in None being assigned that value
                """
                params = []
                def __init__(self, *args, **kwargs):
                        if not self.params:
                                self.__dict__.update(kwargs)
                                return
                        for param in self.params:
                                self.__dict__[param] = kwargs.get(param, None)
                                try:
                                        del(kwargs[param])
                                except KeyError:
                                        pass
                        if kwargs:
                                raise NameError(
                                  "%s initialized with extra params: %r" % (
                                  self.__class__.__name__, kwargs.keys()))
        	
        	def __repr__(self):
        		return "%s(%s)" % (
                           self.__class__.__name__,
                           ", ".join(["%s=%r" % x for x in self.__dict__.items()]))

It's very similar in concept to yours; however, I tend to prefer classes
which are tied closer to the data object I'm storing, so I almost always
subclass Container. In my subclass I define a class attribute named
'params' which specifies which parameters/fields I accept. I then go
about creating a PersonRecord the same way you create your Fields
objects: For example:

   >>> from wam.Utils import Container
        >>> class PersonRecord(Container):
        ...   params = ["fname", "lname", "status"]
        ...
        >>> me = PersonRecord(fname="William", lname="McVey", status="Active")
        >>> me
        PersonRecord(lname='McVey', status='Active', fname='William')
        >>> me.status
        'Active'
        
The nice thing is that if I try and send down an unexpected field value
(a sure sign of a bug), I get myself a traceback that indicates what the
problem is. In the rare cases where I just want a generic
"accept-anything" object, I just don't define the fields the object
should be constrained by. 

I also really like having __repr__ methods that can recreate the object
in question.

   -- William

P.S. Note the use of the update() method on the dictionary. That would
shorten your version to a one liner:
	def __init__(self, **kwargs): self.__dict__.update(kwargs)




From bmintern at gmail.com  Thu Jan 17 02:05:07 2008
From: bmintern at gmail.com (Brandon Mintern)
Date: Wed, 16 Jan 2008 20:05:07 -0500
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <D19216EB-9007-4597-92D4-7CCFDB6AFFCB@acm.org>
References: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
	<D19216EB-9007-4597-92D4-7CCFDB6AFFCB@acm.org>
Message-ID: <4c0fccce0801161705l5e014244m9e2d433303fb3ebd@mail.gmail.com>

Thanks for the quick replies

On Jan 16, 2008 5:57 PM, William McVey <wam at cisco.com> wrote:
>
> I have something similar:
>
>         class Container(object):
<snip>
> It's very similar in concept to yours; however, I tend to prefer classes
> which are tied closer to the data object I'm storing, so I almost always
> subclass Container. In my subclass I define a class attribute named
> 'params' which specifies which parameters/fields I accept. I then go
> about creating a PersonRecord the same way you create your Fields
> objects: For example:
>
>    >>> from wam.Utils import Container
>         >>> class PersonRecord(Container):
>         ...   params = ["fname", "lname", "status"]
>         ...
>         >>> me = PersonRecord(fname="William", lname="McVey", status="Active")
>         >>> me
>         PersonRecord(lname='McVey', status='Active', fname='William')
>         >>> me.status
>         'Active'
>
> The nice thing is that if I try and send down an unexpected field value
> (a sure sign of a bug), I get myself a traceback that indicates what the
> problem is. In the rare cases where I just want a generic
> "accept-anything" object, I just don't define the fields the object
> should be constrained by.
>
> I also really like having __repr__ methods that can recreate the object
> in question.
>
>    -- William
>
> P.S. Note the use of the update() method on the dictionary. That would
> shorten your version to a one liner:
>         def __init__(self, **kwargs): self.__dict__.update(kwargs)

I like the addition of the __repr__ method for sure. I'm not quite as
sure about the subclassing and use of params; I can understand why you
do it, and I see that it works well for you, but my entire thrust was
to avoid the need to have to create special classes for every
different little "Container" in my program. This may not be the best
practice, but it certainly beats indexing tuples.

The __dict__.update suggestion is spot on. Thanks for the suggestion.

On Jan 16, 2008 6:06 PM, Steven Huwig <steven_h at acm.org> wrote:
>
> I like it! My only suggestion would be to name it "Record" instead of
> "Fields", following the description at http://en.wikipedia.org/wiki/
> Record_(computer_science).
>
> -- Steve
>

I like that suggestion. I had been wrestling with what to call it for
quite some time (Fields was about the 3rd name I've used), and Record
is one that I think fits well.

Taking the suggestions of both of you into account, here's what I get:

class Record:
    """
    A class intended to provide a simple interface for creating objects
    with named fields. That is, instead of returning a tuple and indexing
    it or writing a unique class, you can simply do something like:
    a = Record(x=1, y=2)
    a.x # 1
    a.y # 2
    a   # Record(x=1, y=2)
    """
    def __init__ (self, **kwargs):
        self.__dict__.update(kwargs)

    def __repr__ (self):
        return "Record(%s)" \
               % ", ".join(["%s=%s" \
                            % field for field in self.__dict__.iteritems()])

From samus at codeargyle.com  Thu Jan 17 02:37:17 2008
From: samus at codeargyle.com (Sam Corder)
Date: Wed, 16 Jan 2008 20:37:17 -0500 (EST)
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <4c0fccce0801161705l5e014244m9e2d433303fb3ebd@mail.gmail.com>
Message-ID: <22506872.3341200533837542.JavaMail.root@spring.codeargyle.com>

I know the idea here is to avoid using indexes on tuples but what is wrong with using a good old fashioned dictionary with strings as keys?  I know the syntax isn't as pretty as a.x but it accomplishes the same thing without the need for a utility class.

----- Original Message -----
From: Brandon Mintern <bmintern at gmail.com>
To: Steven Huwig <steven_h at acm.org>
Cc: centraloh at python.org
Sent: Wednesday, January 16, 2008 8:05:07 PM GMT-0500 Auto-Detected
Subject: Re: [CentralOH] A simple class to provide named fields

Thanks for the quick replies

On Jan 16, 2008 5:57 PM, William McVey <wam at cisco.com> wrote:
>
> I have something similar:
>
>         class Container(object):
<snip>
> It's very similar in concept to yours; however, I tend to prefer classes
> which are tied closer to the data object I'm storing, so I almost always
> subclass Container. In my subclass I define a class attribute named
> 'params' which specifies which parameters/fields I accept. I then go
> about creating a PersonRecord the same way you create your Fields
> objects: For example:
>
>    >>> from wam.Utils import Container
>         >>> class PersonRecord(Container):
>         ...   params = ["fname", "lname", "status"]
>         ...
>         >>> me = PersonRecord(fname="William", lname="McVey", status="Active")
>         >>> me
>         PersonRecord(lname='McVey', status='Active', fname='William')
>         >>> me.status
>         'Active'
>
> The nice thing is that if I try and send down an unexpected field value
> (a sure sign of a bug), I get myself a traceback that indicates what the
> problem is. In the rare cases where I just want a generic
> "accept-anything" object, I just don't define the fields the object
> should be constrained by.
>
> I also really like having __repr__ methods that can recreate the object
> in question.
>
>    -- William
>
> P.S. Note the use of the update() method on the dictionary. That would
> shorten your version to a one liner:
>         def __init__(self, **kwargs): self.__dict__.update(kwargs)

I like the addition of the __repr__ method for sure. I'm not quite as
sure about the subclassing and use of params; I can understand why you
do it, and I see that it works well for you, but my entire thrust was
to avoid the need to have to create special classes for every
different little "Container" in my program. This may not be the best
practice, but it certainly beats indexing tuples.

The __dict__.update suggestion is spot on. Thanks for the suggestion.

On Jan 16, 2008 6:06 PM, Steven Huwig <steven_h at acm.org> wrote:
>
> I like it! My only suggestion would be to name it "Record" instead of
> "Fields", following the description at http://en.wikipedia.org/wiki/
> Record_(computer_science).
>
> -- Steve
>

I like that suggestion. I had been wrestling with what to call it for
quite some time (Fields was about the 3rd name I've used), and Record
is one that I think fits well.

Taking the suggestions of both of you into account, here's what I get:

class Record:
    """
    A class intended to provide a simple interface for creating objects
    with named fields. That is, instead of returning a tuple and indexing
    it or writing a unique class, you can simply do something like:
    a = Record(x=1, y=2)
    a.x # 1
    a.y # 2
    a   # Record(x=1, y=2)
    """
    def __init__ (self, **kwargs):
        self.__dict__.update(kwargs)

    def __repr__ (self):
        return "Record(%s)" \
               % ", ".join(["%s=%s" \
                            % field for field in self.__dict__.iteritems()])
_______________________________________________
CentralOH mailing list
CentralOH at python.org
http://mail.python.org/mailman/listinfo/centraloh


From steven_h at acm.org  Thu Jan 17 05:49:31 2008
From: steven_h at acm.org (Steven Huwig)
Date: Wed, 16 Jan 2008 23:49:31 -0500
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <22506872.3341200533837542.JavaMail.root@spring.codeargyle.com>
References: <22506872.3341200533837542.JavaMail.root@spring.codeargyle.com>
Message-ID: <B83C40B9-1CCC-4D3E-92F4-0C4DC3B3E936@acm.org>


On Jan 16, 2008, at 8:37 PM, Sam Corder wrote:

> I know the idea here is to avoid using indexes on tuples but what  
> is wrong with using a good old fashioned dictionary with strings as  
> keys?  I know the syntax isn't as pretty as a.x but it accomplishes  
> the same thing without the need for a utility class.

Nothing's wrong with using dictionaries. I did think of a very minor  
advantage of using a class (using a slightly different implementation):


class Record(object):
     __slots__ = []
     """
     A class intended to provide a simple interface for creating objects
     with named fields. That is, instead of returning a tuple and  
indexing
     it or writing a unique class, you can simply do something like:
     a = Record(x=1, y=2)
     a.x # 1
     a.y # 2
     a   # Record(x=1, y=2)
     """
     def __init__ (self, **kwargs):
         for k, v in kwargs.iteritems():
             setattr(self, k, v)

     def __repr__ (self):
         vals = []
         for k in self.__slots__:
             vals.append((k, repr(getattr(self, k))))
         return "%s(%s)" % (self.__class__.__name__,
                            ", ".join(["%s=%s" % field for field in  
vals]))

class Name(Record):
     __slots__ = ['first','last']


 >>> from Record import Name
 >>> me = Name(first="Steven", last="Huwig")
 >>> me
Name(first='Steven', last='Huwig')
 >>> oops = Name(first="Steven", middle="J", last="Huwig")
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "Record.py", line 14, in __init__
     setattr(self, k, v)
AttributeError: 'Name' object has no attribute 'middle'
 >>>


Of course everyone knows that the real reason to use __slots__ is to  
cut down on space usage by not allocating __dict__. But for simple  
record types, that's at least as desirable as the attribute  
modification prevention shown above.

-- Steve

P.S. the above __repr__ has the nice property of recreating the same  
value when its output is fed to eval().

P.P.S. I believe there is talk of adding an official record type to  
Python at some point.

From bmintern at gmail.com  Thu Jan 17 13:24:26 2008
From: bmintern at gmail.com (Brandon Mintern)
Date: Thu, 17 Jan 2008 07:24:26 -0500
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <22506872.3341200533837542.JavaMail.root@spring.codeargyle.com>
References: <4c0fccce0801161705l5e014244m9e2d433303fb3ebd@mail.gmail.com>
	<22506872.3341200533837542.JavaMail.root@spring.codeargyle.com>
Message-ID: <4c0fccce0801170424p2a2ec60fna6c7e35f5457de50@mail.gmail.com>

On Jan 16, 2008 8:37 PM, Sam Corder <samus at codeargyle.com> wrote:
> I know the idea here is to avoid using indexes on tuples but what is wrong with using a good old fashioned dictionary with strings as keys?  I know the syntax isn't as pretty as a.x but it accomplishes the same thing without the need for a utility class.

For me, "the syntax isn't as pretty" is a good enough reason. Anything
that saves typing and increases clarity without much more effort is a
winner for me. Let's compare:

a = Record(x=1, y=2)
a.x
a.y

a = {"x": 1, "y": 2}
a["x"]
a["y"]

It seems to me that the Record one is no harder to create (probably
even easier with a higher number of fields, since you don't need to
type the quotation marks), and later accesses are much clearer. Is "a"
really a dictionary? No, it's a collection of data, and I think the
a.x syntax says that much clearer than the dictionary accesses.

That's not to mention when you have my initial use case in mind: a
dictionary where a key references such a record:

employees = {}
for first, last, ssn, salary in some_data:
    employees[ssn] = Record(first=first, last=last, salary=salary)
    # compared to
    employees[ssn] = {"first": first, "last": last, "salary": salary}
employees[12345678].first
# compared to
employees[12345678]["first"]

To me, the very last line above is starting to get a bit ugly, but
maybe I'm just focusing too much on details.

From catherine.devlin at gmail.com  Sat Jan 19 01:42:19 2008
From: catherine.devlin at gmail.com (Catherine Devlin)
Date: Fri, 18 Jan 2008 19:42:19 -0500
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
References: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
Message-ID: <6523e39a0801181642p3f0aef37rc16d7134152a9b5d@mail.gmail.com>

> 2. Create a small class with named data.

You have just re-implemented Recipe 4.18 from the Python Cookbook (2nd Ed.)  :)

Understand, that's a compliment - if you're thinking the way Alex
Martelli thinks, you're thinking right.  I just can't say enough good
things about the Cookbook.  I should really review it weekly...

-- 
- Catherine
http://catherinedevlin.blogspot.com/
*** PyCon 2008 * Chicago * March 13-20 * us.pycon.org ***

From bmintern at gmail.com  Sat Jan 19 19:50:51 2008
From: bmintern at gmail.com (Brandon Mintern)
Date: Sat, 19 Jan 2008 13:50:51 -0500
Subject: [CentralOH] A simple class to provide named fields
In-Reply-To: <6523e39a0801181642p3f0aef37rc16d7134152a9b5d@mail.gmail.com>
References: <4c0fccce0801161328j24d6acbj24ae320a20ecf63c@mail.gmail.com>
	<6523e39a0801181642p3f0aef37rc16d7134152a9b5d@mail.gmail.com>
Message-ID: <4c0fccce0801191050n51dc35eej8083006dcd933586@mail.gmail.com>

Wow, cool. Thanks for the info.

On Jan 18, 2008 7:42 PM, Catherine Devlin <catherine.devlin at gmail.com> wrote:
> > 2. Create a small class with named data.
>
> You have just re-implemented Recipe 4.18 from the Python Cookbook (2nd Ed.)  :)
>
> Understand, that's a compliment - if you're thinking the way Alex
> Martelli thinks, you're thinking right.  I just can't say enough good
> things about the Cookbook.  I should really review it weekly...
>
> --
> - Catherine
> http://catherinedevlin.blogspot.com/
> *** PyCon 2008 * Chicago * March 13-20 * us.pycon.org ***
>

From wam at cisco.com  Tue Jan 29 16:59:35 2008
From: wam at cisco.com (William McVey)
Date: Tue, 29 Jan 2008 10:59:35 -0500
Subject: [CentralOH] Who plans on being at PyCon 2008?
Message-ID: <1201622375.9984.15.camel@tardis.cisco.com>

I just registered for PyCon and I was curious who else is planning on
attending. I'll be arriving on Weds in time for the Thursday tutorials
and staying on through at least part of the sprints (not real sure which
ones I'll be working on at this point though). Was just curious what
other people in the area were planning. 

If you don't already know about PyCon 2008, details are at:
http://us.pycon.org/2008/about/

  -- William


From catherine.devlin at gmail.com  Wed Jan 30 21:52:09 2008
From: catherine.devlin at gmail.com (Catherine Devlin)
Date: Wed, 30 Jan 2008 15:52:09 -0500
Subject: [CentralOH] Who plans on being at PyCon 2008?
In-Reply-To: <1201622375.9984.15.camel@tardis.cisco.com>
References: <1201622375.9984.15.camel@tardis.cisco.com>
Message-ID: <6523e39a0801301252y46d3e6ecj39c5f4b7397e9848@mail.gmail.com>

That's great, William!

Well, you *know* I'm going.  In fact, this year I'm staying for
sprints... for the first time ever.  Probably for the TurboGears
sprint, although if a SQLAlchemy sprint gets scheduled I'll go for
that instead.  PyCon is bending over backwards to welcome newbies to
sprints this year, which is good, because a newbie (to sprints) is
exactly what I am.

I hope quite a few of you can come!  I always love PyCon more than I
can say.  Catch it now, while it's in the Midwest.

On Jan 29, 2008 10:59 AM, William McVey <wam at cisco.com> wrote:
> I just registered for PyCon and I was curious who else is planning on
> attending. I'll be arriving on Weds in time for the Thursday tutorials
> and staying on through at least part of the sprints (not real sure which
> ones I'll be working on at this point though). Was just curious what
> other people in the area were planning.
>
> If you don't already know about PyCon 2008, details are at:
> http://us.pycon.org/2008/about/
>
>   -- William

-- 
- Catherine
http://catherinedevlin.blogspot.com/
*** PyCon 2008 * Chicago * March 13-20 * us.pycon.org ***

From mark at microenh.com  Thu Jan 31 15:19:12 2008
From: mark at microenh.com (Mark Erbaugh)
Date: Thu, 31 Jan 2008 09:19:12 -0500
Subject: [CentralOH] PyCon 2008
Message-ID: <1201789153.7276.1.camel@P1900>

I'm definitely interested. Does anyone have any recommendations on
alternative lodging?  The conference rate is probably pretty good @
$99/night, but that's too steep for me.


From wam at cisco.com  Thu Jan 31 19:52:39 2008
From: wam at cisco.com (William McVey)
Date: Thu, 31 Jan 2008 13:52:39 -0500
Subject: [CentralOH] PyCon 2008
In-Reply-To: <1201789153.7276.1.camel@P1900>
References: <1201789153.7276.1.camel@P1900>
Message-ID: <1201805559.9984.65.camel@tardis.cisco.com>

On Thu, 2008-01-31 at 09:19 -0500, Mark Erbaugh wrote:
> I'm definitely interested. Does anyone have any recommendations on
> alternative lodging?  The conference rate is probably pretty good @
> $99/night, but that's too steep for me.

Not sure if you know, but there is a wiki page at:
http://wiki.python.org/moin/PyCon2008/Room_Sharing

that is helping people find roommates to split the cost of the hotel
bill. Also, there is the option of applying for financial aid. Details
are here:
http://us.pycon.org/2008/registration/financial-aid/

And as a tip, if you do seek financial aid to attend the conference, I
highly recommend indicating your willingness to volunteer (perhaps at
the registration desk or the like).

  -- William


From gacsinger at gmail.com  Thu Jan 31 20:01:11 2008
From: gacsinger at gmail.com (Greg Singer)
Date: Thu, 31 Jan 2008 14:01:11 -0500
Subject: [CentralOH] PyCon 2008
In-Reply-To: <1201789153.7276.1.camel@P1900>
References: <1201789153.7276.1.camel@P1900>
Message-ID: <b032e3360801311101p27601facjfd184e10ca040228@mail.gmail.com>

On Jan 31, 2008 9:19 AM, Mark Erbaugh <mark at microenh.com> wrote:
> I'm definitely interested. Does anyone have any recommendations on
> alternative lodging?  The conference rate is probably pretty good @
> $99/night, but that's too steep for me.

Hotwire is showing a few options at around $50/night. You might be
able to do better than that as the date gets closer and the hotels try
to sell off unused rooms. Priceline is also a good option, of course.

 - Greg

From catherine.devlin at gmail.com  Thu Jan 31 20:30:21 2008
From: catherine.devlin at gmail.com (Catherine Devlin)
Date: Thu, 31 Jan 2008 14:30:21 -0500
Subject: [CentralOH] PyCon 2008
In-Reply-To: <1201789153.7276.1.camel@P1900>
References: <1201789153.7276.1.camel@P1900>
Message-ID: <6523e39a0801311130q20a27dd9o1f80742292d4a1c5@mail.gmail.com>

You can actually use hostels as a full-blown adult.  It feels a little
like you're in college all over again, but it's not quite as wacky as
it sounds.  (I've never stayed in the Chicago one, but Seattle and New
York both felt like a cross between a standard hotel and student
collective housing.)  The Chicago one is listing beds "from
$27/night".

http://www.hihostels.com/affiliates/hiusa60034.php?country=US&city=a60034&AffiliateID=97060

On Jan 31, 2008 9:19 AM, Mark Erbaugh <mark at microenh.com> wrote:
> I'm definitely interested. Does anyone have any recommendations on
> alternative lodging?  The conference rate is probably pretty good @
> $99/night, but that's too steep for me.

-- 
- Catherine
http://catherinedevlin.blogspot.com/
*** PyCon 2008 * Chicago * March 13-20 * us.pycon.org ***

From brian.costlow at gmail.com  Thu Jan 31 23:07:00 2008
From: brian.costlow at gmail.com (Brian Costlow)
Date: Thu, 31 Jan 2008 17:07:00 -0500
Subject: [CentralOH] PyCon 2008
In-Reply-To: <6523e39a0801311130q20a27dd9o1f80742292d4a1c5@mail.gmail.com>
References: <1201789153.7276.1.camel@P1900>
	<6523e39a0801311130q20a27dd9o1f80742292d4a1c5@mail.gmail.com>
Message-ID: <89d8b1b00801311407m7082ae43w45ef974b2bb4c264@mail.gmail.com>

If you are flying in on a cheap flight, the L will get you real close to the
hostel and pycon. Blue line within walking distance of both. But if you are
driving, the additional parking charge may be more than your bed. Last time
I stayed down in that area a couple years ago, the hotel I was at didn't
have its own garage and provided 'discount' parking at a nearby garage for
45.00 a night.

There used to be a Super-8 and La Quinta in Elk Grove, and a Travelodge in
Park Ridge. I used to live in Elk Grove, and those were the only places less
than 99 a night back in 1993. You might try to google them.

Other than that, if you are driving, the suggestions for using discount
broker or finding a room share are probably your best bets.

On Jan 31, 2008 2:30 PM, Catherine Devlin <catherine.devlin at gmail.com>
wrote:

> You can actually use hostels as a full-blown adult.  It feels a little
> like you're in college all over again, but it's not quite as wacky as
> it sounds.  (I've never stayed in the Chicago one, but Seattle and New
> York both felt like a cross between a standard hotel and student
> collective housing.)  The Chicago one is listing beds "from
> $27/night".
>
>
> http://www.hihostels.com/affiliates/hiusa60034.php?country=US&city=a60034&AffiliateID=97060
>
> On Jan 31, 2008 9:19 AM, Mark Erbaugh <mark at microenh.com> wrote:
> > I'm definitely interested. Does anyone have any recommendations on
> > alternative lodging?  The conference rate is probably pretty good @
> > $99/night, but that's too steep for me.
>
> --
> - Catherine
> http://catherinedevlin.blogspot.com/
> *** PyCon 2008 * Chicago * March 13-20 * us.pycon.org ***
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/mailman/private/centraloh/attachments/20080131/c9dcae17/attachment.htm