Group items tagged

PyScripter is a free and open-source Python Integrated Development Environment (IDE) created with the ambition to become competitive in functionality with commercial Windows-based IDEs available for other languages. Being built in a compiled language is rather snappier than some of the other Python IDEs and provides an extensive blend of features that make it a productive Python development environment. 

interpreter:>>>import matplotlib>>>matplotlib.interactive(True)>>>matplotlib.use("WXAgg")>>>from matplotlib.pylab import *>>>plot([1,2,3])>>>xlabel('time (s)') 

PyScripter is a free and open-source Python Integrated Development Environment (IDE) created with the ambition to become competitive in functionality with commercial Windows-based IDEs available for other languages. Being built in a compiled language is rather snappier than some of the other Python IDEs and provides an extensive blend of features that make it a productive Python development environment.

in PyCrypto: >>> key = os.urandom(16) # Generate 16 random bytes (128 bits) >>> bin_to_hex(key) # Show the key in hex (32 characters) '61aa60e43a5e7fdb4b86a4897b52a0dc' >>> y = RFC1751.key_to_english(key) >>> y # Show the pass phrase version of the key 'BUSY BARN RUB DOLE TAUT TOOK ALTO PRY KIT WALL MUG CURT' >>> # The transformation is always reversible >>> bin_to_hex(RFC1751.english_to_key(y)) '61aa60e43a5e7fdb4b86a4897b52a0dc'

Human-Readable Encryption Keys

This is something I always forget how to do, and it's kind of hard to Google or search the Python docs because you can't search for **.The point is, when using **kwargs, you have to use the ** prefix not only in the function definition, but also in the call, prefixed to the variable you want to use as a keyword dictionary.

There are two applications that require using the NumPy array type in C extension modules: Access to numerical libraries: Extension modules can be used to make numerical libraries written in C (or languages linkable to C, such as Fortran) accessible to Python programs. The NumPy array type has the advantage of using the same data layout as arrays in C and Fortran. Mixed-language numerical code: In most numerical applications, only a small part of the total code is CPU time intensive. Only this part should thus be written in C, the rest can be written in Python. NumPy arrays are important for the interface between these two parts, because they provide equally simple access to their contents from Python and from C. This document is a tutorial for using NumPy arrays in C extensions.

> Is there a way to find the number of processors on a machine (on linux/ > windows/macos/cygwin) using python code (using the same code/cross > platform code)? From processing <http://cheeseshop.python.org/pypi/processing/0.34> : def cpuCount():     '''     Returns the number of CPUs in the system     '''     if sys.platform == 'win32':         try:             num = int(os.environ['NUMBER_OF_PROCESSORS'])         except (ValueError, KeyError):             pass     elif sys.platform == 'darwin':         try:             num = int(os.popen('sysctl -n hw.ncpu').read())         except ValueError:             pass     else:         try:             num = os.sysconf('SC_NPROCESSORS_ONLN')         except (ValueError, OSError, AttributeError):             pass     if num >= 1:         return num     else:         raise NotImplementedError --

 > According to the fact that all Thread run on the same CPU (if i didn't  > understand wrong), i'm asking if python will suffer from the future  > multicore CPU. Will not python use only one core, then a half or a  > quarter of CPU ? It could be a serious problem for the future of python... I agree that it could potentially be a serious hindrance for cpython if "multiple core" CPUs become commonplace. This is in contrast to jython and ironpython, both of which support multiple-cpu parallelism. Although I completely accept the usual arguments offered in defense of the GIL, i.e. that it isn't a problem in the great majority of use cases, I think that position will become more difficult to defend as desktop CPUs sprout more and more execution pipelines. I think that this also fits in with AM Kuchling's recent musing/thesis/prediction that the existing cpython VM may no longer be in use in 5 years, and that it may be superceded by python "interpreters" running on top of other VMs, namely the JVM, the CLR, Smalltalk VM, Parrot, etc, etc, etc. http://www.amk.ca/diary/archives/cat_python.html#003382 I too agree with Andrew's basic position: the Python language needs a period of library consolidation. There is so much duplication of functionality out there, with the situation only getting worse as people re-invent the wheel yet again using newer features such generators, gen-exps and decorators.