Warnings in Python and Anaconda

It seems as if Python developers are having more than a few problems at the moment from a number of sources. I recently wrote about the potential issues for readers of Beginning Programming with Python For Dummies and Python for Data Science for Dummies from Windows 10 (Python and Windows 10). However, some readers have come back afterward to say they’re still seeing warnings. It wasn’t until one of the beta readers for Machine Learning for Dummies also saw some of these warnings that it became apparent that some other problem is at work. A recent upgrade to NumPy 1.10.1 has created these warnings. You can see some message threads about the issue at:

The important thing to remember is that you’ll see warnings, not errors (unless there is a problem Luca, my coauthor for Python for Data Science for Dummies, and I haven’t seen yet). For now, updating all of the Anaconda components is the only way to actually get rid of the warnings, which can prove to be quite a pain. However, the warnings are just that, warnings. The code in the books will still run just fine. The best way to avoid a lot of work and potentially creating yet more problems is to ignore the warnings for now. In order to ignore the warnings, type the following two lines of code:

import warnings
warnings.simplefilter("ignore")

Obviously, the situation is inconvenient for everyone, but the various libraries will get in sync sometime soon and then the warnings will disappear until the next set of updates. Please let me know if you continue to see problems after making this fix at John@JohnMuellerBooks.com.

 

NumPy and SciPy Update

As books age, some of the resources used to create them get abandoned or simply don’t work right. Such is the case with Professional IronPython. There has been an ongoing conversation about NumPy and SciPy support for the product. In fact, you’ll find the first signs of trouble in my NumPy and SciPy Support in IronPython 2.7 post, followed by an update in NumPy and SciPy Support in IronPython 2.7 – An Update. At the time I uploaded those posts, Enthought was still engaged in producing a NumPy and SciPy library for IronPython. Recently, a reader notified me that the support is no longer available from Enthought—a problem that I’ve since verified.

Of course, my posts alerted to you issues with the Enthought library and things have only gotten worse from what I understand. As a result, I can’t even recommend you download and try the Enthought library an longer, unless you’re running an older version of IronPython and just happen to find a compatible version. There is a version on the SciPy site. However, when you review the FAQ on this site, you see this information related to .NET installations:

Does NumPy/SciPy work with IronPython (.NET)?

Some users have reported success in using NumPy with Ironclad on 32-bit Windows. The current status of Ironclad support for SciPy is unknown, but there are several complicating factors (namely the Fortran compiler situation on Windows) that make it less feasible than NumPy.

So, the chances of the SciPy installation working are relatively small. There are some additional sites you could try, but given that I haven’t actually tried them myself, I can’t guarantee success. Please contact the site owners if you have questions about their software. With this caveat in mind, you can try these locations:

If someone has actually tried these extensions and used them successfully, I’d really like to hear from them. It would be nice to have a working solution for the book. In the meantime, there is a message thread at https://mail.python.org/pipermail/ironpython-users/2014-May/017067.html that could provide helpful information about the situation. Anyone with book-specific questions should feel free to contact me at John@JohnMuellerBooks.com.

 

NumPy and SciPy Support in IronPython 2.7 – An Update

