[Numpy-discussion] Scientific Python at SIAM CSE 2011 conference
Hi all, sorry for the massive cross-post, but since all these projects were highlighted with talks at this event, I figured there would be interest... Hans-Petter Langtangen, Randy LeVeque and I organized a set of Python-focused sessions at the recent SIAM Computational Science and Engineering conference, with talks on numpy/scipy, cython, matplotlib, ipython, sympy, as well as application-oriented talks on astronomy and femhub. For those interested: - The slides: http://fperez.org/events/2011_siam_cse/ - A blog post: http://blog.fperez.org/2011/04/python-goes-to-reno-siam-cse-2011.html - Some pictures: https://picasaweb.google.com/fdo.perez/SIAMCSE2011InReno# Back to being quiet... f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] strange behavior of np.minimum and np.maximum
Hello, a, b, c = np.array([10]), np.array([2]), np.array([7]) min_val = np.minimum(a, b, c) min_val array([2]) max_val = np.maximum(a, b, c) max_val array([10]) min_val array([10]) (I'm using numpy 1.4, and I observed the same behavior with numpy 2.0.0.dev8600 on another machine). I'm quite surprised by this behavior (It took me quite a long time to figure out what was happening in a script of mine that wasn't giving what I expected, because of np.maximum changing the output of np.minimum). Is it a bug, or am I missing something? Cheers, Emmanuelle ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] strange behavior of np.minimum and np.maximum
a, b, c = np.array([10]), np.array([2]), np.array([7]) min_val = np.minimum(a, b, c) min_val array([2]) max_val = np.maximum(a, b, c) max_val array([10]) min_val array([10]) (I'm using numpy 1.4, and I observed the same behavior with numpy 2.0.0.dev8600 on another machine). I'm quite surprised by this behavior (It took me quite a long time to figure out what was happening in a script of mine that wasn't giving what I expected, because of np.maximum changing the output of np.minimum). Is it a bug, or am I missing something? Read the documentation for numpy.minimum and numpy.maximum: they give you element-wise minimum values from two arrays passed as arguments. E.g.: numpy.minimum([1,2,3],[3,2,1]) array([1, 2, 1]) The optional third parameter to numpy.minimum is an out array - an array to place the results into instead of making a new array for that purpose. (This can save time / memory in various cases.) This should therefore be enough to explain the above behavior. (That is, min_val and max_val wind up being just other names for the array 'c', which gets modified in-place by the numpy.minimum and numpy.maximum.) If you want the minimum value of a sequence of arbitrary length, use the python min() function. If you have a numpy array already and you want the minimum (global, or along a particular axis), use the min() method of the array, or numpy.min(arr). Zach ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] strange behavior of np.minimum and np.maximum
Hi Emmanuelle, a, b, c = np.array([10]), np.array([2]), np.array([7]) min_val = np.minimum(a, b, c) min_val array([2]) max_val = np.maximum(a, b, c) max_val array([10]) min_val array([10]) (I'm using numpy 1.4, and I observed the same behavior with numpy 2.0.0.dev8600 on another machine). I'm quite surprised by this behavior (It took me quite a long time to figure out what was happening in a script of mine that wasn't giving what I expected, because of np.maximum changing the output of np.minimum). Is it a bug, or am I missing something? you're just missing that np.minimum/np.maximum are _binary ufuncs_ with syntax np.minimum(X, Y, out=None) i.e. you were telling np.minimum to store it's output in array c and then return min_val, obviously as a reference, not a copy of it. Thus when storing the output of np.maximum in c as well, the contents of c also changed again. Being binary ufuncs, I think you'll have to apply them consecutively if you need the min/max of several arrays. See also np.info(np.minimum) HTH, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] strange behavior of np.minimum and np.maximum
Hi Zach and Derek, thank you very much for your quick and clear answers. Of course the third parameter is the out array, I was just being very stupid! (I had read the documentation though, but somehow it didn't make it to my brain :-) Sorry... Read the documentation for numpy.minimum and numpy.maximum: they give you element-wise minimum values from two arrays passed as arguments. E.g.: numpy.minimum([1,2,3],[3,2,1]) array([1, 2, 1]) The optional third parameter to numpy.minimum is an out array - an array to place the results into instead of making a new array for that purpose. (This can save time / memory in various cases.) Thanks again, Emmanuelle ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Rounding the decimal part of a real number
Dear sir, Is there any function for rounding the real number, for n (say) decimal places: Example: Let X= 6.9867349234888211237767867863478728314... but i need only 4 decimal position. That is the answer should be.. answer=6.9867 -- DILEEPKUMAR. R J R F, IIT DELHI ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rounding the decimal part of a real number
On 4/6/2011 9:14 AM, dileep kunjaai wrote: Is there any function for rounding the real number, for n (say) decimal places: http://www.google.com/search?q=numpy+round produces http://docs.scipy.org/doc/numpy/reference/generated/numpy.round_.html Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2
Sorry to keep harping on this, but for history's sake, I was one of the folks that got 'U' introduced in the first place. I was dealing with a nightmare of unix, mac and dos test files, 'U' was a godsend. On 4/5/11 4:51 PM, Matthew Brett wrote: The difference between 'rt' and 'U' is (this is for my own benefit): For 'rt', a '\r' does not cause a line break - with 'U' - it does. Perhaps semantics, but what 'U' does is actually change any of the line breaks to '\n' -- any line breaking happens after the fact. In Py2, the difference between 'U' and 't' is that 't' assumes that any file read uses the native line endings -- a bad idea, IMHO. Back in the day, Guido argued that text file line ending conversion was the job of file transfer tools. The reality, however, is that users don't always use file transfer tools correctly, nor even understand the implications of line endings. All that being said, mac-style files are pretty rare these days. (though I bet I've got a few still kicking around) Right - my argument is that the behavior implied by 'U' and 't' is conceptually separable. 'U' is for how to do line-breaks, and line-termination translations, 't' is for whether to decode the text or not. In python 3. but 't' and 'U' are the same in python 3 -- there is no distinction. It seems you are arguing that there could/should be a way to translate line termination without decoding the text, but ... In python 3 a binary file is a file which is not decoded, and returns bytes. It still has a concept of a 'line', as defined by line terminators - you can iterate over one, or do .readlines(). I'll take your word for it that it does, but that's not really a binary file then, it's a file that you are assuming is encoded in an ascii-compatible way. While I know that practicality beats purity, we really should be opening the file as a text file (it is text, after all), and specifying utf-8 or latin-1 or something as the encoding. However, IIUC, then the issue here is later on down the line, numpy uses regular old C code, which expects ascii strings. In that case, we could encode the text as ascii, into a bytes object. That's a lot of overhead for line ending translation, so probably not worth it. But if nothing else, we should be clear in the docs that numpy text file reading code is expecting ascii-compatible data. (and it would be nice to get the line-ending translation) Right - so obviously if you open a utf-16 file as binary, terrible things may happen - this was what Pauli was pointing out before. His point was that utf-8 is the standard, but it's not the standard -- it's a common use, but not a standard -- ideally numpy wouldn't enforce any particular encoding (though it could default to one, and utf-8 would be a good choice for that) Once you really make the distiction between text and binary, the concept of a line terminator doesn't really make sense anyway. Well - I was arguing that, given we can iterate over lines in binary files, then there must be the concept of what a line is, in a binary file, and that means that we need the concept of a line terminator. maybe, but that concept is built on a assumption that your file is ascii-compatible (for \n anyway), and you know what they say about assumptions... I realize this is a discussion that would have to happen on the python-dev list... I'm not sure -- I was thinking that python missed something here, but I don't think so anymore. In the unicode world, there is not choice but to be explicit about encodings, and if you do that, then python's text or binary distinction makes sense. .readline() for binary file doesn't, but so be it. Honestly, I've never been sure in this discussion what code actually needs fixing, so I'm done now -- we've talked enough that the issues MUST have been covered by now! -Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.6.0 beta 2
On 4/5/11 10:33 PM, Matthew Brett wrote:
Did you mean to send this just to me? It seems like the whole is
generally interesting and helpful, at least to me...
I did mean to send to the list -- I've done that now.
Well, the current code doesn't split on \r in py3k, admittedly that
must be a rare case.
I guess that's a key question here -- It really *should* split on /r,
but maybe it's rare enough to be unimportant.
The general point about whether to read binary or text is also in
play. I agree with you, reading text sounds like a better idea to
me, but I don't know the performance hit. Pauli had it as reading
binary in the original conversion and was defending that in an earlier
email...
The thing is -- we're talking about parsing text here, so we really are
reading text files, NOT binary files.
So the question really is -- do we want py3's file reading code to
handle encoding issues for us, or do we want to handle them ourselves.
If we only want to support ansi encodings, then handling ourselves may
well be easier and faster performing. If we go that way we need to
handle line-endings, too. The easy way is to only support line endings
with a '\n' in them -- that works out of the box. But it's not that hard
to support 'r' also, depending on how you want to do it. Before 'U'
existed, I did that all the time, something like:
some_text = file.read(some_size_buffer)
some_text.replace('\r\n', '\n')
some_text.replace('\r', '\n')
lines = some_text.split('\n')
(by the way, if you're going to support this, it's really nice to
support mixed line-endings (like this approach does) -- there are a lot
of editors that can make a mess of line endings.
If you can read the entire file into memory at once, this is almost
trivial, if you can't -- there is a bit more bookeeping code to be written.
DARN -- I think I said my last note was the last on this topic!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rounding the decimal part of a real number
On 4/6/11 6:24 AM, Alan G Isaac wrote: http://docs.scipy.org/doc/numpy/reference/generated/numpy.round_.html simple enough, of course, but just to be clear: In [108]: np.round(1.23456789, 3) Out[108]: 1.2351 so the number is rounded to the requested number of decimal places, but then stored in a binary floating point format, which may not be able to exactly represent that rounded number -- hence the 1 at the end. This is simply how floating point works. and that slight difference _probably_ doesn't matter, but it's worth being aware of, because is does make a difference occasionally. python has a decimal type that can work with exact decimal numbers -- numpy doesn't support that, as there is no hardware support for it (at least on most platforms). If you want to display it differently, you can use the string formatters: In [110]: %.3f%np.round(1.23456789, 3) Out[110]: '1.235' HTH, Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installation problem: numpy1.5.1 + python2.7 + virtualenv-1, 5, 1
On Tue, Apr 5, 2011 at 11:17 PM, Vicent Mas uve...@gmail.com wrote:
Hi,
I'm trying to install numpy1.5.1 in a virtual environment (virtualenv-1.5.1)
on my debian testing box. I'm using python 2.7 installed from a debian
package.
This is what I get:
(venv2.7)vmas@rachael$ python setup.py install
Running from numpy source directory.F2PY Version 1
blas_opt_info:
blas_mkl_info:
libraries mkl,vml,guide not found in /usr/lib
NOT AVAILABLE
atlas_blas_threads_info:
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
FOUND:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base']
language = c
include_dirs = ['/usr/include/atlas']
FOUND:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base']
language = c
define_macros = [('ATLAS_INFO', '\\?.?.?\\')]
include_dirs = ['/usr/include/atlas']
lapack_opt_info:
lapack_mkl_info:
mkl_info:
libraries mkl,vml,guide not found in /usr/lib
NOT AVAILABLE
NOT AVAILABLE
atlas_threads_info:
Setting PTATLAS=ATLAS
libraries lapack not found in /usr/lib/atlas-base
numpy.distutils.system_info.atlas_threads_info
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
FOUND:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base/atlas', '/usr/lib/atlas-base']
language = f77
include_dirs = ['/usr/include/atlas']
FOUND:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base/atlas', '/usr/lib/atlas-base']
language = f77
define_macros = [('ATLAS_INFO', '\\?.?.?\\')]
include_dirs = ['/usr/include/atlas']
running install
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands --compiler
options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands --fcompiler
options
running build_src
build_src
building py_modules sources
creating build
creating build/src.linux-i686-2.7
creating build/src.linux-i686-2.7/numpy
creating build/src.linux-i686-2.7/numpy/distutils
building library npymath sources
Traceback (most recent call last):
File setup.py, line 211, in module
setup_package()
File setup.py, line 204, in setup_package
configuration=configuration )
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/core.py,
line 186, in setup
return old_setup(**new_attr)
File /usr/lib/python2.7/distutils/core.py, line 152, in setup
dist.run_commands()
File /usr/lib/python2.7/distutils/dist.py, line 953, in run_commands
self.run_command(cmd)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/install.py,
line 55, in run
r = old_install.run(self)
File /usr/lib/python2.7/distutils/command/install.py, line 601, in run
self.run_command('build')
File /usr/lib/python2.7/distutils/cmd.py, line 326, in run_command
self.distribution.run_command(command)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build.py,
line 37, in run
old_build.run(self)
File /usr/lib/python2.7/distutils/command/build.py, line 128, in run
self.run_command(cmd_name)
File /usr/lib/python2.7/distutils/cmd.py, line 326, in run_command
self.distribution.run_command(command)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 152, in run
self.build_sources()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 163, in build_sources
self.build_library_sources(*libname_info)
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 298, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 385, in generate_sources
source = func(extension, build_dir)
File numpy/core/setup.py, line 681, in get_mathlib_info
st = config_cmd.try_link('int main(void) { return 0;}')
File /usr/lib/python2.7/distutils/command/config.py, line 248, in try_link
self._check_compiler()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/config.py,
line 45, in _check_compiler
old_config._check_compiler(self)
File /usr/lib/python2.7/distutils/command/config.py, line 103, in
_check_compiler
customize_compiler(self.compiler)
File /usr/lib/python2.7/distutils/ccompiler.py, line 44, in
customize_compiler
cpp = cc + -E # not always
TypeError: unsupported operand type(s)
Re: [Numpy-discussion] Installation problem: numpy1.5.1 + python2.7 + virtualenv-1, 5, 1
On Wed, Apr 6, 2011 at 8:08 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Tue, Apr 5, 2011 at 11:17 PM, Vicent Mas uve...@gmail.com wrote:
Hi,
I'm trying to install numpy1.5.1 in a virtual environment (virtualenv-1.5.1)
on my debian testing box. I'm using python 2.7 installed from a debian
package.
This is what I get:
(venv2.7)vmas@rachael$ python setup.py install
Running from numpy source directory.F2PY Version 1
blas_opt_info:
blas_mkl_info:
libraries mkl,vml,guide not found in /usr/lib
NOT AVAILABLE
atlas_blas_threads_info:
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
FOUND:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base']
language = c
include_dirs = ['/usr/include/atlas']
FOUND:
libraries = ['ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base']
language = c
define_macros = [('ATLAS_INFO', '\\?.?.?\\')]
include_dirs = ['/usr/include/atlas']
lapack_opt_info:
lapack_mkl_info:
mkl_info:
libraries mkl,vml,guide not found in /usr/lib
NOT AVAILABLE
NOT AVAILABLE
atlas_threads_info:
Setting PTATLAS=ATLAS
libraries lapack not found in /usr/lib/atlas-base
numpy.distutils.system_info.atlas_threads_info
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
FOUND:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base/atlas', '/usr/lib/atlas-base']
language = f77
include_dirs = ['/usr/include/atlas']
FOUND:
libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas']
library_dirs = ['/usr/lib/atlas-base/atlas', '/usr/lib/atlas-base']
language = f77
define_macros = [('ATLAS_INFO', '\\?.?.?\\')]
include_dirs = ['/usr/include/atlas']
running install
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands --compiler
options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands --fcompiler
options
running build_src
build_src
building py_modules sources
creating build
creating build/src.linux-i686-2.7
creating build/src.linux-i686-2.7/numpy
creating build/src.linux-i686-2.7/numpy/distutils
building library npymath sources
Traceback (most recent call last):
File setup.py, line 211, in module
setup_package()
File setup.py, line 204, in setup_package
configuration=configuration )
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/core.py,
line 186, in setup
return old_setup(**new_attr)
File /usr/lib/python2.7/distutils/core.py, line 152, in setup
dist.run_commands()
File /usr/lib/python2.7/distutils/dist.py, line 953, in run_commands
self.run_command(cmd)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/install.py,
line 55, in run
r = old_install.run(self)
File /usr/lib/python2.7/distutils/command/install.py, line 601, in run
self.run_command('build')
File /usr/lib/python2.7/distutils/cmd.py, line 326, in run_command
self.distribution.run_command(command)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build.py,
line 37, in run
old_build.run(self)
File /usr/lib/python2.7/distutils/command/build.py, line 128, in run
self.run_command(cmd_name)
File /usr/lib/python2.7/distutils/cmd.py, line 326, in run_command
self.distribution.run_command(command)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 152, in run
self.build_sources()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 163, in build_sources
self.build_library_sources(*libname_info)
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 298, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/build_src.py,
line 385, in generate_sources
source = func(extension, build_dir)
File numpy/core/setup.py, line 681, in get_mathlib_info
st = config_cmd.try_link('int main(void) { return 0;}')
File /usr/lib/python2.7/distutils/command/config.py, line 248, in try_link
self._check_compiler()
File
/usr/local/src/ViTables_environ/General/numpy-1.5.1/numpy/distutils/command/config.py,
line 45, in _check_compiler
old_config._check_compiler(self)
File /usr/lib/python2.7/distutils/command/config.py, line 103, in
_check_compiler
customize_compiler(self.compiler)
File /usr/lib/python2.7/distutils/ccompiler.py, line 44, in
customize_compiler
Re: [Numpy-discussion] Installation problem: numpy1.5.1 + python2.7 + virtualenv-1, 5, 1
On 2011-04-05 Vicent Mas uve...@gmail.com said:
Hi,
I'm trying to install numpy1.5.1 in a virtual environment
(virtualenv-1.5.1) on my debian testing box. I'm using python 2.7
installed from a debian package.
[...]
Doing the same with python2.6 (also from debian package) works just fine.
Could somebody tell me what am I doing wrong? Thanks.
FYI,
it seems that python2.7 packaged by debian is not fully compatible with
virtualenv-1.5.1. The following changes in /usr/lib/python2.7/sysconfig.py
fix the problem:
vmas@rachael$ diff -u /usr/lib/python2.7/sysconfig.py /tmp/sysconfig.py
--- /usr/lib/python2.7/sysconfig.py 2011-04-06 20:51:00.0 +0200
+++ /tmp/sysconfig.py 2011-04-06 20:47:12.0 +0200
@@ -294,7 +294,7 @@
def _get_makefile_filename():
if _PYTHON_BUILD:
return os.path.join(_PROJECT_BASE, Makefile)
-return os.path.join(get_path('platstdlib').replace(/local,,1),
config + (sys.pydebug and _d or ), Makefile)
+return os.path.join(get_path('platstdlib').replace(/usr/local,/usr,1),
config + (sys.pydebug and _d or ), Makefile)
def _init_posix(vars):
@@ -394,7 +394,7 @@
else:
inc_dir = _PROJECT_BASE
else:
-inc_dir = get_path('platinclude').replace(/local,,1)+(sys.pydebug
and _d or )
+inc_dir =
get_path('platinclude').replace(/usr/local,/usr,1)+(sys.pydebug and _d or
)
return os.path.join(inc_dir, 'pyconfig.h')
def get_scheme_names():
I suppose these changes can create other problems sooner or later so they are
not a fully satisfactory solution, just a workaround to this specific problem.
If someone has a better solution please, tell me.
Vicent
::
Share what you know, learn what you don't
signature.asc
Description: This is a digitally signed message part.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Uninstallation of 1.6.0b2 leaves files behind with Python3.x under windows 7
Hi, I tend to get files left behind for 32-bit versions of Python 3.1 and Python3.2 usually after I have ran the tests and then immediately try to uninstall it using the Windows uninstaller via control panel. With Python 3.1 files are left behind have the '.pyd' suffix: C:\Python31\Lib\site-packages\numpy\linalg\lapack_lite.pyd C:\Python31\Lib\site-packages\numpy\fft\fftpack_lite.pyd With Python 3.2, most are in the __pycache__ directories. I do not see these __pycache__ directories with Python3.1 binary installer. Also can people with Windows check that ticket 144 (Uninstall in Windows does not remove some directories) is still valid? http://projects.scipy.org/numpy/ticket/1466 I do not see this with the Python 2.x - I think... Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Uninstallation of 1.6.0b2 leaves files behind with Python3.x under windows 7
On Thu, Apr 7, 2011 at 11:01 AM, Bruce Southey bsout...@gmail.com wrote: Hi, I tend to get files left behind for 32-bit versions of Python 3.1 and Python3.2 usually after I have ran the tests and then immediately try to uninstall it using the Windows uninstaller via control panel. With Python 3.1 files are left behind have the '.pyd' suffix: C:\Python31\Lib\site-packages\numpy\linalg\lapack_lite.pyd C:\Python31\Lib\site-packages\numpy\fft\fftpack_lite.pyd With Python 3.2, most are in the __pycache__ directories. I do not see these __pycache__ directories with Python3.1 binary installer. __pycache__ is a feature added in python 3.2 to my knowledge: http://www.python.org/dev/peps/pep-3147 cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
