Re: [Python-Dev] Iterable String Redux (aka String ABC)
Greg Ewing schrieb: Bill Janssen wrote: Look, even if there were *no* additional methods, it's worth adding the base class, just to differentiate the class from the Sequence, as a marker, so that those of us who want to ask "isinstance(o, String)" can do so. Doesn't isinstance(x, basestring) already cover that? That doesn't cover UserString, for example. 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] Finishing up PEP 3108
Brett Cannon schrieb: The issues related to PEP 3108 now total 14. With the beta (supposedly) in a week, I am hoping the last minor details can be pulled together or decisions made on what can be postponed and what should definitely be considered a release blocker. Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical. It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ... Issue 2848 - mimetools has been deprecated for a while, but it is still used in a bunch of places. Since this has been deprecated in PEP 4 for a long time, should we add the removal warning in 2.6 now and then make its actual removal of usage something to do by another beta? Issue 2849 - rfc822 is the same problem as mimetools. The problem is that nobody seems to know what exactly distinguishes mimetools/rfc822' classes and its successor's (email's) classes, so it's hard to replace it in the stdlib. Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then again, pydoc is busted thanks to the new doc format. I will try to handle this in the coming week. Issue 2919 - profile and cProfile needs to be merged. This has not been dealt with yet. Would it be reasonable to deprecate importing cProfile directly in 2.6 with the assumption the merge will work out for 3.0? That's not the right way to go, you don't want to deprecate cStringIO or cPickle either. So that is everything that's left. Issue 2775 is the tracking issue so you can look there to see what issues are still open and need work. I was hoping to spend Monday and Tuesday trying to tie up as many loose ends as possible, but the conference paper I have been working on that was due Sunday is now due a week later, and so Monday and Tuesday will be spent on that (supervisor's orders). Plus I am flying out Wednesday for 10 days to help my mother move and I don't know when I will get Net again. In other words, I still need help. =) Let's hope we get this right in time. Then again, there are lots of other release blockers, so it may well be that the beta is delayed by some time. 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] [Python-3000] PyString -> PyBytes C API renaming (Stabilizing the C API of 2.6 and 3.0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 M.-A. Lemburg wrote: | If you use PyBytes APIs, you expect to find PyBytes functions in | the libs and also set breakpoints on these. Very good point. - -- 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 iQCVAwUBSD5ccplgi5GaxT1NAQIZwQP/SMW+GFHxPWui2/tjj2DgZtnzYigjQj/o T8/DYFXEwls65E1xukOi3zS9ePU49u+i36EaVOvYmYdasedTmODnV3anmBo49VFv rsWWr4BBbRwLj4TjjwWPGy7KNKCvyG/mIiBH0uq9tOe2oW9gZng67e1f3snBIite mw4qF6w9bmw= =1Rh8 -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] Why is type_modified() in typeobject .c not a public function?
Stefan Behnel behnel.de> writes:
> BTW, I noticed that the code in typeobject.c uses "DECREF before set" two
> times, like this:
>
> method_cache[h].version = type->tp_version_tag;
> method_cache[h].value = res; /* borrowed */
> Py_INCREF(name);
> Py_DECREF(method_cache[h].name);
> method_cache[h].name = name;
Since this is so common, would it be useful to define a macro for the correct
construct?
Something like
#define Py_SETREF(var, obj) \
{ PyObject *tmp = (var); Py_INCREF(obj); \
(var) = (obj); Py_XDECREF(tmp); }
Or, if we want to allow more optimizations, make two versions of it:
#define Py_SETREF(var, obj) \
{ PyObject *tmp = (var); Py_INCREF(obj); \
(var) = (obj); Py_DECREF(tmp); }
#define Py_XSETREF(var, obj) \
{ PyObject *tmp = (var); Py_INCREF(obj); \
(var) = (obj); Py_XDECREF(tmp); }
Regards
Antoine.
___
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] [Python-3000] PyString -> PyBytes C API renaming
Stefan Behnel wrote: M.-A. Lemburg wrote: If you use PyBytes APIs, you expect to find PyBytes functions in the libs and also set breakpoints on these. AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem here. The PyBytes_* functions appear to be there, but a preprocessor macro means it is actually the PyString_* functions that appear in the Python DLL. That's great from a backwards compatibility point of view, but seriously confusing from the point of view of anyone trying to embed or otherwise debug Python 2.6. Besides, how likely is it that users set a breakpoint on the PyBytes/PyString functions? Not very likely at all - but it would still be nice if the PyBytes_* symbols were visible to the linker as well as the preprocessor. 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] A thought on generic functions
Greg Ewing wrote: Paul Moore wrote: I'd rather see a solution which addressed the wider visitor use case (I think I just sprained my back bending over backwards to avoid mentioning generic functions :-)) Speaking of generic functions, while thinking about the recent discussion on proxy objects, it occurred to me that this is something you can do with an OO system that you can't do so easily with a generic function system. If the operations being proxied were generic functions rather than methods, you'd have to override them all individually instead of having a central point to catch them all. I don't think it would actually be that much worse - something like typetools.ProxyMixin would just involve a whole series of register calls instead of method definitions. I wouldn't expect the total amount of code involved to change much. That said, a recursive flatten() implementation is indeed a problem that generic functions are well suited to solving - have the default implementation attempt to iterate over the passed in object yielding its contents, yielding the object itself only if iteration fails, and then, for the types the application wishes to consider atomic, register an alternative implementation that just yields the object without attempting to iterate over it. 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] Py_SETREF/Py_XSETREF (was: Why is type_modified() in typeobject.c not a public function?)
Antoine Pitrou wrote:
> Stefan Behnel behnel.de> writes:
>> BTW, I noticed that the code in typeobject.c uses "DECREF before set" two
>> times, like this:
>>
>> method_cache[h].version = type->tp_version_tag;
>> method_cache[h].value = res; /* borrowed */
>> Py_INCREF(name);
>> Py_DECREF(method_cache[h].name);
>> method_cache[h].name = name;
>
> Since this is so common, would it be useful to define a macro for the correct
> construct?
>
> Something like
>
> #define Py_SETREF(var, obj) \
> { PyObject *tmp = (var); Py_INCREF(obj); \
> (var) = (obj); Py_XDECREF(tmp); }
>
> Or, if we want to allow more optimizations, make two versions of it:
>
> #define Py_SETREF(var, obj) \
> { PyObject *tmp = (var); Py_INCREF(obj); \
> (var) = (obj); Py_DECREF(tmp); }
>
> #define Py_XSETREF(var, obj) \
> { PyObject *tmp = (var); Py_INCREF(obj); \
> (var) = (obj); Py_XDECREF(tmp); }
Both sound like a good idea to me. Having to think about whether or not DECREF
poses a problem in a specific case is just cumbersome.
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] Stabilizing the C API of 2.6 and 3.0
Stefan Behnel schrieb: > Christian Heimes wrote: >> * add a new file stringobject.h which contains the aliases PyString_ -> >> PyBytes_ > > Just a quick note that that file is still missing from SVN, so it's kind of > hard to compile existing code against the current branch state... No, the file is in SVN. It's just not in the py3k branch because it's not vital to the core. I had plans to add a Python 2.x compatibility header to Python 3.0 But I'm not going to spend any more time on the topic or any other development until we have reached an agreement on the naming. I don't want to waste more of my free time in vain. 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] PyString -> PyBytes C API renaming
Stefan Behnel schrieb: > M.-A. Lemburg wrote: >> If you use PyBytes APIs, you expect to find PyBytes functions in >> the libs and also set breakpoints on these. > > AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem > here. In Python 2.6 the PyBytes_* functions are only available to the compiler but not to the linker. In 2.6 the ABI functions are PyString_* and in 3.0 it's PyBytes_* 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] PEP 371 Discussion (pyProcessing Module)
Jesse Noller wrote: > Georg kindly published the PEP I submitted last night to the PEP site: > > http://www.python.org/dev/peps/pep-0371/ > > This PEP includes some of the previous discussion on the processing > module's inclusion, and I hope clears up/clarifies some of the > goals/non goals and issues. I also included benchmark data and a link > to the code used for said benchmarks. > > I would like to renew the discussion now that "there is a PEP" to see > if there are any outstanding things people would like to get resolved. > I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback > both here and elsewhere that people would rather see this in sooner in > some form, rather than later (i.e.: 2.7/3.1). +1 from me (under the 'multiprocessing' name, with the understanding that some code duplication with other parts of the standard library may still remain in 2.6/3.0). From a non-web programmer's point of view, it seems like even more of a gain than standard library support for JSON ;) 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] Stabilizing the C API of 2.6 and 3.0
Christian Heimes wrote: > Stefan Behnel schrieb: >> Christian Heimes wrote: >>> * add a new file stringobject.h which contains the aliases PyString_ -> >>> PyBytes_ >> Just a quick note that that file is still missing from SVN, so it's kind of >> hard to compile existing code against the current branch state... > > No, the file is in SVN. It's just not in the py3k branch because it's > not vital to the core. It might be vital to those who try to test their code with Py3, though... :) > I had plans to add a Python 2.x compatibility header to Python 3.0 But > I'm not going to spend any more time on the topic or any other > development until we have reached an agreement on the naming. I don't > want to waste more of my free time in vain. Sounds to me like people should get back to real work rather than keeping bike-shedding in this thread... 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] [Python-3000] PyString -> PyBytes C API renaming
Nick Coghlan wrote: > Stefan Behnel wrote: >> Besides, how likely is it that users set a breakpoint on the >> PyBytes/PyString functions? > > Not very likely at all - but it would still be nice if the PyBytes_* > symbols were visible to the linker as well as the preprocessor. Right, that's a nice-to-have, an add-on. Why don't we just let Christian finish his work, which is vital for the beta release? Then it's still time to file a bug report on the missing bits and provide a patch that adds linker symbols for PyBytes_*() in Py2.6 as an additional feature. 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] [Python-3000] PyString -> PyBytes C API renaming
Stefan Behnel wrote: Nick Coghlan wrote: Stefan Behnel wrote: Besides, how likely is it that users set a breakpoint on the PyBytes/PyString functions? Not very likely at all - but it would still be nice if the PyBytes_* symbols were visible to the linker as well as the preprocessor. Right, that's a nice-to-have, an add-on. Why don't we just let Christian finish his work, which is vital for the beta release? Then it's still time to file a bug report on the missing bits and provide a patch that adds linker symbols for PyBytes_*() in Py2.6 as an additional feature. Yeah, it took me a while to get my head around what he was trying to do, but GPS explained it pretty well elsewhere in this thread. 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] PEP 371 Discussion (pyProcessing Module)
Nick Coghlan wrote: Jesse Noller wrote: > Georg kindly published the PEP I submitted last night to the PEP site: > > http://www.python.org/dev/peps/pep-0371/ > > This PEP includes some of the previous discussion on the processing > module's inclusion, and I hope clears up/clarifies some of the > goals/non goals and issues. I also included benchmark data and a link > to the code used for said benchmarks. > > I would like to renew the discussion now that "there is a PEP" to see > if there are any outstanding things people would like to get resolved. > I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback > both here and elsewhere that people would rather see this in sooner in > some form, rather than later (i.e.: 2.7/3.1). +1 from me (under the 'multiprocessing' name, with the understanding that some code duplication with other parts of the standard library may still remain in 2.6/3.0). +1 from me as well. I think multiple-processes is over played as a concurrency solution in Python (where you need to marshal lots of data in and out, the overheads of multiple processes can be very expensive) - but it is a very good solution for some problems. Michael Foord From a non-web programmer's point of view, it seems like even more of a gain than standard library support for JSON ;) Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.theotherdelia.co.uk/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
On Thu, May 29, 2008 at 6:22 AM, Michael Foord <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: >> >> Jesse Noller wrote: >> > Georg kindly published the PEP I submitted last night to the PEP site: >> > >> > http://www.python.org/dev/peps/pep-0371/ >> > >> > This PEP includes some of the previous discussion on the processing >> > module's inclusion, and I hope clears up/clarifies some of the >> > goals/non goals and issues. I also included benchmark data and a link >> > to the code used for said benchmarks. >> > >> > I would like to renew the discussion now that "there is a PEP" to see >> > if there are any outstanding things people would like to get resolved. >> > I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback >> > both here and elsewhere that people would rather see this in sooner in >> > some form, rather than later (i.e.: 2.7/3.1). >> >> +1 from me (under the 'multiprocessing' name, with the understanding that >> some code duplication with other parts of the standard library may still >> remain in 2.6/3.0). > > +1 from me as well. > > I think multiple-processes is over played as a concurrency solution in > Python (where you need to marshal lots of data in and out, the overheads of > multiple processes can be very expensive) - but it is a very good solution > for some problems. > > Michael Foord Agreed - this is a "step" rather than the final solution. As I pointed out in the PEP this is a method to side-step GIL limitations rather than to address the larger "GIL issue", I am implicitly assuming that no movement will be made on that front until the bulk of Adam Olsen's safethreading work is rolled into future versions. -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] Finishing up PEP 3108
On Thu, May 29, 2008 at 9:12 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > >> The issues related to PEP 3108 now total 14. With the beta >> (supposedly) in a week, I am hoping the last minor details can be >> pulled together or decisions made on what can be postponed and what >> should definitely be considered a release blocker. >> >> Issue 2847 - the aifc module still imports the cl module in 3.0. >> Problem is that the cl module is gone. =) So it seems silly to have >> the imports lying about. This can probably be changed to critical. >> > > It shouldn't be a problem to rip everything cl-related out of aifc. > The question is how useful aifc will be after that ... > Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ? [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html Quentin ___ 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] optimization required: .format() is much slower than %
Nick> $ ./python -m timeit "'' % ()" Nick> 100 loops, best of 3: 0.389 usec per loop vs. Nick> $ ./python -m timeit "'%s' % 'nothing'" Nick> 1000 loops, best of 3: 0.0736 usec per loop I think you need to use a tuple for the second case to make it comparable to the first. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could you possibly extend the PEP to also document performance when, for instance, passing "big" objects via a queue, or sending "Events" back, testing "thread.isAlive()", and stuff like that?. What about mutexes? (not to protect shared objects, but files, for example). A share-nothing without data-passing doesn't need a new module :). I'm interesting in an almost direct conversion from thread module, and so I'm interested in knowing performance data outside "pyprocessing" sweet point (that is, "fire and forget" code, with little communication). How is implemented "thread.setDaemon()"?. - -- 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 iQCVAwUBSD6x9plgi5GaxT1NAQI4DQP/dJWp2Mfj8e5M1zMM7JNJFFyBMRAxwagd 8EAS1Kbbl4sH8mhaucOwBntj6uXi55HOXo/+bcPD8OuMGq1gouIo7ZJvn3+SNoRM OKsL9Judks8GAZmSF40COAziqQ/Y9M73tOoRBHtqbSTFvexbeKbfY4DvfE+/erss g+oCjUi76FY= =erA0 -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] optimization required: .format() is much slower than %
[EMAIL PROTECTED] wrote: Nick> $ ./python -m timeit "'' % ()" Nick> 100 loops, best of 3: 0.389 usec per loop vs. Nick> $ ./python -m timeit "'%s' % 'nothing'" Nick> 1000 loops, best of 3: 0.0736 usec per loop I think you need to use a tuple for the second case to make it comparable to the first. It doesn't actually make that big a difference - I'm guessing a Py_INCREF shortcut ends up getting used either way: $ ./python -m timeit "'%s' % 'nothing'" 1000 loops, best of 3: 0.0848 usec per loop $ ./python -m timeit "'%s' % 'nothing'," 1000 loops, best of 3: 0.133 usec per loop $ ./python -m timeit "'' % ()" 100 loops, best of 3: 0.513 usec per loop (times are a bit variable at this very moment since I have a few different apps open) 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] PEP 371 Discussion (pyProcessing Module)
On Thu, May 29, 2008 at 9:39 AM, Jesus Cea <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Could you possibly extend the PEP to also document performance when, for > instance, passing "big" objects via a queue, or sending "Events" back, > testing "thread.isAlive()", and stuff like that?. What about mutexes? > (not to protect shared objects, but files, for example). > > A share-nothing without data-passing doesn't need a new module :). I'm > interesting in an almost direct conversion from thread module, and so > I'm interested in knowing performance data outside "pyprocessing" sweet > point (that is, "fire and forget" code, with little communication). > > How is implemented "thread.setDaemon()"?. Alec Thomas sent me a bit of code to benchmark Queue-based object passing performance which I will incorporate when I get a chance. As for the provided examples/benchmarks - I can work on adding more, or if you want - as linked in the PEP, Oudkerk already has some of those outlined in a benchmark script here: http://pyprocessing.berlios.de/examples/benchmarks.py I chose not to recreate his tests directly, rather I chose to link to them. I will work on adding Queue-based numbers. I also wouldn't say I picked the "sweet spot" for the module - rather I picked the poor-spot for the threading module (parallel, python-based crunching). I do again want to point out that the goal is not to pick on threading, but to offer an API which mimics the existing threading API that allows for actual multi-processor/core usage. -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] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-05-28 19:08, Bill Janssen wrote: I'm beginning to wonder whether I'm the only one who cares about the Python 2.x branch not getting cluttered up with artifacts caused by a broken forward merge strategy. I share your concern. Seems to me that perhaps (not sure, but perhaps) the rush to back-port from 3.x, and the concern about minimizing pain of moving from 2.x to 3.x, has become the tail wagging the dog. Indeed. If the need to be able to forward merge changes from the 2.x trunk to the 3.x branch is the only reason for the current approach, then we need to find a better procedure for getting patches to 2.x forwarded to 3.x. I believe that everyone is aware that 3.x breaks things and that's fine. However, the reason for introducing such breakage in 3.x is that users have the option to decide whether and when to switch to the new major version. Being able to play with 3.x features in 2.x is nice, but I wouldn't really consider those essential for 2.x. It certainly doesn't warrant causing major problems in the 2.x releases. The module renaming backport was one example (which was undone again), the C API renaming is another. I expect more such features to be backported from 3.x to 2.x (even though I don't really think it's worth the trouble) and since this always means that changes have to applied in two worlds, we'll need a better process for getting changes in one major release ported to the other. Simply tweaking 2.x into shape so that the rather simple minded SVN merge command works, isn't a good enough procedure for this. That's why I suggested to use an intermediate form or branch for the merging - one that implements the 2.x with all renaming and syntax fixing applied. This would: * reduce the number of merge conflicts since the renaming would already have happened * reduce the patch sizes that have to be applied to 3.x in order to stay in sync with 2.x * result in a tool chain that makes it easier for all Python users to port their code to 3.x * simplify renaming or reorg of modules, functions, methods and C APIs without requiring major changes on either side -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 29 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/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania38 days to go 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] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-05-28 22:47, Gregory P. Smith wrote: On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: I'm beginning to wonder whether I'm the only one who cares about the Python 2.x branch not getting cluttered up with artifacts caused by a broken forward merge strategy. How can it be that we allow major C API changes such as the renaming of the PyString APIs to go into the trunk without discussion or a PEP ? I do not consider it a C API change. The API and ABI have not changed. Old code still compiles. Old binaries still dynamically load and work fine. (I just confirmed this by importing a couple python2.4 .so files into my non-debug build of 2.6 trunk) A of the PyString APIs are the real implementations in 2.x and are still there. We only switched to using their PyBytes equivalent names within the Python trunk code base. Are you objecting to our own code switching to use a different name even though the actual underlying API and ABI haven't changed? I suppose to people reading the code and going against old reference books it could be confusing but they've got to get used to the new names somehow and sometime. I strongly support changes like this one that makes the life of porting C code forwards and backwards between 2.x and 3.x easier without breaking compatibility with earlier 2.x version because that is going to be a serious pain for all of us otherwise. Well, first of all, it is a change in the C API: APIs have different names now, they live in different files, the Python documentation doesn't apply anymore, books have to be updated, programmers trained, etc. etc. That's fine for 3.x, it's not for 2.x. Second, if you leave out the "ease merging" argument, all of this is not really necessary in 2.x. If you absolutely want to have PyBytes APIs in 2.x, then you can *add* them, without removing the PyString APIs. We have done that on a smaller scale a couple of times in the past (turned functions into macros or vice-versa). And finally, the "merge" argument itself is not really all that strong. It's just a matter of getting the procedure corrected. Then you can rename and restructure as much as you want in 3.x - without affecting the stability and matureness of the 2.x branch. I suspect more of these backports to happen, so we better get things done right now instead of putting Python's reputation as stable and mature programming language at risk. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 29 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/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania38 days to go 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] [Python-3000] Finishing up PEP 3108
On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <[EMAIL PROTECTED]> wrote: > > >>Issue 2847 - the aifc module still imports the cl module in 3.0. >>Problem is that the cl module is gone. =) So it seems silly to have >>the imports lying about. This can probably be changed to critical. >> >> >>It shouldn't be a problem to rip everything cl-related out of aifc. >>The question is how useful aifc will be after that ... >> >> >> Has someone already used that module ? I took a look into it, but I'm a >> bit confused about the various compression types, case-sensitivity and >> compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the >> same encoding ? Can we use the audioop module for ALAW, just like it's >> already done for ULAW ? >> > > There is just one alaw I've ever come across (G.711), and the audioop > implementation could be used (audioop's alaw support is younger than the > aifc module, BTW) > > The capitalisation is confusing, but your document [1] says: "Apple > Computer's QuickTime player recognize only the Apple compression types. > Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and > "ulaw" formats and were in use long before Apple introduced the new codes, > QuickTime does not recognize them." > > So this seems just a matter of naming in the AIFC, but not a matter of two > different alaw implementations. > > - Lars > Ok, I'll handle this issue. I'll be using the audioop implementation as a replacement of the SGI compression library. I'll also create a test suite, as Brett mentioned in the bug tracker the module was missing one. Quentin > > [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html > ___ 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] [Python-3000] Stabilizing the C API of 2.6 and 3.0
M.-A. Lemburg schrieb: > Well, first of all, it is a change in the C API: > APIs have different names now, they live in different files, > the Python documentation doesn't apply anymore, books have to > be updated, programmers trained, etc. etc. That's fine for > 3.x, it's not for 2.x. No, that's not correct. The 2.x API is still the same. I've only changed the internal code. > Second, if you leave out the "ease merging" argument, all of > this is not really necessary in 2.x. If you absolutely want > to have PyBytes APIs in 2.x, then you can *add* them, without > removing the PyString APIs. We have done that on a smaller > scale a couple of times in the past (turned functions into > macros or vice-versa). The PyString methods are still available and the official API for dealing with str objects in 2.x. > And finally, the "merge" argument itself is not really all that > strong. It's just a matter of getting the procedure corrected. > Then you can rename and restructure as much as you want in > 3.x - without affecting the stability and matureness of the > 2.x branch. I'm volunteering to revert my chances if you are volunteering to keep the Python 2.x series in sync with the 3.x series. 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] Finishing up PEP 3108
On Thu, May 29, 2008 at 12:12 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: >> >> The issues related to PEP 3108 now total 14. With the beta >> (supposedly) in a week, I am hoping the last minor details can be >> pulled together or decisions made on what can be postponed and what >> should definitely be considered a release blocker. >> >> Issue 2847 - the aifc module still imports the cl module in 3.0. >> Problem is that the cl module is gone. =) So it seems silly to have >> the imports lying about. This can probably be changed to critical. > > It shouldn't be a problem to rip everything cl-related out of aifc. > The question is how useful aifc will be after that ... > If it ends up not being useful then the module can just go. >> Issue 2848 - mimetools has been deprecated for a while, but it is >> still used in a bunch of places. Since this has been deprecated in PEP >> 4 for a long time, should we add the removal warning in 2.6 now and >> then make its actual removal of usage something to do by another beta? >> >> Issue 2849 - rfc822 is the same problem as mimetools. > > The problem is that nobody seems to know what exactly distinguishes > mimetools/rfc822' classes and its successor's (email's) classes, so > it's hard to replace it in the stdlib. > Right. I have looked myself over the years and it never seemed brain-dead simple. >> Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then >> again, pydoc is busted thanks to the new doc format. > > I will try to handle this in the coming week. > Fred had the interesting suggestion of removing pydoc in Py3K based on the thinking that documentation tools like pydoc should be external to Python. With the docs now so easy to generate directly, should pydoc perhaps just be gutted to only what is needed for help() to work? >> Issue 2919 - profile and cProfile needs to be merged. This has not >> been dealt with yet. Would it be reasonable to deprecate importing >> cProfile directly in 2.6 with the assumption the merge will work out >> for 3.0? > > That's not the right way to go, you don't want to deprecate cStringIO > or cPickle either. > Yeah, sorry, you're right. Guess my brain was not fully working when I wrote that. =) >> So that is everything that's left. Issue 2775 is the tracking issue so >> you can look there to see what issues are still open and need work. I >> was hoping to spend Monday and Tuesday trying to tie up as many loose >> ends as possible, but the conference paper I have been working on that >> was due Sunday is now due a week later, and so Monday and Tuesday will >> be spent on that (supervisor's orders). Plus I am flying out Wednesday >> for 10 days to help my mother move and I don't know when I will get >> Net again. In other words, I still need help. =) > > Let's hope we get this right in time. > > Then again, there are lots of other release blockers, so it may well be > that the beta is delayed by some time. Guess it depends on the whim of the release manager. =) -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] [Python-3000] Stabilizing the C API of 2.6 and 3.0
Christian, so far you have not responded to any of the suggestions made on this thread, only defended your checkin. That's not very helpful in getting to some conclusion. * What's so hard about going with a proper, standard solution that doesn't involve using your preprocessor hack ? * Why can't we have both PyString *and* PyBytes exposed in 2.x, with one redirecting to the other ? * Why should the 2.x code base turn to hacks, just because 3.x wants to restructure itself ? * Why aren't you even considering my proposed solution for this whole renaming and reorg problem ? BTW: Is there some PEP or wiki page explaining how you actually implement the merging from 2.x to 3.x ? I'm still under the assumption that you're only using svnmerge.py for this and doing straight merging from the trunk to the branch. Not sure how others feel about it, but if the only option you would feel comfortable with is not having the 3.x renaming backported, then I'd rather go with that, really. It's easy enough to add a header file to map PyString APIs to PyBytes if you want to port an extension to 3.x. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 29 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/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania38 days to go 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 On 2008-05-29 17:45, Christian Heimes wrote: M.-A. Lemburg schrieb: Well, first of all, it is a change in the C API: APIs have different names now, they live in different files, the Python documentation doesn't apply anymore, books have to be updated, programmers trained, etc. etc. That's fine for 3.x, it's not for 2.x. No, that's not correct. The 2.x API is still the same. I've only changed the internal code. Second, if you leave out the "ease merging" argument, all of this is not really necessary in 2.x. If you absolutely want to have PyBytes APIs in 2.x, then you can *add* them, without removing the PyString APIs. We have done that on a smaller scale a couple of times in the past (turned functions into macros or vice-versa). The PyString methods are still available and the official API for dealing with str objects in 2.x. And finally, the "merge" argument itself is not really all that strong. It's just a matter of getting the procedure corrected. Then you can rename and restructure as much as you want in 3.x - without affecting the stability and matureness of the 2.x branch. I'm volunteering to revert my chances if you are volunteering to keep the Python 2.x series in sync with the 3.x series. 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/mal%40egenix.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] optimization required: .format() is much slower than %
Nick Coghlan wrote:
[EMAIL PROTECTED] wrote:
Nick> $ ./python -m timeit "'' % ()"
Nick> 100 loops, best of 3: 0.389 usec per loop
vs.
Nick> $ ./python -m timeit "'%s' % 'nothing'"
Nick> 1000 loops, best of 3: 0.0736 usec per loop
I think you need to use a tuple for the second case to make it
comparable to
the first.
It doesn't actually make that big a difference - I'm guessing a
Py_INCREF shortcut ends up getting used either way:
$ ./python -m timeit "'%s' % 'nothing'"
1000 loops, best of 3: 0.0848 usec per loop
$ ./python -m timeit "'%s' % 'nothing',"
1000 loops, best of 3: 0.133 usec per loop
Technically there you aren't using a tuple to provide the substitution
argument, you are doing the substitution from a single string then
putting the result in a tuple:
>>> '%s' % 'nothing',
('nothing',)
>>>
On the basis of evidence like this:
[EMAIL PROTECTED] ~
$ python -m timeit "'%s' % 'nothing'"
1000 loops, best of 3: 0.0705 usec per loop
[EMAIL PROTECTED] ~
$ python -m timeit "'%s' % ('nothing',)"
100 loops, best of 3: 0.691 usec per loop
I'd say not using a tuple was the way to go if ever you needed to
optimize the code for speed.
$ ./python -m timeit "'' % ()"
100 loops, best of 3: 0.513 usec per loop
If you want an even stranger result, it appears to take the interpreter
longer to substitute nothing from a tuple than it does to substitute the
empty string from a string:
[EMAIL PROTECTED] ~
$ python -m timeit "'' % ()"
100 loops, best of 3: 0.454 usec per loop
[EMAIL PROTECTED] ~
$ python -m timeit "'%s' % ''"
1000 loops, best of 3: 0.0715 usec per loop
(times are a bit variable at this very moment since I have a few
different apps open)
Me too. Timings are not benchmarks, I am not a lawyer, etc. Our machines
seem to be of comparable speed.
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] PEP 371 Discussion (pyProcessing Module)
On Thu, May 29, 2008 at 3:18 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jesse Noller wrote:
>> Georg kindly published the PEP I submitted last night to the PEP site:
>>
>> http://www.python.org/dev/peps/pep-0371/
>>
>> This PEP includes some of the previous discussion on the processing
>> module's inclusion, and I hope clears up/clarifies some of the
>> goals/non goals and issues. I also included benchmark data and a link
>> to the code used for said benchmarks.
>>
>> I would like to renew the discussion now that "there is a PEP" to see
>> if there are any outstanding things people would like to get resolved.
>> I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback
>> both here and elsewhere that people would rather see this in sooner in
>> some form, rather than later (i.e.: 2.7/3.1).
>
> +1 from me (under the 'multiprocessing' name, with the understanding that
> some code duplication with other parts of the standard library may still
> remain in 2.6/3.0).
+1 from me as well, and I support the rename to multiprocessing
("processing" is just too much of a common word).
This will provide a good short-term answer to those who still clamor
for dropping the GIL.
--
--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] PEP 371 Discussion (pyProcessing Module)
I would like to renew the discussion now that "there is a PEP" to see
if there are any outstanding things people would like to get resolved.
I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback
both here and elsewhere that people would rather see this in sooner in
some form, rather than later (i.e.: 2.7/3.1).
+1 from me (under the 'multiprocessing' name, with the understanding that
some code duplication with other parts of the standard library may still
remain in 2.6/3.0).
+1 from me as well, and I support the rename to multiprocessing
("processing" is just too much of a common word).
This will provide a good short-term answer to those who still clamor
for dropping the GIL.
I'm very happy this is going forward. It's a big win.
Raymond
___
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] Finishing up PEP 3108
On Wed, May 28, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Issue 2854 - gestalt needs to be added back into 3.0. This is > Benjamin's issue. =) Is that your way of say "Check in the patch!" ? :) -- 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] Finishing up PEP 3108
On Thu, May 29, 2008 at 1:49 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> Issue 2854 - gestalt needs to be added back into 3.0. This is >> Benjamin's issue. =) > > Is that your way of say "Check in the patch!" ? :) > More or less; specifically, "don't forget to do this." =) -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] Iterable String Redux (aka String ABC)
Mike Klaas wrote: I agree that it would be perverse to disallowing iterating over a string. Just to be clear, I'm saying that it would be perverse to disallow iterating *but* to allow indexing of individual characters. Either you should have both or you should have neither. -- 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] Iterable String Redux (aka String ABC)
Georg Brandl wrote: Greg Ewing schrieb: > Doesn't isinstance(x, basestring) already cover that? That doesn't cover UserString, for example. A better solution to that might be to have UserString inherit from basestring. -- 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] [Python-3000] Stabilizing the C API of 2.6 and 3.0
M.-A. Lemburg wrote: * Why can't we have both PyString *and* PyBytes exposed in 2.x, with one redirecting to the other ? We do have that - the PyString_* names still work perfectly fine in 2.x. They just won't be used in the Python core codebase anymore - everything in the Python core will use either PyBytes_* or PyUnicode_* regardless of which branch (2.x or 3.x) you're working on. I think that's a good thing for ease of maintenance in the future, even if it takes people a while to get their heads around it right now. * Why should the 2.x code base turn to hacks, just because 3.x wants to restructure itself ? With the better explanation from Greg of what the checked in approach achieves (i.e. preserving exact ABI compatibility for PyString_*, while allowing PyBytes_* to be used at the source code level), I don't see what has been done as being any more of a hack than the possibly more common "#define " (which *would* break binary compatibility). The only things that I think would tidy it up further would be to: - include an explanation of the approach and its effects on API and ABI backward and forward compatibility within 2.x and between 2.x and 3.x in stringobject.h - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0 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] A thought on generic functions
Nick Coghlan wrote: I don't think it would actually be that much worse - something like typetools.ProxyMixin would just involve a whole series of register calls instead of method definitions. I wouldn't expect the total amount of code involved to change much. I'm not thinking about the __xxx__ methods, they're an aberration. I'm thinking about all the user-defined methods and attributes that get caught in one go by the __getattr__ method of the proxy. That said, a recursive flatten() implementation is indeed a problem that generic functions are well suited to solving Yes, I agree with that. It was just something I thought of that shows that generic functions and OO are not quite equivalent in general. -- 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] A thought on generic functions
Greg Ewing wrote: Nick Coghlan wrote: I don't think it would actually be that much worse - something like typetools.ProxyMixin would just involve a whole series of register calls instead of method definitions. I wouldn't expect the total amount of code involved to change much. I'm not thinking about the __xxx__ methods, they're an aberration. I'm thinking about all the user-defined methods and attributes that get caught in one go by the __getattr__ method of the proxy. Ah, I see what you mean. That's where the generic system itself needs to be based on generic functions - then you can hook the lookup function so that proxies get looked up based on their target type rather than the fact they're a proxy. It all gets very brain bending and self referential, which is when folks tend to throw generics in the 'too complicated' basket ;) 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] A thought on generic functions
Nick Coghlan wrote: That's where the generic system itself needs to be based on generic functions - then you can hook the lookup function so that proxies get looked up based on their target type rather than the fact they're a proxy. It all gets very brain bending and self referential, which is when folks tend to throw generics in the 'too complicated' basket ;) Yep. :-) Also, when hooking into things at such a deep level, I'd be a bit worried that I was catching too *much*, or that I was imposing performance penalties on unrelated things. At least with __getattr__ you know what you're doing can *only* affect the proxy object and nothing else. -- 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] [Python-3000] Finishing up PEP 3108
On 29/05/2008, at 14:32, Brett Cannon wrote: On Thu, May 29, 2008 at 12:12 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: Issue 2848 - mimetools has been deprecated for a while, but it is still used in a bunch of places. Since this has been deprecated in PEP 4 for a long time, should we add the removal warning in 2.6 now and then make its actual removal of usage something to do by another beta? Issue 2849 - rfc822 is the same problem as mimetools. The problem is that nobody seems to know what exactly distinguishes mimetools/rfc822' classes and its successor's (email's) classes, so it's hard to replace it in the stdlib. Right. I have looked myself over the years and it never seemed brain-dead simple. Well, as documented in issue 2849, rfc822 is almost gone. I've already removed it from mailbox and test_urllib2 modules. It seems that there remains only one important use of it, which is in cgi.FieldStorage.read_multi(). I couldn't figure out how to replace it there, though, as read_multi's current implementation relies on the fact that rfc822.Message(fp) advances the file pointer just by the amount it needs, while email.parser.Parser.parse() reads the whole file. I believe that read_multi can be rewritten in a way that's compatible with email.parser, but I don't know how to do that... :\ -- Humberto Diógenes http://humberto.digi.com.br ___ 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] http://bugs.python.org/issue708007 - telnetpopen
my apologies, i found the issue "closed" after doing a search for my own work, requiring (again) the telnetlib code for yet another project. since 2001, the work done has been reimplemented time and time again, by different individuals, in different projects, in different ways, all solving exactly the same issues, providing exactly the same type of functionality, as that provided by TelnetPopen3. e.g. Pexpect is the one i found today, listed off of http://en.wikipedia.org/wiki/Expect l. ___ 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 Tue, May 13, 2008 at 09:23:02PM -0400, Tom Pinckney wrote: -> Why not use MPI? It's cross platform, cross language and very widely -> supported already. And there're Python bindings already. MPI requires far more setup than the pyprocessing module does; it's by no means plug & play. --titus -- C. Titus Brown, [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] BSDDB3
Thanks Jesus. I'll import BSDDB 4.6.4 into svn.python.org/projects/external today. Once that's done, I'll create a new bsddb46.vcproj and update the pcbuild.sln to use this project instead of the bsddb44 one currently being used. (Hopefully I'll be able to get that done today as well.) I assume you're just working on trunk at the moment? i.e. should I block or merge the changes to py3k? For everyone else: just a heads up that there will probably be a little bit of buildbot instability whilst we transition BSDDB versions on Windows. Trent. -Original Message- From: Jesus Cea [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 12:50 AM To: Trent Nelson Cc: python-dev@python.org Subject: 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] PEP 370 extras
> Christian, you get this week's Awesome Award. Hah, 'Weekly Awesome Award', we should make that one of our things, like QOTW. 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] Committing bsddb 4.6.4, and where can I put testsuite temp files?
Hi Jesus,
Regarding where to place test files, you might want to look at how the current
bsddb test suite in Lib/bsddb/test handles the need to create temporary files
and such. A bit of work has gone into this particular aspect to improve
reliability and robustness on buildbots -- particularily when it comes to
Windows. (I believe the current test suite comes up with a unique directory
based on process ID..)
Trent.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesus Cea
Sent: Tuesday, May 13, 2008 8:10 PM
To: Python DEV
Subject: [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/tnelson%40onresolve.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
[Python-Dev] Importing bsddb 4.6.21; with or without AES encryption?
I was about to commit an initial import of the bsddb 4.6.21 source to the 'external' area in the repo, which I obtained from the following URL: http://www.oracle.com/technology/software/products/berkeley-db/index.html 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? (Note that all of this only applies to Windows.) 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
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (05/09/08 - 05/16/08)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1874 open (+61) / 12843 closed (+30) / 14717 total (+91)
Open issues with patches: 558
Average duration of open issues: 704 days.
Median duration of open issues: 1397 days.
Open Issues Breakdown
open 1852 (+61)
pending22 ( +0)
Issues Created Or Reopened (92)
___
Exception state lives too long in 3.005/13/08
http://bugs.python.org/issue2507reopened collinwinter
patch
Integer right shift raises OverflowError when second operand is 05/09/08
CLOSED http://bugs.python.org/issue2804created marketdickinson
patch
2to3 doesn't correct divisions 05/09/08
http://bugs.python.org/issue2805created gpolo
Py30a5: Tk Menu Alt-f behaves differently Linux vs Windows 05/09/08
http://bugs.python.org/issue2806created mark
Remove the API PyUnicode_AsString() 05/09/08
CLOSED http://bugs.python.org/issue2807created alexandre.vassalotti
asynchat forgets packets when push is called from a thread 05/10/08
http://bugs.python.org/issue2808created xix xeaon
string docstring doesn't mention that ' '.split() != ' '.split(' 05/10/08
CLOSED http://bugs.python.org/issue2809created Neil Muller
patch
_winreg.EnumValue fails when the registry data includes multibyt 05/10/08
http://bugs.python.org/issue2810created stutzbach
doctest doesn't treat unicode literals as specified by the file 05/10/08
http://bugs.python.org/issue2811created neves
Document property.getter/setter/deleter etc 05/10/08
CLOSED http://bugs.python.org/issue2812created benjamin.peterson
patch
No float formatting in PyString_FromFormat 05/10/08
http://bugs.python.org/issue2813created duaneb
Remove old classes from mailbox module 05/11/08
CLOSED http://bugs.python.org/issue2814created hdiogenes
patch
Python Manuals: horizontal scrolling broken 05/11/08
CLOSED http://bugs.python.org/issue2815created tjreedy
Quote-type recognition bug 05/11/08
CLOSED http://bugs.python.org/issue2816created chester
Make Python create a tuple with one element in a clean way 05/11/08
CLOSED http://bugs.python.org/issue2817created chester
pulldom cannot handle xml file with large external entity proper 05/11/08
http://bugs.python.org/issue2818created hanselda
Full precision summation 05/11/08
http://bugs.python.org/issue2819created MrJean1
patch
Remove mac modules 05/11/08
CLOSED http://bugs.python.org/issue2820created benjamin.peterson
unittest.py sys.exit error 05/11/08
http://bugs.python.org/issue2821created acgetchell
Quote-type recognition bug [badly fixed last time]
Re: [Python-Dev] optimization required: .format() is much slower than %
On Tue, May 27, 2008 at 12:43 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Ten minutes ago I raised a concern about speed differences between the
> old style % formatting and the new .format() code. Some quick
> benchmarking from Benjamin and me showed, that it's even worse than I
> expected.
My own tests show a less dire difference:
$ ./python -m timeit "'some text with %s'.format('nothing')"
100 loops, best of 3: 0.578 usec per loop
$ ./python -m timeit "'some text with %s' % 'nothing'"
100 loops, best of 3: 0.472 usec per loop
> $ ./python -m timeit "'%s'.format('nothing')"
> 10 loops, best of 3: 2.63 usec per loop
> $ ./python -m timeit "'%s' % 'nothing'"
> 1000 loops, best of 3: 0.188 usec per loop
It struct me as odd that this one case shows such a big difference
while the others show less of one.
My tests show that the old-style % formatting is much faster when the
final string is 20 characters or less:
$ ./python -m timeit "'|||...%s' % '12'"
1000 loops, best of 3: 0.0764 usec per loop
$ ./python -m timeit "'|||...%s' % '123'"
100 loops, best of 3: 0.481 usec per loop
A read through stringobject.c didn't give me any clue as to why 20 is
the magic number. %d shows an even bigger jump:
$ ./python -m timeit "'|||...%d' % 12"
1000 loops, best of 3: 0.0764 usec per loop
$ ./python -m timeit "'|||...%d' % 123"
100 loops, best of 3: 1.28 usec per loop
Schiavo
Simon
___
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] Obtaining short file path
Hi,
Purpose: obtaining the system ("short") path from a full path
Background: File dialogs (visual studio) return a full path (e.g.
f="C:\this path has spaces\thisfilenameislongerthan8char.txt"). If this
value is provided to Python, it will not recongize this as a file. In
fact os.path.isfile(f) doesn't return false, it crashes. Likewise, when
calling executables (from Python) with files as arguments a short path
is required. VB FileSystemObject has the ShortPath method, while os.path
and path (www.jorendorff.com) modules do not (at least as far as my
googling could determine). Why bother creating a COM interface when
you're just going to pass as shell run-time arguments all the values the
server is better at computing?
System: Python 2.3; Windows XP
Sample Code:
import win32com.client
import time
import os,sys
import os.path
#-
def shortpath(x):
z=''
for y in x.split('\\'):
if len(y.split('.')[0])>8:
if ('.' in y):
z=z+'\\'+y.split('.')[0][:6].upper()+'~1'+'.'+y.split('.')[1]
else:
z=z+'\\'+y[:6].upper()+'~1'
else:
z=z+'\\'+y
return z[1:]
#-
xlApp = win32com.client.Dispatch("Excel.Application")
xlBook = xlApp.ActiveWorkbook
savFile = str(sys.argv[1])
rawFile = str(xlBook.Sheets("Timestamp").TextBox2)
#print os.path.isfile(savFile)
r=shortpath(rawFile)
print r
try:
print os.path.isfile(r)
except:
print 'something rude'
time.sleep(7)
Notes: This code does not account for peer paths or files that share the
first 8 characters (and file extension). I'm also aware that this is not
the normal means for submitting a "patch", but in my job function I
don't see myself regularly participating in python development (and I'm
probably not savvy enough) so the effort wasn't worth it. However I
still thought others might benefit from what seems to be (to me) a
fundamental path function. Do with it, or ignore it, as you please.
Cheers,
Bryan Hartwell
This message is intended only for the use of the intended recipients, and it
may be privileged and confidential. If you are not the intended recipient, you
are hereby notified that any review, retransmission, conversion to hard copy,
copying, circulation or other use of this message is strictly prohibited. If
you are not the intended recipient, please notify me immediately by return
e-mail, and delete this message from your system.
___
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] [Python-3000] PyString -> PyBytes C API renaming
2008/5/29 Nick Coghlan <[EMAIL PROTECTED]>: > it would still be nice if the PyBytes_* symbols > were visible to the linker as well as the preprocessor. If this is not a strict requirement but a useful extra, then it might be done in an unportable way. GCC has an 'alias' attribute: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html -- Marcin Kowalczyk [EMAIL PROTECTED] http://qrnik.knm.org.pl/~qrczak/ ___ 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] [Python-3000] Finishing up PEP 3108
Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical. It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ... Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ? There is just one alaw I've ever come across (G.711), and the audioop implementation could be used (audioop's alaw support is younger than the aifc module, BTW) The capitalisation is confusing, but your document [1] says: "Apple Computer's QuickTime player recognize only the Apple compression types. Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and "ulaw" formats and were in use long before Apple introduced the new codes, QuickTime does not recognize them." So this seems just a matter of naming in the AIFC, but not a matter of two different alaw implementations. - Lars [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html ___ 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] FWD: 26 Python-Dev moderator request(s) waiting
I just processed two weeks of backlog on python-dev (I'm only a backup moderator). Would anyone object to changing the list policy so that non-member posts get discarded instead of held? -- 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] http://bugs.python.org/issue708007 - telnetpopen
On Tue, May 13, 2008 at 1:06 PM, Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote: > my apologies, i found the issue "closed" after doing a search for my > own work, requiring (again) the telnetlib code for yet another > project. I have reopened it for you. > > since 2001, the work done has been reimplemented time and time again, > by different individuals, in different projects, in different ways, > all solving exactly the same issues, providing exactly the same type > of functionality, as that provided by TelnetPopen3. e.g. Pexpect is > the one i found today, listed off of > http://en.wikipedia.org/wiki/Expect > > l. > ___ > 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/musiccomposition%40gmail.com > -- 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] FWD: 26 Python-Dev moderator request(s) waiting
On Thu, May 29, 2008 at 8:14 PM, Aahz <[EMAIL PROTECTED]> wrote: > I just processed two weeks of backlog on python-dev (I'm only a backup > moderator). Would anyone object to changing the list policy so that > non-member posts get discarded instead of held? Is any of the mail spam? -- 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] FWD: 26 Python-Dev moderator request(s) waiting
On Thu, May 29, 2008, Benjamin Peterson wrote: > On Thu, May 29, 2008 at 8:14 PM, Aahz <[EMAIL PROTECTED]> wrote: >> >> I just processed two weeks of backlog on python-dev (I'm only a backup >> moderator). Would anyone object to changing the list policy so that >> non-member posts get discarded instead of held? > > Is any of the mail spam? Very yes -- more than half. (What gets through SpamBayes) -- 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] FWD: 26 Python-Dev moderator request(s) waiting
On Thu, May 29, 2008 at 8:28 PM, Aahz <[EMAIL PROTECTED]> wrote: > On Thu, May 29, 2008, Benjamin Peterson wrote: >> >> Is any of the mail spam? > > Very yes -- more than half. (What gets through SpamBayes) In that case, I'm -1. -- 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] Obtaining short file path
On Tue, May 27, 2008 at 6:00 AM, Hartwell Bryan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Purpose: obtaining the system ("short") path from a full path
>
Best thing to do is to open an issue with the patch, otherwise this
will just be ignored as we don't accept code to this mailing list.
-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] FWD: 26 Python-Dev moderator request(s) waiting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 29, 2008, at 9:14 PM, Aahz wrote: I just processed two weeks of backlog on python-dev (I'm only a backup moderator). Would anyone object to changing the list policy so that non-member posts get discarded instead of held? How about we recruit additional moderators? Any volunteers? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSD9fl3EjvBPtnXfVAQK+cQP/Xwx5+k9gzBcDLG4QQGvAdMSXTfXjayxL OxDnWWzDNm+CfzDoY76GHhTPk/Jc3Rx80aTxBmv2DyElq+Z5r0TrqbYp25EFV4Ia J0P4q2WGkBq71LFYuTrmcYp7Z2oF47M/vm3F1zpErgXK+zEiOfKlQO9V1FMKNnRu sG4vOFq+tbU= =gWHk -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] FWD: 26 Python-Dev moderator request(s) waiting
"Barry Warsaw" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On May 29, 2008, at 9:14 PM, Aahz wrote: > >> I just processed two weeks of backlog on python-dev (I'm only a backup >> moderator). Would anyone object to changing the list policy so that >> non-member posts get discarded instead of held? By 'non-member' I hope you mean 'never approved before' as opposed to 'non-subscriber' like me who participates through gmane. > > How about we recruit additional moderators? Any volunteers? Yes ___ 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] FWD: 26 Python-Dev moderator request(s) waiting
[Barry] > ... > How about we recruit additional moderators? Any volunteers? Sure -- add me as a python-dev admin, send me the password, and go back to eating in peace :-) ___ 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] FWD: 26 Python-Dev moderator request(s) waiting
On Thu, May 29, 2008, tjreedy wrote: >> On May 29, 2008, at 9:14 PM, Aahz wrote: >>> >>> I just processed two weeks of backlog on python-dev (I'm only a backup >>> moderator). Would anyone object to changing the list policy so that >>> non-member posts get discarded instead of held? > > By 'non-member' I hope you mean 'never approved before' as opposed to > 'non-subscriber' like me who participates through gmane. This seems to be a settled issue now, but IMO the proper way to handle your situation is to subscribe from the e-mail address you use as your From: line, setting the subscription to "no mail". -- 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] PEP 371 Discussion (pyProcessing Module)
On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: > I would like to renew the discussion now that "there is a PEP" to see > if there are any outstanding things people would like to get resolved. > I chose to continue to push it for 2.6 / 3.0 inclusion due to feedback > both here and elsewhere that people would rather see this in sooner in > some form, rather than later (i.e.: 2.7/3.1). I'm not sure if this is a big issue, but I just tested the module with an application that embeds Python and it doesn't work properly. Instead of spawning worker threads using python.exe, it attempts to use the application. Does the processing module allow specifying the exe to use for spawning worker threads? I would definitely like to see this included in the next release, and having support for embedded Python interpreters would be a big plus. -Farshid ___ 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] Iterable String Redux (aka String ABC)
Greg Ewing schrieb: Georg Brandl wrote: Greg Ewing schrieb: > Doesn't isinstance(x, basestring) already cover that? That doesn't cover UserString, for example. A better solution to that might be to have UserString inherit from basestring. But with that argument you could throw out the whole ABC machinery, just let all lists inherit from list, all dicts from dict, etc. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