Since I last wrote about NumPy and SciPy support in IronPython (see the NumPy and SciPy Support in IronPython 2.7 post), I’ve received some additional e-mails from readers on the topic. It turns out that there are some twists and turns to this support issue. Some readers have noted that the use of ironpkg-1.0.0.py file from Enthought actually causes problems with the Visual Studio IDE. You may very well see an assertion error. The error shows up when you attempt to type clr.AddReference(. As soon as you type the (, the IDE displays the assertion error. I haven’t personally experienced the error, but you can find discussions of it at http://pytools.codeplex.com/discussions/349615 and http://pytools.codeplex.com/workitem/656 (amongst other locations).

The issue is that the NumPy and SciPy support is strongly compiled to use a specific version of the IronPython libraries. In fact, a few authors have gone on to suggest that you use the version of IronPython supplied by Enthought, which seems like a good idea to me. I’m using IronPython 2.7.3 downloaded directly from the Codeplex site without any problem. For the time being, I’ll continue to use this version for your support questions so that I can provide the best possible information. If you encounter problems using this version, you may have to download the Enthought-specific version of IronPython to ensure NumPy and SciPy support works (or go without these libraries).

Simply installing the Enthought version of IronPython won’t be enough to fix the problem, unfortunately. You must remove the NumPy and SciPy library files completely using the ironpkg –remove command (specifically ironpkg scipy –remove in this case). You must then uninstall the copy
of IronPython that caused the error, which includes physically removing
the folder that contains the IronPython files. After you remove everything, restart Visual Studio to ensure that your IDE is working properly. Then you can install the Enthought version of IronPython and reinstall the NumPy and SciPy libraries. Following this procedure should fix the assertion error if you’re experiencing it.

I’ve been told that there will eventually be a fix for this problem, but when you think about it, the fix can’t be complete using the current programming strategy because you’re relying on low level routines to perform a specific task. Remember that you must start your application using the -X:Frames switch or you’ll most definitely run into problems. Let me know if you encounter any other issues with this particular issue at John@JohnMuellerBooks.com.

 

A Common IronPython References Error

I’ve been encountering a common error when answering reader emails for Professional IronPython. The problem is compounded by the fact that the error messages readers receive vary and there seems to be little consistency in the way Visual Studio reacts to the error. When making references to a .NET assembly in IronPython, you must include the .DLL extension. Otherwise, the IDE is going to give you a very odd error message nearly every time. For example, if you want to reference the System.Drawing assembly, you’d use the AddReference() method like this:

import clr
clr.AddReference('System.Drawing.DLL')

When working with the book, Chapter 7 tells how to interact with the .NET Framework. In fact, you can find the procedure for importing a CLR assembly on page 125. In addition to importing clr, you also need to provide a path for finding the assemblies as shown in the example code.  Chapter 8, page 143, shows a simple example of a Windows Forms application. Most readers find the code in Listing 8-1 really helpful.

Making matters worse, some readers have told me that they have been able to make applications work without including the .DLL part of the file name, but I’m finding including the whole file name works better. These odd errors are a concern for me, so please let me know if you continue to experience problems with IronPython, Python Tools for Visual Studio (PTVS), or the use of NumPy and SciPy at John@JohnMuellerBooks.com. I’ll try to reproduce the error on my system so that I can troubleshoot it with greater ease. If I can’t reproduce the error, I’ll likely need some additional input and testing from you.

 

NumPy and SciPy Support in IronPython 2.7

On page 434 of the English version of Professional IronPython, I talk about some much needed CPython additions to IronPython. Two of these additions are the Numerical Python (NumPy) and Scientific Python (SciPy) packages. You use these two packages in tandem to perform scientific numeric computations. In other words, a lot of people use these packages to perform heavy duty math. At the time of writing, you needed to obtain a copy of the IronClad product (discussed on page 437) to make the packages work. That’s because IronPython has trouble supporting some CPython packages.

Recently, a reader mentioned that he was having trouble obtaining a copy of the required IronClad product for IronPython 2.7. A quick search didn’t point out any potential solutions to the problem. Of course, you can always continue to use IronPython 2.6 for development purposes, but then you lose out on all the great new features in IronPython 2.7 (see IronPython 2.7 and PTVS and IronPython 2.7.1 Update). To make things a little more complicated, there is a new IronPython 2.7.3 release to consider as part of this question.

I did quite a bit of research about this issue. IronClad is definitely aware of the problem because people have been writing them about it. A second solution that entails using a product from Enthought doesn’t work because the required download is missing. I currently have e-mails in to Enthought and hope that I receive a response that I can pass along. In short, the bad news is that you can’t use NumPy and SciPy with IronPython 2.7 for now, but there should be a solution available. More than a few people have said they were able to get the Enthought solution to work—all we need is the Enthought solution to become available.

Even though the binaries are missing, I did manage to find source files at https://github.com/ilanschnell/ironpkg. The only problem is that I know nothing at all about these source files or how to build them into something you can use with .NET. The README.txt file does make it clear that these are the correct files. (Interestingly enough, I found the required egg files at http://www.enthought.com/repo/.iron/eggs/, so most of the support seems to be there.)

I have found one bit of useful information about employing this solution, you need to use it with the -X:Frames command line switch. The Enthought documentation doesn’t make this very clear and some users have encountered problems making the solution work. If you find out where we can locate the missing ironpkg-1.0.0.py file, please let me know at John@JohnMuellerBooks.com.


Breaking news update! I’ve just tried downloading the ironpkg-1.0.0.py file from Enthought and it now works as anticipated. If you need NymPy and SciPy support in IronPython 2.7, please use the Enthought solution. Make sure you follow the directions precisely, including the need to use the -X:Frames command line switch. I found that I did need to import SciPy once inside the interactive environment, rather than at the command line as suggested on the Enthought site, but that could be a problem with my system. Contact me at John@JohnMuellerBooks.com with the result of any programming you do, but as far as I can tell, this solution now works as anticipated.