Re: [Python-Dev] PEP 355 status
On Sun, 01 Oct 2006 13:56:53 +1000, Nick Coghlan [EMAIL PROTECTED] wrote: Things the PEP 355 path object lumps together: - string manipulation operations - abstract path manipulation operations (work for non-existent filesystems) - read-only traversal of a concrete filesystem (dir, stat, glob, etc) - addition removal of files/directories/links within a concrete filesystem Dumping all of these into a single class is certainly practical from a utility point of view, but it's about as far away from beautiful as you can get, which creates problems from a learnability point of view, and from a capability-based security point of view. PEP 355 itself splits the methods up into 11 distinct categories when listing the interface. At the very least, I would want to split the interface into separate abstract and concrete interfaces. The abstract object wouldn't care whether or not the path actually existed on the current filesystem (and hence could be relied on to never raise IOError), whereas the concrete object would include the many operations that might need to touch the real IO device. (the PEP has already made a step in the right direction here by removing the methods that accessed a file's contents, leaving that job to the file object where it belongs). There's a case to be made for the abstract object inheriting from str or unicode for compatiblity with existing code, I think that compatibility can be achieved by having a pathname string attribute or similar to convert to a string when appropriate. It's not like datetime inherits from str to facilitate formatting or anything like that. but an alternative would be to enhance the standard library to better support the use of non-basestring objects to describe filesystem paths. A PEP should at least look into what would have to change at the Python API level and the C API level to go that route rather than the inheritance route. In C, this is going to be really difficult. Existing C APIs want to use C functions to deal with pathnames, and many libraries are not going to support arbitrary VFS I/O operations. For some libraries, like GNOME or KDE, you'd have to use the appropriate VFS object for their platform. For the concrete interface, the behaviour is very dependent on whether the path refers to a file, directory or symlink on the current filesystem. For an OO filesystem interface, does it really make sense to leave them all lumped into the one class with a bunch of isdir() and islink() style methods? Or does it make more sense to have a method on the abstract object that will return the appropriate kind of filesystem info object? I don't think returning different types of objects makes sense. This sort of typing is inherently prone to race conditions. If you get a DirectoryPath object in Python, and then the underlying filesystem changes so that the name that used to be a directory is now a file (or a device, or UNIX socket, or whatever), how do you change the underlying type? If the latter, then how would you deal with the issue of state coherency (i.e. it was a file when you last touched it on the filesystem, but someone else has since changed it to a link)? (that last question actually lends strong support to the idea of a *single* concrete interface that dynamically responds to changes in the underlying filesystem). In non-filesystem cases, for example the zip path case, there are inherent failure modes that you can't really do anything about (what if the zip file is removed while you're in the middle of manipulating it?) but there are actual applications which depend on the precise atomic semantics and error conditions associated with moving, renaming, and deleting directories and files, at least on POSIX systems. The way Twisted does this is that FilePath objects explicitly cache the results of stat and then have an explicit restat method for resychronizing with the current state of the filesystem. None of their methods for *manipulating* the filesystem look at this state, since it is almost guaranteed to be out of date :). Another key difference between the two is that the abstract objects would be hashable and serialisable, as their state is immutable and independent of the filesystem. For the concrete objects, the only immutable part of their state is the path name - the rest would reflect the state of the filesystem at the current point in time. It doesn't really make sense to separate these to me; whenever you're serializing or hashing that information, the mutable parts should just be discarded. ___ 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
Re: [Python-Dev] Tix not included in 2.5 for Windows
On Sep 30, 2006, at 11:13 PM, Scott David Daniels wrote: Christos Georgiou wrote: Does anyone know why this happens? I can't find any information pointing to this being deliberate. I just upgraded to 2.5 on Windows (after making sure I can build extensions with the freeware VC++ Toolkit 2003) and some of my programs stopped operating. I saw in a French forum that someone else had the same problem, and what they did was to copy the relevant files from a 2.4.3 installation. I did the same, and it seems it works, with only a console message appearing as soon as a root window is created: Also note: the Os/X universal seems to include a Tix runtime for the non-Intel processor, but not for the Intel processor. This makes me think there is a build problem. The OSX universal binaries don't include Tcl/Tk at all but link to the system version of the Tcl/Tk frameworks. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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
[Python-Dev] HAVE_UINTPTR_T test in configure.in
Hi, Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't defined in pyconfig.h while it should have been defined. I'm looking into this and am now wondering whether the configure snipped below is correct: AC_MSG_CHECKING(for uintptr_t support) have_uintptr_t=no AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [ AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type uintptr_t.]) have_uintptr_t=yes ]) AC_MSG_RESULT($have_uintptr_t) if test $have_uintptr_t = yes ; then AC_CHECK_SIZEOF(uintptr_t, 4) fi This seems to check for uintptr_t as a builtin type. Isn't one supposed to include stdint.h to get this type? Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me, but I've only tested on OSX and don't know if this is the right fix for all supported platforms. AC_TRY_COMPILE([#include stdint.h], [uintptr_t x; x = (uintptr_t) 0;], [ Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [Python-Dev] Caching float(0.0)
On Fri, Sep 29, 2006 at 12:03:03PM -0700, Guido van Rossum wrote: I see some confusion in this thread. If a *LITERAL* 0.0 (or any other float literal) is used, you only get one object, no matter how many times it is used. For some reason that doesn't happen in the interpreter which has been confusing the issue slightly... $ python2.5 Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 Type help, copyright, credits or license for more information. a=0.0 b=0.0 id(a), id(b) (134737756, 134737772) $ python2.5 -c 'a=0.0; b=0.0; print id(a),id(b)' 134737796 134737796 But if the result of a *COMPUTATION* returns 0.0, you get a new object for each such result. If you have 70 MB worth of zeros, that's clearly computation results, not literals. In my application I'm receiving all the zeros from a server over TCP as ASCII and these are being float()ed in python. -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick ___ 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
Re: [Python-Dev] Caching float(0.0)
On Sat, Sep 30, 2006 at 03:21:50PM -0700, Bob Ippolito wrote:
On 9/30/06, Terry Reedy [EMAIL PROTECTED] wrote:
Nick Coghlan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
I suspect the problem would typically stem from floating point
values that are read in from a human-readable file rather than
being the result of a 'calculation' as such:
Over a TCP socket in ASCII format for my application
For such situations, one could create a translation dict for both common
float values and for non-numeric missing value indicators. For instance,
flotran = {'*': None, '1.0':1.0, '2.0':2.0, '4.0':4.0}
The details, of course, depend on the specific case.
But of course you have to know that common float values are never
cached and that it may cause you problems. Some users may expect them
to be because common strings and integers are cached.
I have to say I was surprised to find out how many copies of 0.0 there
were in my code and I guess I was subconsciously expecting the
immutable 0.0s to be cached even though I know consciously I've never
seen anything but int and str mentioned in the docs.
--
Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick
___
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
Re: [Python-Dev] PEP 351 - do while
Nick Coghlan wrote: Hans Polak wrote: Hi, Just an opinion, but many uses of the ‘while true loop’ are instances of a ‘do loop’. I appreciate the language layout question, so I’ll give you an alternative: do: body setup code while condition (I don't think this has been suggested yet.) while enter_condition, exit_condition: body This would be a do-loop. while 1, exit_condition: body In situations where you want to enter a loop on one condition and exit on a second condition: if value1: value2 = True while value2: body Would be ... while value1, value2: body I've used that pattern on more than a few occasions. A single condition while would be the same as... while condition, condition:# same entry and exit condition body So do just as we do now... while condition: # same entry and exit condition body As I recall, the main objection to this style was that it could hide the loop termination condition, but that isn't actually mentioned in the PEP (and in the typical do-while case, the loop condition will still be clearly visible at the end of the loop body). Putting both the entry and exit conditions at the top is easier to read. The end of the first loop is also the beginning of all the following loops, so having the exit_condition at the top doesn't really put anything out of order. If the exit_condition is not evaluated until the top of the second loop, the names it uses do not need to be pre defined, they can just be assigned in the loop. Ron ___ 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
Re: [Python-Dev] PEP 351 - do while
On 10/1/06, Ron Adam [EMAIL PROTECTED] wrote: (I don't think this has been suggested yet.) while enter_condition, exit_condition: body [snip] Putting both the entry and exit conditions at the top is easier to read. I agree in principle, but I thought the proposed syntax already has meaning today (as it turns out, parentheses are required to make a tuple in a while condition, at least in 2.4 and 2.5). To help stave off similar confusion I'd rather see a pseudo-keyword added. However my first candidate until seems to apply a negation to the exit condition. while True until False: # run once? run forever? while True until True: # run forever? run once? It's still very different from any syntactical syntax I can think of in python. I'm not sure I like the idea. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ 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
Re: [Python-Dev] PEP 351 - do while
(I don't think this has been suggested yet.) while enter_condition, exit_condition: body This usage makes me uneasy, not the least because I don't understand why the comma isn't creating a tuple. That is, why whould while x, y: body be any different from while (x, y): body ? My other concern is that exit_condition is evaluated out of sequence. ___ 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
Re: [Python-Dev] Caching float(0.0)
Nick Craig-Wood [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, Sep 29, 2006 at 12:03:03PM -0700, Guido van Rossum wrote: I see some confusion in this thread. If a *LITERAL* 0.0 (or any other float literal) is used, you only get one object, no matter how many times it is used. For some reason that doesn't happen in the interpreter which has been confusing the issue slightly... $ python2.5 a=0.0 b=0.0 id(a), id(b) (134737756, 134737772) Guido said *a* literal (emphasis shifted), reused as in a loop or function recalled, while you used *a* literal, then *another* literal, without reuse. Try a=b=0.0 instead. Terry Jan Reedy ___ 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
Re: [Python-Dev] PEP 351 - do while
At 12:58 PM 10/1/2006 -0400, Andrew Koenig wrote: (I don't think this has been suggested yet.) while enter_condition, exit_condition: body This usage makes me uneasy, not the least because I don't understand why the comma isn't creating a tuple. That is, why whould while x, y: body be any different from while (x, y): body ? My other concern is that exit_condition is evaluated out of sequence. This pattern: while entry_cond: ... and while not exit_cond: ... has been suggested before, and I believe that at least one of the times it was suggested, it had some support from Guido. Essentially, the and while not exit is equivalent to an if exit: break that's more visible due to not being indented. I'm not sure I like it, myself, but out of all the things that get suggested for this issue, I think it's the best. The fact that it's still not very good despite being the best, is probably the reason we don't have it yet. :) ___ 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
Re: [Python-Dev] Caching float(0.0)
On Sun, 1 Oct 2006 13:54:31 -0400, Terry Reedy [EMAIL PROTECTED] wrote: Nick Craig-Wood [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, Sep 29, 2006 at 12:03:03PM -0700, Guido van Rossum wrote: I see some confusion in this thread. If a *LITERAL* 0.0 (or any other float literal) is used, you only get one object, no matter how many times it is used. For some reason that doesn't happen in the interpreter which has been confusing the issue slightly... $ python2.5 a=0.0 b=0.0 id(a), id(b) (134737756, 134737772) Guido said *a* literal (emphasis shifted), reused as in a loop or function recalled, while you used *a* literal, then *another* literal, without reuse. Try a=b=0.0 instead. Actually this just has to do with, um, compilation units, for lack of a better term: [EMAIL PROTECTED]:~$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type help, copyright, credits or license for more information. a = 0.0 b = 0.0 print a is b False ^D [EMAIL PROTECTED]:~$ cat test.py a = 0.0 b = 0.0 print a is b ^D [EMAIL PROTECTED]:~$ python test.py True [EMAIL PROTECTED]:~$ cat test_a.py a = 0.0 ^D [EMAIL PROTECTED]:~$ cat test_b.py b = 0.0 ^D [EMAIL PROTECTED]:~$ cat test.py from test_a import a from test_b import b print a is b ^D [EMAIL PROTECTED]:~$ python test.py False [EMAIL PROTECTED]:~$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type help, copyright, credits or license for more information. a = 0.0; b = 0.0 print a is b True [EMAIL PROTECTED]:~$ Each line in an interactive session is compiled separately, like modules are compiled separately. With the current implementation, literals in a single compilation unit have a chance to be cached like this. Literals in different compilation units, even for the same value, don't. Jean-Paul ___ 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
Re: [Python-Dev] HAVE_UINTPTR_T test in configure.in
On Oct 1, 2006, at 10:54 AM, Ronald Oussoren wrote: Hi, Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't defined in pyconfig.h while it should have been defined. I'm looking into this and am now wondering whether the configure snipped below is correct: AC_MSG_CHECKING(for uintptr_t support) have_uintptr_t=no AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [ AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type uintptr_t.]) have_uintptr_t=yes ]) AC_MSG_RESULT($have_uintptr_t) if test $have_uintptr_t = yes ; then AC_CHECK_SIZEOF(uintptr_t, 4) fi This seems to check for uintptr_t as a builtin type. Isn't one supposed to include stdint.h to get this type? Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me, but I've only tested on OSX and don't know if this is the right fix for all supported platforms. AC_TRY_COMPILE([#include stdint.h], [uintptr_t x; x = (uintptr_t) 0;], [ The same problem exists on Linux, and is fixed by the same change. BTW. Python 2.4 suffers from the same problem and I've filed a bugreport for this (http://www.python.org/sf/1568842). Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [Python-Dev] PEP 351 - do while
This pattern: while entry_cond: ... and while not exit_cond: ... has been suggested before, and I believe that at least one of the times it was suggested, it had some support from Guido. Essentially, the and while not exit is equivalent to an if exit: break that's more visible due to not being indented. I like this suggestion. In fact it is possible that at one time I suggested something similar. It reminds me of something that Dijkstra suggested in his 1971 book A Discipline of Programming. His ides looked somewhat like this: do condition 1 - action 1 ... [] condition n - action n od Here, the [] should be thought of as a delimiter; it was typeset as a tall narrow rectangle. The semantics are as follows: If all of the conditions are false, the statement does nothing. Otherwise, the implementation picks one of the true conditions, executes the corresponding action, and does it all again. There is no guarantee about which action is executed if more than one of the conditions is true. The general idea, then, is that each action should falsify its corresponding condition while bring the loop closer to termination; when all of the conditions are false, the loop is done. For example, he might write Euclid's algorithm this way: do x y - y := y mod x [] y x - x := x mod y od If we were to adopt while ... and while in Python, then Dijkstra's construct could be rendered this way: while x y: y %= x or while y x: x %= y I'm not suggesting this seriously as I don't have enough realistic use cases. Still, it's interesting to see that someone else has grappled with a similar problem. ___ 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
Re: [Python-Dev] PEP 351 - do while
Michael Urman wrote: On 10/1/06, Ron Adam [EMAIL PROTECTED] wrote: (I don't think this has been suggested yet.) while enter_condition, exit_condition: body [snip] Putting both the entry and exit conditions at the top is easier to read. I agree in principle, but I thought the proposed syntax already has meaning today (as it turns out, parentheses are required to make a tuple in a while condition, at least in 2.4 and 2.5). To help stave off similar confusion I'd rather see a pseudo-keyword added. However my first candidate until seems to apply a negation to the exit condition. while True until False: # run once? run forever? while True until True: # run forever? run once? It's still very different from any syntactical syntax I can think of in python. I'm not sure I like the idea. Michael I thought the comma might be a sticking point. My first thought was to have a series of conditions evaluated on loops with the last condition repeated. while loop1_cond, loop2_cond, loop3_cond, ..., rest_condition: body But I couldn't think of good uses past the first two that are obvious so I trimmed it down to just enter_condition and exit_condition which keeps it simple. But from this example you can see they are all really just top of the loop tests done in sequence. A do loop is just a matter of having the first one evaluate as True. The current while condition is an entry condition the first time it's evaluated and an exit condition on the rest. So by splitting it in two, we can specify an enter and exit test more explicitly. There's a certain consistency I like about this also. Is it just getting around or finding a nice alternative to the comma that is the biggest problem with this? Maybe just using then would work? while cond1 then cond2: body Cheers, Ron ___ 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
Re: [Python-Dev] PEP 355 status
On 9/30/06, Giovanni Bajo [EMAIL PROTECTED] wrote: It would be terrific if you gave us some clue about what is wrong in PEP355, so that the next guy does not waste his time. For instance, I find PEP355 incredibly good for my own path manipulation (much cleaner and concise than the awful os.path+os+shutil+stat mix), and I have trouble understanding what is *so* wrong with it. You said it's an amalgam of unrelated functionality, but you didn't say what exactly is unrelated for you. Sorry, no time. But others in this thread clearly agreed with me, so they can guide you. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source
Hi Brett, On Wed, Sep 27, 2006 at 02:11:30PM -0700, Brett Cannon wrote: is so bad that it is worth trying to re-implement the import semantics in pure Python or if in the name of time to just work with the C code. In the name of time, sanity and usefulness, rewriting the expected semantics in Python would be a major good idea IMHO. I can cite many projects that have reimplemented half of the semantics in Python (runpy.py, the 'py' lib, PyPy...), but none that completed them. Having such a complete implementation available in the first place would be helpful. A bientot, Armin ___ 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
[Python-Dev] OT: How many other people got this spam?
I was wondering: how many other people who maintain websites (well: maintain might be a bit of a misnomer in my case:-) related to Python have also got this spam? Begin forwarded message: From: Snake Tracks [EMAIL PROTECTED] Date: October 1, 2006 21:21:45 GMT+02:00 To: Cwi [EMAIL PROTECTED] Subject: Special Invitation for cwi.nl from Snake Tracks Fellow Website Owner/Operator; As of September 29th, 2006 we will be launching what is soon to be the worlds largest snake enthusiast website. The website contains valuable information for all those interested in snakes including care sheets, species information and identification, breeding information, and an extensive list of snake specific forums. We welcome you to visit our website and join our community of snake enthusiasts worldwide. Currently we are browsing through Google and other major search engines looking for websites we feel would make good link partners. I have personally come across your site and think that exchanging links could benefit both of our businesses. By linking to us you will receive a reciprocal link and be showcased in front of all our visitors. If you are interested in this partnership please add one of the following text links or banners to a high traffic area on your website: 1) Snake Tracks - The Worlds Largest Snake Enthusiast Website. Visit our site for care sheets, species information, field herping information, breeding, captive care, and our extensive list of snake enthusiast forums. 2) Snake Tracks Forums - Visit the Worlds Largest Collection of Snake Enthusiast forums including our field herping, captive care, habitat design, and regional forums. 3) Snake Care Sheets - Visit the Worlds Largest Snake Enthusiast Website. Forums, Care Sheets, Field Herping, Species information and more. You may also visit our link page to choose from several banner images and text links. Once you have linked to our website, fill out the form and we will add your site to our directory. http://www.snaketracks.com/linktous.html I look forward to hearing from you in regards to this email. Please allow up to 24 hours for a response as we are currently receiving extremely large amounts of email. Sincerely; Blair Russell - Snaketracks.com -- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ 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
Re: [Python-Dev] OT: How many other people got this spam?
Jack Jansen wrote: I was wondering: how many other people who maintain websites (well: maintain might be a bit of a misnomer in my case:-) related to Python have also got this spam? I got it. I was rather amused that they claim to have been looking for sites that would make good link partners when obviously no human eye of theirs has actually seen my site. Addressing me as Canterbury in the To: line wasn't a good sign either. :-) I'm tempted to take them up on the offer and see whether they actually make a link to my site from theirs... -- Greg ___ 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
Re: [Python-Dev] OT: How many other people got this spam?
Jack Jansen wrote: I was wondering: how many other people who maintain websites (well: maintain might be a bit of a misnomer in my case:-) related to Python have also got this spam? probably everyone. I've gotten two copies, this far. /F ___ 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
