Forgive me if this idea has been already proposed and shot down.
Earlier today I was trying to print some binary data I received over a
socket in hexadecimal format so that I could decipher the contents. The
first thing I instinctively tried was hex(datastring) and was somewhat
suprised to find that it didn't work.
I wandered around the documentation a bit looking for a simple and
"obvious" way to do this and came up empty (I would appreciate it if
someone could enlighten me if there already is a way). For the rest of
the day it kinda bothered me that my first attempt didn't work.
After spending probably not enough time thinking about this, I came up
with what might be a reasonable extension for hex() and oct() that would
allow those functions to accept a string and produce a quoted hexadecimal
or octal representation of the input string using the escape notation \xhh
>>> print hex('ABC') # This is what I was trying to do today
>>> print oct('ABC')
Are there any subtle issues with supporting this that I'm not seeing?
In the past 24 hours, gmane.comp.python.devel was flooded with about
20000 py-dev posts from the last 3 years. (Is this the whole
archive?) Fortunately, they had the original posting dates so
current stuff could be sorted out and the rest 'catchup'ed away.
Just curious -- did these come from or go to the mailing list (and
people mailboxes) also? (If the latter, a plus for the news gateway.)
Is this an effect of the current virus storm or just a strange
After unanimous consent <wink> on the meta-sig and mimelib-devel lists,
I've gone ahead and created the new email-sig. See
This SIG's mission is to design and implement version 3.0 of the email
package for Python 2.4. Please use this SIG instead of the
mimelib-devel list from now on.
I am moving Tuesday morning down to San Luis Obispo. The problem with
this is that I am going to lose Net for two weeks thanks to SBC saying
it will take 10 to 12 working days for me to get my DSL turned on; I
ordered it this past Friday.
So I have disabled delivery on all lists (pydotorg-related lists,
PyCon-related lists) but python-dev, but that is just so that I have a
copy for when I do the next Summary. There is a chance I will be able
to check between now and and when I get DSL, but if I do it will only be
python-dev and I have no clue if that will even happen.
Hopefully I will be productive during my time "off".
With Martin and Brett away from the keyboard,
the pending bug/patch pool is growing faster than
it is shrinking.
Even if you only have a little time, please scan
through the list to set priorities, endorse good
ideas, trump the bad, assign to the appropriate
If you bless an idea and suggest an approach,
sometimes I can take it from there and get it
implemented, tested, and documented.
Even if no immediate action is to be taken, a
comment of some sort will let the contributor
know that their efforts haven't fallen on deaf ears.
I've solicited participation from newsgroup followers
and would like to their efforts to be rewarded with
> I'm a Windows user, and I tend to prefer using html docs. Am I
> unusual in this regard?
> I don't know. Have you used a .chm file for Python docs (one has been
> separately downloadable for years, but not from python.org)?
> The display is
> identical to what you'd see if you used IE to browse the HTML docs directly
> today, so it's unclear what it is about "html docs" you might prefer.
Mostly just that it's "more standard". I can view in a browser of my choice,
launch a browser from within my editor/IDE, set bookmarks (but I don't usually
do that), share on a drive and view from unix (but I don't do that), etc.
> prime usability gain is that the .chm file supports full-text search across
> the whole set of Python docs, including Boolean (AND, OR, NOT) and proximity
> (NEAR) searches.
Well, that's a significant feature! I don't want to knock a technology
that I haven't even really tried... just wanted to point out that there
are some advantages to HTML. I guess I think Guido's "beta test" idea
sounds good -- I can't think of any other way we'd actually get feedback
from users. Maybe a mention in "What's New In" under the title "where are
the html docs?" could give the gripers a place to complain to so they can
Nobody-uses-html-any-more-that-was-so-1990's lly yours,
-- Michael Chermside
I'm starting work on the MacPython 2.3 installer for MacOSX 10.3, which
install only the bits that Apple doesn't include (one extension module
the IDE and other applets). But, I'm a bit at loss for where to put
I was going to put it on the release23-maint branch, but it isn't
a bug fix. Still, it seems the most logical place.
Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Tim Peters writes:
> If there's a nice searchable .chm file, I wouldn't want a thousand separate
> HTML files in addition.
I'm a Windows user, and I tend to prefer using html docs. Am I unusual in this
-- Michael Chermside
In PEP 310 Reliable Acquisition/Release Pairs:
Should existing classes (for example, file-like objects and locks) gain
appropriate __enter__ and __exit__ methods? The obvious reason in favour
is convenience (no adapter needed). The argument against is that if
built-in files have this but (say) StringIO does not, then code that uses
"with" on a file object can't be reused with a StringIO object. So
__exit__ = close becomes a part of the "file-like object" protocol, which
user-defined classes may need to support.
maybe this is too much DWIMish, but it occurred to me that a further option
would be for the semantics to be:
var = expr
if hasattr(var, "__enter__"):
if hasattr(var, "__exit__"):
elif hasattr(var, "close"): # consider also close as a synonym of __exit__
I'm not proposing to do without __exit__, I recall the next/__next__
debate, but I'm wondering if this is well documented, how many times
considering close a synomym of __exit__ would do the wrong thing, such that
the user would have to hide close somehow to use 'with' & some object, and
this wrt the times someone would need a wrapper to have __exit__ trigger a
I don't think it is worth to have a debate right now, still this should
maybe be added to the PEP as an option to consider.