it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
/F
___
Python-Dev mailing list
Python-Dev@python.org
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
/F
On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh fred...@pythonware.com wrote:
it's reviews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove
* they did that. That *is* a community problem.
(Luckily, there are people helping out, and the nice people
driven-development rule overrides that other rule I mentioned, so
things will get tweaked sooner or later.)
/F
On Mon, Oct 5, 2009 at 1:02 PM, Nick Coghlan ncogh...@gmail.com wrote:
Fredrik
On Mon, Oct 5, 2009 at 8:48 PM, P.J. Eby p...@telecommunity.com wrote:
names for the same thing. (I'm guessing that PIL was registered on PyPI
manually, before the setup.py register command existed. Heck, it was
probably being distributed before the distutils even existed, and indeed
before
On Sat, Jun 20, 2009 at 6:57 PM, Martin v. Löwismar...@v.loewis.de wrote:
Fredrik Lundh wrote:
I think you really need to get Fredrik Lundh to comment on it. If he
can't predict when he'll be able to review the changes, maybe he can
accept releasing control of xmlrpclib.
Pointer to the patch
On Sat, Jun 20, 2009 at 6:57 PM, Martin v. Löwismar...@v.loewis.de wrote:
While I have your attention, please also review
http://bugs.python.org/issue6233
I'm pretty sure that fix is the wrong fix - afaik, _encode is used to
encode tag/attribute names, and charrefs don't work in that context.
2009/6/20 Martin v. Löwis mar...@v.loewis.de:
I‘d really like to get this stuff in. The performance gains allowing
http1.1 and gzip for xmlrpc are quite significant.
I think you really need to get Fredrik Lundh to comment on it. If he
can't predict when he'll be able to review the changes
http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/
mentions that Objects/frameobject.c contains a C99-style comment, which
means that Python 2.6 won't build on AIX.
shouldn't we use a suitable gcc option for the buildbots to prevent that
from happening?
/F
Brett Cannon wrote:
You sit in front of a bunch of people answering questions asked by the
audience. You know, a panel. =) It's just a QA session so that PyCon
attendees can ask python-dev a bunch of random questions. Demystifies
some things and puts faces to python-dev.
and using
the Code Migration and Modernization PEP hasn't been updated for 2.5
and 2.6.
http://www.python.org/dev/peps/pep-0290/
surely there's something new in 2.5 and 2.6 that might be worth mentioning?
/F
___
Python-Dev mailing list
C. Titus Brown wrote:
over on the pygr list, we were recently discussing a mildly confusing
edit I made:
assert 'seq1' in self.db, self.db.keys()
This was interpreted by someone as being
assert 'seq1' in (self.db, self.db.keys())
which is very different from the actual meaning,
Olemis Lang wrote:
Fetching external item into 'docutils'
svn: Can't connect to host 'svn.berlios.de': A connection attempt
failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond.
Barry Warsaw wrote:
I'm not going to release rc1 tonight. There are too many open release
blockers that I don't want to defer, and I'd like the buildbots to churn
through the bsddb removal on all platforms.
I'd like to try again on Friday and stick to rc2 on the 17th.
any news on this
Barry Warsaw wrote:
(I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but
have had absolutely no time to spend on that. is the window still open?)
There are 8 open release blockers, a few of which have patches that need
review. So I think we are still not ready to release
Terry Reedy wrote:
In particular, built-in functions, in spite of of being labeled
'builtin_function_or_method', are not usable as methods because they
lack the __get__ method needed to bind function to instance.
They're not usable as Python-level instance methods, but they're
definitely
Benjamin Peterson wrote:
Does anybody ever complain about not being able to use isinstance on
twisted.application.Application? (At least it's documented as a
function there.)
the threading non-classes are documented to be factory functions on
the module page.
/F
Antoine Pitrou wrote:
event_class = Event().__class__ ?
Not pretty I know :-)
somewhat prettier, assuming 2.3 or newer:
import threading
e = threading.Event()
type(e)
class 'threading._Event'
isinstance(e, type(threading.Event()))
True
(but pretty OT)
/F
Kilian Klimek wrote:
Saying your method must accept an extra parameter (which most people
call 'self') that carries all object attributes is hardly any more
explicit then saying there is a special variable (which is always named
'this') that carries all object attributes.
in this context,
Guido van Rossum wrote:
I can't reproduce this as described.
Which Windows version? This sounds like one of those things that could
well vary by Windows version; if it works for you in Vista it may well
be broken in XP. It could also vary by other setup parameters besides
PATHEXT.
It works
Curt Hagenlocher wrote:
I've found the documentation for CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty
reliable. And the mention of a .com in the docs suggests that the
description has been around for a while...
And I just described it as pretty vague ;-)
(using 3.0a4)
exec(open(file.py))
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: exec() arg 1 must be a string, file, or code object, not
TextIOWrapper
so what's file referring to here?
(the above works under 2.5, of course)
/F
Fredrik Lundh wrote:
(using 3.0a4)
ahem. I could have sworn that I installed a beta, but I guess the
Windows builds weren't fully synchronized when I did that. I still get
the same error after updating to 3.0b2, though.
(the download page still says This is an alpha release, btw.)
/F
Barry Warsaw wrote:
I agree. This seriously feels like new, potentially high risk code to
be adding this late in the game. The BDFL can always override, but
unless someone is really convincing that this is low risk high benefit,
I'd vote no for 2.6/3.0.
at least two Unicode experts have
Barry Warsaw wrote:
You don't mean the experts claimed they weren't important, right?
Unimportant changes definitely don't need to go in now wink.
Well, at least Guido managed to figure out what I was trying to say ;-)
/F
___
Python-Dev mailing
Amaury Forgeot d'Arc wrote:
when I'm trying to build extensions under Python 2.6 on Windows XP, the
build process terminates with single line that says:
error: None
which is about as useless as an error message can be. Googling for this
brings up a few hits which all seem to involve
Thomas Heller wrote:
I'm beginning to suspect that I have a botched VS install on this
machine, though. I'll investigate.
Do you get a traceback when you set the DISTUTILS_DEBUG environment
variable?
Indeed I do:
...
File c:\python26\lib\distutils\msvc9compiler.py, line 436, in
Tres Seaver wrote:
- -1. The feature exists to allow adherence to PEP-8, Limit all lines to
a maximum of 79 characters., without requiring runtime concatenation
costs. I use it frequently when assembling and testing message strings,
for instance.
removing it is a bad idea for the reasons
Isaac Morland wrote:
This would avoid accidentally leaving out commas in list construction,
but tuple construction would still have the same problem.
Tuple construction already has a no comma, no tuple problem. That
problem remains, but as soon as you add a comma, you'll get the same
when I'm trying to build extensions under Python 2.6 on Windows XP, the
build process terminates with single line that says:
error: None
which is about as useless as an error message can be. Googling for this
brings up a few hits which all seem to involve setuptools (and none of
the
On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
So while we could say: we provide access to the Unicode 5.1.0
database, we cannot say: we support Unicode 5.1.0, simply because
we have not reviewed the all the necessary changes and implications.
Mark's response to
On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
(how's the 3.2/4.1 dual support implemented? do we have two distinct
datasets, or are the differences encoded in some clever way? would it
make sense to split the unicodedata module into three separate
modules, one
when did Python-Dev turn into a members only list, btw?
---
Your mail to 'Python-Dev' with the subject
Re: Unicode 5.1.0
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
---
Bartlomiej Wolowiec wrote:
For some time I'm interested in regular expressions and Finite State Machine.
Recently, I saw that Python uses Secret Labs' Regular Expression Engine,
which very often works too slow. Its pesymistic time complexity is O(2^n),
although other solutions, with time
Guido van Rossum wrote:
What about reimplementing commands.* using subprocess? Or providing a
commands.*-compatible interface in the subprocess module?
What does that buy us?
multi-platform support? (commands is Unixoid only, right?)
/F
___
Martin v. Löwis wrote:
I never considered it an extension. Ask 10 people around you to see
what a leading dot on Unix in a file name means, and I would be
suprised if more than one answered it separates the file name from
the extension. Most of them likely include hidden file in their
Guido van Rossum wrote:
My suspicion is that building Python for an 64-bit address space is
still a somewhat academic exercise.
arbitrary 64-bit systems, perhaps. the first Python system I ever built was
deployed
on an LP64 system back in 1995. it's still running, and is still being
Talin wrote:
Rather than fixing on a standard markup, I would like to see support for
a __markup__ module variable which specifies the specific markup
language that is used in that module. Doc processors could inspect that
variable and then load the appropriate markup translator.
Ideally, a
Guido van Rossum wrote:
Even apart from the website that Samuele found, the content sounded
genuine. Just not something I feel like dealing with (too many
surveys).
from what I can tell, it was blasted to everyone with a sourceforge
account, which indicates that they're don't really care
Kurt B. Kaiser wrote:
Going mainstream :-))
indeed. from what I can tell on my local market, we've crossed the chasm
[1], and
are seeing wider range of pragmatists adding Python to the tool chain.
The Rails buzz seems to be jumping to Python lately.
fwiw, the people I see pick up Python
Martin v. Löwis wrote:
I've just been putting together a podcasting doodad and have included
resuming
support in it. Is this something that's already in the pipeline or should I
abstract it out to urllib and submit a patch?
Not sure where you got the impression that 206 is resume; in my
Martin v. Löwis wrote:
given that urllib2 already supports partial requests, I'm not sure I see
the point of reimplementing this on top of httplib. an example:
import urllib2
request = urllib2.Request(http://www.pythonware.com/daily/index.htm;)
request.add_header(range,
Guido van Rossum wrote:
That was the month of October.
If people believe these numbers are real, we're doing great!!!
2.5 was of course released in september, so I assume that part of
what you're seeing is simply tinkerers upgrading their existing
installations.
plotting weekly figures for
Talin wrote:
Maybe instead of considering a match object to be a sequence, a match
object should be considered a map?
sure, except for one small thing. from earlier in this thread:
Ka-Ping Yee wrote:
I'd say, don't pretend m is a sequence. Pretend it's a mapping.
Then the
Talin wrote:
The original proposal was to make m[n] a synonym for m.group(n).
group() is clearly map-like in its behavior.
so have you checked what exception m.group(n) raises when you try to
access a group that doesn't exist ?
frankly, speaking as the original SRE author, I will now flip
M.-A. Lemburg wrote:
This was added to make the transition to all Unicode in 3k easier:
thanks for the clarification.
do you recall when this was added? 2.5?
/F
___
Python-Dev mailing list
Python-Dev@python.org
Michael Urman wrote:
The idea that slicing a match object should produce a match object
sounds like a foolish consistency to me.
well, the idea that adding m[x] as a convenience alias for m.group(x)
automatically turns m into a list-style sequence that also has to
support full slicing sounds
Ben Wing wrote:
i'm ok either way -- that is, either with the proposal i previously
published, or with this restricted idea.
ok, I'll whip up a patch for the minimal version of the proposal, if
nobody beats me to it (all that's needed is a as_sequence struct with a
item slot that basically
Alastair Houghton wrote:
(The current groups() method *doesn't* match those expectations,
incidentally. I know I've been tripped up in the past because it
didn't include the full match as element 0.)
that's because there is no group 0 in a regular expression; that's
just a historical
Martin v. Löwis wrote:
In any case, having Python in the LSB means that ISVs (software
vendors) who target LSB (rather than targetting specific Linux
distributions) could develop their applications also in Python
(whereas now they have to use C or C++).
... without having to include a Python
Steven Bethard wrote:
Fredrik Lundh has been working on a `new Python FAQ`_
footnote: working on cleaning up the old FAQ, to be precise. it'll end
up on python.org, as soon as Andrew Kuchling gets around to complete his
FAQ renderer (which may take a while, since he's busy with PyCon 2007
Ka-Ping Yee wrote:
I'd say, don't pretend m is a sequence. Pretend it's a mapping.
Then the conceptual issues go away.
almost; that would mean returning KeyError instead of IndexError for
groups that don't exist, which means that the common pattern
a, b, c = m.groups()
cannot be
Martin v. Löwis wrote:
Several issues need to be taken into account:
the most important issue is that if you want an object to behave as a
sequence of something, you need to decide what that something is before
you start tinkering with the syntax.
under Ben's simple proposal, m[:][1] and
Martin v. Löwis wrote:
Ah, right; I misread his proposal as saying that m[:] should return
[m[0]] + list(m.groups()) (rather, I expected that m.groups() would
include m.group(0)).
match groups are numbered 1..N, not 0..(N-1), in both the API and in the
RE syntax (and we don't have much
Martin v. Löwis wrote:
match groups are numbered 1..N, not 0..(N-1), in both the API and in the
RE syntax (and we don't have much control over the latter).
py m = re.match(a(b),ab)
py m.group(0)
'ab'
py m.group(1)
'b'
0 isn't a group, it's an alias for the full match.
/F
Martin v. Löwis wrote:
I know what the Zen says about special cases, but in this case the rules
were apparently broken with impunity.
Well, the proposal was to interpret m[i] as m.group(i), for all values
of i. I can't see anything confusing with that.
it can quickly become rather
Martin v. Löwis wrote:
it can quickly become rather confusing if you also interpret m[:] as
m.groups(), not to mention if you add len() and arbitrary slicing to
the mix. what about m[] and m[i,j,k], btw?
I take it that you are objecting to that feature, then?
I haven't seen a complete
Guido van Rossum wrote:
it would be a good thing if it could, optionally, be made to report
horizontal whitespace as well.
It's remarkably easy to get this out of the existing API
sure, but it would be even easier if I didn't have to write that code
myself (last time I did that, I needed a
Frank Lomax wrote:
The PSU does not, nor ever has existed. Any statement implying
otherwise is false and subversive. There is no PSU and even if there
is, it has no influence whatsoev
it's a bit interesting that every time someone writes something along
those lines, their computer's
Martin v. Löwis wrote:
Like I said, it's possible to split Python without making things
complicated for newbies.
You may have that said, but I don't believe its truth. For example,
most distributions won't include Tkinter in the standard Python
installation: Tkinter depends on _tkinter
tomer filiba wrote:
no, it requires *infinity* to accomplish x - y == x; y != 0, for example:
while limit 0:
limit -= len(chunk)
with limit = posinf, the above code should be equivalent to while True.
that's a remarkably stupid way to count bytes. if you want to argue for
Talin wrote:
But it isn't just the docs that are at fault here - otherwise, I'd be
posting this on a different mailing list. It seems like the whole
architecture is 'diff'-based, a series of patches on top of patches,
which are in need of some serious refactoring.
so to summarize, you
Armin Rigo wrote:
Yuk! Not renamed to .py files. Distributing .py files that are
actually bytecode looks like a new funny way to create confusion. No, I
was half-heartedly musing about introducing Yet Another file extension
(.pyc for caching and .pyX for importable bytecode, or possibly
Ka-Ping Yee wrote:
Wow. Did you catch this news?
http://www-tech.mit.edu/V125/N65/coursevi.html
The first four weeks of C1 will be a lot like the first
four weeks of 6.001, Abelson said. The difference is
that programming will be done in Python and not Scheme.
This story
Martin v. Löwis wrote:
I'd like to share an observation on portability of extension
modules to Python 2.5: python-ldap would crash on Solaris, see
http://groups.google.com/group/comp.lang.python/msg/a678a969c90f21ab?dmode=sourcehl=en
It turns out that this was caused by a mismatch in
(reposted from c.l.py)
the following FAQ item talks about using sleep to make sure that threads
run properly:
http://effbot.org/pyfaq/none-of-my-threads-seem-to-run-why.htm
I suspect it was originally written for the thread module, since as
far as I know, the threading module takes care of the
Martin v. Löwis wrote:
Patch #1067760 deals with passing of float values to file.seek;
the original version tries to fix the current implementation
by converting floats to long long, rather than plain C long
(thus supporting files larger than 2GiB).
I propose a different approach: passing
I guess I should remember, but what's the rationale for not including
even a single concrete tzinfo implementation in the standard library?
not even a UTC class?
or am I missing something?
/F
___
Python-Dev mailing list
Python-Dev@python.org
Martin v. Löwis wrote:
I guess I should remember, but what's the rationale for not including
even a single concrete tzinfo implementation in the standard library?
not even a UTC class?
or am I missing something?
If you are asking for a time-zone database
I was more thinking of basic
Guido van Rossum wrote:
IMO it was an oversight. Or we were all exhausted. I keep copying
those three classes from the docs, which is silly. :-)
I'll whip up a patch. would the embedded python module approach I'm
using for _elementtree be okay, or should this go into a support library ?
/F
Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that *overrides* the standard
dir() behaviour. *adding* to the default
Guido van Rossum wrote:
I think that ought to go into the guidlines for what's an acceptable
__dir__ implementation. We don't try to stop people from overriding
__add__ as subtraction either.
to me, overriding dir() is a lot more like overriding id() than over-
riding +. I don't think an
Martin v. Löwis wrote:
Andrew Dalke schrieb:
urlparse.urljoin(http://blah.com/;, ..)
'http://blah.com/'
urlparse.urljoin(http://blah.com/;, ../)
'http://blah.com/../'
urlparse.urljoin(http://blah.com/;, ../..)
'http://blah.com/'
Does the result make sense to you? Does it make
sense
Steve Holden wrote:
Ah, but how do you know when that's wrong? At least under ftp:// your
root is often a mid-level directory until you change up out of it.
http:// will tend to treat the targets as roots, but I don't know that
there's any requirement for a /.. to be meaningless (even if it
Steve Holden wrote:
Although the last two smell like bugs, the point of urljoin is to make
an absolute URL from an absolute (current page) URL
also known as a base URL:
http://www.w3.org/TR/html4/struct/links.html#h-12.4.1
(os.path.join's behaviour is also well-defined, btw; if any
[EMAIL PROTECTED] wrote:
I am not addressing this message to the py3k list because its general
message of extreme conservatism on new features is more applicable to
python-dev. However, py3k designers might also take note: if py3k is
going to do something in this area and drop support for
[EMAIL PROTECTED] wrote:
I assert that it needs a better[1] interface because the current
interface can lead to a variety of bugs through idiomatic, apparently
correct usage. All the more because many of those bugs are related to
critical errors such as security and data integrity.
Chris Barker wrote:
While /F suggested we get off the PIL bandwagon
I suggest we drop the obsession with pointers to memory areas that are
supposed to have a specific format; modern data access API:s don't work
that way for good reasons, so I don't see why Python should grow a
standard based
Talin wrote:
I'm right in the middle of typing up a largish post to go on the
Python-3000 mailing list about this issue. Maybe we should move it over
there, since its likely that any path reform will have to be targeted at
Py3K...?
I'd say that any proposal that cannot be fit into the
Terry Reedy wrote:
I believe that at present PyGame can only work with external images that it
is programmed to know how to import. My guess is that if image source
program X (such as PIL) described its data layout in a way that NumPy could
read and act on, the import/copy step could be
Talin wrote:
You probably want to use the posixpath module directly in that case,
though perhaps you've already discovered that.
Never heard of it. Its not in the standard library, is it? I don't see
it in the table of contents or the index.
http://effbot.org/librarybook/posixpath.htm
[EMAIL PROTECTED] wrote:
I'm not sure what a pebkac problem is.
http://en.wikipedia.org/wiki/PEBKAC
You'll learn some new nonsense every day ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Josiah Carlson wrote:
It would be a radical change for Python 2.6, and really the 2.x series,
likely requiring nontrivial changes to extension modules that deal with
strings, and the assumptions about strings that have held for over a
decade.
the assumptions hidden in everyone's use of the
Larry Hastings wrote:
Am I correct in understanding that changing the Python minor revision
number (2.5 - 2.6) requires external modules to recompile?
not, in general, on Unix. it's recommended, but things usually work
quite well anyway.
/F
___
Larry Hastings wrote:
I knocked out a prototype of this last week, emailed Mr. Lundh about it,
then forgot about it.
It's on my TODO list, so I haven't forgotten about it, but I've been (as
usual) busy with other stuff. I'll get there, sooner or later.
Posting this to the patch tracker and
Talin wrote:
Interesting - is it possible that the same technique could be used to
hide differences in character width? Specifically, if I concatenate an
ascii string with a UTF-32 string, can the up-conversion to UTF-32 also
be done lazily?
of course.
and if all you do with the result
Martin v. Löwis wrote:
In 2.3.6, there wouldn't just be that change, but also a few other
changes that have been collected, some relevant for Windows as well
why not just do a 2.3.5+security source release, and leave the rest to the
downstream maintainers?
/F
Anthony Baxter wrote:
why not just do a 2.3.5+security source release, and leave the rest to
the downstream maintainers?
I think we'd need to renumber it to 2.3.6 at least, otherwise there's the
problem of distinguishing between the two. I'd _hope_ that all the
downstreams will have
Brett Cannon wrote:
I know AMK was experimenting with rest2web as a possible way to do the
web site. There has also been talk about trying out another system.
But I also know some people would rather put the effort into improving
Pyramid.
You forgot the ponies!
Once again, it's a
Anthony Baxter wrote:
The other thing to watch out for is that I (or whoever) can still do local
work on a bunch of different files
the point of my previous post is that you *shouldn't* have to edit a
bunch of different files to make a new release.
/F
Alexey Borzenkov wrote:
P.S. Although it's a bit stretching, one might also say that
implementing spawn*p* on windows is not actually a new feature, and
rather is a bugfix for misfeature. Why every other platform can
benefit from spawn*p* and only Windows can't? This just makes
os.spawn*p*
Anthony Baxter wrote:
For reference, here's my effbot.org release procedure:
1) upload the distribution files one by one, as soon as they're
available. all links and stuff will appear automatically
2) update the associated description text through the web, when
necessary, as an HTML
Nick Coghlan wrote:
would collapse to
static PyTypeObject NoddyType;
Wouldn't that have to be a pointer to allow the Python runtime complete
control of the structure size without recompiling the extension?:
static PyTypeObject *NoddyType;
yeah, that's a silly typo. or maybe
Alexey Borzenkov wrote:
any reason you cannot just use the subprocess module instead, like
everyone else?
Oh! Wow! I just simply didn't know of its existance (I'm pretty much
new to python), and both distutils and SCons (I was looking inside
them because they are major build systems and
Anthony Baxter wrote:
16 releases in 12 months would just about make me go crazy.
is there any way we could further automate or otherwise streamline or
distribute the release process ?
ideally, releasing (earlier release + well-defined patch set) should be
fairly trivial, compared to releasing
Greg Ewing wrote:
Fredrik Lundh wrote:
marshal hasn't changed in many years:
Maybe not, but I was given to understand that it's
regarded as a private format that's not guaranteed
to remain constant across versions. So even if
it happens not to change, it wouldn't be wise to
rely
Martin v. Löwis wrote:
Of course, if everybody would always recompile all extension modules
for a new Python feature release, those flags weren't necessary.
a dynamic registration approach would be even better, with a single entry point
used to register all methods and hooks your C extension
I wrote:
PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods);
methods and members could of course be registered to, so the implementation can
chose
how to store them (e.g. short lists for smaller method lists, dictionaries for
others).
/F
Greg Ewing wrote:
if you're aware of a way to do that faster than the current marshal
implementation, maybe you could work on speeding up marshal instead?
Even if it weren't faster than marshal, it could still
be useful to have something nearly as fast that used
a
I forgot the import statement (especially the * version)
not only that, you also forgot what mailing list you were posting to...
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Neal Becker [EMAIL PROTECTED] wrote:
http://www.google.com/codesearch?q=+doc:DxlBcBw4TXo+proprietary+confidential+show:DxlBcBw4TXo:BwgQSUaGDCc:1s0hP8rbIGEsa=Ncd=1ct=rics_p=http://www.python.org/download/releases/binaries-1.3/python-IRIX-5.3-full.tar.gzcs_f=lib/python/irix5/AWARE.py#a0
that's
1 - 100 of 622 matches
Mail list logo
