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
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
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
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
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
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&
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.
___
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
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
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
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
;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
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.
___
) -> (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
> 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
--
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
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
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
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
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
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
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
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
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
-
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
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
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
"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
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
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
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
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
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.
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
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
--
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
-
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.
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
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:
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
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
.
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
-
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.
___
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
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
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
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
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:
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.
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 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.
___
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
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
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
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 '&
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
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.
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.
__
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
_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
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
--
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
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
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 Tuesday 30 November 2004 02:46 pm, Thomas Heller wrote:
> http://www.python.org/doc/current/
> and
> http://docs.python.org/
>
> still point to 2.3.4 docs.
I'll be fixing that up tonight.
-Fred
--
Fred L. Drake, Jr.
__
On Tuesday 30 November 2004 02:46 pm, Thomas Heller wrote:
> http://www.python.org/doc/current/
> and
> http://docs.python.org/
>
> > still point to 2.3.4 docs.
I think everything is properly updated now. Please let me know if I've missed
anything.
-Fred
hat
> should be included, but it seems an example or two would make it easy to
> get right.
Examples would be good, though specific wording should not be proscribed.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
[EMAIL PROTECTED]
? The 26th is a public holiday here,
> and so that's the day that's most likely for me...
Sounds good to me. Anything in that range is equally doable.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python
ctions is not a backward compatibility concern. :-)
-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
tell setup.py
> to look where they are installed.
...
> This might be an excellent sprint topic for PyCon.
Indeed it would be!
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
GC since Windows will be convinced that the file is still
open and refuse to let you delete it. To fix that, you'd have to trigger GC
from the failed removal operation and try again.
I think we'd find there are a lot more operations that need that support than
we'd like to thi
o.html
for information on posting opportunities there.
-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-
time, so, again,
I'd rather be conservative in what we generate.
-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
place(microsecond=0).isoformat()
>
> suffices for that much. Tack on .replace('-', '') to do the whole job.
Yep, that would work too.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http:/
m to be
anything that describes the range of what's accepted and produced by the
various XML-RPC libraries, but I've not looked hard for it.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
/Lib/idlelib/idlever.py,v
> -IDLE_VERSION = "1.1.1"
> +IDLE_VERSION = "1.1.1c1"
Shouldn't this progress from 1.1.1 to 1.1.2c1? Otherwise it's moving
backward.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mail
On Wednesday 09 March 2005 12:06, Anthony Baxter wrote:
> No - Py2.4 shipped with idle 1.1. I must've updated it to 1.1.1 sometime
> after the 2.4 release (I vaguely recall doing this).
Ah, ok. I guess I should have looked.
-Fred
--
Fred L
uld be very helpful.
Patch reviews should be written in the tracker, as always, and a summary of
all the webbrowser-related patches in a single email to python-dev.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@pyth
ta-Version 1.2. Some sort of Metadata-Encoding field should be
included. There should also be a field for the version of Python that's
required.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
er. For now, you can include
comments in the long description or on a project web page. A proper field
will be added for this in the future (hopefully not too distant).
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
see uploads for two or
more versions of Python (PyXML for example). Getting the metadata wrong is
just too evil. Now that more people have seen the code for PyPI (and
understand more of it), it'll be easier to implement new fields once they&#
robably be controllable via the API, if its useful at all.
-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
evelopment environment, a developer should not find difficulty to
> reverse that if needed.
Right. I think if the API provides a control for this and some mention is
made in the documentation, that would be good.
-Fred
--
Fred L. Drake, Jr.
___
Py
ason they were really introduced: to enhance readability.
-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 host
platforms, would be helpful.
-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
can change the text used
to describe them. So "Python 2.2.2" can become "Python 2.2.2
(unmaintained)". Whether this is desirable or not, I'm not sure.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-
d be a way to say that
certain categories/groups were marked unusable for new submissions. But
that's not necessary in any way.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
is currently handled automatically.
-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
ealize more than ever before the
> importance of keeping URLs stable; PageRank(tm) numbers don't get
> transferred as quickly as contents. I have this worry too in the
> context of the python.org redesign; 301 permanent redirect is *not*
> going to help PageRank of the new page.
sion.
bytes([0, 1, 2, 3])
-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
from the stream with the
previous encoding, but that seems like it would be pretty fragile in
practice.
There may be cases where switching encoding on the fly makes sense, but I'm
not aware of any actual examples of where that approach would be required.
-Fr
f the
documentation). I'm not really on either side of the fence about whether
docs.python.org is the "right thing" to do; the idea came out of the folks
interested in advocacy.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mai
with it had not been fully spelled out).
-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
n massively
swamped. python-dev topics occaissionally pop up for me, but time has been
too limited to get back to the important items, like this one.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
all the cases I've actually dealt
with where I wanted a variation of a mapping with default values.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
here this commonly comes up, but not the only one.
> and in the process breaking an important
> quality of good Python code, that attribute and getitem access not have
> noticeable side effects.
I'm not sure that's quite as well-defined or agreed upon as you do.
; any chance we can switch to that on
buildbot.zope.org as well? ;-) The improved use of horizontal space is
good.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Sunday 19 February 2006 18:07, Walter Dörwald wrote:
> How about this one:
> http://styx.livinglogic.de/~walter/python/BuildBot_%20Python.html
Sigh. This is nice too. Now I'm not sure which I'd rather see on
zope.org. ;-)
-Fred
--
F
new variable, but that's minor.
-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
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
