stdlib-sig March 2008

stdlib-sig@python.org

18 participants
26 discussions

Py3K bsddb name query
by Mark Summerfield 10 Apr '08

10 Apr '08

Hi, I notice that in PEP 3108 the dbm modules are going to be in package dbm: New Old ----------- -------------------------------------------- dbm.tools anydbm + whichdb dbm.db db.hash (actually bsd db so presumably using bsddb.hashopen() behind the scenes?) dbm.ndbm dbm dbm.dumb dumbdbm dbm.gnu gdbm This leaves bsddb as a separate package. As far as I can tell bsddb is not so different from the others. I presume (although the documentation for bsddbobject.keys() denies it) that btopen() gives lexicographical ordering and rnopen() give insertion order ordering by keys, whereas hashopen() is unordered like a dict and like the other dbms provided. In any case the name dbm.db seems wrong to me (too generic when the others are specific to their dbm type), so at the least shouldn't dbm.db be renamed dbm.bsd? If consistency were wanted, dbm.bsd.open() could be a wrapper for dbm.bsd.hashopen() but only with filenname, flag and mode arguments so as to match the other dbms, and with dbm.bsd.hashopen(), dbm.bsd.btopen() and dbm.bsd.rnopen() and the other bsddb-specific functions available in the module as usual? -- Mark Summerfield, Qtrac Ltd., www.qtrac.eu

4 4

reorganizing xmlrpc and adding json/jsonrpc
by Ronny Pfannschmidt 29 Mar '08

29 Mar '08

hi, I propose adding a json lib in combination with a reorganisation of xmlrpc in order to support jsonrpc either by choice of the programmer or content-type neogation. This mostly requires a json lib that's able to marshal jsonrpc requests/responses sharing the api of the xmlrpclib and some simple content-type choice in the rpcserver. additional changes could be the reimplementation in terms of wsgi instead of having separate cgi/http server implementations and recreating the original api in terms of the wsgiref cgi/standalone handlers. I'm looking forward to comments on this. --- Ronny Pfannschmidt

2 1

What about a mirror to Google Groups?
by Giampaolo Rodolà 29 Mar '08

29 Mar '08

Hi, Do you think it would be possible to create a mirrror of this list to Google Groups? I usually read python-dev, python-3000 and python-ideas via Google Groups which I find very convenient (or, at least, surely more convenient than using the stinky mailman web interface). Toughs?

2 1

Depreciation warnings in 2.6 for removed modules in 3.x
by Alexandre Vassalotti 22 Mar '08

22 Mar '08

Hi, I would like to know what is the plan for the removal warnings in 2.6. PEP 3108 states: For the removal of modules that are continuing to exist in the Python 2.x series (i.e., not deprecated explicitly in the 2.x series), a proper warning will be set that is silenced by default; PendingDeprecationWarning initially, moving over to a Py3K-specific warning later if one comes into existence. So if I understand correctly, this means that modules that already are depreciated won't have an extra 3.x warning, right? And for other, something like the following should be added, right? from warnings import warnpy3k as _warnpy3k _warnpy3k("The 'x' module is not supported in 3.x", stacklevel=2) Finally, would it be a good idea to add tests for the added warnings in test_py3kwarns? If so, what would be the best way to do it? Does something like this would fit? def test_removed_modules(self): # For superseded modules, state the replacement expected = "The '%s' module is not supported in 3.x, use %s instead." replacements = { "hotshot": "the 'profile' module", "cProfile": "the 'profile' module", "cPickle": "the 'pickle' module", "rexec": "the exec statement", ... } for m, r in replacements: with catch_warning() as w: self.assertWarning(__import__(m), w, expected % (m, r)) Thanks, -- Alexandre

2 1

Fwd: [New-bugs-announce] [issue2433] Merge audio modules
by Facundo Batista 20 Mar '08

20 Mar '08

