Re: a.index(float('nan')) fails
Am 27.10.2012 06:48 schrieb Dennis Lee Bieber: I don't know about the more modern calculators, but at least up through my HP-41CX, HP calculators didn't do (binary) "floating point"... They did a form of BCD with a fixed number of significant /decimal/ digits Then, what about sqrt(x)**2 or arcsin(sin(x))? Did that always return the original x? Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: better way for ' '.join(args) + '\n'?
Am 26.10.2012 09:49 schrieb Ulrich Eckhardt:
Hi!
General advise when assembling strings is to not concatenate them
repeatedly but instead use string's join() function, because it avoids
repeated reallocations and is at least as expressive as any alternative.
What I have now is a case where I'm assembling lines of text for driving
a program with a commandline interface.
Stop.
In this case, you think too complicated.
Just do
subprocess.Popen(['prog', 'foo', 'bar', 'baz'])
- is the most safest thing for this use case.
If it should not be possible for any reason, you should be aware of any
traps you could catch - e.g., if you want to feed your string to a
Bourne shell, you should escape the strings properly.
In such cases, I use
def shellquote(*strs):
r"""Input: file names, output: ''-enclosed strings where every ' is
replaced with '\''. Intended for usage with the shell."""
# just take over everything except ';
# replace ' with '\''
# The shell sees ''' as ''\'''\'''\'''. Ugly, but works.
return " ".join([
"'"+st.replace("'","'\\''")+"'"
for st in strs
])
so I can use
shellquote('program name', 'argu"ment 1', '$arg 2',
"even args containing a ' are ok")
For Windows, you'll have to modify this somehow.
HTH,
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
Sphinx / sys.path
Hi, I figure out how it works with sphinx documentation. But I'm stucked in the sys.path issue? sys.path.insert(0, '/home/chris/projekte/dev/testmodule') /home/chris/projekte/dev/testmodule/doc/source/code.rst:4: WARNING: autodoc can't import/find module 'myproject', it reported error: "No module named useful_1", please check your spelling and sys.path Thanks in advance Christian +-- doc | +-- build | | +-- doctrees | | | +-- code.doctree | | | +-- environment.pickle | | | +-- index.doctree | | +-- genindex.html | | +-- html | | | +-- code.html | | | +-- genindex.html | | | +-- index.html | | | +-- objects.inv | | | +-- py-modindex.html | | | +-- search.html | | | +-- searchindex.js | | | +-- _sources | | | | +-- code.txt | | | | +-- index.txt | | | +-- _static | | | +-- ajax-loader.gif | | | +-- basic.css | | | +-- comment-bright.png | | | +-- comment-close.png | | | +-- comment.png | | | +-- default.css | | | +-- doctools.js | | | +-- down.png | | | +-- down-pressed.png | | | +-- file.png | | | +-- jquery.js | | | +-- minus.png | | | +-- plus.png | | | +-- pygments.css | | | +-- searchtools.js | | | +-- sidebar.js | | | +-- underscore.js | | | +-- up.png | | | +-- up-pressed.png | | | +-- websupport.js | | +-- index.html | | +-- objects.inv | | +-- search.html | | +-- searchindex.js | | +-- _sources | | | +-- index.txt | | +-- _static | | +-- ajax-loader.gif | | +-- basic.css | | +-- comment-bright.png | | +-- comment-close.png | | +-- comment.png | | +-- default.css | | +-- doctools.js | | +-- down.png | | +-- down-pressed.png | | +-- file.png | | +-- jquery.js | | +-- minus.png | | +-- plus.png | | +-- pygments.css | | +-- searchtools.js | | +-- sidebar.js | | +-- underscore.js | | +-- up.png | | +-- up-pressed.png | | +-- websupport.js | +-- make.bat | +-- Makefile | +-- source | +-- code.rst | +-- conf.py | +-- index.rst | +-- _static | +-- _templates +-- myproject | +-- __init__.py | +-- __init__.pyc | +-- usefuel1.py | +-- usefuel1.pyc | +-- usefuel2.py | +-- usefuel2.pyc +-- README +-- setup.py +-- tests -- http://mail.python.org/mailman/listinfo/python-list
Re: Sphinx / sys.path
On 10/27/2012 06:18 AM, mining.fa...@googlemail.com wrote: > Hi, > > I figure out how it works with sphinx documentation. But I'm stucked > in the sys.path issue? > > sys.path.insert(0, '/home/chris/projekte/dev/testmodule') > > /home/chris/projekte/dev/testmodule/doc/source/code.rst:4: WARNING: autodoc > can't import/find module 'myproject', it reported error: "No module named > useful_1", please check your spelling and sys.path I have no idea if it's the ONLY problem, but the module below isn't called useful_1, it's called usefuel1. Notice there are two differences. > Thanks in advance > Christian > > > +-- doc > | +-- build > | | +-- doctrees > | | | +-- code.doctree > | | | +-- environment.pickle > | | | +-- index.doctree > | | +-- genindex.html > | | +-- html > | | | +-- code.html > | | | +-- genindex.html > | | | +-- index.html > | | | +-- objects.inv > | | | +-- py-modindex.html > | | | +-- search.html > | | | +-- searchindex.js > | | | +-- _sources > | | | | +-- code.txt > | | | | +-- index.txt > | | | +-- _static > | | | +-- ajax-loader.gif > | | | +-- basic.css > | | | +-- comment-bright.png > | | | +-- comment-close.png > | | | +-- comment.png > | | | +-- default.css > | | | +-- doctools.js > | | | +-- down.png > | | | +-- down-pressed.png > | | | +-- file.png > | | | +-- jquery.js > | | | +-- minus.png > | | | +-- plus.png > | | | +-- pygments.css > | | | +-- searchtools.js > | | | +-- sidebar.js > | | | +-- underscore.js > | | | +-- up.png > | | | +-- up-pressed.png > | | | +-- websupport.js > | | +-- index.html > | | +-- objects.inv > | | +-- search.html > | | +-- searchindex.js > | | +-- _sources > | | | +-- index.txt > | | +-- _static > | | +-- ajax-loader.gif > | | +-- basic.css > | | +-- comment-bright.png > | | +-- comment-close.png > | | +-- comment.png > | | +-- default.css > | | +-- doctools.js > | | +-- down.png > | | +-- down-pressed.png > | | +-- file.png > | | +-- jquery.js > | | +-- minus.png > | | +-- plus.png > | | +-- pygments.css > | | +-- searchtools.js > | | +-- sidebar.js > | | +-- underscore.js > | | +-- up.png > | | +-- up-pressed.png > | | +-- websupport.js > | +-- make.bat > | +-- Makefile > | +-- source > | +-- code.rst > | +-- conf.py > | +-- index.rst > | +-- _static > | +-- _templates > +-- myproject > | +-- __init__.py > | +-- __init__.pyc > | +-- usefuel1.py > | +-- usefuel1.pyc > | +-- usefuel2.py > | +-- usefuel2.pyc > +-- README > +-- setup.py > +-- tests -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Sphinx / sys.path
Got it spelling error! -- http://mail.python.org/mailman/listinfo/python-list
Re: SSH Connection with Python
On 10/27/2012 02:21 AM, Roy Smith wrote: In article , Gelonida N wrote: Another problem is, that paramiko depends on pycrypto 2.1+ which doesn't exist as binary release for python 2.7 I'm running paramiko-1.7.6 with python 2.7.3 on my Ubunto Precise box. I'm reasonably sure all I did was "pip install paramiko". Apologies. I failed to mention, that I was talking about Windows not Linux. I use Python for applications, that should work under Linux and under Windows. But, keep in mind that fabric depends on paramiko. If you can't get paramiko installed, you probably can't get fabric either. Thanks, that's good to know, so I don't have to bother looking at farbic (at least not as solution on windows python 2.7 without having to try to recompile pycrypto myself) -- http://mail.python.org/mailman/listinfo/python-list
Re: attaching names to subexpressions
On 10/27/2012 04:42 AM, Steve Howell wrote: > I have been reading the thread "while expression feature proposal," > and one of the interesting outcomes of the thread is the idea that > Python could allow you to attach names to subexpressions, much like C > allows. In C you can say something like this: > >tax_next_year = (new_salary = salary * (1 + raise)) * tax_rate > > To avoid the "=" pitfall, folks have proposed something like this for > Python: > >tax_next_year = ((salary * (1 + raise)) as new_salary) * tax_rate >print new_salary, tax_next_year > . . . > > If the problem statement is "How do I name subexpression?", then > Python already has a clear path--break your code up into multiple > lines. I'm wondering where this simple solution really breaks down > from a readability perspective. Perhaps with short-circuited boolean > expressions? > For me two places where expression assignemts can be useful are while loops and sometimes elif statements. While example line = complex_exression while line: do something with(line) line = complex_expression violates clearly the DRY principle and the risk to change one line but not the other is high. The 'canonical way' while True: line = complex_expression if not line: break do_something_with(line) avoids this problem, but I was never really convinced about the beauty / readbility of this construct. One misses the exit condition of the while loop on the first glance. In my opinion I shouldn't be obliged to read any of the indented lines of the while statement on a first 'visual' pass through somebody elses code and still be able to see what the loop iterates through. Following looks in my opinion nicer. while complex_expression as line: do_something_with(line) or the even more powerful suggestion: while (complex_expression as line) is not None: do_something_with(line) Elif Example: -- value1 = expression1 if (value1): do_something else: value2 = expression2 if(value2): do_something_with(value2) else: value2 = expression3 if(value3): do_something_with(value3) Could be rewritten as value1= expression1 if(value1): do_something_with(value1) elif(expression2 as value2): do_something_with(value2) elif(expression3 as value3): do_something_with(value3) However in all other cases I really think using this new syntax would reduce readability andit would be better to just split the statement into two lines. for while / elif statements splitting up is not possible without doing some further acrobatics, which render in my opinion the code less readable. If the new syntax were adopted, then one open question would be scoping. value=expression if(value): do_something_with(value) elif(expression2 as value): do_something_with(value) elif(expression3 as value): do_something_with(value) print value # will value leak out of the elif statements or not I never tried to use other 'as-variables' (e.g. from 'with' or 'except' statements) outside of their indented block, so I never bothered to check how Python would react. -- http://mail.python.org/mailman/listinfo/python-list
Re:
On Sun, Oct 28, 2012 at 12:13 AM, Shaojun Li wrote: > nothing Step aside, 'import this', we've found the true Zen of Python! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Shipping python modules - best practices?
Hello, I developed some moderate-sized python scripts that I would like to distribute as python modules. I have never shipped modules before and I read http://docs.python.org/distutils/index.html. I was able to generate a source distribution, but I still have some questions. 1) My module contains some unit tests in separate scripts. I want to execute them when I generate the source distribution. How can I do it? 2) When I install 3rd party modules, I see some of them executing their unit tests during the installation. How can I do it? How can I provide an option to the user to ignore possible test failures? 3) I generate some html documentation with pydoc. How shall I distribute it with the module? Thank you very much in advance. Regards rambius -- http://mail.python.org/mailman/listinfo/python-list
Re: Sphinx / sys.path
So now it works, but taking my project get some trouble. I use in MyData my
ConfigParser Class for configuration issues. The project.ini file is in
/project and has some entries.
[Logging]
my_data:MyData.py#/tmp/MyData.log#logging.WARN
I guess Sphinx has trouble to load the ini-file!?
Thanks for help
Christian
File
"/usr/local/lib/python2.7/site-packages/Sphinx-1.1.3-py2.7.egg/sphinx/ext/autodoc.py",
line 321, in import_object
__import__(self.modname)
File "/home/chris/projekte/dev/my/module/project/MyData.py", line 17, in
vec = conf.ConfigSectionMap('Logging')['my_data'].split('#')
/home/chris/projekte/dev/my/module/doc/source/index.rst:42: WARNING: autodoc
can't import/find module 'MyData', it reported error: "No section: 'Logging'",
please check your spelling and sys.path
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to correctly pass “pointer-to-pointer” into DLL via ctypes?
On Thursday, November 18, 2010 8:03:57 PM UTC+8, Grigory Petrov wrote:
> Hello.
>
> I have a DLL that allocates memory and returns it. Function in DLL is like
> this:
>
> void Foo( unsigned char** ppMem, int* pSize )
> {
> * pSize = 4;
> * ppMem = malloc( * pSize );
> for( int i = 0; i < * pSize; i ++ ) (* pMem)[ i ] = i;
> }
>
> Also, i have a python code that access this function from my DLL:
>
> from ctypes import *
> Foo = windll.mydll.Foo
> Foo.argtypes = [ POINTER( POINTER( c_ubyte ) ), POINTER( c_int ) ]
> mem = POINTER( c_ubyte )()
> size = c_int( 0 )
> Foo( byref( mem ), byref( size ) ]
> print size, mem[ 0 ], mem[ 1 ], mem[ 2 ], mem[ 3 ]
>
> I'm expecting that print will show "4 0 1 2 3" but it shows "4 221 221
> 221 221" O_O. Any hints what i'm doing wrong?
I am wondering in Python how you free the memory which is allocated in your DLL
?
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Error compiling python3.2.3: architecture of input file is incompatible
Hello, I am trying to compile Python 3.2.3. On my 64 bit Ubuntu machine I have no problems but using Ubuntu 32 but I get the following error: /usr/bin/ld: i386:x86-64 architecture of input file `Parser/tokenizer_pgen.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `Parser/printgrammar.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `Parser/pgenmain.o' is incompatible with i386 output collect2: ld returned 1 exit status make: *** [Parser/pgen] Error 1 As it's the first time for me compiling python by myself, I have no idea how to solve this. So I'm glad to see any suggestions. Thanks, Tobias -- http://mail.python.org/mailman/listinfo/python-list
ctypes free memory which is allocated in C DLL
Hi Guys, I have a DLL which written in C language, one of the function is to allocate a structure, fill the members and then return the pointer of the structure. After Python called this function, and done with the returned structure, I would like to free the returned structure. How can I achieve this ? Basically, I tried that I wrote a corresponding free interface in the DLL, it works, but calling the libc.free in Python doesn't work. my_dll.return_structure_ptr.restypes = POINTER(Dummy) res_ptr = my_dll.return_structure_ptr() windll.msvcrt.free(res_ptr) < doesn't work, memory violation my_dll.free_dummy_struture(res_ptr) <== This works. Thanks ! -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes free memory which is allocated in C DLL
On Sun, Oct 28, 2012 at 1:42 AM, wrote: > Hi Guys, > > I have a DLL which written in C language, one of the function is to allocate > a structure, fill the members and then return the pointer of the structure. > > After Python called this function, and done with the returned structure, I > would like to free the returned structure. How can I achieve this ? > Basically, I tried that I wrote a corresponding free interface in the DLL, it > works, but calling the libc.free in Python doesn't work. As a general rule, you should always match your allocs and frees. Use the same library to free the memory as was used to allocate it. Nothing else is safe. If your DLL exposes an API that allocates memory, your DLL should expose a corresponding API to free it. So what you have is the best way :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes free memory which is allocated in C DLL
On Saturday, October 27, 2012 10:56:54 PM UTC+8, Chris Angelico wrote: > On Sun, Oct 28, 2012 at 1:42 AM, wrote: > > > Hi Guys, > > > > > > I have a DLL which written in C language, one of the function is to > > allocate a structure, fill the members and then return the pointer of the > > structure. > > > > > > After Python called this function, and done with the returned structure, I > > would like to free the returned structure. How can I achieve this ? > > Basically, I tried that I wrote a corresponding free interface in the DLL, > > it works, but calling the libc.free in Python doesn't work. > > > > As a general rule, you should always match your allocs and frees. Use > > the same library to free the memory as was used to allocate it. > > Nothing else is safe. If your DLL exposes an API that allocates > > memory, your DLL should expose a corresponding API to free it. So what > > you have is the best way :) > > > > ChrisA Thanks a lot, Chris! Yes, I agree writing a corresponding API to free the memory is the best practice and best bet. Sometimes, the third party API may not provide that. After digging the Python manual again and again. I finally figure out why windll.msvcrt.free is failing. As the manual stated below, the DLL is using another version of msvcrt lib which is different than the builtin windll.msvcrt. After I explicitly load the msvcrt which built the DLL, things are getting function now. "ctypes.util.find_msvcrt() Windows only: return the filename of the VC runtype library used by Python, and by the extension modules. If the name of the library cannot be determined, None is returned. If you need to free memory, for example, allocated by an extension module with a call to the free(void *), it is important that you use the function in the same library that allocated the memory." -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote: > Containment of nan in collection is tested by is, not ==. AFAICT, it isn't specific to NaN. The test used by .index() and "in" appears to be equivalent to: def equal(a, b): return a is b or a == b IOW, it always checks for object identity before equality. Replacing NaN with an instance of a user-defined class with a non-reflexive __eq__() method supports this: > class Foo(object): = def __eq__(self, other): = return False = > a = Foo() > b = Foo() > a in [1,2,a,3,4] True > b in [1,2,a,3,4] False > [1,2,a,3,4].index(a) 2 > [1,2,a,3,4].index(b) Traceback (most recent call last): File "", line 1, in ValueError: <__main__.Foo object at 0x7fa7055b0550> is not in list -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Sat, 27 Oct 2012 08:56:16 +0200, Thomas Rachel wrote: > Am 27.10.2012 06:48 schrieb Dennis Lee Bieber: > >> I don't know about the more modern calculators, but at least up >> through my HP-41CX, HP calculators didn't do (binary) "floating >> point"... They did a form of BCD with a fixed number of significant >> /decimal/ digits > > Then, what about sqrt(x)**2 or arcsin(sin(x))? Did that always return > the original x? I'd be impressed if it managed the latter, i.e. arcsin(sin(0))==0 while arcsin(sin(pi))==pi ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: a.index(float('nan')) fails
On Thu, Oct 25, 2012 at 9:04 PM, Terry Reedy wrote:
> On 10/25/2012 9:46 PM, mambokn...@gmail.com wrote:
>
> a = [float('nan'), 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> a
>>
>> [nan, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>
> a.index(float('nan'))
>>
>> Traceback (most recent call last):
>>File "", line 1, in
>> ValueError: list.index(x): x not in list
>>
>> That means, the function .index() cannot detect nan values.
>> It happens on both Python 2.6 and Python 3.1
>>
>> Is this a bug? Or I am not using .index() correctly?
>
>
> It is a consequence of the following, which some people (but not all)
> believe is mandated by the IEEE standard.
>
nan = float('nan')
nan is nan
> True
It should be noted, for the record, that "nan is nan" returning True
has nothing to do with the concept of numbers or the IEEE standard and
is purely a consequence that Python runs on hardware with memory
addresses and such.
nan == nan
> False
Here, equality, IS about number and this is appropriate and conforms
to the IEEE standard.
nanlist = [nan]
nan in nanlist
> True
nanlist.index(nan)
> 0
Here you just see an phenomenon with the python object/reference
model, which, being as it is, has nothing to do with numbers. This is
an area which, potentially could be changed in Python without
violating the IEEE standard whatsoever.
Mark
--
http://mail.python.org/mailman/listinfo/python-list
Re: while expression feature proposal
On 10/26/12 19:18, Steven D'Aprano wrote: > def iterate_until_none_or_false(func, *args, **kwargs): > while True: > x = func(*args, **kwargs) > # Halt if x is None or False, but not other falsey values. > if x is None or x is False: > return > yield x > > for x in iterate_until_none_or_false( > some_function, 1, 2, "c", spam="yummy"): > process(x) I was initially a pretty strong advocate of the proposed "as" syntax. However, the more I've thought about it, the more I keep coming back to how I've solved the problem in the past which is mostly what Steven suggests here. There are so many edge-cases and warts in the "as" syntax; most of which disappear with this generator+forloop: - yielding/unpacking multiple results each time: the "as" syntax would get really ugly. Do you test the whole result, or an element of the result? - knowing the stopping condition varies: is it when something is False-ish (an empty string/tuple/list, False, None, etc)? When it "is None"? When it is exactly "False"? - the whole "x = (foo(bar) as result) if result else None" (or should that be "x = result if (foo(bar) as result) else None"?) style/discussion just really looks ugly to me. Usually I find Python code quite beautiful and this syntax doesn't resonate as "beautiful". To despite my previous excitement, I'm now neutral at best on a limited "while TERM as VAR:" syntax. I know this "being persuaded by rational arguments and changing one's mind" thing is rare on the Intarwebs, so I hope I haven't upset the natural balance of things too greatly. :-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes free memory which is allocated in C DLL
On Sun, Oct 28, 2012 at 2:40 AM, Ken Chen wrote: > Yes, I agree writing a corresponding API to free the memory is the best > practice and best bet. > Sometimes, the third party API may not provide that. Then that's a majorly dangerous third party API. The only time it's safe to provide a half-only API like that is when the code gets statically linked with the application, so there's a guarantee that malloc() in one place corresponds to free() in another. > After digging the Python manual again and again. > I finally figure out why windll.msvcrt.free is failing. > > As the manual stated below, the DLL is using another version of msvcrt lib > which is different than the builtin windll.msvcrt. After I explicitly load > the msvcrt which built the DLL, things are getting function now. That's still vulnerable. There's really no guarantee about _anything_ with mismatched memory allocators; it's theoretically possible for compiler switches to change the behaviour of malloc/free such that compiling malloc in debug mode and free in release mode would crash your program. (I don't know off-hand of any compilers/libraries that do that specifically, but there are similar changes done in other ways.) If a DLL allocates memory and doesn't deallocate it, lean on its author to complete the job. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Error compiling python3.2.3: architecture of input file is incompatible
On 27/10/12 16:11:48, Tobias Marquardt wrote: > Hello, > > I am trying to compile Python 3.2.3. > On my 64 bit Ubuntu machine I have no problems but using Ubuntu 32 but I > get the following error: > > /usr/bin/ld: i386:x86-64 architecture of input file > `Parser/tokenizer_pgen.o' is incompatible with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file > `Parser/printgrammar.o' is incompatible with i386 output > /usr/bin/ld: i386:x86-64 architecture of input file `Parser/pgenmain.o' > is incompatible with i386 output > collect2: ld returned 1 exit status > make: *** [Parser/pgen] Error 1 > > As it's the first time for me compiling python by myself, I have no idea > how to solve this. So I'm glad to see any suggestions. It looks like you've copied *.o files from your 64 bit build to your 32 bit box. If that's your problem, then the easiest solution is to delete everything and start over. Alternatively, you could run "make distclean"; that will delete a lot of generated files and then re-run configure. After that, running "make" should work. Hope this helps, -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: Shipping python modules - best practices?
1) IMHO, these should be two distinct steps. You will definitely want to run unit tests without sdist and likewise, I'm sure you'll want to sdist without unit tests. Personally, if I wanted to combine the two, I'd create tasks in a makefile and just run something along the lines of: make unit sdist 2) I don't understand why you'd want to run unit tests during installation. Unit tests are generally used pre-commit to ensure everything's working as expected in your environment and post commit to ensure there are no knock-on effects caused by your changes to the current code base. Running them during installation seems rather strange and useless to me.. 3) Docs are generally stored in a /doc directory at the root of your project. I haven't used pydoc, but if it's anything like sphinx, then best practice is to commit the source for your docs and have the users using the project generate the static content themselves (usually done through a make target). On 2012-10-27, at 7:02 AM, rambius wrote: > Hello, > > I developed some moderate-sized python scripts that I would like to > distribute as python modules. I have never shipped modules before and I read > http://docs.python.org/distutils/index.html. I was able to generate a source > distribution, but I still have some questions. > > 1) My module contains some unit tests in separate scripts. I want to execute > them when I generate the source distribution. How can I do it? > > 2) When I install 3rd party modules, I see some of them executing their unit > tests during the installation. How can I do it? How can I provide an option > to the user to ignore possible test failures? > > 3) I generate some html documentation with pydoc. How shall I distribute it > with the module? > > Thank you very much in advance. > > Regards > rambius > -- > http://mail.python.org/mailman/listinfo/python-list Demian Brecht @demianbrecht http://demianbrecht.github.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Shipping python modules - best practices?
I should also mention that these are just my personal best practices that I've put together during my time working with/on OS projects. You'll almost never find two projects with identical packaging, so really at the end of the day, it's totally up to you and your particular project requirements. On 2012-10-27, at 2:39 PM, Demian Brecht wrote: > 1) IMHO, these should be two distinct steps. You will definitely want to run > unit tests without sdist and likewise, I'm sure you'll want to sdist without > unit tests. Personally, if I wanted to combine the two, I'd create tasks in a > makefile and just run something along the lines of: make unit sdist > > 2) I don't understand why you'd want to run unit tests during installation. > Unit tests are generally used pre-commit to ensure everything's working as > expected in your environment and post commit to ensure there are no knock-on > effects caused by your changes to the current code base. Running them during > installation seems rather strange and useless to me.. > > 3) Docs are generally stored in a /doc directory at the root of your project. > I haven't used pydoc, but if it's anything like sphinx, then best practice is > to commit the source for your docs and have the users using the project > generate the static content themselves (usually done through a make target). > > On 2012-10-27, at 7:02 AM, rambius wrote: Demian Brecht @demianbrecht http://demianbrecht.github.com -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes free memory which is allocated in C DLL
On Sat, 27 Oct 2012 07:42:01 -0700, zlchen.ken wrote: > I have a DLL which written in C language, one of the function is to > allocate a structure, fill the members and then return the pointer of > the structure. > > After Python called this function, and done with the returned structure, > I would like to free the returned structure. How can I achieve this ? > Basically, I tried that I wrote a corresponding free interface in the > DLL, it works, but calling the libc.free in Python doesn't work. > > my_dll.return_structure_ptr.restypes = POINTER(Dummy) res_ptr = > my_dll.return_structure_ptr() windll.msvcrt.free(res_ptr) < doesn't > work, memory violation my_dll.free_dummy_struture(res_ptr) <== This > works. On Windows, a process may have multiple versions of the MSVCRT DLL (which provides malloc/free). If an executable or DLL is linked against multiple DLLs, each DLL could be using a different version of MSVCRT. Different versions of MSVCRT may have separate heaps, so anything which is allocated with malloc() (or calloc() or realloc()) from a specific version of MSVCRT must be passed to free() from the same version of MSVCRT. windll.msvcrt refers to the version of MSVCRT against which the Python DLL is linked, which isn't necessarily the version against which my_dll is linked. If a function in a DLL returns a pointer to memory which it allocated with malloc(), that DLL must also provide a function which can be used to free that memory. It can't leave it to the application (or higher-level DLL) to call free(), because the application may not be using the same version of MSVCRT as the DLL. -- http://mail.python.org/mailman/listinfo/python-list
Re: SSH Connection with Python
On 27Oct2012 14:18, Gelonida N wrote: | On 10/27/2012 02:21 AM, Roy Smith wrote: | > In article , | > Gelonida N wrote: | > | >> Another problem is, that paramiko depends on pycrypto 2.1+ | >> which doesn't exist as binary release for python 2.7 | > | > I'm running paramiko-1.7.6 with python 2.7.3 on my Ubunto Precise box. | > I'm reasonably sure all I did was "pip install paramiko". | | Apologies. I failed to mention, that I was talking about Windows not Linux. | | I use Python for applications, that should work under Linux and under | Windows. | | > But, keep in mind that fabric depends on paramiko. If you can't get | > paramiko installed, you probably can't get fabric either. | > | Thanks, that's good to know, so I don't have to bother looking at farbic | (at least not as solution on windows python 2.7 without having to try to | recompile pycrypto myself) Many years ago we ran an ssh executable on Windows; it was a tiny standalone kit consisting, IIRC, of the Cygwin libc and ssh. Or you could just install Cygwin... That would let you use Python's subprocess module to invoke ssh and dispatch your command. -- Cameron Simpson There is a fine line between idiocy and genius. We aim to erase that line. -- http://mail.python.org/mailman/listinfo/python-list
Re: attaching names to subexpressions
On Oct 28, 5:49 am, Steven D'Aprano wrote: > It's sure as hell more beautiful and readable than assignment as an > expression. > > If we are going to judge code on the ability of people to take a quick > glance and immediately understand it, then pretty much nothing but > trivial one-liners will pass. Certainly assignment as an expression won't: > > while (look_ahead(it) and next(it) or default).strip().lower() as line: > spam(x) > > is easy to miss that it is an assignment to x. *Much* easier than missing > an indented "break". > > > In > > my opinion I shouldn't be obliged to read any of the indented lines of > > the while statement on a first 'visual' pass through somebody elses code > > and still be able to see what the loop iterates through. > > Fine. Then write your code as: > > line = function(x, y, z) > while line: > do something with(line) > line = function(x, y, z) > > > Following looks in my opinion nicer. > > > while complex_expression as line: > > do_something_with(line) > > That's only because you don't actually have a complex expression. Just > writing "complex_expression" doesn't make it complex -- it's actually > trivially simple, a mere rebinding of a name to a name, no more "complex" > than > > while x as y: > ... > > See how easy to read it is! Well duh. But write out an *actual* complex > expression, and the "as name" can easily disappear into the noise. > > Complex expressions are a code smell at least as bad as violating DRY, > and frequently much worse. If the expression is too complex to write > twice, refactor it into a function, *and write tests for the function*. > Otherwise that complex expression is a bug waiting to bite, whether you > write it once or twice. The details of the various syntaxes proposed Ive not fully gone into and I am not discussing. The general notion of having assignments inside expressions would put python into the C bracket I had written about the 'all-hell-breaks-loose' when using C to teach programming: http://www.the-magus.in/Publications/chor.pdf That paper is dated... if C is dated. Otherwise I would request people having this idea to read it. In particular, with respect to this suggestion, heres how things tend to pan out when the language allows assignments inside expressions: You cant really *teach* students to use i=i+1; instead of i++; because its unidiomatic C. And then someone (with no malice just ignorance) writes: i=i++; What does the teacher do? You can simply say: "Dont do that!!" and confuse the students with what exactly is the set of "Dont-dos" (or worse leave them smug that they understand when they dont) Or you can explain why it could increment i or leave it unchanged and so is indeterminate. So I would take the 'muscular' approach -- Show expressions like: i=i++-1; 1. Explain why it could increment, decrement or leave i unchanged 2. Elaborate compilation strategies for each of the above 3. Work out sufficient conditions for the behavior of an expression to be determinate, viz. Variables that are assigned inside an expression, should have only a single occurence, multiply occurring variables should not be assigned. [And assignment means all forms: = += ++ etc) Naturally when students are taught like this, they tend to become cowboys -- learning all kinds of tricks of a narrow and useless sort and ignoring more important aspects of their studies. And if python chooses such a direction its sad (for us teachers) Having said this I need to add: the imperatives of teaching and professional development are not the same. If professional developers feel that adding confusing semantics for the sake of saving lines of code is a benediction... Well... -- http://mail.python.org/mailman/listinfo/python-list
Re: ctypes free memory which is allocated in C DLL
On Sunday, October 28, 2012 6:26:28 AM UTC+8, Nobody wrote: > On Sat, 27 Oct 2012 07:42:01 -0700, zlchen.ken wrote: > > > > > I have a DLL which written in C language, one of the function is to > > > allocate a structure, fill the members and then return the pointer of > > > the structure. > > > > > > After Python called this function, and done with the returned structure, > > > I would like to free the returned structure. How can I achieve this ? > > > Basically, I tried that I wrote a corresponding free interface in the > > > DLL, it works, but calling the libc.free in Python doesn't work. > > > > > > my_dll.return_structure_ptr.restypes = POINTER(Dummy) res_ptr = > > > my_dll.return_structure_ptr() windll.msvcrt.free(res_ptr) < doesn't > > > work, memory violation my_dll.free_dummy_struture(res_ptr) <== This > > > works. > > > > On Windows, a process may have multiple versions of the MSVCRT DLL (which > > provides malloc/free). If an executable or DLL is linked against multiple > > DLLs, each DLL could be using a different version of MSVCRT. > > > > Different versions of MSVCRT may have separate heaps, so anything which > > is allocated with malloc() (or calloc() or realloc()) from a specific > > version of MSVCRT must be passed to free() from the same version of MSVCRT. > > windll.msvcrt refers to the version of MSVCRT against which the Python DLL > > is linked, which isn't necessarily the version against which my_dll is > > linked. > > > > If a function in a DLL returns a pointer to memory which it allocated > > with malloc(), that DLL must also provide a function which can be used to > > free that memory. It can't leave it to the application (or higher-level > > DLL) to call free(), because the application may not be using the same > > version of MSVCRT as the DLL. Thank you for the details. This is really useful! -- http://mail.python.org/mailman/listinfo/python-list
problems with xml parsing (python 3.3)
Hello all,
I am new to Python and have a problem with the behaviour of the xml parser.
Assume we have this xml document:
Title of the first book.
Title of the second book.
If I now check for the text of all 'entry' nodes, the text for the node with
the empty element isn't shown
import xml.etree.ElementTree as ET
tree = ET.ElementTree(file='test.xml')
root = tree.getroot()
resultSet = root.findall(".//entry")
for r in resultSet:
print (r.text)
--
http://mail.python.org/mailman/listinfo/python-list
Re: problems with xml parsing (python 3.3)
To my understanding the empty element is a child of entry as is the text node. Is there anything I am doing wrong here? Any help is appreciated, Fotis -- http://mail.python.org/mailman/listinfo/python-list
Re: problems with xml parsing (python 3.3)
On 2012-10-28 02:27, janni...@gmail.com wrote:
Hello all,
I am new to Python and have a problem with the behaviour of the xml parser.
Assume we have this xml document:
Title of the first book.
Title of the second book.
If I now check for the text of all 'entry' nodes, the text for the node with
the empty element isn't shown
import xml.etree.ElementTree as ET
tree = ET.ElementTree(file='test.xml')
root = tree.getroot()
resultSet = root.findall(".//entry")
for r in resultSet:
print (r.text)
It _is_ shown, it's just that it's all whitespace:
>>> for r in resultSet:
print(ascii(r.text))
'\nTitle of the first book.\n'
'\n'
--
http://mail.python.org/mailman/listinfo/python-list
Re: attaching names to subexpressions
On Sun, Oct 28, 2012 at 4:57 PM, Devin Jeanpierre wrote: > What if he wants to avoid both downsides A and B? What solution does > he use then? He switches to a language whose BDFL is not Steven D'Aprano. :) No offense meant Steven... ChrisA -- http://mail.python.org/mailman/listinfo/python-list
