Re: [Python-Dev] Slice as a copy... by design?
2008/5/22 Facundo Batista <[EMAIL PROTECTED]>: > I couldn't answer why, so I'm asking here...Is it because the > reference counting will be complicated? Is it because it'd be > inefficient in other way? It's something else? Or is something that > could be done... but is not done yet? Thank you all for the information provided! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Importing bsddb 4.6.21; with or without AES encryption?
> That's all fine, but then I'm missing the OpenSSL license and > attribution notice somewhere in the installer, the README of the > installation or elsewhere. Good point. We need this for both the ssl module and the hashlib module. Bill ___ 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] Slice as a copy... by design?
Facundo Batista wrote: A thread in PyAr raised the question that, considering that strings are immutable, why a slice of a string is a copy and not a reference to a part of that string. Because it would make it too easy to accidentally keep a large string alive via a reference to a small part of it. Some way of explicitly requesting a view into another string might be desirable, but it shouldn't be the default behaviour for string slicing. -- 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] Importing bsddb 4.6.21; with or without AES encryption?
On 2008-05-20 00:46, Jesus Cea wrote: Trent Nelson wrote: | I downloaded the source that includes AES encryption, for no reason | other than it was first on the list. I'm now wondering if we should | only be importing the 'NC' source that doesn't contain any | encryption? Jesus, does pybsddb use any of the Berkeley DB | encryption facilities? Would anything break if we built the | bsddb module without encryption? Yes, pybsddb3 4.6.4 supports cryptography if the underlying Berkeley DB library is crypto enabled. In principle, you can compile BDB without crypto, and pybsddb3 should work, but you would lose ability to open any DB formerly created using page encryption or page checksum. Export laws aside, we better compile with crypto :). I hope you're only talking about the Windows build... In any case, if you do include crypto code in the Windows installer, please make sure that the PSF is informed, so that the proper reporting procedure can be put in place (whatever it is nowadays in the US). The installer already includes the ssl module, so it's not problem to include crypto code in general. BTW: AFAIK the _ssl module is built against OpenSSL. Since I couldn't find any OpenSSL DLLs in my Python install dir and due to the size of the _ssl.pyd, I assume that it is statically linked against OpenSSL. That's all fine, but then I'm missing the OpenSSL license and attribution notice somewhere in the installer, the README of the installation or elsewhere. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 22 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] buffer interface for C extensions
On Thu, 22 May 2008 23:10:09 +0200, M.-A. Lemburg wrote: > On 2008-05-19 00:59, Dan Lenski wrote: > You should probably ask such questions on the capi-sig list. > > To answer your question: > > t# requires support for the read-only 8-bit character buffer interface > s# can use the read buffer interface > w# requires support for the write buffer interface I somehow overlooked the fact that the "s#" argument specifier supports exactly the functionality that I need. D'oh! > Those are two different buffer interface slots, so whether a particular > object works with t# or w# depends on whether it implements the slots in > question. > > You should probably try s#, as this will also work with objects that > implement the getreadbuffer slot. Worked like a charm! > The details can be found in Python/getargs.c I'm still unclear on the difference between the character/read buffer interfaces, but I'll read the code and try and figure that out. Thanks for your help, Marc-Andre!!! Dan ___ 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] Trying to understand svn history (was: Buildbots have trouble checking out the repository due to recent changes.)
>>From what I can see of the changes, you simply added a > Lib/lib-old/Queue.py in that revision - Lib/queue.py was already > there. But your description "Moved..." implies you did something > slightly different (and the text of your original message on this > thread suggests that you might have done a svn copy Lib/queue.py > Lib/lib-old/Queue.py followed by an edit). In this case, adding -v helps: Changed paths: D /python/trunk/Lib/Queue.py A /python/trunk/Lib/lib-old/Queue.py (from /python/trunk/Lib/Queue.py:63101) > I know it's a while ago but can you recall exactly what you did? Or > can some svn guru tell me how to get svn to tell me exactly what > operations it believes went on? See above. If you want to know whether it was a mere move, or whether something was changed as well, try svn diff svn+ssh://[EMAIL PROTECTED]/python/trunk/Lib/lib-old/[EMAIL PROTECTED] svn+ssh://[EMAIL PROTECTED]/python/trunk/Lib/[EMAIL PROTECTED] which shows no differences. In fact, Queue.py got its current contents in r63077, the same version where queue.py was copied from Queue.py. HTH, Martin ___ 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] Trying to understand svn history (was: Buildbots have trouble checking out the repository due to recent changes.)
2008/5/22 Paul Moore <[EMAIL PROTECTED]>: > I know it's a while ago but can you recall exactly what you did? Or > can some svn guru tell me how to get svn to tell me exactly what > operations it believes went on? Never mind, I found out how to do this using svn dump. 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] buffer interface for C extensions
On 2008-05-19 00:59, Dan Lenski wrote:
Hi all,
I've written a small C extension to submit commands to SCSI devices via
Linux's sg_io driver (for a camera hacking project). The extension is
just a wrapper around a couple ioctl()'s with Pythonic exception handling
thrown in. One of my extension methods is called like this from python:
sg.write(fd, command[, data, timeout)
Both command and data are binary strings. I would like to be able to use
either a regular Python string or an array('B', ...) for these read-only
arguments. So I tried to use the "t#" argument specifier to indicate that
these arguments could be either strings or objects that implement the read-
only buffer interface:
if (!PyArg_ParseTuple(args, "it#|t#i:write", &sg_fd, &cmd,
&cmdLen, &buf, &bufLen, &timeout))
return NULL;
Now, this works fine with strings, but when I call it with an array I get
a TypeError:
TypeError: write() argument 2 must be string or read-only character
buffer, not array.array
So, I then tried changing "t#" to "w#" to indicate that the arguments must
implement the /read-write/ buffer interface. Now the array objects work,
but when I try a string argument, I naturally get this error:
TypeError: Cannot use string as modifiable buffer
So here's what I don't understand. Why doesn't the "t#" argument
specifier support read-write buffers as well as read-only buffers? Aren't
read-write buffers a *superset* of read-only buffers?? Is there something
I'm doing wrong or a quick fix to get this to work appropriately?
You should probably ask such questions on the capi-sig list.
To answer your question:
t# requires support for the read-only 8-bit character buffer interface
s# can use the read buffer interface
w# requires support for the write buffer interface
Those are two different buffer interface slots, so whether a
particular object works with t# or w# depends on whether it
implements the slots in question.
You should probably try s#, as this will also work with objects
that implement the getreadbuffer slot.
The details can be found in Python/getargs.c
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 22 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Addition of "pyprocessing" module to standard lib.
> % make > cc -c -DNDEBUG -O -I. -IInclude -I./Include -DPy_BUILD_CORE -o > Modules/python.o ./Modules/python.c > "/usr/include/sys/feature_tests.h", line 353: #error: "Compiler or > options invalid for pre-UNIX 03 X/Open applications and pre-2001 > POSIX applications" > cc: acomp failed for ./Modules/python.c which cc? It works fine for me, with cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 (it just complains about not supporting -OPT:Olimit) > *** Error code 2 > make: Fatal error: Command failed for target `Modules/python.o' > % > > So maybe Python just doesn't run on Solaris with the Sun C compiler. > Certainly doesn't build out of the box. Apparently, there were some intermediate releases of SunPRO which had this problem; in these cases, setting -xc99=%none may help. Regards, Martin ___ 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] Trying to understand svn history (was: Buildbots have trouble checking out the repository due to recent changes.)
2008/5/12 Paul Moore <[EMAIL PROTECTED]>: > Revision 63129 is not valid on case folding filesystems. In > particular, this horribly breaks using hg-svn to make a local mirror > of the Python repository: I'm still trying to identify what breaks in converting svn to Mercurial at around the time of your library renamings. Specifically, I cannot convert the svn repository history for r63104: >svn log -r63104 r63104 | alexandre.vassalotti | 2008-05-12 00:04:27 +0100 (Mon, 12 May 2008) | 2 lines Moved the Queue module stub in lib-old. >From what I can see of the changes, you simply added a Lib/lib-old/Queue.py in that revision - Lib/queue.py was already there. But your description "Moved..." implies you did something slightly different (and the text of your original message on this thread suggests that you might have done a svn copy Lib/queue.py Lib/lib-old/Queue.py followed by an edit). I know it's a while ago but can you recall exactly what you did? Or can some svn guru tell me how to get svn to tell me exactly what operations it believes went on? This is something of a showstopper for converting Python svn->hg on Windows, and I'd like to identify and if at all possible fix the bug. Thanks, 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] Committing bsddb 4.6.4, and where can I put testsuite temp files?
> I would like to print the Berkeley DB release used, also. Could that be done at build time as well? Martin ___ 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] Importing bsddb 4.6.21; with or without AES encryption?
> |> In any case, what would be the procedure to update the buildbot > |> infraestructure?. > | > | You need to import the sources into the Python subversion repository; > | I understand Trent was about to do that. > | > | Then you need to adjust Tools/msi/external.bat to have the slaves export > | the new version. > > I was thinking about the Unix buildbots. Ah. There is no way to upgrade them, and attempts to upgrade them should not be made (see my other message) Regards, Martin ___ 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] Importing bsddb 4.6.21; with or without AES encryption?
> I guess we need first all buildbots updated to 4.7.25 before changing > the setup.py to support BDB 4.7, to avoid no updated ones linking > against (old) buggy 4.6 releases. Why do you think so? Updating all buildbots is not feasible, atleast not within this year. Some machines *intentionally* stay at old software, just to make sure Python continues to build. Would pybsddb 4.7 continue to build with all bsddb releases that it currently builds with? > Reading the buildbot outputs, I see some machines using "ancient" BDB > versions. For example, "amd64 gentoo trunk" uses 4.4.x. Would be nice to > know the exact release :-). Feel free to temporarily commit code to make it find out - either directly in the trunk, or by making a temporary branch and have that branch be built on the particular slave only. > This is interesting, because a buildbot using a DBD < 4.7 will not > exercise the module at full capacity, so buildbot value is, somewhat, > reduced. That's a matter of standpoint. It also tests whether the module works and passes its test suite with older releases, which is a good thing. So it's more valuable to have old releases on some slaves, rather than having them test all the same version (which is known to work in principle, anyway). > I would hate to find problems in Python beta releases because the > buildbots are outdated :( Don't worry, some slaves will surely have the latest version, at some point (if none else, the Windows ones will). Regards, Martin ___ 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] Slice as a copy... by design?
> I couldn't answer why, so I'm asking here...Is it because the > reference counting will be complicated? Is it because it'd be > inefficient in other way? It's something else? Or is something that > could be done... but is not done yet? There are two problems with that approach: a) you may hold onto very long strings for a long time, even though you don't "see" the larger string anymore, e.g. when you have only a single line of an entire file that you hold onto. That, in turn, may cause the program to consume much more memory than the copying slicing. b) it is very difficult to implement and maintain. At any point in the code that deals with string representations, you have to make the distinction of whether you have a "real" string, or a slice. Nobody has contributed a correct and efficient implementation of that yet, let alone one that is also easy to maintain. c) (related to b) Currently, the string object's internal representation might be used in extension modules. We would need to find a way to protect against errors that may occur when we silently change the representation semantically. (as any good list of two items, this has three :-) Regards, Martin ___ 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] vmgen based python interpretter
> it would would also be helpfull if someone could tell me, how to locate the > code, which causes this SEG fault I think you already found the code; gdb tells you the exact location of the crash. What are the values of pool and bp? Regards, Martin ___ 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] Slice as a copy... by design?
Hi, Christian Heimes wrote: > Stefan Behnel wrote: >> Even worse, it's gone in Py3: > > No, it has been replaced by a better system. > > Try "memoryview" I know. We are already discussing the buffer protocol on the Cython list. http://comments.gmane.org/gmane.comp.python.cython.devel/1763?set_lines=10 Stefan ___ 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] Slice as a copy... by design?
Stefan Behnel schrieb: > Even worse, it's gone in Py3: No, it has been replaced by a better system. Try "memoryview" Christian ___ 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] Committing bsddb 4.6.4, and where can I put testsuite temp files?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregory P. Smith wrote: | btw, I fixed the Lib/test/test_bsddb3.py file for the updated | Lib/bsddb/test/ modules. Thats how the test suite gets run by the | buildbots (run the test suite from a python trunk sandbox using | "./python Lib/test/regrtest.py -v -u bsddb test_bsddb test_bsddb3" to | reproduce exactly how it is run yourself). What about changing that file to read the testsuite from "Lib/bsddb/test", directly, to avoid skipping new tests again?. I would like to print the Berkeley DB release used, also. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW93Jlgi5GaxT1NAQKUcwP/ZOu3jOGEpGHmDGZYZbChowHnDYnpwh0E DgVbHnP3hWRneo5UESNSg6yu481jJ4eLHF662zAYbLlJx1J15yF8jMXHxWuW4fH1 QNVU4DwtIVGU9FdAKHcDqKglgvTtKy/0rzDPBcjkgmbjsM9MkxtOu8lZjBw1RgaB T4ojB+pr7Ps= =JU9d -END PGP 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] Slice as a copy... by design?
Isaac Morland wrote: > On Thu, 22 May 2008, Christian Heimes wrote: > >> The buffer interface was designed for the slice-as-copy use case: >> > a = "abcdefg" > b = buffer(a, 2, 3) > b >> > str(b) >> 'cde' > [] > > This answers my musing about shared slices. But it points me at another > question: why is buffer() listed in "Non-essential Built-in Functions"? > While it is obviously not essential like str() or list(), it isn't > deprecated like apply(). Even worse, it's gone in Py3: Python 3.0a5 (r30a5:62856, May 9 2008, 11:26:14) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> buffer Traceback (most recent call last): File "", line 1, in NameError: name 'buffer' is not defined Stefan ___ 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] Importing bsddb 4.6.21; with or without AES encryption?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: |> In any case, what would be the procedure to update the buildbot |> infraestructure?. | | You need to import the sources into the Python subversion repository; | I understand Trent was about to do that. | | Then you need to adjust Tools/msi/external.bat to have the slaves export | the new version. I was thinking about the Unix buildbots. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW7/Jlgi5GaxT1NAQL88AP+MXziTzh5wnF6oyjmZtAk9/75LVzHwcjU QyY/MF/DPsL9qnI81Lg7awl4adFaSmntzGX7AAh/TojI40TuW3LI53zFfMAUGsBB q8YaY6zswHENABry+NI8X/mo7J/VeCJstPNANsu1C6o7GSIVH7e6QhzDeOLgsp+O Ae3a1RE+9AU= =m5VB -END PGP 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] Importing bsddb 4.6.21; with or without AES encryption?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregory P. Smith wrote: | On Wed, May 21, 2008 at 5:12 PM, Trent Nelson <[EMAIL PROTECTED]> wrote: |>> Trent Nelson wrote: |>> | Gah. I just went and visited the Berkeley DB download site as |>> | I was preparing my commit message so I could refer to the |>> | exact .tar.gz being imported, only to notice that the latest |>> | version is now 4.7.25. Jesus, can we use this version? |>> |>> Err No. |>> |>> It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 |>> or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. |>I could have sworn I heard a few people mention that "4.5 has issues, |>but they're solved in 4.6" at PyCon ;-) | | The line I was giving at PyCon was "4.6 has issues, we might want to | stick with 4.5" which is why I left setup.py limiting itself to (4, 5) | despite the code being compatible with 4.6. I guess we need first all buildbots updated to 4.7.25 before changing the setup.py to support BDB 4.7, to avoid no updated ones linking against (old) buggy 4.6 releases. Reading the buildbot outputs, I see some machines using "ancient" BDB versions. For example, "amd64 gentoo trunk" uses 4.4.x. Would be nice to know the exact release :-). This is interesting, because a buildbot using a DBD < 4.7 will not exercise the module at full capacity, so buildbot value is, somewhat, reduced. For example, testsuite against a 4.0 BDB has 270 tests. Against 4.6, it has 292 test. Now that 4.7.25 is published, pybsddb 4.7.x testsuite will get even bigger, but only when testing against a 4.7 installation!. I would hate to find problems in Python beta releases because the buildbots are outdated :( | If it passes the entire test suite | several times on windows x86 and amd64 builds when built with | BerkeleyDB 4.7 (once Jesus commits the support code) I'm inclined to | say we should ship with it and only revert back to 4.5 if someone has | problems with it during a beta. :-). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW7qplgi5GaxT1NAQLWrwQAk9Xxm5tCB/p4dcCnoWQj3H1rvpJs+c9s g8m/g6+JL8rhlUWixEYApsK53komCGzSC5Ghf91c2QuIQugeGFA4dE3VcYGO89J+ GgvCw+YnJ3KG3DQ2Qw9Lus4LFuDS67bPlSTALQYuLk32ks7FTcTkhNO5qs5JTejs tpQde3MBlLw= =p2qf -END PGP 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] Slice as a copy... by design?
On Thu, 22 May 2008, Christian Heimes wrote: The buffer interface was designed for the slice-as-copy use case: a = "abcdefg" b = buffer(a, 2, 3) b str(b) 'cde' [] This answers my musing about shared slices. But it points me at another question: why is buffer() listed in "Non-essential Built-in Functions"? While it is obviously not essential like str() or list(), it isn't deprecated like apply(). On the other hand, some other built-in functions listed under "Built-in Functions" are probably also not essential (I'm not going to go any further out on the limb by giving an example!). Perhaps I misunderstand the intent of this manual page. http://docs.python.org/lib/non-essential-built-in-funcs.html#l2h-88 Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] Importing bsddb 4.6.21; with or without AES encryption?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent Nelson wrote: |> It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 |> or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. | | I could have sworn I heard a few people mention that "4.5 has issues, | but they're solved in 4.6" at PyCon ;-) Or course, it is natural to expect new releases to solve known issues. But initial releases of BDB 4.6 were crappy (current ones are fairly good, even if they didn't patch the "compact()" crash :). I glad to say than pybsddb3 testsuite has catched a few errors in Oracle BDB 4.7 pre-releases, so I'm fairly confident in the final version. | I think I remember reading some concerns you had about doing this last | week though, surrounding things like wanting to be able to release pybsddb | versions more frequently than Python versions are released. Just because | you live in trunk/Lib/bsddb shouldn't prevent you from doing this though; | in fact, as long as you're sensitive to major release timeframes, I'm | sure we'd love trunk to always track the latest Berkeley DB version; This issue is complex and I would like to delay a hard decision until it becomes a real issue. Currently, I rather prefer to keep them apart (but in sync). Aside the frequent release issue (something that would not be an issue when pybsddb3 cover the entire Berkeley DB API, some day), there are mailing lists, community support, open patch submission, etc. I know that merging can be a bit painful. Been there, done that. I'm waiting SVN 1.5 release and its much improved merge repeated merge, like the holy grial :-p. Someday Mercurial could be integrated in Python version control system, and I would sleep better at night. Meanwhile, bsddb patches in the python side are few and apart, and I can cope with them. I want to shield python-dev of this: """ [EMAIL PROTECTED] trunk]$ svn diff svn://svn.argo.es/jcea/pybsddb/tags/4.7.0 svn://svn.argo.es/jcea/pybsddb/trunk | wc ~ 12753554 37696 """ About ten big commits. And 4.7.0 was released mere hours ago... | if | all the buildbots stay green with 4.7 and there are no regressions in | functionality, then hey, lets go with 4.7 for 2.6/3.0. I will write about this, after you upgrade MS Windows buildbots to 4.7.25. Let's see how it behave. I rather prefer BDB 4.7.25 in Py2.6/3.0 than BDB 4.6.21, unless we discover some ugly bug in last release (as was discovered after 4.6 release; gracefully no python version was released using the faulty lib). I'm using this 4.7.0/4.7.25 release for... uhmm... 20 hours now. No issues so far, in a very BDB busy machine (mailserver, storing user mailboxes via Python->Durus->my durus backend for Berkeley DB->pybsddb3->BDB 4.7.25). A couple of millions emails per day :). | If Oracle come out with Berkeley DB 4.8 a week after 2.6 is released, | that's fine, we'll keep release26-maint chugging along with 4.7, but we | can switch trunk over to 4.8 once you're ready. One of the "problems" with Berkeley DB is that upgrading libraries can require "upgrade" also the database files. The "upgrade" is usually painless, but you can't go back. So, any BDB upgrade in a python release must be clearly marked, because it can become a no-return-point for some users. In Unix world, Python releases would use BDB installed in the system. So, the user/admin has control over BDB upgrades. But since MS Windows Python bundles BDB, we need to be extra-careful there. Someday we need to talk about pybsddb3 "eggs" (via pypi) supporting BDB DLL bundled by stock python in MS Windows. Current approach needs a new DLL. Some *other* day. So much to do, so little time... :). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW1rplgi5GaxT1NAQJEpQP+IFcmL+0zqg1n8MrtyvPiRZk4oBSlwUzD Ov0SHVmx8MmhKk5NOI3FjpKSVZIVU55HZ+qFBuqz12VeYOucZOUeDlsE5LFnmXsC E4HR6+NCi7zHSOyESjy6j6M3rNPWqNiPOUnJ5kevDOcnoA+W8urdj97wHflArsJ3 e1M1R04UoMI= =lisl -END PGP 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] Slice as a copy... by design?
On Thu, May 22, 2008 at 10:01 AM, Aahz <[EMAIL PROTECTED]> wrote: > On Thu, May 22, 2008, Facundo Batista wrote: >> >> A thread in PyAr raised the question that, considering that strings >> are immutable, why a slice of a string is a copy and not a reference >> to a part of that string. > > Someone did a patch for this at one point, but I don't remember what > happened. I rejected it because I came up with a worst-case scenario where the behavior with the patch in place was much, much worse than the behavior without it -- improved performance in other scenarios notwithstanding. -- --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] Slice as a copy... by design?
Facundo Batista schrieb: > Hi! > > A thread in PyAr raised the question that, considering that strings > are immutable, why a slice of a string is a copy and not a reference > to a part of that string. Because the reference approach is more complicated, harder to implement and may lead to unexpected behavior. For example: >>> a = "a long string with 500,000 chars ..." >>> b = a[0] >>> del a With the slice-as-copy design the string 'a' is immediately freed. The slice-as-reference design would keep the 500kB string in memory although you are only interested in the first character. The buffer interface was designed for the slice-as-copy use case: >>> a = "abcdefg" >>> b = buffer(a, 2, 3) >>> b >>> str(b) 'cde' >>> sys.getrefcount(a) 3 >>> del b >>> sys.getrefcount(a) 2 Christian ___ 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] Slice as a copy... by design?
On Thu, May 22, 2008, Facundo Batista wrote: > > A thread in PyAr raised the question that, considering that strings > are immutable, why a slice of a string is a copy and not a reference > to a part of that string. Someone did a patch for this at one point, but I don't remember what happened. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Need a book? Use your library! ___ 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] Importing bsddb 4.6.21; with or without AES encryption?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent Nelson wrote: | Indeed. Where do we stand with regards to svn commit e-mails | being sent for 'external'? DB 4.6 is ~16MB... I just committed bsddb3 4.7.0. Please install Berkeley DB >=4.7.25. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDWh45lgi5GaxT1NAQLorQQAh3t/waArJtE94d3Fk4YbbxdO9i4+GmMO /xqcT1iHr+qg034LUYxVfWhGdjnbqNj2ZcTjWXEBVqgIqVT5yCYzbDrh0bKmROC0 QjQ0WaMJeMvqj1mGhmDCD3+QAYirUkEg3kAO8icrI9SkTedM6m4EMoT+GI2N6JSI k3SjvOPTKFw= =k2lF -END PGP 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] Slice as a copy... by design?
2008/5/22 Isaac Morland <[EMAIL PROTECTED]>: > By contrast, the worst that can happen with no sharing is that performance > and memory use is what you expect - the only "bad" is the apparent missed > opportunity for optimization. Exactly, "apparent". Also, this could be handled like a "good writing tip". For example, right now everybody knows that appending a letter to a string a zillion times is not efficient, you should store them in a list, and then .join() them. Similarly, we could know that slicing zillions of long lines and keeping small portion of them is not memory efficient, you should do everytime "shortstring = str(longstring[:2])", for example. Note that this "special coding" will be for an "special case"... in your normal life the code just will be more efficient... Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Slice as a copy... by design?
2008/5/22 Scott Dial <[EMAIL PROTECTED]>: > If we changed Python to slice-by-reference, then tomorrow someone would be > asking why it isn't slice-by-copy. There are pros and cons to both that are Which are the cons of slice-by-reference of an immutable string? > dependent on your application. It's not hard to imagine applications where > you want to hold onto a small portion of a large string, thereby forcing the > entire string to remain in memory. If a slices had a copy method, then I This is a garbage collection issue. It's real, and maybe could be optimized somehow... but I think that this un-optimization is by far smaller than the optimization of not copying it in the first place. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Slice as a copy... by design?
On Thu, 22 May 2008, Gary Herron wrote: In fact, a slice is *not* always a copy! In at least some (simple) cases, a slice references the original string: s = 'abc' t = s[:] s is t True id(s) 3081872000L id(t) 3081872000L I think the more interesting case is where the string objects are not the same object but use (portions of) the same underlying array in memory. If I understand correctly, Python does not do this, and I thought I read something about why not but I can't remember the details. Sharing contents is an obvious optimization which in some circumstances can dramatically reduce the amount of copying that goes on, but without a reasonably clever algorithm to decide when to let the underlying storage go (copying any part still in use), extremely bad behaviour can result - imagine reading in lots of long lines, then keeping just a short piece of each one. By contrast, the worst that can happen with no sharing is that performance and memory use is what you expect - the only "bad" is the apparent missed opportunity for optimization. I wonder if a "shared slice" object would be useful? That is, an object which behaves like a string obtained from a slicing operation except that it shares storage. It could have a .release method to go ahead and copy the underlying storage. One complexity comes to mind immediately - what happens if one takes a shared slice of a shared slice? Presumably it shares the original string's storage, but if the first shared slice is .released what happens to the second shared slice? It would be nice if it shared with the first shared slice, but keeping track of everything could get tricky. I'd be interested in pointers to any existing discussion on this issue. Trivia - right now there are *no* Google hits for 'python shared slice', although there are lots for 'python shared slices'. They don't appear to be talking about the same thing, however (without being exhaustive). Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] Slice as a copy... by design?
2008/5/22 Oleg Broytmann <[EMAIL PROTECTED]>: > I remember some discussions... let me see... google to help... aha: > > http://mail.python.org/pipermail/python-3000/2006-August/003224.html > http://mail.python.org/pipermail/python-3000/2006-August/003242.html These descussions are too general, and implies some work regarding the unification between slice and range, and discusses sequences in general... I'm just asking about strings (the discussion could apply similarly to bytes, but not bytearrays), and why slicing them returns a copy. Of course that when the slice has the step component different that 1, or reverses the string, this could not be done. But when the slice is mystring[x:y], being x < y, we *could* return just a view of the string (llot of emphasis to that "could"). Thanks. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Slice as a copy... by design?
Facundo Batista wrote: I couldn't answer why, so I'm asking here...Is it because the reference counting will be complicated? Is it because it'd be inefficient in other way? It's something else? Or is something that could be done... but is not done yet? If we changed Python to slice-by-reference, then tomorrow someone would be asking why it isn't slice-by-copy. There are pros and cons to both that are dependent on your application. It's not hard to imagine applications where you want to hold onto a small portion of a large string, thereby forcing the entire string to remain in memory. If a slices had a copy method, then I suppose this would be moot. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] Slice as a copy... by design?
Facundo Batista wrote: Hi! A thread in PyAr raised the question that, considering that strings are immutable, why a slice of a string is a copy and not a reference to a part of that string. I couldn't answer why, so I'm asking here...Is it because the reference counting will be complicated? Is it because it'd be inefficient in other way? It's something else? Or is something that could be done... but is not done yet? Thank you very much! In fact, a slice is *not* always a copy! In at least some (simple) cases, a slice references the original string: >>> s = 'abc' >>> t = s[:] >>> s is t True >>> id(s) 3081872000L >>> id(t) 3081872000L Gary Herron ___ 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] Slice as a copy... by design?
On Thu, May 22, 2008 at 12:28:47PM -0300, Facundo Batista wrote: > considering that strings > are immutable, why a slice of a string is a copy and not a reference > to a part of that string. I remember some discussions... let me see... google to help... aha: http://mail.python.org/pipermail/python-3000/2006-August/003224.html http://mail.python.org/pipermail/python-3000/2006-August/003242.html 2006, August... I don't remember what was the resolution of the discussion. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Slice as a copy... by design?
Hi! A thread in PyAr raised the question that, considering that strings are immutable, why a slice of a string is a copy and not a reference to a part of that string. I couldn't answer why, so I'm asking here...Is it because the reference counting will be complicated? Is it because it'd be inefficient in other way? It's something else? Or is something that could be done... but is not done yet? Thank you very much! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Importing bsddb 4.6.21; with or without AES encryption?
> > In any case, what would be the procedure to update the buildbot > > infraestructure?. > You need to import the sources into the Python subversion repository; > I understand Trent was about to do that. Indeed. Where do we stand with regards to svn commit e-mails being sent for 'external'? DB 4.6 is ~16MB... Trent. ___ 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] Issue 643841: Including a new-style proxy base class in 2.6/3.0
Fred Drake wrote: On May 21, 2008, at 5:41 AM, Nick Coghlan wrote: While a proxy class written in C would no doubt be faster than one written in Python, one of the things I'm hoping to achieve is for the stdlib generic proxy to serve as an example for people writing their own new-style proxy classes in addition to being usable as a base class (Adam Olsen suggested ProxyMixin instead of ProxyBase as a possible name). The idea that it would serve as an example seems odd; the reason to make things part of the standard library is because their implementation needs to track the Python core closely. For a proxy, it would be the need to reflect additional slot methods as they're added. A Python implementation may be able to do this just fine, but the performance penalty would make it uninteresting for many large applications. I've added a documentation file to the tracker item and kicked it in Barry's direction (I also bumped the priority to 'release blocker' because I think we need an explicit decision on this one from Barry or Guido before the first beta release of 3.0). Here's what I included in the proposed documentation for ProxyMixin (note that I modelled the implicit unwrapping behaviour directly on the behaviour of weakref.proxy): class:: ProxyMixin(target) A proxy class that ensures all special method invocations which may otherwise bypass the normal :method:`__getattribute__` lookup process are correctly delegated to the specified target object. Normal attribute manipulation operations are also delegated to the specified target object. All operations on a :class:`ProxyMixin` instance return an unproxied result. Operations involving multiple :class:`ProxyMixin` instances (e.g. addition) are permitted, and endeavour to return the same result as would be calculated if the proxy objects were not involved. Custom proxy class implementations may inherit from this class in order to automatically delegate all such special methods that the custom proxy class does not need to provide special handling for. This may not be practical for more complex delegation scenarios (e.g. a local interface to a remote object, or delegating to a weakly referenced target as in :code:`weakref.proxy`), but :class:`ProxyMixin` may still be used as a reference when developing such classes to identify which methods must be defined explicitly on the proxy type in order for them to be delegated correctly by the Python interpreter. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] vmgen based python interpretter
hello everyone,
i'm working on the branch:
http://svn.python.org/projects/python/branches/release25-maint/
i'm trying to build a vmgen based interpreter for python:
http://www.complang.tuwien.ac.at/anton/vmgen
from vmgen's input file, which specifies the python's opcodes a c source is
generated which may be included in ceval.c.
when i include that generated source in ceval.c the whole interpreter crashes
with this error:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209710912 (LWP 28223)]
PyObject_Malloc (nbytes=32) at Objects/obmalloc.c:747
747 if ((pool->freeblock = *(block **)bp) != NULL) {
(gdb)
so far i implemented only 4 opcodes (LOAD_CONST, PRINT_ITEM, PRINT_NEWLINE,
RETURN_VALUE)
on the other hand when i leave these 4 opcodes, as provided by ceval.c within
the switch(opcode) statement every thing works well, the interpreter exits with
an uknown opcode error, when an unknown opcode is executed.
my question is, why does this segfault appear? as far as i know the
PyObject_Malloc is only called by the compiler related code, and i changed code
only in ceval.c
it would would also be helpfull if someone could tell me, how to locate the
code, which causes this SEG fault
hopefully somebody can help me with that
-- michal
___
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] Addition of "pyprocessing" module to standard lib.
On Thu, 22 May 2008, "Martin v. Löwis" wrote: > > I would say that writing portable C code is hard as well, aren't there > > just more tools that help? > > The C compiler in particular. It already gets symbolic constants and > struct layouts right, something that ctypes can't do (because it doesn't > use header files). I don't think it makes much sense to talk about "The C Compiler" when you are discussing matters of portability. Just my $0.02. -- Cheers, Leif___ 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] Addition of "pyprocessing" module to standard lib.
>> Writing portable ctypes modules is really hard - significantly harder >> than writing portable C code (although writing non-portable ctypes >> code is apparently easier than writing non-portable C code). > > I would say that writing portable C code is hard as well, aren't there > just more tools that help? The C compiler in particular. It already gets symbolic constants and struct layouts right, something that ctypes can't do (because it doesn't use header files). Regards, Martin ___ 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
