We Keep Coding

What is "Pure Python?"

Many questions on Stack Overflow refer to "Pure Python" (some random examples from the "similar questions" list: 1, 2, 3, 4, 5, 6, 7, 8,
9,
10,
11).
I also encounter the concept elsewhere on the web, e.g. in the package documentation for imageio and in tutorials such as "An introduction to Pure Python".
This has led me to believe there must be some universally accepted standard definition of what "Pure Python" is.
However, despite googling to the limits of my ability, I have not yet been able to locate this definition.
Is there a universally accepted definition of "Pure Python," or is this just some elusive concept that means different things to different people?
To be clear, I am asking: Does such a definition exist, yes or no, and if so, what is the acclaimed source? Although I truly appreciate all comments and answers, I am not looking for personal interpretations.

In that imageio package, they mean it's all implemented in Python, and not (as is sometimes done) with parts written in C or other languages. As a result it's guaranteed to work on any system that Python works on.
In that tutorial, it means the Python you get when you download and install Python -- the language and the standard libraries, not any external modules. The chapter after that adds some external libraries, like numpy and scipy, that are used a lot but aren't part of the standard library.
So they mean different things there already.

A "pure-Python" package is a package that only contains Python code, and doesn't include, say, C extensions or code in other languages. You only need a Python interpreter and the Python Standard Library to run a pure-Python package, and it doesn't matter what your OS or platform is.
Pure-Python packages can import or depend on non-pure-Python packages:
Package X contains only Python code and is a pure-Python package.
Package Y contains Python and C code and isn't a pure-Python package.
Package Z imports Package Y, but Package Z is still a pure-Python package.
A good rule of thumb: If you can make a source distribution ("sdist") of your package and it doesn't include any non-Python code, it is a pure-Python package.
Pure-Python packages aren't restricted to just the Python Standard Library; packages can import modules from outside the Python Standard Library and still be considered pure-Python.
Additionally, a standalone module is a single .py file that only imports modules from the Python Standard Library. A standalone module is necessarily a pure-Python module.
Note that in Python, package technically refers to a folder with an __init__.py file in it. The things you download and install from PyPI with pip are distributions (such as "source distribution" or "sdist"), though the term "package" is also used as a synonym with "distribution", since that term could be confused with the "Linux distro" usage of the word.
Is there an official definition for "pure-Python"? As of this writing, no, though the Python Packaging User Guide makes heavy use of the term in https://packaging.python.org/overview/

Unfortunately, it seems there is no standardized, formalized definition.
As a programmer in Python for almost 2 decades, my definition of pure Python is: a Python package that implements the core logic only in Pythonic statements that only require pure python or native packages. This is a recursive statement, so at the far end of your packages dependency tree, you end up with python packages that only require native python libraries/functions. With this approach, the whole chain of code logic that allows for the main objective of the tool to be accomplished can be read and modified only using Python, and no other programming language nor tool besides the CPython interpreter.
This can't be overstated: "pure Python" is more defined as an objective -- of being entirely readable and modifiable in the Python language --, rather than a state. It's very similar to what the sibling language Julia is trying to do but by generalizing the procedure down to the interpreter, which is written in the Julia language itself. You can say that Julia is "pure" by design, whereas CPython is not (because the CPython interpreter is compiled in C++), but you can still write "pure Python" packages, just like you can write "pure PHP" or "pure Ruby" packages that do not require the use of any package written in another language at any point of the program's logic.

How we can import/use python 3.4 installed library in python2.7?

I need to use one python library which is available only in 3.4 but my framework runs on python version 2.7 and i want to use that lib to build
extension search a lot but found very less info about forward compatibility.
checked lib called future but didn't get much info on docs.python.
anyone has any clue then please share.

Generally speaking, module that are provided for python >3 are absolutely not compatible with python 2. The special future import allows to create a module that is compatible by importing into python 2 some of the behaviors of python 3 that would otherwise be breaking, such as the division.
So most of the time, there is no simple way to import a 3.x module in 2.x, sorry

Documentation for gnomekeyring Python lib

Is there a documentation for Python 'gnomekeyring' lib somewhere in the Web?

There is the reference for the C library which the Python package uses. Most function names are identical (except for the "gnome_keyring_" prefix). The Bending Gnome Keyring with Python blog series should give you a good start as well.
And as the keyring package was already mentioned: If I remember correctly, that package supports gnome-keyring as a backend, so you can look at its source code to find out how to use gnome-keyring.

Apparently not. But this one is documented, maybe that's an option?
http://pypi.python.org/pypi/keyring
If not, maybe you can figure out how to use gnomekeyring from reading the source of keyring. :)

using cython to port modules to python 3.1

Is it possible to import arbitrary modules in cython, compile them to shared object files and then use them in python 3.1?
The reason for this is, that I am writing an extension for the program "blender", which has an internal python 3.1 interpreter. But i would also like to make use of some python-modules which are not ported to 3.x, yet
I have specifically numpy in my mind (but also some other libraries). I have a module, which makes use of numpy. As I want to redistribute that module, I don't want poeple to install numpy on their machines. would that work?

In principle, I believe it's possible. Cython works by translating Python-like code to C code. That code can be compiled for either Python 2 or Python 3 (it uses C preprocessor statements to change which code is used).
The bad news is that it will only work for extensions written in Python-like code that Cython can translate. You can't use Cython on extensions written in C, like Numpy.
The good news is that, at least for Numpy, you shouldn't have to. Since version 1.5, Numpy supports Python 3. There's a binary available for Windows; on other systems, you might have to work out how to compile the code yourself.

Check your Python documentation, the section "Python/C API Reference Manual" describes in detail how to do it.
EDITED:
So what you want is porting a 2.x lib to 3.x. That's a big work to do.
If the solution your wished exists. Python 2.x should have been eliminated by now.
Sure there is a 2to3 tool. But a Python lib written by C is not applicable in this way.
So, you may follow the instruction in the "Python/C API Reference Manual" to port the lib to 3.x or just wait.

Python bindings for libparted?

I'm looking for a way to interact with the GNU libparted library from Python, but so far what I've found, a GSOC project from 2005 and an Ubuntu/debian package that's been dropped from the archive, have been disheartening.
Is there something I'm missing, or should I just get used to manipulating libparted from the command line / trying to fix the bitrot that's occurred in the other packages?

You mean like the pyparted library?

The reason debian dropped the package is lack of a maintainer. If you are willing (and able) to maintain the existing package and become their maintainer that would be a great contribution to FOSS.

You can try using SIP to generate a Python binding for it. It works for QT so it may work for libparted.

Old thread, but you can also checkout reparted, it's a ctypes python binding.