Earlier quoted context omitted.
By volume numpy is mostly assembler written to the Fortran ABI (it's a LAPACK/BLAS-etc wrapper).
Are you sure you aren't mistaking numpy for scipy?
numpy is the foundation of scipy.
Grumpy: Go running Python
371–380 of 463 posts
Re: Grumpy: Go running Python
#372Earlier quoted context omitted.
So is it just a time issue, or are there compatibility reasons for why not all of you code is Python 3? I ask because I started to learn to code with Python 2 because that's what was preloaded on my system. Is one over the other a big enough deal at a beginner level that I should switch to 3 now? How much of a learning curve am I in for?
> Is one over the other a big enough deal at a beginner level No, at a beginner level it's not, there are many guides that explain the differences at a beginner level, and you can go through those in a few hours at most, for example http://python-future.org/compatible_idioms.html But, if you start working now on a Python 2 project and that project starts growing significantly, then it will be hard to convert the code…
For me, the hardest part was migrating from Python 2 string to Python 3 Unicode string. But at the same time, this was a huge improvement for my code base because I work with several languages and unicode makes that much easier/safer. So it was a good thing.
Now the rest of upgrades were a bit painful (I was using some functional programming stuff, httprequest libraries, etc.)
Re: Grumpy: Go running Python
#373Earlier quoted context omitted.
That sounds like the kind of issue you'd have with any reimplementation of CPython though. It sounds like Grumpy doesn't support quite a few things, so I still wonder how they compare and why developing a new runtime was considered easier than reusing Jython.
There might be a strategic element: Jython development has been erratic throughout the years.
Google's own projects have been developed erratically throughout the years. They could have simply forked it.
Re: Grumpy: Go running Python
#374Earlier quoted context omitted.
The reference [1] is a decent spec. It might not be as formally rigorous as an ISO standard, but it's probably as good as Go's [2], which also a "reference". [1] https://docs.python.org/3/reference/index.html [2] https://golang.org/ref/spec
In my experience with both languages, while the Go spec is incredibly readable, navigable, and succinct, the Python reference is a sprawling mess that is difficult to navigate or even to Ctrl-F in.
To be fair, Go is also a much smaller language, which hasn't gone through the process of collecting and shedding multiple layers of legacy, and exposes far fewer implementation details.
Re: Grumpy: Go running Python
#375Earlier quoted context omitted.
> Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them. Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.
Scala, Clojure, F# also allow it, with the added benefit of industrial strength JIT/AOT compilers.
Except without the great Python ecosystem and without great projects like Numpy/Scipy
Re: Grumpy: Go running Python
#376Earlier quoted context omitted.
That's top-down change from the PSF/core dev team and some major library developers added dual 2/3 support. The users never arrived and it'll be 10 years Python3 has been available next December. I'd like to unify Python again but we as users didn't break it either. 10 years any reasonable person in charge would hang it up or change course. Grumpy is pretty much what most everyone would actually want out of a new Pyt…
> some major library developers added dual 2/3 support > The users never arrived That's the way it used to be a few years ago - it changed a lot the last few years. Pretty much all libraries are ported and many new libraries are Python 3-only. asyncio is nice . All Python devs I personally know moved to Python 3. Porting is a lot less painful than it used to be.
Python 3 is largely cross-compatible with Python 2. If you're not working with unicode, not reliant on perfect floating point division, and not using aysncio, then chances are what you produce will work just fine on Python 2.
Re: Grumpy: Go running Python
#377Earlier quoted context omitted.
Those can be built into Grumpy if anyone cares to do so. You don't need Python3 for that stuff. Someone, one developer, recently released a Python 2.8 that backported almost every new Python3 feature. I'm hoping it becomes a permanent fork of Python2 that uses the Go runtime. That would really be great and exactly what they've got now.
If you backport every new Python3 feature to Python2, it becomes Python3, by definition.
It could become Python 2.8, wherein the standard library has both the legacy versions and the new versions, and any cross-compatible syntax is allowed.
This leaves us with more than 1 way to do things, like meta-class declaration.
There's a lot in Python 3 where changes were made to the syntax for 'clarity', but those worts weren't removed for any technical reason but because of the thought that since backwards compatability was being broken anyways, then we might as well get the most bang for our buck.
Re: Grumpy: Go running Python
#378- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. - It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make all of Python's self modification at run-time features work, complicating PyPy enormously. Nobody uses that stuff in production code,…
> - It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make all of Python's self modification at run-time features work, complicating PyPy enormously. Nobody uses that stuff in production code, and Google apparently dumped it. Does it really imply many restrictions? Common Lisp, for exampl…
> ~20 years.
Common Lisp was designed for interpretation and compilation from day one. The first implementations from 1984/85 had already compilers.
> Common Lisp, for example, is probably more dynamic than Python
Some parts are more dynamic than Python, some not. For example everything that uses CLOS+MOP is probably more dynamic. Also some stuff one can do when using a Lisp interpreter may be more dynamic. CL is more static, where one uses non-extensible functions, type declarations, static compilation, inlining, ... The parts where a CL compiler achieves good runtime speed may not be very 'dynamic' anymore.
Re: Grumpy: Go running Python
#379Earlier quoted context omitted.
Is there not a single namedtuple in the entire Google codebase? That's strange :o
There are some defined in built-in modules. Even in Python 2.7, where sys.version_info is a namedtuple.
Yeah, one of the motivations for adding namedtuple to stdlib was a drop-in compatible upgrade of existing interfaces returning tuples.
Notable atrocities included `time.localtime()` returning a 9-tuple, and `os.stat()` returning a 10-tuple...
Re: Grumpy: Go running Python
#380Earlier quoted context omitted.
In Python, you can get at a variable, or even code, in another thread with "getattr()". You can monkey-patch another thread while it is running. This is not very useful, but it's easy to implement in a naive interpreter such as CPython. Part of the price for this is the Global Interpreter Lock, so you don't really have two threads running at once. PyPy has a huge amount of machinery so that stuff will work. Grumpy do…
> That's a good thing. If you restrict Python a little, it's much easier to compile. Isn't that more or less what RPython does? https://rpython.readthedocs.io/en/latest/architecture.html I mean, I know that starting with a full-fledged(?) Py27 codebase rules out _actually_ using RPython for the stated goals of Grumpy, but I think the two projects agree in principle and differ about the definition of "restricted" :-)
RPython is a restricted (hence R) language specifically for VM development, it is not a general-purpose language.