Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.
Nick Coghlan wrote: Talin wrote: multiprocessing multiprocessing would work for me Me, too. -- 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] Addition of "pyprocessing" module to standard lib.
Tom Pinckney wrote: Why not use MPI? It's cross platform, cross language and very widely supported already. And there're Python bindings already. The point of pyprocessing is that fact that the API is the same as that of the threading module - making it very easy to convert a multithreaded program to a multiprocessing one, and hence making it easy to exploit multiple processors in a CPU bound Python program, regardless of the restrictions imposed by Python's GIL. 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
Re: [Python-Dev] Adding start to enumerate()
Steven D'Aprano wrote: [...] [tongue firmly in cheek] Perhaps what we need is a more flexible enumerate function? enumerate(iterable, start_at_index=0, count_from=0) Super idea. Then we can have a thread about whether it belongs in itertools or somewhere else. [...] Please take your tongue out of your cheek immediately. I am beginning to feel somewhat uncomfortable on your behalf. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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.
Talin wrote: multiprocessing multiprocessing would work for me - it adds the concurrency implications that threading has, but 'processing' on its own would be missing. 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
Re: [Python-Dev] Committing bsddb 4.6.4, and where can I put testsuite temp files?
Brett Cannon wrote: On Tue, May 13, 2008 at 12:41 PM, Jesus Cea <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Cannon wrote: | It is up to the tests to clean up after themselves since they can be | executed directly, so there is not magical location that gets cleaned | up in case a test screws up. You can use test.test_support.TESTFN if | you want a location. Or something from tempfile. I'm worried about the case when a test crashes and leave garbage behind... that will crash future test runs. Then don't crash on tests. =) I guess I would delete the directory before using it, but I guess somebody already had this problem and solved it, somehow. :-? That's usually the other way to go about it. In your test_main() or your setUp() methods you make sure everything is clean before you start. Personally, I use the tempfile module to get a temporary directory and do anything I need in there (see test_runpy.py or test_cmdline_script.py for examples). That way, even if the test does manage to crash in a way that bypasses the shutil.rmtree cleanup call (which is actually fairly hard to do when the cleanup call is in a finally clause or a tearDown method), it won't affect subsequent executions (although it may accumulate clutter in the buildbot machine's temporary directories over time). 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
Re: [Python-Dev] Committing bsddb 4.6.4, and where can I put testsuite temp files?
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).
I'm seeing what appears to be a memory corruption error when using a
debug build of trunk (configure --with-pydebug). It causes a crash
while deallocating the argument tuple passed to DBEnv.lock_get on the
second call in bsddb.test.test_lock's test03_lock_timeout() test.
Platform tested on: OS X 10.4, gcc 4.0.1 x86. BerkeleyDB 4.5.
I haven't tested on other platforms but I expect other buildbots will
also have issues now that the test suite isn't being skipped.
-gps
On Tue, May 13, 2008 at 12:09 PM, Jesus Cea <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I just committed pybsddb 4.6.4 to python svn. My next step (after a
> successfull buildbot cycle, I hope!) is to commit the new testsuite.
> First I need to review any changes there since I maintain pybsddb.
>
> The testsuite creates a lot of files/directories while working. Fine,
> since it cleans later, unless some test crashes hard. My testcode
> defines a variable to the path I want to use to keep those files/dirs.
> Currently it is "/tmp/z-BerkeleyDB", or something like that.
>
> Since my code allows for testcases to be run in multiple threads and/or
> processes, where would be a sensible path choice for temporal files?.
> Current working directory would be fine, if "somebody" is cleaning after
> running all tests.
>
> Ramdisk ("/tmp" in some systems, for example Solaris) would be nice,
> since some test uses transactions, and transactions are write-synchronous.
>
> In my system, runnning all tests serially (you can run all of them in
> parallel, if you wish) takes about 15-20 seconds. Far faster than
> current tests in python svn, and that can be improved even more.
>
> - --
> 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
>
> iQCVAwUBSCnngZlgi5GaxT1NAQLhPwP9GMMyNMgz6mfmfHXVOV8bDJGOQRok95uL
> 14A+K9zXW3/wlp1rhvoPmCHYqvRoCLVkPZ/7pLEQlo1ZksOlHy6BH3MDeDJEjVax
> 69XlzUUeuqplGbTiMdX8qd0dPi2Jp+Akg7U6ZmBdADhF7D21umU474OalKO2eIoL
> ba/wnlMvens=
> =1lai
> -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/greg%40krypto.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
Re: [Python-Dev] Adding start to enumerate()
Greg Ewing wrote: Steven D'Aprano wrote: With iterators being such a fundamental part of Python these days, perhaps one day we'll see the functions in the itertools module become iterator methods I hope not. The set of potential functions that operate on iterators is open-ended, and there's no reason to single out a particular subset and make them methods. I've occasionally experimented with the idea of a 'FlexibleIterator' class that accepted an arbitrary iterable in it's constructor and then used itertools internally to provide native support for concatenation (via itertools.chain) and slicing (via itertools.islice), but have never been able to come up with anything which didn't lend itself to fundamental misunderstanding of what it was doing. I've come to the conclusion that there are some aspects of dealing with arbitrary iterators where trying to make it look 'pretty' starts to hide things that the programmer really needs to be aware of in order to reason correctly about the program. 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
Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.
multiprocessing Greg Ewing wrote: Jesse Noller wrote: I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library Sounds good, but I'd suggest giving a more specific name than "processing", which is so generic as to be meaningless. ___ 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.
The inclusion of the processing module does not exclude the potential to also use or one day include MPI bindings. The goal is to add a module with a "known" API and semantics which allows programmer using cPython to easily take advantage of multple cores (and as a side benefit, machines). In theory - one could also use MPI within an application using the processing module as a communications/message passing system. -Jesse On May 13, 2008, at 9:23 PM, Tom Pinckney <[EMAIL PROTECTED]> wrote: Why not use MPI? It's cross platform, cross language and very widely supported already. And there're Python bindings already. On May 13, 2008, at 8:52 PM, Jesse Noller wrote: I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library - preferably in the 2.6 timeline. In March, I began working on the PEP for the inclusion of the pyprocessing (processing) module into the python standard library[1]. The original email to the stdlib-sig can be found here, it includes a basic overview of the module: http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html The processing module mirrors/mimics the API of the threading module - and with simple import/subclassing changes depending on the code, allows you to leverage multi core machines via an underlying forking mechanism. The module also supports the sharing of data across groups of networked machines - a feature obviously not part of the core threading module, but useful in a distributed environment. As I am trying to finish up the PEP, I want to see if I can address any questions or include any other useful data (including benchmarks) in the PEP prior to publishing it. I am also intending to include basic benchmarks for both the processing module against the threading module as a comparison. -Jesse [1] Processing page: http://pyprocessing.berlios.de/ ___ 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/thomaspinckney3%40gmail.com ___ 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] heads up on svn.python.org ssh keys - debian/ubuntu users may need new ones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 13, 2008, at 7:12 PM, Martin v. Löwis wrote: If you generated your python subversion ssh key during this time on a machine fitting the description above, please consider replacing your keys. apt-get update ; apt-get upgrade on debian will provide you with a ssh-vulnkey program that can be used to test if your ssh keys are valid or not. I'll ping all committers for which ssh-vulnkey reports COMPROMISED. I personally don't think the threat is severe - unless people also published their public SSH keys somewhere, there is little chance that somebody can break in by just guessing them remotely - you still need to try a lot of combinations for user names and passwords, plus with subversion, we'll easily recognize doubtful checkins (as we do even if the committer is legitimate :-). It's also probably worth checking the keys for everyone who has shell access on the python.org machines. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSCpCXHEjvBPtnXfVAQLy5gP+MZJ7/RKDqw9QKvNr9rlGm7GjOBkuWR3B UA91clzb4Iuy+51+V4B3iUcdmwGtpfYum8/2+1/qpi7abO/IiIQvvOKczQzkv5XL ALh59zR2iiBuNg1BVW0JPdkyNt6qr2oe8kKdUZfyrwRSKIukX+e40Oa+1zvfp0E7 9AumiqMUCtI= =EXC8 -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] Addition of "pyprocessing" module to standard lib.
Why not use MPI? It's cross platform, cross language and very widely supported already. And there're Python bindings already. On May 13, 2008, at 8:52 PM, Jesse Noller wrote: I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library - preferably in the 2.6 timeline. In March, I began working on the PEP for the inclusion of the pyprocessing (processing) module into the python standard library[1]. The original email to the stdlib-sig can be found here, it includes a basic overview of the module: http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html The processing module mirrors/mimics the API of the threading module - and with simple import/subclassing changes depending on the code, allows you to leverage multi core machines via an underlying forking mechanism. The module also supports the sharing of data across groups of networked machines - a feature obviously not part of the core threading module, but useful in a distributed environment. As I am trying to finish up the PEP, I want to see if I can address any questions or include any other useful data (including benchmarks) in the PEP prior to publishing it. I am also intending to include basic benchmarks for both the processing module against the threading module as a comparison. -Jesse [1] Processing page: http://pyprocessing.berlios.de/ ___ 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/thomaspinckney3%40gmail.com ___ 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 May 13, 2008, at 8:57 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: Jesse Noller wrote: I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library Sounds good, but I'd suggest giving a more specific name than "processing", which is so generic as to be meaningless. -- Greg Any suggestions? Subprocess is taken and concurrent might be presumptuous unless it was added as concurrent.processing or some like permutation. -Jesse ___ 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.
Jesse Noller wrote: I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library Sounds good, but I'd suggest giving a more specific name than "processing", which is so generic as to be meaningless. -- 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
[Python-Dev] Addition of "pyprocessing" module to standard lib.
I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library - preferably in the 2.6 timeline. In March, I began working on the PEP for the inclusion of the pyprocessing (processing) module into the python standard library[1]. The original email to the stdlib-sig can be found here, it includes a basic overview of the module: http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html The processing module mirrors/mimics the API of the threading module - and with simple import/subclassing changes depending on the code, allows you to leverage multi core machines via an underlying forking mechanism. The module also supports the sharing of data across groups of networked machines - a feature obviously not part of the core threading module, but useful in a distributed environment. As I am trying to finish up the PEP, I want to see if I can address any questions or include any other useful data (including benchmarks) in the PEP prior to publishing it. I am also intending to include basic benchmarks for both the processing module against the threading module as a comparison. -Jesse [1] Processing page: http://pyprocessing.berlios.de/ ___ 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] Adding start to enumerate()
Steven D'Aprano wrote: With iterators being such a fundamental part of Python these days, perhaps one day we'll see the functions in the itertools module become iterator methods I hope not. The set of potential functions that operate on iterators is open-ended, and there's no reason to single out a particular subset and make them methods. Also, it would force all iterators to inherit from a common base class in order to support those methods, which is not a Pythonic thing to do. Strings are different, because (a) they're a concrete class, and (b) string methods benefit from having access to implementation details of the string. -- 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] heads up on svn.python.org ssh keys - debian/ubuntu users may need new ones
On Tue, May 13, 2008 at 7:12 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > If you generated your python subversion ssh key during this time on a > > machine fitting the description above, please consider replacing your > > keys. > > > > apt-get update ; apt-get upgrade on debian will provide you with a > > ssh-vulnkey program that can be used to test if your ssh keys are > > valid or not. > > I'll ping all committers for which ssh-vulnkey reports COMPROMISED. > > I personally don't think the threat is severe - unless people also > published their public SSH keys somewhere, there is little chance that > somebody can break in by just guessing them remotely - you still need > to try a lot of combinations for user names and passwords, plus with > subversion, we'll easily recognize doubtful checkins (as we do even > if the committer is legitimate :-). > Well, I had a break in on my public server (peadrop.com) this week, which had a copy my ssh pubkey. I don't know if the attacker took a look at my pubkeys, but I won't take any change. So, I definitely have to change my key, ASAP. -- Alexandre ___ 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] BSDDB3
On Tue, May 13, 2008 at 4:54 PM, Jesus Cea <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Gregory P. Smith wrote: > | After that, merging his changes into trunk will be relatively easy and I > | think we should give jcea commit access and let him do it and henceforth > | use python svn as the official repository for the pybsddb code and > | documentation. > | > | I do not see this as a daunting task assuming jcea is willing to be > | volunteered to do the merge and to handle any py3k merge issues that > | come up. > > Well, I would like to keep bsddb3 alive outside python SVN. There are a > few reasons (like being able to accept foreign patches, for instance); > the main one is: I've published *four* bsddb3 versions in the last 3-4 > months. Each release gives a quantum leap improvement in Berkeley DB > support (for example, replication and distributed transactions). If I > link the bsddb releases to python ones, progress would be very slow. > This is why I think bsddb should just be an external package. The few wrappers we still have in the core (sqlite and tkinter) do not have a high churn rate at all since both are fairly stable and not constantly changing (or at least that I can tell). Regardless, we are trying to prevent external maintenance from happening anymore. Python is not like a Linux distribution where we push patches upstream; we are the upstream. Patches should end with us. > In current state, bsddb3 still needs a lot of work to catch current > Berkeley DB feature sets. I think I can publish a new release per month > until 2009. Those releases will be consistent improvements in Berkeley > DB support. But I don't want to link Python with this much needed bsddb3 > releases. My intention is to upgrade python bsddb3 versions from time to > time, enough to keep them fresh without burden you with constant > patches. On time for official releases. > If the wrapper is still behind then I think this is another reason to remove the package from the core and just keep it external. Why have something in the core that is outdated when its committed? > Moreover, keeping the bsddb3 separate will allow me to publish a new > release when Oracle updates Berkeley DB. This has been a serious issue > in the past. bsddb3, as a separate project, can support last Berkeley DB > release without python build servers needing a BDB upgrade and users > waiting a full release cycle (months). > > A last point: I can provide bsddb3 packages for python 2.3, 2.4 and 2.5, > also. > > That said, I'm very interested in being a good python-dev netizen. I > will do what needed to merge patches back and forth. I will read your > comments with maximum interest. I will have the buildbot webpage open > permanently :-). I will do the python 3.0 necessary changes when time > comes. And Python will integrate a bsddb3 library proved in the wild, > verified against 5 different python releases and 8 different Berkeley DB > ones. > > And I will love to do additional work in python, aside bsddb. > > Let me show you that I can do it... I am always happy to have developers to step forward and want to help! And the last thing I want to do is discourage another contributor, but I still think bsddb should be gone from 3.0. The churn rate sounds too high on Berkeley DB itself to warrant making it an included package that we continue to support internally. I also worry about maintenance in terms of multiple people being able to help. bsddb sat there for a while when Gregory scaled back his work. I remember trying to do the initial port of bsddb to 3.0 and it was hard and not many people wanted to work on it (and I don't blame them). sqlite and tkinter, on the other hand, was not as difficult and we have never had issues finding people willing to help with the code. While Jesus is up for doing all of this work at this moment (which is great!), if he fell off the face of the earth we will be stuck with a stale package again. -Brett ___ 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] BSDDB3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregory P. Smith wrote: | After that, merging his changes into trunk will be relatively easy and I | think we should give jcea commit access and let him do it and henceforth | use python svn as the official repository for the pybsddb code and | documentation. | | I do not see this as a daunting task assuming jcea is willing to be | volunteered to do the merge and to handle any py3k merge issues that | come up. Well, I would like to keep bsddb3 alive outside python SVN. There are a few reasons (like being able to accept foreign patches, for instance); the main one is: I've published *four* bsddb3 versions in the last 3-4 months. Each release gives a quantum leap improvement in Berkeley DB support (for example, replication and distributed transactions). If I link the bsddb releases to python ones, progress would be very slow. In current state, bsddb3 still needs a lot of work to catch current Berkeley DB feature sets. I think I can publish a new release per month until 2009. Those releases will be consistent improvements in Berkeley DB support. But I don't want to link Python with this much needed bsddb3 releases. My intention is to upgrade python bsddb3 versions from time to time, enough to keep them fresh without burden you with constant patches. On time for official releases. Moreover, keeping the bsddb3 separate will allow me to publish a new release when Oracle updates Berkeley DB. This has been a serious issue in the past. bsddb3, as a separate project, can support last Berkeley DB release without python build servers needing a BDB upgrade and users waiting a full release cycle (months). A last point: I can provide bsddb3 packages for python 2.3, 2.4 and 2.5, also. That said, I'm very interested in being a good python-dev netizen. I will do what needed to merge patches back and forth. I will read your comments with maximum interest. I will have the buildbot webpage open permanently :-). I will do the python 3.0 necessary changes when time comes. And Python will integrate a bsddb3 library proved in the wild, verified against 5 different python releases and 8 different Berkeley DB ones. And I will love to do additional work in python, aside bsddb. Let me show you that I can do it... - -- 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 iQCVAwUBSCoqO5lgi5GaxT1NAQJP1wP6A46t6f7wajIyrUoScLE8RSqJSncnW1jo r/7A69hRC6UW2I0JbMJ+wFVcXC2507XaCiC0l0Xljq9IqH7JAU6H/gwv6Cyp4eVF tmwiUVFmlw+wyZMCnvBAa4EOF4/ZBwrILIdNywFNpoRmCLH8RmiBDE+x4jgjcSCh N5yssDDLzPk= =/YFF -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] BSDDB3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent Nelson wrote: |> Next week I will (if nothing goes wrong) publish pybsddb |> 4.6.4. This release supports distributed transactions and |> replication, testsuite is way faster, and rewritten to be |> able to launch tests from multiple threads/processes if you |> wish, setuptools/pypi support, etc. | | Great! Once you've settled in with your changes let me know and I'll help with doing the necessary things on the Windows-side to set up the bsddb46.vcproj and switching the build to use that. Python SVN updated. Let me know if you need anything from me. - -- 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 iQCVAwUBSCopHZlgi5GaxT1NAQKrCQQAj/HTk5oqSbF2PYkZpCw2T7Dd6yEgddlY L+qW1Cde/b3duClEfawy7kf5DkSjlGLVZ9XSS+njAMKszzYK6ZIg9N4GEu5A9TO2 Rg2PiytaPbs88Jo5IIlDjvaVFPPqsOasn7WH1wcawtUKNei8whMReOveZgYXfFFf QphSJ7zspNU= =L6jr -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] heads up on svn.python.org ssh keys - debian/ubuntu users may need new ones
> If you generated your python subversion ssh key during this time on a > machine fitting the description above, please consider replacing your > keys. > > apt-get update ; apt-get upgrade on debian will provide you with a > ssh-vulnkey program that can be used to test if your ssh keys are > valid or not. I'll ping all committers for which ssh-vulnkey reports COMPROMISED. I personally don't think the threat is severe - unless people also published their public SSH keys somewhere, there is little chance that somebody can break in by just guessing them remotely - you still need to try a lot of combinations for user names and passwords, plus with subversion, we'll easily recognize doubtful checkins (as we do even if the committer is legitimate :-). 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] Adding start to enumerate()
On Tue, May 13, 2008 at 3:11 PM, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > With iterators being such a fundamental part of Python these days, > perhaps one day we'll see the functions in the itertools module become > iterator methods, as happened with strings. But that's a discussion for > another day. Unlikely. Every method needs to be reimplemented for each type that is expected to support it. There are only two string types, so that's manageable. But there are many dozens of iterator types. Insisting on a common base class would be unpythonic. Plus, the functional approach makes it possible to treat various non-iterators (like sequences and other iterables) the same way. -- --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] Adding start to enumerate()
On Wed, 14 May 2008 05:01:20 am you wrote: > > While slices are wonderfully useful things, they aren't panaceas. > > They're not so useful with iterators, and they make a copy of the > > data, which can be problematic if there's a *lot* of it. > > That's why we have itertools.islice(). I always forget itertools. Perhaps I should engrave it on my monitor as a reminder. With iterators being such a fundamental part of Python these days, perhaps one day we'll see the functions in the itertools module become iterator methods, as happened with strings. But that's a discussion for another day. -- Steven ___ 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] heads up on svn.python.org ssh keys - debian/ubuntu users may need new ones
On Tue, May 13, 2008 at 1:45 PM, Guilherme Polo <[EMAIL PROTECTED]> wrote:\ > Thanks for pointing it out Gregory. > > ssh-vulnkey says most of my keys are compromised, including the one > used for python's svn. Then according to the developer FAQ, you should change your keys and email [EMAIL PROTECTED] . -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] Adding start to enumerate()
"Duncan Booth" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | | If you are generating paginated output then a function to generate an | arbitrary page would likely want to enumerate starting at some value larger | than one. | | Of course in that case you'll also want to skip part way through the data, | but I think it is more likely that you'll want to enumerate the partial | data (e.g. if it is a database query) rather than slice the enumeration. Not if the data is split across multiple files. I remember editing and printing a book from multiple files. Decent word processors have an option to start page numbering at something other than 1. Much bigger memories perhaps make this less common now. ___ 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?
On Tue, May 13, 2008 at 12:41 PM, Jesus Cea <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Brett Cannon wrote: > | It is up to the tests to clean up after themselves since they can be > | executed directly, so there is not magical location that gets cleaned > | up in case a test screws up. You can use test.test_support.TESTFN if > | you want a location. Or something from tempfile. > > I'm worried about the case when a test crashes and leave garbage > behind... that will crash future test runs. > Then don't crash on tests. =) > I guess I would delete the directory before using it, but I guess > somebody already had this problem and solved it, somehow. :-? That's usually the other way to go about it. In your test_main() or your setUp() methods you make sure everything is clean before you start. -Brett ___ 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 Brett Cannon wrote: | It is up to the tests to clean up after themselves since they can be | executed directly, so there is not magical location that gets cleaned | up in case a test screws up. You can use test.test_support.TESTFN if | you want a location. Or something from tempfile. I'm worried about the case when a test crashes and leave garbage behind... that will crash future test runs. I guess I would delete the directory before using it, but I guess somebody already had this problem and solved it, somehow. :-? - -- 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 iQCVAwUBSCnvA5lgi5GaxT1NAQIM7wP9EEOsr+WYpQtA+0tbHTv247kplxzNDo7T WTIWU+pfs575gMSbK5NUCrr6TXuFsqlgybOaFqA3wTKHiKslcRhkBrmjtd/Wj4iF /bdv8C/SnLdM443ZnakWFnPAH+Y/horuRxKvsx01lNdaNtbADZG9bClOCfVBfoWM j/fUSb5RtAU= =GkQb -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] Committing bsddb 4.6.4, and where can I put testsuite temp files?
On Tue, May 13, 2008 at 9:09 PM, Jesus Cea <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just committed pybsddb 4.6.4 to python svn. My next step (after a > successfull buildbot cycle, I hope!) is to commit the new testsuite. > First I need to review any changes there since I maintain pybsddb. > > The testsuite creates a lot of files/directories while working. Fine, > since it cleans later, unless some test crashes hard. My testcode > defines a variable to the path I want to use to keep those files/dirs. > Currently it is "/tmp/z-BerkeleyDB", or something like that. > > Since my code allows for testcases to be run in multiple threads and/or > processes, where would be a sensible path choice for temporal files?. > Current working directory would be fine, if "somebody" is cleaning after > running all tests. > It is up to the tests to clean up after themselves since they can be executed directly, so there is not magical location that gets cleaned up in case a test screws up. You can use test.test_support.TESTFN if you want a location. Or something from tempfile. -Brett ___ 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] Committing bsddb 4.6.4, and where can I put testsuite temp files?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just committed pybsddb 4.6.4 to python svn. My next step (after a
successfull buildbot cycle, I hope!) is to commit the new testsuite.
First I need to review any changes there since I maintain pybsddb.
The testsuite creates a lot of files/directories while working. Fine,
since it cleans later, unless some test crashes hard. My testcode
defines a variable to the path I want to use to keep those files/dirs.
Currently it is "/tmp/z-BerkeleyDB", or something like that.
Since my code allows for testcases to be run in multiple threads and/or
processes, where would be a sensible path choice for temporal files?.
Current working directory would be fine, if "somebody" is cleaning after
running all tests.
Ramdisk ("/tmp" in some systems, for example Solaris) would be nice,
since some test uses transactions, and transactions are write-synchronous.
In my system, runnning all tests serially (you can run all of them in
parallel, if you wish) takes about 15-20 seconds. Far faster than
current tests in python svn, and that can be improved even more.
- --
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
iQCVAwUBSCnngZlgi5GaxT1NAQLhPwP9GMMyNMgz6mfmfHXVOV8bDJGOQRok95uL
14A+K9zXW3/wlp1rhvoPmCHYqvRoCLVkPZ/7pLEQlo1ZksOlHy6BH3MDeDJEjVax
69XlzUUeuqplGbTiMdX8qd0dPi2Jp+Akg7U6ZmBdADhF7D21umU474OalKO2eIoL
ba/wnlMvens=
=1lai
-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] Adding start to enumerate()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Ewing wrote: | Steven D'Aprano wrote: |> The only thing I can think of is printing lines with line numbers | | Parsing a file and wanting to be able to print | error messages with line numbers would seem to | be a fairly likely use. What is wrong with: for lineno,line in enumerate(file) : ~ print lineno+1,line :-? - -- 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 iQCVAwUBSCnopJlgi5GaxT1NAQJSAAP/V8U23owV+YjGiAKQbZOb6FIXA6Wfll65 /oLg1WuzQ/KBre41LJ3sw4RS8+FThrfihe56nYmJagnkvo353rceb/W45T85b17Y +VXg33jQy8UkoJX2a0YwFP8jZPO+5iWlO6zUc44iisBmh8BeLCMQAJHl6+0pJfqQ /cp/BLcxEYI= =T1Bc -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] Adding start to enumerate()
Guido van Rossum schrieb:
On Tue, May 13, 2008 at 11:59 AM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
2008/5/13, Steven D'Aprano <[EMAIL PROTECTED]>:
> Perhaps what we need is a more flexible enumerate function?
> enumerate(iterable, start_at_index=0, count_from=0)
+1 to provide both options: they're not intrusive (as I can keep using
enumerate without those), and having both helps in the understanding
of the function.
I mean, if I find an option that is "start", I can confuse if it will
start counting or giving me the elements of the iterable... if I found
both parameters, it will be easier to understand.
Actually, having both dramatically increases the potential for
confusion. Once you have the starting index option, you're always
going to be worried about whether the first index generated defaults
to zero or to the starting index, since depending on your use case one
or the other is vastly more useful...
We already have itertools.islice() which can handle both of these
easily (slice the input or slice the output).
-1 on providing a start index.
+1 on providing a start value for the count, making it a
positional-with-optional-keyword-name ('start') parameter.
This is what's now implemented in SVN. Thanks for the discussion!
cheers,
Georg
___
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] Adding start to enumerate()
On Tue, May 13, 2008 at 11:59 AM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/5/13, Steven D'Aprano <[EMAIL PROTECTED]>:
>
>
> > Perhaps what we need is a more flexible enumerate function?
> > enumerate(iterable, start_at_index=0, count_from=0)
>
> +1 to provide both options: they're not intrusive (as I can keep using
> enumerate without those), and having both helps in the understanding
> of the function.
>
> I mean, if I find an option that is "start", I can confuse if it will
> start counting or giving me the elements of the iterable... if I found
> both parameters, it will be easier to understand.
Actually, having both dramatically increases the potential for
confusion. Once you have the starting index option, you're always
going to be worried about whether the first index generated defaults
to zero or to the starting index, since depending on your use case one
or the other is vastly more useful...
We already have itertools.islice() which can handle both of these
easily (slice the input or slice the output).
-1 on providing a start index.
+1 on providing a start value for the count, making it a
positional-with-optional-keyword-name ('start') parameter.
--
--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] Adding start to enumerate()
On Tue, May 13, 2008 at 11:53 AM, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Wed, 14 May 2008 12:25:01 am Guido van Rossum wrote: > > > However I see no use for skipping items > > from the start, > > You've never had to deal with data where the first N items were special > in some way? e.g. skipping over a header line in a file? Of course I have. But never in the argument to enumerate(). [...] > > and if that use case ever came up, passing a slice to > > enumerate() would be the appropriate thing to do. > > While slices are wonderfully useful things, they aren't panaceas. > They're not so useful with iterators, and they make a copy of the data, > which can be problematic if there's a *lot* of it. That's why we have itertools.islice(). -- --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] Adding start to enumerate()
2008/5/13, Steven D'Aprano <[EMAIL PROTECTED]>: > Perhaps what we need is a more flexible enumerate function? > enumerate(iterable, start_at_index=0, count_from=0) +1 to provide both options: they're not intrusive (as I can keep using enumerate without those), and having both helps in the understanding of the function. I mean, if I find an option that is "start", I can confuse if it will start counting or giving me the elements of the iterable... if I found both parameters, it will be easier to understand. 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] Adding start to enumerate()
On Wed, 14 May 2008 12:25:01 am Guido van Rossum wrote: > However I see no use for skipping items > from the start, You've never had to deal with data where the first N items were special in some way? e.g. skipping over a header line in a file? I know I've written code like this before: it = iter(whatever()) for i in xrange(N): # skip the first N items it.next() for item in it: process(item) > and if that use case ever came up, passing a slice to > enumerate() would be the appropriate thing to do. While slices are wonderfully useful things, they aren't panaceas. They're not so useful with iterators, and they make a copy of the data, which can be problematic if there's a *lot* of it. [tongue firmly in cheek] Perhaps what we need is a more flexible enumerate function? enumerate(iterable, start_at_index=0, count_from=0) Having a consistent index provided by enumerate reduces the amount of thought I have to put into the loop structure, and avoids the temptation to do this: for i, item in enumerate(seq, start=1): print "line %d: %s" % (i, item) # subtract one from the index to adjust for one-based counting seq[i-1] = foo(item) I never need to think about whether it is zero-based, one-based, or some other N-based counting, because it is always zero-based. -0 on any change to enumerate. -- Steven D'Aprano ___ 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] heads up on svn.python.org ssh keys - debian/ubuntu users may need new ones
2008/5/13 Gregory P. Smith <[EMAIL PROTECTED]>: > Heads up. > > Debian screwed up. As a result all ssh and ssl keys generated in the > last 18 months on debian and ubuntu systems may be compromised due to > not using a good random number generator seed. > http://lists.debian.org/debian-security-announce/2008/msg00152.html > and http://www.links.org/?p=327 > > If you generated your python subversion ssh key during this time on a > machine fitting the description above, please consider replacing your > keys. > > apt-get update ; apt-get upgrade on debian will provide you with a > ssh-vulnkey program that can be used to test if your ssh keys are > valid or not. > Thanks for pointing it out Gregory. ssh-vulnkey says most of my keys are compromised, including the one used for python's svn. > -gps > ___ > 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/ggpolo%40gmail.com > -- -- Guilherme H. Polo Goncalves ___ 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] heads up on svn.python.org ssh keys - debian/ubuntu users may need new ones
Heads up. Debian screwed up. As a result all ssh and ssl keys generated in the last 18 months on debian and ubuntu systems may be compromised due to not using a good random number generator seed. http://lists.debian.org/debian-security-announce/2008/msg00152.html and http://www.links.org/?p=327 If you generated your python subversion ssh key during this time on a machine fitting the description above, please consider replacing your keys. apt-get update ; apt-get upgrade on debian will provide you with a ssh-vulnkey program that can be used to test if your ssh keys are valid or not. -gps ___ 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] Adding start to enumerate()
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote: > On Mon, 12 May 2008 08:20:51 am Georg Brandl wrote: >> I believe the following is a common use-case for enumerate() >> (at least, I've used it quite some times): >> >> for lineno, line in enumerate(fileobject): >> ... >> >> For this, it would be nice to have a start parameter for enumerate(). > > Why would it be nice? What would you use it for? > > The only thing I can think of is printing lines with line numbers, and > starting those line numbers at one instead of zero. If that's the only > use-case, should it require built-in support? > If you are generating paginated output then a function to generate an arbitrary page would likely want to enumerate starting at some value larger than one. Of course in that case you'll also want to skip part way through the data, but I think it is more likely that you'll want to enumerate the partial data (e.g. if it is a database query) rather than slice the enumeration. ___ 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] Adding start to enumerate()
On Tue, May 13, 2008 at 2:40 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Terry Reedy wrote: >> >> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> | I'd like to hear from Raymond before we do this. I'm pretty sure we had >> | a reason for *not* doing it that way in when enumerate() was added, but >> | I can't remember what that reason might have been... >> >> http://bugs.python.org/issue2831 > > Thanks. I think this part is the main reason I see a start argument to > enumerate as potentially problematic: > > """all variants can easily be misread as starting at the nth item in the > sequence (much like islice() does now): enumerate(3, 'abcdefg') --> > (3,'d') (4,'e') (5, 'f') (6, 'g').""" So the ambiguity is that enumerate(it, start=N) could be taken as skipping the first N items of it rather than adding N to the index it returns. (And it is my own argument!) I'd like to withdraw this argument. There are two separate use cases for using enumerate(): one is to iterate over a sequence and to have a handy index by which to update the value in the sequence. Another is for 1-based counting, usually when printing 1-based ordinals (such as line numbers in files, dates in a month or months in a year, etc.). N-based counting is less common but still conceivable. However I see no use for skipping items from the start, and if that use case ever came up, passing a slice to enumerate() would be the appropriate thing to do. In fact, if you passed in a slice, you might also want to pass a corresponding start value so the indices produced match those of the original sequence. So, I am still in favor of adding a new argument to enumerate(). I'm neutral on the need for a keyword (don't think it would hurt, not sure how much it matters). I'm strongly against making it an optional *leading* argument like Raymond proposed; that's a style I just don't want to promote, range() and the curses module notwithstanding. > Is the need to use zip(count(3), seq) for the offset index case really such > a burden given the associated benefits in keeping the builtin function > really simple and easy to understand? Yes, zip(count(3), seq) is too complex for this simple use case. I've always solved this so far with this less-than-elegant but certainly simpler idiom (except for users stuck in the tradition of for-loops in certain older languages :-): for i, line in enumerat(lines): i += 1 print "%4d. %s" % (i, line) and variants thereof. [Also added to the issue.] -- --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] Adding start to enumerate()
Terry Reedy wrote: "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I'd like to hear from Raymond before we do this. I'm pretty sure we had | a reason for *not* doing it that way in when enumerate() was added, but | I can't remember what that reason might have been... http://bugs.python.org/issue2831 Thanks. I think this part is the main reason I see a start argument to enumerate as potentially problematic: """all variants can easily be misread as starting at the nth item in the sequence (much like islice() does now): enumerate(3, 'abcdefg') --> (3,'d') (4,'e') (5, 'f') (6, 'g').""" Is the need to use zip(count(3), seq) for the offset index case really such a burden given the associated benefits in keeping the builtin function really simple and easy to understand? 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
