People use __main__.py now? That seems bad, because __ names
> are reserved, so they should just use main.py, I would think.
I've seen __main__ suggested as a place to store application-specific global
settings, but not for a long time. I don't think it was ever mapped di
On Friday 13 July 2007, Anders J. Munch wrote:
> How about .pyzip instead? To make it more obvious, and not mistakable for
> .py.z.
I guess it would be pinheaded to call it .zippy. ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailin
x users to prepend to sys.path. It should also be separate from
the -z (or whatever that gets called).
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
f it's a zip file
>seems problematic to me. I'd rather be explicit with the -z flag.
>Likewise, I'd rather be explicit and call it __zipmain__ rather than
>__main__.
Identifying ZIP files is straightforward; there's nothing weird about this
one.
-Fred
--
_message = None
@apply
def message():
def get(self):
return self._message
def set(self, value):
self._message = value
return property(get, set)
I think your use case is entirely reasonable, and can be handled read
ts were added in 2.5, though, and I've no real idea how widely
they've been adopted.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
Python-Dev@python.org
n; the
existing function signatures for cgi.parse_qs and cgi.parse_qsl are
sufficient.
It may be convenient to add methods to the urlparse.BaseResult class providing
access to the parsed version of the query on the instance.
-Fred
--
Fred L. Drake, Jr.
__
to be able to say "yes, the code is painful to read, let's make it
nicer", but it's hard to say that without being able to say "I'm sure it
won't break anything for anybody." Python's too flexible for that to be
easy.
-Fred
--
Fred L. Drake, Jr.
to the code since that can
increase the maintenance burden (patches can be harder to produce that can be
cleanly applied to multiple versions).
Are there motivations we're missing?
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Py
s to Georg, latex2html also misses the smart quotes. See the
> same paragraph here:
>
> http://docs.python.org/ref/front.html
There's a way to make latex2html do "the right thing" for these, except... it
then happily does so even to ` and '' (and `` and '&
On Tuesday 22 May 2007, Georg Brandl wrote:
> But that's at least funnier than before :)
It's not our job to make whiner-babies sound funny.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
ings easier for people who are willing to put
the work into contribution, which is valuable in its own right.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
if anyone wants it (it uses Myghty - Mason in Python.)
This is very cool. ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
On Monday 21 May 2007, A.M. Kuchling wrote:
> Disadvantages:
>
> * reST markup isn't much simpler than LaTeX.
* reST doesn't support nested markup, which is used in the current
documentation.
-Fred
--
Fred L. Drake, Jr.
___
le to continue to use the old tools, but where will they get them if
> they are no longer part of Python?
I'll be happy to pull the existing tools out into a separate distribution if
we move to something else for Python. There are too many users of the
existing tools to abandon.
-Fr
On Thursday 10 May 2007, Barry Warsaw wrote:
> This came up in a different context. I originally emailed this to
> the python.org admins, but Aahz rightly points out that we should
> first agree here that this actually /is/ our official stance.
+1
-Fred
--
Fred L.
ange, but
consistency is valuable too. Perhaps it's time to make the change across the
board.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
would be
very useful as a dictionary key as well, and more space-efficient than
tuple(b'...').
Whether there should be one type with a flag indicating mutability, or two
separate types (as with set and frozenset), I'm not sure. The later offers
some small performance benefits, but I
On Friday 04 May 2007, M.-A. Lemburg wrote:
> I also suggest making all bytes literals immutable to avoid running
> into any issues like the above.
+1 from me.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.or
dst_dir, dst))
>
> I use this kind of thing frequently. Don't know if others consider it
> bad style.
I do this too; this is a good way to have a simple human-readable message
without doing weird things to about extraneous newlines or strange
indent
ver break anything it should be more
> > tracable).
>
> +1
+1 here as well; there's no need to let things like this get out-of-sync from
what we want.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.or
as much of the information found in the W3C DOM as possible.
Something based more on the ElementTree API, perhaps. The value of the
W3C-approved API has certainly turned out to be more decoy than anything.
-Fred
--
Fred L. Drake, Jr.
___
.
On Friday 06 April 2007 10:31, [EMAIL PROTECTED] wrote:
> PEP 8 anyone?
New users should be exposed sooner than this; most will never read any PEP.
The tutorial seems like a good place. This is general good programming
practice we're talking about here, not style.
-Fred
-
ther occurrances of \em on the
trunk of in Py3K. The online build will catch up when the automated build
runs again.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
but it only was a problem of the text, not of the
> markup.
This doesn't seem to be a problem any more, so I'm going to presume Martin
fixed it. ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
inue pushing
that mis-feature on me. :-/
I appear to be receiving my Python lists just fine again.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
int:
r == int(r)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
gt; different ways for different libraries and having to make a (small, but
> annoying) semantic leap when going from, say, httplib to smtpllib or
> ftplib.
Agreed. In the meanwhile, there's socket.setdefaulttimeout(), which has
proved quite useful.
utput to the appropriate HTML / text output module?
> How does the HTML output module know how to handle non-standard metadata?
There's already __docformat__; see:
http://www.python.org/dev/peps/pep-0258/#choice-of-docstring-format
-Fred
-
y would have to study the details here, first.
If everything public gets included from Python.h, perhaps python/object.h and
friends could become pythonX.Y/object.h; I'm not sure this will solve the Mac
OS framework magic issue, though, not being a Mac OS developer.
-Fred
--
part I care about.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wednesday 03 January 2007 12:38, Guido van Rossum wrote:
> Maybe this should be done in a more systematic fashion? E.g. by giving
> all "internal" header files a "py_" prefix?
Even better.
+42
-Fred
--
Fred L. Drake, Jr.
e many problems with existing software as object.h
> shouldn't be included directly, anyway.
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
constant over a
magic number in code.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d
the value may need to be re-computed frequently anyway.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
t the numeric values mean with checking the
reference documentation.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
"layegg"?
Actually, why not just "egg"? That's parallel to "rpm" at least, and there
isn't such a command installed on my Ubuntu box already. (Using synaptic to
search for "egg" resulted in little that actually had "egg" in the name
wrong.
os.path is an alias for one of several different real modules; which is
selected depends on the platform. I see the following: macpath, ntpath,
os3emxpath, riscospath. (ntpath is used for all Windows versions, not just
NT.)
-Fred
look at the release PEP again...
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
generally interesting, as you note, and
remains open to crawlers.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
k I changed what was generated for float literals. That could be
my memory going bad, though.
The code changed several times as people with more numeric-fu that myself
fixed all sorts of border cases. I've tried really hard to stay away from
the code generator since then. :-)
-Fred
-
hat certainly sounds like it should be sufficient. The doc build should
never write anywhere but within the Doc/ tree; it doesn't even use the
tempfile module to pick up any other temporary scratch space.
-Fred
--
Fred L. Drake, Jr.
___
Py
referring to an old heading. That
does sound like a .aux file got left around.
I don't know what the build process is for the material in
docs.python.org/dev/; I think the right thing would be to start each build
with a fresh checkout/export.
-Fre
decoys than
usable end-user docs.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
document, and
> a placeholder for "what's new in python 2.6".
I suspect Google (and all other search engines) should be warded off from
docs.python.org/dev/.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@pyth
how these pages should be updated properly at the Arlington sprint this
weekend, at which point I can update PEP 101 appropriately and make sure this
gets done when releases are made.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-D
On Thursday 21 September 2006 20:21, Greg Ewing wrote:
>if x not in somelist:
> somelist.remove(x)
I'm just guessing you really meant "if x in somelist". ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev ma
et if it is a member.
>
> If the element is not a member, do nothing.
Would the argument be the key, or the pair? I'd guess the key.
If so, there's the 2-arg flavor of dict.pop():
>>> d = {}
>>> d.pop("key", None)
It's not terribly obvio
g (overly generic) jargon like unparsed and data.
I don't see the distinction between tail and rest as problematic. But I've
not used lisp for a long time.
> Whatever the final decision, it would probably be best to add an
> example to the docstring. "a.b.c&quo
> the ordering of the return tuple. OTOH, there is some small loss in
> that the head/tail terminology is highly suggestive of how to use the
> function when making succesive partitions.
See my previous note in this thread for another suggestion.
-Fred
--
) -> (tail, sep, rest)
Here, "rest" is always used for "what remains"; head/tail are somewhat more
clear here I think.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
On Saturday 02 September 2006 23:58, Anthony Baxter wrote:
> I think this is suitable for 2.5. I'm thinking, though, that we need a
> second release candidate, given the number of changes since rc1.
+1
-Fred
--
Fred L. Drake, Jr.
___
;s docs. This new patch corrects and clarifies
> numerous sections of the module's documentation.
Anthony did approve documentation changes for 2.5, so I've committed this for
2.5 and on the trunk (2.6). These should be considered for 2.4.4 as well.
(The
cessible to a reviewer. It's not the only way.
I can guess at Martin's thinking, but I'd rather let him speak for himself,
since I'm not a trained channeller. ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
hanges.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
what
he's been up to. ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sunday 30 July 2006 15:44, Barry Warsaw wrote:
> if isinstance(obj, ClassType) or isinstance(obj, type(type))
Looks like you've got a possible name clash in the second isinstance. ;-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mail
hose are the only reasonable solutions. I'd rather see things fixed,
but I don't know how much time Phillip has to work on it. I'll be working on
the straigtening out the xmlcore issue tonight/tomorrow.
-Fred
--
Fred L. Drake, Jr.
___
t; by "nobody" in the "Submitted By" column.
SourceForge supports anonymous reporting, but the Python project determined
that the management cost of anonymous reports was higher than the value they
provided.
It might be time to reconsider that decision (though my position hasn&
On Tuesday 18 July 2006 14:52, Mihai Ibanescu wrote:
> Unicode might be a perfectly acceptable suggestion for others too.
Are we still supporting builds that don't include Unicode? If so, that needs
to be considered in a patch as well.
-Fred
--
Fred L. D
On Friday 14 July 2006 01:45, Fredrik Lundh wrote:
> I'd prefer something like 90 days.
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
ses isn't where the problem is, I think. It's that,
once squeezed, more releases aren't being added to compensate. We really
need to determine what time we need to go from beta1 to (gamma|rc)1, and then
from (gamma|rc)1 to final. Plenty of interim releases
sure some of that is just me having my attention
elsewhere, I suspect a longer tail on the cycle to do gammas (or release
candidates, or whatever) would definately encourage more testing with
applications and the larger frameworks.
No, it won't catch everything, but I think it w
I know the .desktop files have become fairly standard, but are these our
responsibility or does that rest with the distributions/integrators? (I'm
not objecting, but I'm not sure what the right thing really is since Python
is an interpreter, not
ex() calls __hex__, etc.
> * __methods__ and __members__ are lists rather than callable
> objects, which means they cannot be updated on-demand
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http:/
On Monday 03 July 2006 14:07, Facundo Batista wrote:
> I want to know, please, if this is useful in general, for me to post a
> patch in SF.
It seems like something that should be easy, and lots of people need to
consider this for applications.
-Fred
--
Fred L. Dra
m trying to catch up on
that project's email, but don't expect it to be quick. Once I've had time to
discuss this with the current principal maintainer, it shouldn't be difficult
to get a 2.0.1 release out the door. Once that's done, it'll be t
til they get around to doing their next version push?
Sigh. Too much to do all around.
I'll try to take a look at this over the weekend.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
use frequently.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Silly little warnings about perfectly good data-only directories are just
silly.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On Monday 12 June 2006 20:42, Steve Holden wrote:
> Phillip J. Eby wrote:
> I'm sorry to contradict you, but every issue of significance is already
> known to be Barry's fault.
And don't forget, all the issues of no significance as well. Barry's been
busy! :-)
On Monday 12 June 2006 13:42, Guido van Rossum wrote:
> Maybe we
> should get serious about slimming down the core distribution and
> having a separate group of people maintain sumo bundles containing
> Python and lots of other stuff.
+1
-Fred
--
Fred
d identify the tests there that rely on the old behavior,
I'll be glad to look at the problems. I expect to have some time in the next
few evenings, so I should be able to look at these soon.
Is the SourceForge CVS the definitive development source for the feed parser?
. Now, I understand that
RSS has historical issues, with HTML-as-practiced getting embedded as payload
data with various flavors of escaping applied, and I'm not an expert in the
details of that. Have you looked at HTMLParser as an alternate to sgmllib?
It has better support for XHTML con
that xmlcore.etree will be there.
I'd rather not propogate the pain caused "xml" package insanity any further.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
oblem a nice-to-solve issue rather than a particularly
important issue. All the benefit is for PyXML, and shouldn't really impact
Python releases.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
uot;*-" operator is all about, and
- why we'd use it with a string and an int.
I see possibilities here. :-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
ecessarily abuse,
which is what seems to be the point of disagreement in this thread.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
he constraint (insertion of the "*"
marker), there doesn't appear to be any real issue here.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
On Tuesday 02 May 2006 22:32, Guido van Rossum wrote:
> and '@deco').
Pronounced "at-deck-oh", @deco is an art-deco variant favored in "r"-deprived
regions.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailin
extra time taken in the patch's `valuerefs`
> implementation to weed out weakrefs whose referents are already gone:
> the caller has to make this check anyway when it iterates over the
Good point; I've updated the patch accordingly.
-Fred
--
Fred L. Drake, Jr.
__
s, and the WeakValueDictionary gains
the .itervaluerefs() and .valuerefs() methods.
The patch includes tests and docs.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
ing dependencies on the specific signature of the
function. In a subsequent version of the function, the function is
determined to need additional information. The only way to add an
argument is to use a keyword for which there is no positional
equivalent.
-Fred
--
Fred L. Drake,
art using some of these modern desktops
just to get all the pretty pictures.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
us have with the proposal isn't the new
behavior, but the change in the behavior. That's certainly it for me.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
; writing this up).
I have tests that do this. This is a very real use case.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
nvironment: quote
Unknown environment: longtable
Wrong type argument: char-or-string-p, nil
make[1]: *** [python-lib.info] Error 255
make[1]: Leaving directory `/home/fdrake/projects/python/trunk/Doc/info'
make: *** [info] Error 2
-Fred
--
Fred L. Drake, Jr.
_
've put a lot of effort
into discussing it with the community, and applaud you for that as well as
your implementation efforts.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
hat way since December 1999 when Fred added it.
Looks like a bug to me. It should be set just before confstr() is called.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
On Friday 14 April 2006 06:35, Andrew Clover wrote:
> Files and preview here:
>
>http://doxdesk.com/img/software/py/icons2.zip
>http://doxdesk.com/img/software/py/icons2.png
Very nice!
-Fred
--
Fred L. Drake, Jr.
__
On Thursday 06 April 2006 18:09, Georg Brandl wrote:
> a while ago, Raymond proposed str.partition, and I guess the reaction
> was positive. So what about including it now?
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Pyth
oad area.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Monday 03 April 2006 14:45, Guido van Rossum wrote:
> Could one of the tracker admins add a Python-3000 group to the SF
> trackers (while we're still using them :-)? This is so we can easily
> move proposals between Python 3000 and Python 2.x status.
Done.
-Fred
--
Fre
hing between the decorators
and the "def"; having class decorators embedded within the class should still
allow the docstring to be the first thing, so there's more distance between
the decorator and the name being decorated. The extra hint about what's
being deco
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
>import db where db.stdlib == True and db.language == "SQL" \
> and db.interface == "DBAPI2.0"
While we're at it, we could spell import "select&quo
On Wednesday 29 March 2006 00:48, Fred L. Drake, Jr. wrote:
> I think the existing usage for classes is perfectly readable. The
> @-syntax works well for functions as well.
On re-reading what I wrote, I don't think I actually clarified the point I was
trying to make originally
thing. On the other hand, something
like:
class Foo:
"""Documentation is good."""
@class implements(IFoo)
is not ambiguous. Hmm. It even says what it means. :-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
27;d
want to change the existing pattern, though, since it's already so widespread
within the Zope 3 codebase (including 3rd-party components).
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ing System
Services."
> wsgiref can probably go in "Internet Protocols and Support", while
> ElementTree obviously goes under "Structured Markup Processing Tools".
Yes to both.
-Fred
--
Fred L. Drake, Jr.
___
ednesday night (US Eastern time).
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
1 - 100 of 203 matches
Mail list logo