FYI ---------- Forwarded message ---------- From: Michael Bishop <report(a)bugs.python.org> Date: 20-mar-2008 12:20 Subject: [New-bugs-announce] [issue2433] Merge audio modules To: new-bugs-announce(a)python.org New submission from Michael Bishop <michaelsplace(a)gmail.com>: There are many duplicate functions throughout the many audio modules. I plan to merge relevant functions into 2 modules; a C module and a py module. Once I go through the audio modules in detail, I'll post my plan here. Reference: http://www.python.org/dev/peps/pep-3108/ http://mail.python.org/pipermail/python-3000/2007-January/005295.html ---------- components: Library (Lib) messages: 64182 nosy: MichaelBishop, brett.cannon severity: normal status: open title: Merge audio modules type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker <report(a)bugs.python.org> <http://bugs.python.org/issue2433> __________________________________ _______________________________________________ New-bugs-announce mailing list New-bugs-announce(a)python.org http://mail.python.org/mailman/listinfo/new-bugs-announce -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

2 1

proposed removal: netrc
by Brett Cannon 20 Mar '08

20 Mar '08

Who even uses this stuff anymore? FTP itself is suspect, let alone storing your password in a plaintext file. -Brett

2 3

proposed removal: colorsys
by Brett Cannon 20 Mar '08

20 Mar '08

No one can remember what the module is for (pretty much no one here at the sprint right now could remember what the module is for). Plus the stdlib does not really aim towards image work. -Brett

5 4

proposed removal: ftplib
by Raymond Hettinger 20 Mar '08

20 Mar '08

-1 Until there is a better implementation in the stdlib, I think this module needs to be kept. My company uses it and I've seen it used elsewhere. Raymond

2 1

Processing module inclusion into the stdlib proposal
by Jesse Noller 20 Mar '08

20 Mar '08

I have started work on a PEP for the inclusion of the PyProcessing module (http://pypi.python.org/pypi/processing/ and http://developer.berlios.de/projects/pyprocessing) for inclusion into the stdlib in an upcoming release. The pyprocessing module "mostly mimicks" the threading module API to provide a "drop in" process-based approach to concurrency allowing applications within python to utilize multiple cores. For example: from threading import Thread class threads_object(Thread): def run(self): function_to_run() becomes: from processing import Process class process_object(Process): def run(self): function_to_run() Currently, the module runs on Unix/Linux/OSX and Windows. It supports the following features: * Objects can be transferred between processes using pipes or multi-producer/multi-consumer queues. * Objects can be shared between processes using a server process or (for simple data) shared memory. * Equivalents of all the synchronization primitives in ``threading`` are available. * A ``Pool`` class makes it easy to submit tasks to a pool of worker processes. In addition to local concurrency ala "just like threading" model - the processing module allows users to also share data and processes across a cluster of machines via the server Managers and Proxy objects (secured data transfer is supported, data is transferred via pickles). I believe that prior/during inclusion, additional tests will be desired to enhance coverage - but the tests which are already provided test and showcase the module well. I have spoken to the writer, Richard Oudkerk about his willingness to maintain the processing module according to normal stdlib requirements and he is more than willing to do so. I believe inclusion into the standard library will be very beneficial for a lot of people looking to larger-scale applications and for a method to side-step the current threading/GIL implementation. This module easily allows users to exploit their "$N core" machines, in a fashion they are already familiar with. I would suggest that the module is placed at the top-level next to the threading module, however, there is the thought that both this module, and the threading module should be moved to a concurrent.* namespace (i.e: concurrent.threading, concurrent.processing) to allow for additional library inclusion at a later date. IMHO: I think this is simply a "first step" in the evolution of the python stdlib to support these sorts of things - but I also believe it is an excellent first step. Please feel free to ask any questions, comments, etc. The more feedback the better the PEP will be! -jesse

2 1

proposed removal: ftplib
by Brett Cannon 20 Mar '08

20 Mar '08

There is a better implementation in Twisted. FTP is inherently unsafe. And the interface is pretty crappy. -Brett

5 4

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

stdlib-sig March 2008