Re: [Python-Dev] mkdir -p in python
On 07/27/2010 06:18 PM, Alexander Belopolsky wrote: On Tue, Jul 20, 2010 at 10:20 AM, R. David Murray wrote: I'd go with putting it in shutil. +1 I would also call it shutil.mktree which will go well with shutil.rmtree next to it. Note that mktree is not analogous to rmtree - while rmtree removes a directory tree beneath a specified directory, mktree would only create a single "branch", not an entire tree. I'd imagine a mktree function to accept a data structure describing the tree to be created. If you're going for a short name distinctive from mkdir, I propose mksubdirs. ___ 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] mkdir -p in python
Hrvoje Niksic writes: > single "branch", not an entire tree. I'd imagine a mktree function to > accept a data structure describing the tree to be created. -1 on mktree for that reason. > If you're going for a short name distinctive from mkdir, I propose > mksubdirs. A little more accurate might be mkpath, but I'd be happy with either. And of course in Unix jargon "path" is ambiguous. ___ 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] [isssue 2001] Pydoc enhancement patch questions
On Tue, Jul 27, 2010 at 1:25 AM, Ron Adam wrote: >>> Another way to communicate to the server would be to add a link in >>> the browser to open a server status page. For example my router has a >>> configure page where I can check it's status and do other things. >>> That might be something worth exploring at some later date. >> >> This would work as well, but for starters, I think "Search" and "Quit" >> buttons next to each other will be most familiar to the users of the >> current Tk-based control window. > > Nick, what do you think about the "Quit" link in the browser along with > improving the server startup message on the console window? My main concern was having a clear way to shut down the server - I think your command line changes address that quite nicely. Probably best to keep the quit command separate from the help browser though - it would be annoying to accidentally shutdown your help server when you were just trying to browse it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] mkdir -p in python
Hrvoje Niksic wrote: mktree would only create a single "branch", not an entire tree. Maybe mkbranch, then? -- 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] mkdir -p in python
On 28/07/2010 11:53, Greg Ewing wrote: Hrvoje Niksic wrote: mktree would only create a single "branch", not an entire tree. Maybe mkbranch, then? Seeing as we already have a decision to add this functionality to os.makedirs as a switch and not to create a new function, this bikeshedding seems particularly pointless. http://mail.python.org/pipermail/python-dev/2010-July/102132.html All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] GIL musings (was Re: Thoughts fresh after EuroPython)
On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren wrote: > In my opinion the GIL is a weak point of CPython and it would be nice if it > could be fixed. That is however easier said than done, a number of people > have tried in the past and ran into implementation limitations like our > refcounting garbage collector that make hard to remove the GIL without > either rewriting lots of code, or running into a brick wall > performance-wise. > > The HotPy presentation at EuroPython shows that it is possible to remove the > GIL, although at the cost of replacing the garbage collector and most likely > breaking existing C extensions (although the HotPy author seemed to have a > possible workaround for that). This is the kind of approach that seems to hold the most promise of removing the GIL without incurring the single-threaded performance hit that has been the achilles heel of previous attempts at creating a free-threaded CPython implementation. With first IronClad and now PyPy blazing the trail in interfacing a garbage collected Python implementation with deterministic refcounting for C extension modules, it seems plausible that this kind of approach may eventually prove acceptable. Furthermore, the with statement now provides a superior alternative to application level tricks that previously relied on deterministic refcounting. While multi-threading does break down beyond a certain number of cores, it *is* possible to do safely (particularly using queues to pass references around) and can avoid plenty of serialisation overhead when dealing with sizable data structures. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] GIL musings (was Re: Thoughts fresh after EuroPython)
On 28/07/2010 11:50, Nick Coghlan wrote: On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren wrote: In my opinion the GIL is a weak point of CPython and it would be nice if it could be fixed. That is however easier said than done, a number of people have tried in the past and ran into implementation limitations like our refcounting garbage collector that make hard to remove the GIL without either rewriting lots of code, or running into a brick wall performance-wise. The HotPy presentation at EuroPython shows that it is possible to remove the GIL, although at the cost of replacing the garbage collector and most likely breaking existing C extensions (although the HotPy author seemed to have a possible workaround for that). This is the kind of approach that seems to hold the most promise of removing the GIL without incurring the single-threaded performance hit that has been the achilles heel of previous attempts at creating a free-threaded CPython implementation. With first IronClad and now PyPy blazing the trail in interfacing a garbage collected Python implementation with deterministic refcounting for C extension modules, it seems plausible that this kind of approach may eventually prove acceptable. Furthermore, the with statement now provides a superior alternative to application level tricks that previously relied on deterministic refcounting. While multi-threading does break down beyond a certain number of cores, it *is* possible to do safely (particularly using queues to pass references around) and can avoid plenty of serialisation overhead when dealing with sizable data structures. Breaking binary compatibility with C extensions would be "difficult" once PEP 384 (stable binary ABI) has gone into effect. As you intimate, Ironclad demonstrates that C extensions *can* be interfaced with a different garbage collection system whilst maintaining binary compatibility. It does impose constraints however (which is why the PyPy c-ext implementors chose source compatibility rather than binary compatibility). Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] GIL musings (was Re: Thoughts fresh after EuroPython)
On Wed, 28 Jul 2010 11:56:16 +0100 Michael Foord wrote: > > This is the kind of approach that seems to hold the most promise of > > removing the GIL without incurring the single-threaded performance hit > > that has been the achilles heel of previous attempts at creating a > > free-threaded CPython implementation. With first IronClad and now PyPy > > blazing the trail in interfacing a garbage collected Python > > implementation with deterministic refcounting for C extension modules, > > it seems plausible that this kind of approach may eventually prove > > acceptable. > > > > Furthermore, the with statement now provides a superior alternative to > > application level tricks that previously relied on deterministic > > refcounting. > > > > While multi-threading does break down beyond a certain number of > > cores, it *is* possible to do safely (particularly using queues to > > pass references around) and can avoid plenty of serialisation overhead > > when dealing with sizable data structures. > > > > Breaking binary compatibility with C extensions would be "difficult" > once PEP 384 (stable binary ABI) has gone into effect. "Stable" doesn't mean eternal. At worse, we could call the result Python 4.0. It should be noted, though, that a full GC can be detrimental to real-time applications. Kristján has already explained how some of his software disabled the cyclic GC, and took care of breaking cycles manually instead. 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
[Python-Dev] Compiling Free Cad on Rhel5
Hello to all..Today I was trying to install FreeCAD 0.10 from its source
code. I am using RHEL5. I have firstly installed python2.6.5 from source and
also tested it. Python is working fine. But when I try to compile FreeCAD
0.10, I got following configure error :
#./configure --with-python-include=/usr/local/include/python2.6
--with-python-lib=/usr/local/lib/python2.6
-
checking for a Python interpreter with version >= 2.5... python
checking for python... /usr/local/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.6/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.6/site-packages
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for libpython2.6... no
configure: error:
Cannot find Python2.6 devel files.
--
I also searched internet for python-devel source code but was unable to find
any such pacage. Please help me to resolve this python error.
Thanks
Vikas Mahajan
___
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] Compiling Free Cad on Rhel5
On 28/07/2010 12:21, Vikas Mahajan wrote:
Hello to all..Today I was trying to install FreeCAD 0.10 from its
source code. I am using RHEL5. I have firstly installed python2.6.5
from source and also tested it. Python is working fine. But when I try
to compile FreeCAD 0.10, I got following configure error :
Hello Vikas,
This list is for the discussion of the development *of* Python, not
developing *with* Python.
A more appropriate list to use would be the python-list (also known as
comp.lang.python). Other Python lists are referenced here:
http://www.python.org/community/lists/
Having said that, it is common for Linux distributions to package the
bits needed to compile Python separately from their distribution of
Python itself (a horrible practise). You probably need to install the
python-devel package using your package manager.
All the best,
Michael
#./configure --with-python-include=/usr/local/include/python2.6
--with-python-lib=/usr/local/lib/python2.6
-
checking for a Python interpreter with version >= 2.5... python
checking for python... /usr/local/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.6/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.6/site-packages
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for libpython2.6... no
configure: error:
Cannot find Python2.6 devel files.
--
I also searched internet for python-devel source code but was unable
to find any such pacage. Please help me to resolve this python error.
Thanks
Vikas Mahajan
___
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/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your
employer, to release me from all obligations and waivers arising from any and all
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS
AGREEMENTS") that I have entered into with your employer, its partners, licensors,
agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me from any BOGUS AGREEMENTS
on behalf of your employer.
___
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] Compiling Free Cad on Rhel5
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.
python-devel should be a package in your distribution - check the list
of packages.
On Wed, Jul 28, 2010 at 04:51:47PM +0530, Vikas Mahajan wrote:
> Hello to all..Today I was trying to install FreeCAD 0.10 from its source
> code. I am using RHEL5. I have firstly installed python2.6.5 from source and
> also tested it. Python is working fine. But when I try to compile FreeCAD
> 0.10, I got following configure error :
>
> #./configure --with-python-include=/usr/local/include/python2.6
> --with-python-lib=/usr/local/lib/python2.6
>
> -
> checking for a Python interpreter with version >= 2.5... python
> checking for python... /usr/local/bin/python
> checking for python version... 2.6
> checking for python platform... linux2
> checking for python script directory...
> ${prefix}/lib/python2.6/site-packages
> checking for python extension module directory...
> ${exec_prefix}/lib/python2.6/site-packages
> checking Python.h usability... yes
> checking Python.h presence... yes
> checking for Python.h... yes
> checking for libpython2.6... no
> configure: error:
> Cannot find Python2.6 devel files.
>
> --
>
> I also searched internet for python-devel source code but was unable to find
> any such pacage. Please help me to resolve this python error.
>
> Thanks
>
> Vikas Mahajan
Oleg.
--
Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Wed, Jul 28, 2010 at 4:50 PM, Gregory P. Smith wrote: > On Tue, Jul 27, 2010 at 6:43 PM, R. David Murray > wrote: >> On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel >> wrote: >> > Gregory P. Smith, 27.07.2010 07:40: >> > > Random replacement without dropping everything at least means apps >> > > thrashing >> > > the cache degrade much more gracefully. >> > >> > The same algorithm should be helpful in ElementTree's ElementPath >> > module. >> >> We recently added the old re cache-clearing strategy to >> fnmatch, because previously its cache would grow indefinitely. >> It sounds like this should be applied there as well. >> >> That's three...time to figure out how to share the code? > > No doubt. Anyone remember off the top of their head what linecache does? ... ah, it's just unbounded unless you call clearcache(). Probably OK for that particular application. > Its already a standalone _shrink_cache function with unit tests that doesn't > care the dictionaries it is shrinking are composed of. Easy enough to move > somewhere more useful. Any proposed stdlib locations? I'll be offline on > vacation soon so I may not get to it for a couple weeks but feel free to > move it without me if anyone is interested. I created a tracker issue for the idea so we don't forget about it: http://bugs.python.org/issue9396 collections seems like a fairly obvious possibility, but the flavour doesn't quite seem right for that. Nowhere else springs to mind though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] GIL musings (was Re: Thoughts fresh after EuroPython)
On 28 Jul, 2010,at 12:56 PM, Michael Foord wrote:On 28/07/2010 11:50, Nick Coghlan wrote: > On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren > wrote: > >> In my opinion the GIL is a weak point of CPython and it would be nice if it >> could be fixed. That is however easier said than done, a number of people >> have tried in the past and ran into implementation limitations like our >> refcounting garbage collector that make hard to remove the GIL without >> either rewriting lots of code, or running into a brick wall >> performance-wise. >> >> The HotPy presentation at EuroPython shows that it is possible to remove the >> GIL, although at the cost of replacing the garbage collector and most likely >> breaking existing C extensions (although the HotPy author seemed to have a >> possible workaround for that). >> > This is the kind of approach that seems to hold the most promise of > removing the GIL without incurring the single-threaded performance hit > that has been the achilles heel of previous attempts at creating a > free-threaded CPython implementation. With first IronClad and now PyPy > blazing the trail in interfacing a garbage collected Python > implementation with deterministic refcounting for C extension modules, > it seems plausible that this kind of approach may eventually prove > acceptable. > > Furthermore, the with statement now provides a superior alternative to > application level tricks that previously relied on deterministic > refcounting. > > While multi-threading does break down beyond a certain number of > cores, it *is* possible to do safely (particularly using queues to > pass references around) and can avoid plenty of serialisation overhead > when dealing with sizable data structures > Breaking binary compatibility with C extensions would be "difficult" once PEP 384 (stable binary ABI) has gone into effect. As you intimate, Ironclad demonstrates that C extensions *can* be interfaced with a different garbage collection system whilst maintaining binary compatibility. It does impose constraints however (which is why the PyPy c-ext implementors chose source compatibility rather than binary compatibility). The HotPy author mentioned that he has a scheme where refcounts could be used by C extensions while the system natively uses a copying collector, but I got the impression that this was not fully fleshed out yet.Apple's Objective-C garbage collector has a simular feature: you can use CFRetain/CFRelease to manage refcounts and the GC will only collect objects where the CF reference count is 0. This is a non-copying collector in a C environment though, which makes this scheme easier to implement than with a full generational copying collector.It should therefore be possible to have an interpreter where the VM uses a real GC and while extensions using the stable ABI could work as is, but that probably requires that Py_INCREF and Py_DECREF expand into function calls in the stable ABI.Implementing this would still be a significant amount of work.Ronald Michael > Cheers, > Nick. > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] GIL musings (was Re: Thoughts fresh after EuroPython)
On 28/07/2010 12:43, Ronald Oussoren wrote: On 28 Jul, 2010,at 12:56 PM, Michael Foord wrote: On 28/07/2010 11:50, Nick Coghlan wrote: > On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren > wrote: > >> In my opinion the GIL is a weak point of CPython and it would be nice if it >> could be fixed. That is however easier said than done, a number of people >> have tried in the past and ran into implementation limitations like our >> refcounting garbage collector that make hard to remove the GIL without >> either rewriting lots of code, or running into a brick wall >> performance-wise. >> >> The HotPy presentation at EuroPython shows that it is possible to remove the >> GIL, although at the cost of replacing the garbage collector and most likely >> breaking existing C extensions (although the HotPy author seemed to have a >> possible workaround for that). >> > This is the kind of approach that seems to hold the most promise of > removing the GIL without incurring the single-threaded performance hit > that has been the achilles heel of previous attempts at creating a > free-threaded CPython implementation. With first IronClad and now PyPy > blazing the trail in interfacing a garbage collected Python > implementation with deterministic refcounting for C extension modules, > it seems plausible that this kind of approach may eventually prove > acceptable. > > Furthermore, the with statement now provides a superior alternative to > application level tricks that previously relied on deterministic > refcounting. > > While multi-threading does break down beyond a certain number of > cores, it *is* possible to do safely (particularly using queues to > pass references around) and can avoid plenty of serialisation overhead > when dealing with sizable data structures > Breaking binary compatibility with C extensions would be "difficult" once PEP 384 (stable binary ABI) has gone into effect. As you intimate, Ironclad demonstrates that C extensions *can* be interfaced with a different garbage collection system whilst maintaining binary compatibility. It does impose constraints however (which is why the PyPy c-ext implementors chose source compatibility rather than binary compatibility). The HotPy author mentioned that he has a scheme where refcounts could be used by C extensions while the system natively uses a copying collector, but I got the impression that this was not fully fleshed out yet. Apple's Objective-C garbage collector has a simular feature: you can use CFRetain/CFRelease to manage refcounts and the GC will only collect objects where the CF reference count is 0. This is a non-copying collector in a C environment though, which makes this scheme easier to implement than with a full generational copying collector. It should therefore be possible to have an interpreter where the VM uses a real GC and while extensions using the stable ABI could work as is, but that probably requires that Py_INCREF and Py_DECREF expand into function calls in the stable ABI. Ironclad artificially inflates the refcount by one when objects are created. If an object is eligible for garbage collection *and* the refcount is 1 (so the C extension doesn't hold any references to it) then Ironclad decrements the refcount to zero and nature takes its course. That's a simplification of course (particularly around what happens when an object is eligible for garbage collection but the refcount is above 1). This allows Py_INCREF and Py_DECREF to remain as macros - switching to functions would have a performance cost I guess. Michael Implementing this would still be a significant amount of work. Ronald Michael > Cheers, > Nick. > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and
Re: [Python-Dev] Compiling Free Cad on Rhel5
Wiadomość napisana przez Vikas Mahajan w dniu 2010-07-28, o godz. 13:21: > Hello to all..Today I was trying to install FreeCAD 0.10 from its source > code. I am using RHEL5. I have firstly installed python2.6.5 from source and > also tested it. Python is working fine. But when I try to compile FreeCAD > 0.10, I got following configure error : 1. Please post Python usage related problems to the python-users mailing list: http://mail.python.org/mailman/listinfo/python-list 2. That being said, your specific problem can be resolved by compiling Python to a dynamic library. You can do this by specifying `--enable-shared` during the `./configure` phase. -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ 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] Compiling Free Cad on Rhel5
> 1. Please post Python usage related problems to the python-users mailing list: > http://mail.python.org/mailman/listinfo/python-list Sorry for posting here. I am new baby to python so I don't know where to post. I will remember this and will not post irrelevant topics here. > 2. That being said, your specific problem can be resolved by compiling Python > to a dynamic library. You can do this by specifying `--enable-shared` during > the `./configure` phase. Thanks a lot for your help. Your solution helped me a lot. > -- > Best regards, > Łukasz Langa > tel. +48 791 080 144 > WWW http://lukasz.langa.pl/ -- Regards Vikas Mahajan ___ 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] mkdir -p in python
I believe, in design purpose, the os.mkdir() is to match the system call "mkdir()" exactly, the os.makedirs() is a "Super-mkdir", it provides extra convenience for using when we want to create directories. This is the case makedirs() should deal with. A new function maybe confused with makedirs(). I think os.makedirs() should go to shutil, but we have missed the right time. On Wed, Jul 28, 2010 at 3:29 PM, Hrvoje Niksic wrote: > On 07/27/2010 06:18 PM, Alexander Belopolsky wrote: > >> On Tue, Jul 20, 2010 at 10:20 AM, R. David Murray >> wrote: >> >>> I'd go with putting it in shutil. >>> >> >> +1 >> >> I would also call it shutil.mktree which will go well with >> shutil.rmtree next to it. >> > > Note that mktree is not analogous to rmtree - while rmtree removes a > directory tree beneath a specified directory, mktree would only create a > single "branch", not an entire tree. I'd imagine a mktree function to > accept a data structure describing the tree to be created. > > If you're going for a short name distinctive from mkdir, I propose > mksubdirs. > > ___ > 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/ysj.ray%2Bpython-dev%40gmail.com > -- Ray Allen Best wishes! ___ 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] Fast Implementation for ZIP decryption
CJ Kucera wrote: > Hello list, resurrecting a rather old thread from here: > > http://mail.python.org/pipermail/python-dev/2009-August/091450.html ... and one final update from me, mostly just so Google and the like will pick it up. I did actually end up packaging up something I called "czipfile," which is just the stock Python Lib/zipfile.py optimized in Cython, which provides very fast zipfile decryption. It's available here: http://pypi.python.org/pypi/czipfile So, anyone with a need for fast zipfile decryption can now head over that way. FWIW, while playing around with things, I found that you can get some pretty nontrivial performance improvements in pure Python by unrolling the decryption loop. For instance, line 608 in Lib/zipfile.py used to be: newdata = ''.join(map(self.decrypter, newdata)) Substituting the following results in some significant speed improvements (though still quite a lot slower than the C-based extension) - key0 = self.decrypter.key0 key1 = self.decrypter.key1 key2 = self.decrypter.key2 crctable = self.decrypter.crctable datalist = [] for c in newdata: k = key2 | 2 cord = ord(c) ^ (((k * (k^1)) >> 8) & 255) datalist.append(chr(cord)) key0 = ((key0 >> 8) & 0xff) ^ crctable[(key0 ^ cord) & 0xff] key1 = (key1 + (key0 & 255)) & 4294967295 key1 = (key1 * 134775813 + 1) & 4294967295 key2 = ((key2 >> 8) & 0xff) ^ crctable[(key2 ^ ((key1 >> 24) & 255)) & 0xff] self.decrypter.key0 = key0 self.decrypter.key1 = key1 self.decrypter.key2 = key2 newdata = ''.join(datalist) Anyone looking to speed up decryption who didn't want to absolutely depend on the user having czipfile installed might want to consider bundling their own modified version of Lib/zipfile.py with the above changes. Okay, that's all. Enjoy! -CJ -- WOW: Flemmy| "The ships hung in the sky in much the same p...@apocalyptech.com |way that bricks don't." - Douglas Adams, 24.24.2.3171 | _The Hitchhiker's Guide To The Galaxy_ ___ 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] caching in the stdlib? (was: New regex module for 3.2?)
On Tue, Jul 27, 2010 at 10:29 PM, Stefan Behnel wrote: > What about actually putting it visibly into the stdlib? Except for files, I > didn't see much about caching there, which seems like a missing battery to > me. Why not do it as with the collections module and add stuff as it comes > in? Caching is a rather large topic to focus on in a single stdlib module or package. It means radically different things to different people. The pattern we're talking about there is probably more something like memoization, so 'memo' or 'memoization' could b a reasonable module name. Maybe it could provide a decorator that you configure with things like how many entries max, the expiration policy (or different policies could have different decorators), and how to compute the memo key from the arguments to the function (the default could be the repr() of the argument tuple). -- --Guido van Rossum (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] caching in the stdlib? (was: New regex module for 3.2?)
On Jul 28, 2010, at 7:31 AM, Guido van Rossum wrote: > On Tue, Jul 27, 2010 at 10:29 PM, Stefan Behnel wrote: >> What about actually putting it visibly into the stdlib? Except for files, I >> didn't see much about caching there, which seems like a missing battery to >> me. Why not do it as with the collections module and add stuff as it comes >> in? > > Caching is a rather large topic to focus on in a single stdlib module > or package. It means radically different things to different people. > > The pattern we're talking about there is probably more something like > memoization, so 'memo' or 'memoization' could b a reasonable module > name. Maybe it could provide a decorator that you configure with > things like how many entries max, the expiration policy (or different > policies could have different decorators), and how to compute the memo > key from the arguments to the function (the default could be the > repr() of the argument tuple). FWIW, this has been a popular caching/memoization recipe: http://code.activestate.com/recipes/498245-lru-cache-decorator 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] caching in the stdlib?
I think this is better suited for python-ideas, so moving it there. Guido van Rossum, 28.07.2010 16:31: On Tue, Jul 27, 2010 at 10:29 PM, Stefan Behnel wrote: What about actually putting it visibly into the stdlib? Except for files, I didn't see much about caching there, which seems like a missing battery to me. Why not do it as with the collections module and add stuff as it comes in? Caching is a rather large topic to focus on in a single stdlib module or package. It means radically different things to different people. Sure. All I would like to see in the stdlib is a dict based cache with a bounded size and a set of different policies that keep it at that size. Maybe a BoundedDict would match that need. The pattern we're talking about there is probably more something like memoization, so 'memo' or 'memoization' could b a reasonable module name. That would be a second interface to it, I'd say. The normal interface would just be the regular mapping interface, maybe even just a .get() method instead of a KeyError raising lookup. Maybe it could provide a decorator that you configure with things like how many entries max, the expiration policy (or different policies could have different decorators), and how to compute the memo key from the arguments to the function (the default could be the repr() of the argument tuple). Absolutely. 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] mkdir -p in python
On 7/28/2010 4:42 AM, Ray Allen wrote: I believe, in design purpose, the os.mkdir() is to match the system call "mkdir()" exactly, the os.makedirs() is a "Super-mkdir", it provides extra convenience for using when we want to create directories. This is the case makedirs() should deal with. After discussion with Guido, the patch on the tracker leaves makedir alone and catches the exception, or not, in makedirs. -- Terry Jan Reedy ___ 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] Thoughts fresh after EuroPython
2010/7/25 Stefan Behnel : > Nick Coghlan, 25.07.2010 08:29: >> >> We knew PEP 380 would be hurt by the moratorium when the moratorium >> PEP went through. >> >> The goals of the moratorium itself, in making it possible to have a >> 3.2 release that is fully supported by all of the major Python >> implementations, still apply, and I believe making an exception for >> PEP 380 *would* make those goals much harder to achieve. > > IMO, it would be worth asking the other implementations if that is the case. > It may well be that they are interested in implementing it anyway, so > getting it into CPython and the other implementations at the same time may > actually be possible. It wouldn't meet the moratorium as such, but it would > absolutely comply with its goals. Speaking from the PyPy perspective, syntax is not really a problem. It, for example, took me ~1 week to more PyPy from 2.5 to 2.7 syntax. A more interesting moratorium for us would be one on tests that are not implementation portable. :) -- Regards, Benjamin ___ 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] Thoughts fresh after EuroPython
On 28/07/2010 22:20, Benjamin Peterson wrote: 2010/7/25 Stefan Behnel: Nick Coghlan, 25.07.2010 08:29: We knew PEP 380 would be hurt by the moratorium when the moratorium PEP went through. The goals of the moratorium itself, in making it possible to have a 3.2 release that is fully supported by all of the major Python implementations, still apply, and I believe making an exception for PEP 380 *would* make those goals much harder to achieve. IMO, it would be worth asking the other implementations if that is the case. It may well be that they are interested in implementing it anyway, so getting it into CPython and the other implementations at the same time may actually be possible. It wouldn't meet the moratorium as such, but it would absolutely comply with its goals. Speaking from the PyPy perspective, syntax is not really a problem. It, for example, took me ~1 week to more PyPy from 2.5 to 2.7 syntax. A more interesting moratorium for us would be one on tests that are not implementation portable. :) At the PyCon language summit the IronPython guys said that syntax wasn't an issue for them either but changes on builtins *could* be an issue. All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Best practice for new namespace (from C/API)
Hi, I'm writing because I'm working on a project where the user can
run scripts that don't reference a file but use internal application
text data.
Otherwise we are not doing anything tricky, only that the scripts
should each run independently (no cruft left from the previous scripts
namespace, sharing sys.modules etc is fine).
Something which is unclear to me even after looking over pythonrun.c
is the correct way to setup a namespace.
For years we have been doing this and it seemed to work fine...
PyObject *d = PyDict_New(); // new namespace
PyDict_SetItemString(d, "__builtins__", PyEval_GetBuiltins());
PyDict_SetItemString(d, "__file__", PyString_FromString(filename));
// fake, avoids sys.argv[0] being used for warnings.
/* --- snip ---*/
PyEval_EvalCode(compiled_text, d, d);
Recently a developer reported a bug where pickle wasn't working, it
turns out that in a few places python expects the __main__ modules
namespace to match that if the running script: _pickle.c's
save_global() in this case
eg:
>>> spam = 10
>>> print(__import__("__main__").__dict__["spam"])
... 10
Once I found this was the problem it was simple to use __main__'s
namespace however there are still things that are not clear about
exactly how this should be done.
Simplified code...
PyObject *item, *dict= PyModule_GetDict(PyImport_AddModule("__main__"));
PyDict_Clear(dict);
PyDict_SetItemString(dict, "__builtins__", PyImport_AddModule("builtins"));
item = PyUnicode_FromString( "__main__" );
PyDict_SetItemString( dict, "__name__", item );
Py_DECREF(item);
PyDict_SetItemString(d, "__file__", PyString_FromString(filename));
// fake, avoids sys.argv[0] being used for warnings.
/* --- snip ---*/
PyEval_EvalCode(compiled_text, dict, dict);
Still this leaves me with the following questions...
- Whats the best way to manage the namespace for running multiple
scripts one after another? clear and initialize __main__'s dict each
time?, keep a copy and restore it after each run?
- should the original __main__ namespace be restored after running a script?
- pickle expects: __import__("__main__").__dict__ == ***the current
namespace***, is this apart of the python spec or just something
specific to pickle?
- PyDict_SetItemString(d, "__builtins__", PyEval_GetBuiltins()) acts
differently to PyDict_SetItemString(dict, "__builtins__",
PyImport_AddModule("builtins")), using the PyEval_GetBuiltins() dict
adds every member of __builtins__ when running:
print(__import__("__main__").__dict__.keys()), rather then just
showing __builtins__.
--
- Campbell
___
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] Thoughts fresh after EuroPython
On Wed, Jul 28, 2010 at 5:20 PM, Benjamin Peterson wrote: > 2010/7/25 Stefan Behnel : >> Nick Coghlan, 25.07.2010 08:29: >>> >>> We knew PEP 380 would be hurt by the moratorium when the moratorium >>> PEP went through. >>> >>> The goals of the moratorium itself, in making it possible to have a >>> 3.2 release that is fully supported by all of the major Python >>> implementations, still apply, and I believe making an exception for >>> PEP 380 *would* make those goals much harder to achieve. >> >> IMO, it would be worth asking the other implementations if that is the case. >> It may well be that they are interested in implementing it anyway, so >> getting it into CPython and the other implementations at the same time may >> actually be possible. It wouldn't meet the moratorium as such, but it would >> absolutely comply with its goals. > > Speaking from the PyPy perspective, syntax is not really a problem. > It, for example, took me ~1 week to more PyPy from 2.5 to 2.7 syntax. > A more interesting moratorium for us would be one on tests that are > not implementation portable. :) > > > I thought at the last two pycons, we've all discussed that we should have a system in place for marking tests *and* modules within the stdlib as "will only work on FooPython". I suspect that it's waiting on the shared-stdlib effort, which is waiting on mercurial (and time). 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] Thoughts fresh after EuroPython
On 28/07/2010 23:57, Jesse Noller wrote: On Wed, Jul 28, 2010 at 5:20 PM, Benjamin Peterson wrote: 2010/7/25 Stefan Behnel: Nick Coghlan, 25.07.2010 08:29: We knew PEP 380 would be hurt by the moratorium when the moratorium PEP went through. The goals of the moratorium itself, in making it possible to have a 3.2 release that is fully supported by all of the major Python implementations, still apply, and I believe making an exception for PEP 380 *would* make those goals much harder to achieve. IMO, it would be worth asking the other implementations if that is the case. It may well be that they are interested in implementing it anyway, so getting it into CPython and the other implementations at the same time may actually be possible. It wouldn't meet the moratorium as such, but it would absolutely comply with its goals. Speaking from the PyPy perspective, syntax is not really a problem. It, for example, took me ~1 week to more PyPy from 2.5 to 2.7 syntax. A more interesting moratorium for us would be one on tests that are not implementation portable. :) I thought at the last two pycons, we've all discussed that we should have a system in place for marking tests *and* modules within the stdlib as "will only work on FooPython". I suspect that it's waiting on the shared-stdlib effort, which is waiting on mercurial (and time). It is also one of the things Brett intends to work on if his proposal is accepted by the PSF board. Michael 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] audience-instructors for Teach Me Python Bugfixing needed
The PyOhio contribu-palooza starts this Saturday! http://www.pyohio.org/Contribute With two talks and a two-day-four-night sprint, I'm very hopeful that it will recruit and train some new core workers. I'm preparing my portion, the teach-the-newbie (me) -to-fix-a-core-bug session, and I want to make sure that I'm prepared in two ways: 1. Any bulky download/compilation steps are complete I pulled the Py3 trunk with svn co http://svn.python.org/projects/python/branches/py3k python, did the compilation steps, and verified that I can fire up the latest build. I also note that http://www.python.org/dev/ doesn't say anything about hg yet. Is there someplace else I should look for hg-centered docs? Should we just teach it using svn if that's better documented? Then again, if hg is the way of the future... I also built the docs (``cd Doc; make html``) Are there other things that I need to do to configure my machine beforehand? Things that are too long/boring for the audience to sit through while I do it live? 2. Have a good set of questions to ask. Here's what I'm planning so far: - While running ``make test`` on the Python trunk, I got an error on "test_os". Is that a problem with my machine's configuration, or with the build? Do I need to report it? Can I ignore it? Now we'll find a bug. - Do I need an account on bugs.python.org? What do I need to do to get one? - How do I find a bug suitable for me to work on? - entry-level - in Python not C - corresponding to my strong points / interests Now we'll "find" a fake bug that David has planted for us. (David, have you planted it yet?) - Can/should I make my edits directly in the trunk that I just pulled down? - Now we'll make the fix... maybe this should involve using a debugging IDE or pdb? - How do I verify that my fix worked? That it didn't break anything else? That it's written with proper style? That it doesn't generally suck? - How do I send my fix back up to the trunk? - How do I record my work in the bug tracker? (If time permits) now let's try writing a test for a gap in test coverage (not necessarily on the code we just worked on - this doesn't have to be fake) DON'T ANSWER THESE! I need to carefully guard my sincere ignorance through Saturday! (Actually, I already have a pretty good idea about some of them, but I don't want my ignorance to become any less sincere than it already is.) But, if you're David or Dan or anybody else who's going to be there, you may want to ponder how you'll guide me through it. But what I want to know from all of you is: what other questions should be on my list? I was going to address this only to David, my primary audience/instructor volunteer, but I thought it wouldn't hurt to get input from the rest of you. Thank you all! -- - Catherine http://catherinedevlin.blogspot.com/ *** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.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] Python Language Summit EuroPython 2010
On Sun, Jul 25, 2010 at 10:52 PM, Guido van Rossum wrote: .. >>> How hard would it be to recode the sprintf language but with the >>> locale fixed to "C"? That would always be ASCII. >> >> This is exactly what I proposed at >> http://bugs.python.org/issue7584#msg110240 not so long ago. Given >> that stftime language uses every English letter as one of its codes >> (both caps and lower case), it would be an effort, but coding it in >> python should not be too hard. A C implementation would be harder, >> but there must be implementations around available under a suitable >> license that can be reused. >> >> In short, definitely +1. > > For b"...".format() we could also support a subset (still better than > hardcoding something str()-based). It appears that the treasure trove that we call the bugs' tracker already has a patch for that: http://bugs.python.org/issue3173 http://bugs.python.org/file10704/strftime.diff ___ 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] GIL musings (was Re: Thoughts fresh after EuroPython)
On 28/07/10 23:12, Antoine Pitrou wrote: It should be noted, though, that a full GC can be detrimental to real-time applications. Kristján has already explained how some of his software disabled the cyclic GC, and took care of breaking cycles manually instead. This worries me, too. I'd be upset if I could no longer write games in Python that achieve smooth animation because of unpredictable GC pauses. -- 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
