Just wondering if this is even possible. If so, are there any practical reasons not to?
Yes, it is possible. A cryptocurrency is essentially a set of rules and network protocols that nodes can use to talk to one another to implement those rules. The reference implementation Bitcoin-Qt is implemented in C++, but there are other implementations (eg. Java).
The tricky part about implementing a client for an existing cryptocurrency in another programming language is that you must be careful to implement the rules in exactly the same way as all other implementations. If there are any changes (even such as fixing bugs present in the original) then the blockchain may fork and your client would need a patch to continue participating.
If you're creating a new cryptocurrency from scratch, of course you don't need to be concerned with replicating bugs in an existing client. However, you run the risk of introducing a whole new set of bugs.
Yes it is completely possible. Bitcoin is not using any special features in the C++ program that aren't possible in other programs. If your programming language can do the following you are good to go. Although I suspect any programming language will pass this test.
- Ability to communicate with other computers over a network
- Ability to store data
- Ability to do basic math as well as advanced math needed for cryptographic functions
If you mean the bitcoin's scripting language (https://en.bitcoin.it/wiki/Script), again, yes, it could be anything you want. If you were going to replace bitcoin's scripts with a turing complete language, there's some risk you need to address. Here's a list of some potential attacks to the network abusing turing completeness:
Most of Bitcoin's script operation are actually "disabled" for security reasons and re-enabling them would probably require a softfork or even a hardfork.
Aside from that, there's many reasons why you would want the scripting language to be very simple, because you want all the different implementations of the script interpreter to behave in exactly the same way, even optimized interpreters.
Here's a couple of critical requirements for a language:
"b. The script must be simple, as thousands of nodes world-wide running multiple implementations will need to reach global consensus over not just the outcome of a script, but also some aspects of the execution (e.g. an instruction counter). Consensus failures whether due to bugs or faulty designs can lead to unsecured payment networks and possible losses in the millions of dollars or more. Interpreter escape would be absolutely catastrophic. So simple, minimal, but expressive architectures with simple fail-safe implementations are to be preferred over complex but user-friendly (RISC is better than CISC).
c. The language must support the various cryptographic primitives necessary for performing core bitcoin functions. Mostly this just means adding a handful of builtin words for performing strong cryptographic hashes and elliptic curve signature verification, but there are some requirements on the language design as well, chiefly in making decisions about how the stack is represented for hash operations and in supporting authenticated data structures as primitive types for external state."
Basically, it would be a bad idea to use directly a language as powerful as python for the scripting, but you could have a more simple language, let's call it secureScript and build a compiler from python to secureScript.