Robert Kern wrote:
>>> Oh, that's right, you need an import library for Python24.dll .
>> That shouldn't be a problem: that library is included with Python.
>
> For mingw, too? I.e. a .a not a .lib?
Right.
Martin
--
http://mail.python.org/mailman/listinfo/python-list
y not true. You can build the entire Python interpreter
with Cygwin (but you don't need to, because there is a precompiled
version), and you can build extensions for the python.org binary
using MingW.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
the Windows
distributions.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
oking the
compiler manually.
There were times when cygwin couldn't link with .DLLs unless
they were created with GNU ld, but these times are long past
history.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
that could be dropped easily) - yet still, the Python
binary will depend on a specific version of the MS CRT.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
me
mangling, so you can't use GCC to link against MSVC-compiled
C++ libraries.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
annot redistribute these DLLs when I compile with MingW
(unless I also have a copy of VS.NET - I would have to reread its
license to find out whether it requires that the application is actually
built with MSVC to allow for redistribution).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
svcrt.dll. So if Python is linked against msvcrt.dll, you can't really
build C++ extensions anymore (with MSVC), unless you are certain that
mixing CRTs causes no harm for your application.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Cygwin application is a native Win32 application, which just happens
to link with cygwin1.dll (which also is a native Win32 DLL).
Just to make that clear: Everything that cygwin does is done solely with
the Win32 API. The C library differs in semantics from the MS C library,
but the system A
this does
not apply to the whole world (yet).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ating strings 'by hand'.
Not sure I understand the question. If you process data in cp1252,
then \x94 and \x94 are legal characters, and the Python codec should
support them just fine.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Pramod TK wrote:
> Is this new function getaddrinfo() of IPv6 is supported in Win32 Extensions
> for python.
Yes, since Python 2.4 (actually, not in the Win32 extensions, but in the
standard Python socket module for Win32).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
t is the case: What is the problem then? If you interpret
the document as cp1252, and it contains \x93 and \x94, what is
it that you don't like about that? In yet other words: what actions
are you performing, what are the results you expect to get, and
what are the results that you actually get?
Ross Ridge wrote:
> Martin v. Löwis wrote:
>> http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
>>
>> 'The msvcrt.dll is now a "known DLL," meaning that it is a system
>> component owned and built by Windows. It is intended for fut
ree is dropped in favour of a "direct" implementation
(e.g. based on HeapAlloc), then Python could become a "native Win32
application" in the sense you defined above.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
sion of MFC that also links with msvcrt.dll.
I understand VC6 would work; not sure whether pywin32 can still
be built with VC6. In any case, requiring an even older version
of the MS compiler isn't such a tempting idea, either.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
possible to build extentions
> with any version of MSVC, instead of just the one that Python was built
> with.
How would you build for MSVCRT.DLL using MSVC 7 or 8? You don't have
the header files for that library, and you don't have the import
library.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
andom decodings and cp1252 seemed to work. I
> don't like to have to guess this way. I think John wouldn't even allow
> it :-)
Well, if the document is UTF-8, you should decode it as UTF-8, of
course.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
John Salerno wrote:
Most FTP servers do allow to use chmod in a ftp session, although you're
client must support it. See for example a cli ftp client (and server) on
FreeBSD.
> [EMAIL PROTECTED]:~$ ftp ftp.xs4all.nl
> Connected to ftp2.xs4all.nl.
> 220 XS4ALL ftpd DCLXVI
> Name (ftp.xs4all.nl:
licitly on the sender).
> If not, are there any nice alternatives to XML-RPC that
> support this?
CORBA certainly supports 64-bit integers.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Hi all,
I created a class which creates a relative unique id string, now my
program just works fine and as expected but somehow I get the feeling
that I misused the __repr__ since I guess people expect to 'execute' a
function in an instance instead of using it's representation string of
the in
Bruno Desthuilliers wrote:
>
> Why not just use the call operator instead ? ie:
>
> >>> id = IDGenerator(...)
> >>> id()
> 01_20060424_151903_1
> >>> id()
> 01_20060424_151905_2
>
Because of:
id = IDGenerator("01",99)
id()
> Traceback (most recent call last):
> File "", line 1,
keirr wrote:
> Martin P. Hellwig wrote:
>> Hi all,
>>
>> I created a class which creates a relative unique id string, now my
>> program just works fine and as expected but somehow I get the feeling
>> that I misused the __repr__ since I guess people expect to '
bruno at modulix wrote:
> Martin P. Hellwig wrote:
>> Bruno Desthuilliers wrote:
>>
>>
>>> Why not just use the call operator instead ? ie:
>>>
>>> >>> id = IDGenerator(...)
>>> >>> id()
>>> 01_2006
Thanks for the input folks!
I adapted my script to the given suggestions and it's now far more
'logical', for reference I added it below.
--
mph
- script -
> import string
> import time
>
> class IDGenerator(object):
> """(leading_id, subversion_length, tz) # tz = 'local' or 'gm'
san wrote:
> Hi
>
> I am using windows xp and have installed python and win32. I am
> familiar with basic Python. I wanted to control some of the
> applications via python script.
>
> I would like to write a python script to say:
> 1. Open firefox and log on to gmail
> 2. Another firefox window t
Bill Atkins wrote:
>
> How do you define scalability?
>
http://www.google.com/search?hl=en&q=define%3Ascalability&btnG=Google+Search
;-)
--
mph
--
http://mail.python.org/mailman/listinfo/python-list
Bill Atkins wrote:
> "Martin P. Hellwig" <[EMAIL PROTECTED]> writes:
>
>> Bill Atkins wrote:
>>
>>> How do you define scalability?
>>>
>> http://www.google.com/search?hl=en&q=define%3Ascalability&btnG=Google+Search
>>
>&
Paul Rubin wrote:
> "Martin P. Hellwig" <[EMAIL PROTECTED]> writes:
>> and clients make it quite scalable. For example, I'm creating a
>> xmlrpcserver that returns a randomized cardlist, but I because of
>> fail-over I needed some form of scalability ,
Paul Rubin wrote:
> "Martin P. Hellwig" <[EMAIL PROTECTED]> writes:
>>> This is a weird approach. Why not let the "ticket" by the (maybe
>>> encrypted) PRNG seed that generates the permutation?
>> Because the server that handles the generate r
[EMAIL PROTECTED] (Alex Martelli) writes:
> Didn't want to trigger some flamewar;-), but, yes, if that was my only
> choice, I'd much rather use small, simple Scheme than huge, complicated,
> rich, powerful Common Lisp. ((But in this case I'm biased by early
> experiences, since when I learned and
or indirectly) the repr() function
to convert a tuple into that string. You shouldn't do that;
instead, you should format the elements of the tuple yourself, e.g.
through
print >>f, u"('%s', '%s')" % value
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
onments--why do we
> tolerate their omission on the Windows platform?
We tolerate them because they aren't omitted. They are readily
available, and we are all lazy enough to never do more than just
post to a newsgroup complaining about it.
> It's time to bundle PythonWin.
So go an
PythonWin could be automatically combined into the
> installer by downloading the latest version from SourceForge, perhaps.
That is technologically challenging. Contributions are welcome.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
code to make any sense.
You have probably chosen to edit the code in order to not show us
your real code. Unfortunately, since you are a newbie in Python,
you make errors in doing so, and omit important details. That makes
it very difficult to help you.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
t work, I would like to know what the exact
value of gloss is, do
print "GLOSS IS", repr(gloss)
to print it out.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
retains their unicode status.
Correct. The result is a Unicode string if the joiner is a Unicode
string, and all tuple elements are Unicode strings. If one is not,
a conversion to Unicode is attempted.
> In the text file, the unicode characters appear perfectly, so I'm very
> happy.
G
*by definition*, though :-) For those that have not followed
encodings too closely: gb18030 is to gb2312 what UTF-8 is to ASCII.
Both encode the entire Unicode in an algorithmic way, and provide
byte-for-byte identical encodings for the for their respective
subset.
Regards,
Martin
--
http://mail.pyt
646:1968. It's not *quite* the same as ASCII, as it leaves a
certain number of code points unassigned that ASCII defines (most
notably, the dollar sign, and the square and curly braces). What Sun
means is probably the "International Reference Version" of ISO 646,
which is (
Petter Haggholm wrote:
> Any help, thoughts, or advice would be vastly appreciated.
After changing PyObject_HEAD, I would run "make distclean".
Most likely, some object files were not recompiled and still
using the old layout.
Regards,
Martin
--
http://mail.python.org/mailman/li
u change the
directory name to be a byte string, the file name should be a byte
string, too.
And yes, it would be desirable to enhance system() to support Unicode
strings; contributions in that direction are welcome (although one
should then also support exec*(), spawn*(), popen*(), and the subproces
creating a new one. Although he explicitly said "clear
the list", he might have meant "make it so that the variable refers to
an empty list", to which clearing the list is only one possible
solution.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
more convenient, for use with ElementTree.
(side note: I think it would be better if ElementTree treated the
.entity mapping similar to DTD ENTITY declarations, assuming internal
entities. The the OP's code might have worked out of the box. That
would be an incompatible change also, of
apparently causing the '&' to be taken
as a literal ampersand, and not as markup.
That said, it *would* be possible to change htmlentitydefs in Python
3.0, to always map to Unicode characters; this would not be possible for
2.x (as Fredrik points out).
Regards,
Martin
--
http://mail.py
> Whatever you want to call it, the Python DLL is not part of the operating
> system, it's not a driver and doesn't belong in the system directory.
Is that just your personal opinion, or a guideline from the operating
system vendor?
Regards,
Martin
--
http://mail.python.org/
another
>> one, msvcr71.dll.
>
> The C runtime doesn't create objects.
Depends on your definition of "object". fopen will create objects,
and passing those to a different CRT will cause crashes.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ems().
> and even if you fix that, it doesn't work for all Python
> versions that ET works for...
That's true. However, the OP seemed to care only about Python 3.0
initially.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
t;iso-2022-jp")
unicode("\x1b(JHallo","iso-2022-jp")
unicode("\x1b(BHal\x1b(Jlo","iso-2022-jp")
or likewise
unicode("[EMAIL PROTECTED]","iso-2022-jp")
unicode("\x1b$BBB","iso-2022-jp")
In iso-2022-jp-3, there are even more ways to encode the same string.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
at all packages classified
as Programming Language :: C
http://pypi.python.org/pypi?:action=browse&c=181
or Programming Language :: C++
http://pypi.python.org/pypi?:action=browse&show=all&c=183
Of course, some of those may only generate C, or deal with C in
some other sense than being
lation
- hence, it can be placed in the System directory.
The backwards compatibility with "those applications" is necessary, in
particular with PythonWin (but also with any other software that embeds
Python).
Regards,
Martin
(*) Python fails to meet other requirements; in addition, it has no
change.
No. The existing applications still require Python to be located on
the path, even if they are rebuilt against the new DLL. This is
source backwards compatibility, not binary backwards compatibility.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
th the old DLL".
I'm not trying to maintain compatibility with the binaries of those
applications, but with their source.
> Since the existing applications have to be rebuilt to use the
> new DLL they also can be changed to use it from a new shared location.
No, they can't, becau
ull-width"
latin (*) and "half-width" Japanese characters). Good codecs are
supposed to round-trip the relevant differences to Unicode, and generate
the appropriate compatibility characters.
Bad codecs might not, and in some cases, users might complain that
certain compatibility char
plication. This handle is incompatible with the C file handling
> functions used by the C runtime of the Python DLL, which causes it to
> crash when calling PyRun_File.
Indeed. That is one of the main reasons to remove that API in Py3k.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Is this functionality intended?
Google for "Python mutable default arguments" (you can actually
leave out Python).
It's part of the language semantics, yes.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
. He gave this talk
several times; one recorded instance was at Google TechTalk.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> How does my object get its own value?
def __unicode__(self):
return unicode(self)
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ay
> still be cheaper, but only very slightly.
I don't understand that remark. To implement the conversion in the
way you want it to be, it definitely needs to produce a copy of
self.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Now i want to build an msi installer out of this. What's procedure
> that I should follow for this ??
See Tools/msi. Notice that this (*) isn't supported, so you are on your
own; you probably need to change msi.py
Regards,
Martin
(*) Packaging a Python installer that was b
2.4 supports Tk 8.5.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
quot; means "Tkinter has wrappers for all commands
and options", then Tkinter has no support for any version of Tk,
as a lot of commands remain unwrapped.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ed - in your code. It's not the same encoding.
>>>> unicode(s, 'mcbs')
> u''
>>>> unicode(s, 'mcbs').encode('mcbs')
> Traceback (most recent call last):
> File "", line 1, in
> LookupError: unknown enc
> Thanks a lot Martin and Marc for the really great explanations! I was
> wondering if it would be reasonable to imagine a utility that will
> determine whether, for a given encoding, two byte strings would be
> equivalent.
But that is much easier to answer:
s1.decode(enc) == s
e an empty
string again. This is correct behavior for all codecs that Python
supports in its default installation, at least for the direction
bytes->unicode. For the reverse direction, such an optimization
would be incorrect; consider u"".encode("utf-16").
HTH,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
lt-in types only
> going to get more and more hazy?
In the long run (ie. Python 3), the distinction is going to be very
hazy, very dark: it will entirely disappear. There will be only one
concept of type/class, not two, so there will be no point
distinguishing between types and clas
n Unix.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
uch item"
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ain that it
is still the same file
then this sequence cannot be implemented on Unix, either - another
process may remove the file and create a new one between b and d.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
n Windows, it will be "mbcs", which
in turn is installation-specific - on Western European/US installations,
it's "windows-1252".
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
t; characters (on Vista), and whoa, files opened with IDLE are empty,
> import doesn't find modules in that directory. Of course Windows-1252
> can't encode these ...
>
> But I understand that Python 3 will clean this up?
In theory, yes. The current implementation doesn&#x
n they can't work
with Tk 8.5, as Tk doesn't provide that kind of binary compatibility.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
d and use the older Tk version *anyway*?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Torsten Bronger wrote:
> Hallöchen!
>
> [EMAIL PROTECTED] writes:
>
>> I am all about using the right tool for the right purposes, [...]
>
> Which purpose?
>
>> I dug up one article from Google that talked about comparison but
>> that was about it.
>>
>> http://www.simple-talk.com/sql/database-
[EMAIL PROTECTED] wrote:
> On Jan 8, 1:57 pm, "Martin P. Hellwig" <[EMAIL PROTECTED]> wrote:
>> And adding to that, if you don't care about cross platform anyway, why
>> even bother with python? I am sure that MS has tools that can do in a
>> point and
rk in the C locale. Of
course, you cannot have any non-ASCII characters in that locale, so
deal with it.
If you have solved that, chances are high that it will work in other
locales as well (but be sure to try Turkish, as that gives a
surprising meaning to "I".lower()).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
is an example.
Some encodings are 8-bit, so that they can decode arbitrary bytes
(again producing moji-bake if the input wasn't that encoding).
ISO-8859-X are examples, as are some of the EBCDIC encodings, and
koi8-x. Also, things will successfully (but meaninglessly) decode
as UTF-16 if the n
> The Unicode standard says that case mappings are language-dependent.
I think you are misreading it. 5.18 "Implementation Guides" says
(talking about "most environments") "In such cases, the
language-specific mappings *must not* be used." (emphasis also
in the
> Even if towlower() gets used? I've found an explicit statement that the
> conversion it does can be locale-specific:
>
> http://msdn2.microsoft.com/en-us/library/8h19t214.aspx
Right. However, the build option of Python where that's the case is
deprecated.
Re
more?
It's not your choice, but the user's. People still use non-UTF-8 locales
heavily, and likely will continue to do so for at least 10 more years.
> Oh boy, this gives me cold chills. I don't have the resources to start
> worrying about every single language's edge-cases. This is kind of why I was
> leaning towards a "use a utf8 locale please" approach.
That doesn't help. For Turkish in particular, the UTF-8 locale is worse
than the ISO-8859-9 locale, as the lowercase I takes two bytes in UTF-8,
so tolower can't really work in the UTF-8 locale (but can in the
ISO-8859-9 locale).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
to display (under LANG=C) in a python script (not the immediate-mode
> interpreter) was: "MÖgul". The second character is a capital O with an umlaut
> (double-dots I think) above it. For some reason I could not get that to
> display as "M?gul" or "Mgul".
I see no problem with that:
>>> u"M\xd6gul".encode("ascii","ignore")
'Mgul'
>>> u"M\xd6gul".encode("ascii","replace")
'M?gul'
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
problem with that:
>>>>> u"M\xd6gul".encode("ascii","ignore")
>> 'Mgul'
>>>>> u"M\xd6gul".encode("ascii","replace")
>> 'M?gul'
> Well, that was what I expected to see too. I must have been doing something
> stupid.
Most likely, you did not invoke .encode on a Unicode string.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> If the user has set up his machine correctly: yes.
> Meaning, I am led to assume, the LANG variable primarily?
Yes.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
obviously
> in a non-ascii set (like japan someplace) but can't find anything easy. I
> want to see exactly how my system (Kubuntu 7.10) handles things.
So what does sys.getfilesystemencoding() say what encoding is used for
filenames?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ditor instead to create such a file. For example, create
a new document, and save it as "活用事例.txt" (which Google says means
"casestudies.txt")
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
type : i.e. bytestring or unicode ) and written *into* as
> 2. Imply that filename will be encoded via and written into as
>
> It's fuzzy, how is the filename handled?
See above. The encoding in codecs.open has no effect at all on
the file name; it only talks about the file content.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Giampaolo Rodola' wrote:
> Hi all,
> I'm trying to use the pywin32 extension to find out the user's home
> directory but currently I didn't find a solution yet.
> What I'd need to do is not getting the home directory of the currently
> logged in user but something like:
>
get_homedir("frank")
at this would stop people from
specifying such formats - in ZIP files, some file names are encoded in
CP437 and some in UTF-8, depending on a per-filename flag).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
m [_][.<[EMAIL PROTECTED] (or whatever
the syntax is), take anything before the underscore as the language code.
However, you should reevaluate why you need that.
> BTW - things are hanging-together much better now, thanks to your info. I
> have
> it running in locale 'C'
anguage written in IQTElif alphabet)
[EMAIL PROTECTED] (as opposed to latin uz_UZ)
There used to be a @bokmal modifier for Norwegian (as opposed to
the Nynorsk grammar), but they have separate language codes now
(nb vs. nn).
Regards,
Martin
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
ameter so you can ask for os.listdir(encoding="iso-8859-1")
> although that then propagates into open, ...
I had the same idea, and I think that parameter should be added.
For open(), I think we should continue to accept byte strings as file
names.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
the
> values.
>
> Maybe I'm missing something?
I think you are right - there is indeed stuff missing; few people have
noticed so far.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> I could do nested for ... in loops, but was looking for a Pythonic way
> to do this. Ideas?
I find nested for loops very Pythonic. Explicit is better than implicit,
and simple is better than complex.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
o a default must be specified. Since we can't know whether the
cross-compiler accepts -fno-strict-aliasing, we leave it out.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> What do I need to do run my app like IDLE does?
Can you please show the fragment of your program that prints
these strings?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
just by using the latest language features.
It may be a smart solution, but not a Pythonic one.
Regards,
Martin
P.S. To solve the general problem, I like
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496807
--
http://mail.python.org/mailman/listinfo/python-list
#x27;t know how to figure out what encoding
MySQL uses.
In principle, rather than doing
print lines[0]
you should do
print lines[0].decode("").encode("")
when printing to the console. Furtenately, you can also write
this as
print lines[0].decode("")
as Python will figure out the console encoding by itself, but
it can't figure out the MySQL encoding (or atleast doesn't,
the way you use MySQL).
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
e, in true cross-compilation, you won't get a chance to run
setup.py, since python will only run on the target system, not on
the host system, therefore setup.py won't even start, and it doesn't
matter that it won't support cross-compilation.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
x.y+"/site-packages (where x.y is from
sys.version_info).
HTH,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
px
Apparently, they do the OEMtoANSI conversion when you run a console
application (i.e. python.exe), whereas they don't convert when running
a GUI application (pythonw.exe).
I'm not quite sure how they find out whether the program is a console
application or not; the easiest thing to do might be to turn the
autoconversion off on the server.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> Also, is there source code available for python24 for Windoze? I have
> seen reference to source code but not in a package for Windows.
It's available from
http://www.python.org/ftp/python/2.4/Python-2.4.tgz
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
3001 - 3100 of 4331 matches
Mail list logo
