Re: [Python-Dev] Behaviour of max() and min() with equal keys
On Sep 7, 2010, at 12:34 PM, Matthew Woodcraft wrote: > In CPython, the builtin max() and min() have the property that if there > are items with equal keys, the first item is returned. From a quick look > at their source, I think this is true for Jython and IronPython too. > > However, this isn't currently a documented guarantee. Could it be made > so? (As with the decision to declare sort() stable, it seems likely that > by now there's code out there relying on it anyway.) That seems like a reasonable request. This behavior has been around for a very long time is unlikely to change. Elsewhere, we've made efforts to document sort stability (i.e. sorted(), heapq.nlargest(), heapq.nsmallest, merge(), etc). It is nice that min(it) parallels sorted(it)[0] and nsmallest(1, it). The same goes for max(it) paralleling sorted(it,reverse=True)[0] and nlargest(1, it). Raymond ___ Python-Dev mailing list [email protected] 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 3149 thoughts
Barry Warsaw writes: > > Section added: > > Windows > === > > This PEP only addresses build issues on POSIX systems that use the > ``configure`` script. While Windows or other platform support is not > explicitly disallowed under this PEP, platform expertise is needed in > order to evaluate, describe, and implement support on such platforms. > It is not currently clear that the facilities in this PEP are even > useful for Windows. > If it's useful on unix like systems, why shouldn't it be useful on windows? Multiple versions of python can be installed on windows too. And people might also like to share their packages between installations. - Ralf ___ Python-Dev mailing list [email protected] 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 384 status
On Wed, Sep 8, 2010 at 8:34 AM, David Cournapeau wrote: > I would turn the question around: what are the cases where you manage > to mix CRT and not getting any issues ? This has never worked in my > own experience in the context of python extensions, I've done it quite a bit over the years with SWIG-wrapped libraries where all I did was recompile my extension for new versions of Python. It works fine, so long as you avoid the very APIs that PEP 384 is blocking from the stable ABI. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 3149 thoughts
On Wed, Sep 8, 2010 at 5:42 PM, Ralf Schmitt wrote: > Barry Warsaw writes: > >> >> Section added: >> >> Windows >> === >> >> This PEP only addresses build issues on POSIX systems that use the >> ``configure`` script. While Windows or other platform support is not >> explicitly disallowed under this PEP, platform expertise is needed in >> order to evaluate, describe, and implement support on such platforms. >> It is not currently clear that the facilities in this PEP are even >> useful for Windows. >> > > If it's useful on unix like systems, why shouldn't it be useful on > windows? Multiple versions of python can be installed on windows > too. And people might also like to share their packages between > installations. Platform mindset. Windows has a history of duplication of files to avoid dependency management (even the C runtime is typically duplicated on disk for each application that uses it). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 384 status
On Wed, Sep 8, 2010 at 5:19 PM, Nick Coghlan wrote: > On Wed, Sep 8, 2010 at 8:34 AM, David Cournapeau wrote: >> I would turn the question around: what are the cases where you manage >> to mix CRT and not getting any issues ? This has never worked in my >> own experience in the context of python extensions, > > I've done it quite a bit over the years with SWIG-wrapped libraries > where all I did was recompile my extension for new versions of Python. > It works fine, so long as you avoid the very APIs that PEP 384 is > blocking from the stable ABI. What do you mean by recompiling ? Using Mingw ? Normally, if you just recompile your extensions without using special distutils options, you use the same compiler as the one used by python, which generally avoids mixing runtimes. In other words, the problem mainly arises when you need to integrate libraries which you can not recompile with the compiler used by python, because the code is not visual-studio compatible, or because the library is only available in binary form. cheers, David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
On 09/07/2010 11:40 PM, Jeffrey Yasskin wrote: Decimal may actually have this backwards. The idea would be that min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Here you mean "is" rather than "==", right? The relations you spelled are guaranteed regardless of stability. (This doesn't apply to Decimal.max and Decimal.min, which return new objects.) ___ Python-Dev mailing list [email protected] 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 384 status
On Wed, Sep 8, 2010 at 6:34 PM, David Cournapeau wrote: > In other words, the problem mainly arises when you need to integrate > libraries which you can not recompile with the compiler used by > python, because the code is not visual-studio compatible, or because > the library is only available in binary form. In my case, I was building on an old dev system which only has VC6, but needed to link against Python 2.4 (which was compiled with MSVC 2005). The build process didn't use distutils, so that didn't affect anything. It works, you just have to know what APIs you have to avoid. The C runtime independence aspects of PEP 384 are just about enlisting the compiler in the task of making sure you *have* avoided all those APIs. The rest of the PEP is about hiding the details of some of Python's own data structures to allow them to change without affecting the stable ABI. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 384 status
On Wed, Sep 8, 2010 at 7:59 PM, Nick Coghlan wrote: > On Wed, Sep 8, 2010 at 6:34 PM, David Cournapeau wrote: >> In other words, the problem mainly arises when you need to integrate >> libraries which you can not recompile with the compiler used by >> python, because the code is not visual-studio compatible, or because >> the library is only available in binary form. > > In my case, I was building on an old dev system which only has VC6, > but needed to link against Python 2.4 (which was compiled with MSVC > 2005). The build process didn't use distutils, so that didn't affect > anything. ok, I was confused by "I just recompiled". > > It works, you just have to know what APIs you have to avoid. The critical point is that you cannot always do that. Retaking my example of mkstemp: I have a C library which has a fdopen-like function (built with one C runtime, not the same as python), there is no way that I know of to use this API with a file descriptor obtained from tempfile.mkstemp function. The only solution is to build my own C extension with C mkstemp, built with the same runtime as my library, and make that available to python. cheers, David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Working on the Python code-base with a VIM-based setup
Another shameless plug: My pyflakes.vim plugin will highlight errors as you type: http://www.vim.org/scripts/script.php?script_id=2441 It's really helpful for catching those typos that you usually don't notice until the runtime NameError. Eli Bendersky wrote: Hello pydev, This is a meta-question which I hope is appropriate in this list (**). Recently I've switched to to VIM as my main development platform (in terms of code editing and navigation). Working on the Python code-base is both a concrete requirement and a yardstick for me - I want to be as effective as possible at it. Therefore I would like to ask those of you working on Python's code with VIM about your setups - the special tweaks to VIM & plugins you use to make working with the code as simple and effective as possible. Myself, since I'm still a VIM newbie, my setup is quite spartan. I created tags with: ctags -R Grammar Include Modules/ Objects/ Parser/ Python/ And now happily browse around the source code with Ctrl-], Ctrl-I/O, Ctrl-T and so on. I've also installed the Taglist plugin to show all functions/macros in open buffers - it's sometimes helpful. Other plugins I've found useful ar NERD-commenter (for commenting out chunks of code) and highlight_current_line (for a visual cue of where I am in a file). Besides, I've taken the suggested settings from the .vimrc file in Misc/ to help enforcing PEP-8. I heard that there are more sophisticated tags plugins that also allow one to check where a function is called for, and other intellisens-y stuff, though I'm not sure whether anyone uses it for Python's code. Thanks in advance, Eli (**) Note that it deals with the source code *of Python* (the stuff you download from Python's official SVN), not Python source code. ___ Python-Dev mailing list [email protected] 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 3149 thoughts
On Sep 08, 2010, at 09:42 AM, Ralf Schmitt wrote: >If it's useful on unix like systems, why shouldn't it be useful on >windows? Multiple versions of python can be installed on windows >too. And people might also like to share their packages between >installations. I guess the point is *I* don't know! I'm not a Windows developer, and I'm still unable to even build Python on Windows 7 with VS2010. In the absence of a Windows developer explicitly saying that it's useful, and offering to help implement it, then we'll just leave it for configure-based builds. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Behaviour of max() and min() with equal keys
Raymond Hettinger wrote: >Matthew Woodcraft wrote: >> In CPython, the builtin max() and min() have the property that if there >> are items with equal keys, the first item is returned. From a quick look >> at their source, I think this is true for Jython and IronPython too. >> However, this isn't currently a documented guarantee. Could it be made >> so? (As with the decision to declare sort() stable, it seems likely that >> by now there's code out there relying on it anyway.) > That seems like a reasonable request. This behavior has been around > for a very long time is unlikely to change. Elsewhere, we've made > efforts to document sort stability (i.e. sorted(), heapq.nlargest(), > heapq.nsmallest, merge(), etc). I've submitted issue 9802 as a feature request with a concrete suggestion for the docs. -M- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cProfile and threads
Hello, Ive just stumbled accross your changes Krisvale, and from your last reply, I can see that you invalidated your changes : I just realized that this is probably a redundant change. > We have C apis to get all the Thread states in an interpreter state (I didn't > even know there was such a thing as multiple interpreter states, but there!) > This is the PyInterpreterState_ThreadHead() api et al. > From C, all that is missing is a SetTrace api that takes a thread state. > > From python, the threading module provides access to all Thread objects, and > each of those has a settrace/setprofile method. > > To turn on global tracing from cProfile, all that is needed is to iterate > over all the Thread objects. > > Setting this to invalid, since there already are APIs to do this, at least > from .py code. > > Could you please provide more explanations, or even an example ? Because it seems that you're the only one on earth to finally find a way to multithread the cProfiler... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cProfile and threads
Hello, Ive just stumbled accross your changes Krisvale, and from your last reply, I can see that you invalidated your changes : I just realized that this is probably a redundant change. > We have C apis to get all the Thread states in an interpreter state (I didn't > even know there was such a thing as multiple interpreter states, but there!) > This is the PyInterpreterState_ThreadHead() api et al. > From C, all that is missing is a SetTrace api that takes a thread state. > > From python, the threading module provides access to all Thread objects, and > each of those has a settrace/setprofile method. > > To turn on global tracing from cProfile, all that is needed is to iterate > over all the Thread objects. > > Setting this to invalid, since there already are APIs to do this, at least > from .py code. > > Could you please provide more explanations, or even an example ? Because it seems that you're the only one on earth to finally find a way to multithread the cProfiler... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cProfile and threads
Ok, I've been busy with other stuff, but I'm almost finished with a patch to submit as an alternative. cProfile.enable() will then take an "allthreads" argument, which when enabled, will set the profiler state on all threads _currently_ running. Now, I only realized this late, but _currently_ is really not good enough. In order to do this properly, you want to also profile threads that are created during the session. For this reason, Maybe I was a bit rash invalidating this. Anyway, keep your eyes trained on issue 9609 where I'll hopefully put my patch in real soon now. K From: [email protected] [mailto:[email protected]] On Behalf Of GrosBedo Sent: Thursday, September 09, 2010 5:10 To: [email protected] Subject: Re: [Python-Dev] cProfile and threads Hello, Ive just stumbled accross your changes Krisvale, and from your last reply, I can see that you invalidated your changes : I just realized that this is probably a redundant change. We have C apis to get all the Thread states in an interpreter state (I didn't even know there was such a thing as multiple interpreter states, but there!) This is the PyInterpreterState_ThreadHead() api et al. >From C, all that is missing is a SetTrace api that takes a thread state. >From python, the threading module provides access to all Thread objects, and >each of those has a settrace/setprofile method. To turn on global tracing from cProfile, all that is needed is to iterate over all the Thread objects. Setting this to invalid, since there already are APIs to do this, at least from .py code. Could you please provide more explanations, or even an example ? Because it seems that you're the only one on earth to finally find a way to multithread the cProfiler... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
