Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Test for lists in Cython

github.com

Post reply on HN
Print view View original

101–110 of 147 posts

Re: Test for lists in Cython

#101

Post by ZeroCool2u »

galangalalgol wrote: post #76
ZeroCool2u wrote: post #56

Earlier quoted context omitted.

Frankly, Julia is a young language, so these things have yet to materialize. Also, for those that really do want it, the Julia package mirror is one of the few products that the company behind Julia sells as part of JuliaHub. It is inconvenient though that it doesn't fit in with the rest of the languages in Nexus.

Isn't julia hub still remote? You can't install it on an airgap or behindnyour firewall on your own equipment can you?

I'm not sure honestly. We didn't end up buying it, because so few people use Julia in our org. Too much legacy matlab code and the professors in academia have yet to switch over.

Re: Test for lists in Cython

#102

Post by duckerude »

nostoc wrote: post #81
leephillips wrote: post #67

Earlier quoted context omitted.

Those who are attached to the class-based OOP model used, for example, in Python will find the dot notation more natural. But Julia’s multiple dispatch is a superset of this, and unarguably more powerful and flexible. Python OOP leads to monstrosities like >>> ', '.join(['1', '2', '3']) '1, 2, 3' >>> '1, 2, 3'.split(', ') ['1', '2', '3']

That's not a failure of OOP, but a failure of design. This could have easily been avoided if `join` would have been a method of the list object, not the string object. But we're stuck with this now.

If join were a method on lists then you wouldn't be able to use it with other iterables. Putting it on str is more useful, if more confusing.

Maybe it would be better as a standalone function. But then you'd either have to import it or it would pollute the global namespace.

Other OOP models offer different solutions.

Re: Test for lists in Cython

#103

Post by deetsb »

leephillips wrote: post #87
deetsb wrote: post #77

Earlier quoted context omitted.

As I’m clearly missing the bigger picture, what do you find to be super offensive about this? I read the first as the concat symbol applied to an iterable leads to string concated by the concat symbol. I read the second as an iterable broken by split symbol leads to an iterable of the chunks.

It’s hard to remember what order to put things in, because the two methods follow opposite conventions. And that’s because this type of OO design has no obvious method of organization. In the first case, I want to do something to a list: join it into a string. So, clearly, I need a list method? But no, I need to engage in some form of indirection; for some reason, I need to reach for a string method. Even if there is…

That’s fair Lee. I think I’d accidentally stumbled upon the logic for .join acting on the separator rather than the iterable, but I do agree it’s awkward unless you’re trying to figure out why it is (which is poor design), and certainly not how most people think, especially with the inconsistency of split not acting on the separator.

Re: Test for lists in Cython

#104

Post by adsharma »

py2many doesn't care which language is faster as long as the source language is annotated python3.

I don't know if this particular benchmark transpiles correctly or not, but it should be possible to achieve much speedup if you annotate your python code properly.

https://github.com/adsharma/py2many

Looking for help with open issues.

Re: Test for lists in Cython

#105

Post by [deleted] »

urschrei wrote: post #9

Rust doesn’t need to copy the data. It’s trivial to pass e.g. Numpy arrays to Rust as slices via Cython (let alone originating in Cython!), modify them, and return them, or use them as input for a new returned struct. https://github.com/urschrei/simplification https://github.com/urschrei/lonlat_bng https://github.com/urschrei/pypolyline Each of those repos has links to the corresponding Rust “shim” libraries that pro…

[deleted]

Re: Test for lists in Cython

#107

Post by leephillips »

duckerude wrote: post #102
nostoc wrote: post #81

Earlier quoted context omitted.

That's not a failure of OOP, but a failure of design. This could have easily been avoided if `join` would have been a method of the list object, not the string object. But we're stuck with this now.

If join were a method on lists then you wouldn't be able to use it with other iterables. Putting it on str is more useful, if more confusing. Maybe it would be better as a standalone function. But then you'd either have to import it or it would pollute the global namespace. Other OOP models offer different solutions.

The Julia join function works on any iterable whose members are or can be converted into strings.

Re: Test for lists in Cython

#108

Post by adsharma »

adsharma wrote: post #104

py2many doesn't care which language is faster as long as the source language is annotated python3. I don't know if this particular benchmark transpiles correctly or not, but it should be possible to achieve much speedup if you annotate your python code properly. https://github.com/adsharma/py2many Looking for help with open issues.

./py2many.py --julia=1 list_py_annotations.py

produces

https://paste.ubuntu.com/p/vwxYkppRCw/

Re: Test for lists in Cython

#110

Post by jhgb »

leephillips wrote: post #109
jhgb wrote: post #106

Earlier quoted context omitted.

It doesn't have named types on which methods get dispatched?

Yes, but those are not classes, in the sense of Python or other OOP language classes.

Named types that can be dispatched on are classes, see CLOS. Hell, even in Python, classes are pretty much the named types that you can dispatch on, although of course, in Python, you generally can't create different kinds of types that can't be dispatched on like types satisfying a predicate - at least to my knowledge you can't, so the difference is somewhat less tangible there.
Post reply on HN