|
feedmegin posted:Mate one of the products I worked on shipped its own copy of the Python interpreter as part of its runtime, even isn't that the purpose of virtualenv?
|
#
?
Jul 13, 2019 04:33
|
|
|
|
| # ? May 31, 2024 09:16 |
|
|
feedmegin posted:What if you're opening files on, for example, a commercial Unix with a legacy encoding like EUCJP for Japanese? 'If it's not Unicode it's garbage' is not a practical approach in the real world. shoulda said GB2312, which is only supported for decoding.* https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html is the list of supported character sets * i have fixed actual customer affecting bugs caused by this one
|
|
#
?
Jul 13, 2019 05:58
|
|
|
Progressive JPEG posted:isn't that the purpose of virtualenv? oh, ye of little years
|
|
#
?
Jul 13, 2019 06:04
|
|
|
Progressive JPEG posted:isn't that the purpose of virtualenv? What are the chances of the customer having that installed on their AIX 5 box?
|
|
#
?
Jul 13, 2019 15:18
|
|
|
ulmont posted:Sure, but outputting to a well-known encoding scheme isn't that big a deal, and in the java example would be easily handled by just setting the default character encoding for the environment to EUCJP (if it wasn't already). Right. Now the user copies a file from a newer system with a name which is in UTF-8. What now? On a UNIX system a filename is a sequence of arbitrary bytes. Trying to coerce it to human text is always going to lead to tears in the edge cases.
|
|
#
?
Jul 13, 2019 15:23
|
|
|
and obviously it is unix that is in the wrong here, but that doesn't really solve any problem.
|
|
#
?
Jul 13, 2019 15:46
|
|
|
I was the guy complaining about Python 3's handling of the separate types -- I still think it's kind of unpythonic, since if I'm handed a file object I don't know whether it's in bytes or not. If you read from it you're lucky since you can do .read(0) and then check whether it's b'' or '', but with a .write() you have to try and catch the exception. So the "file" object has an API that changes invisibly and can't be tested for without trying. This sort of half-baked approach to upgrading the standard library worn me down to the point that I gave up on Python altogether. In later Python 3 releases they put back a lot of the functionality that they intentionally removed from the bytes type, but that shows that their initial hard line stance about what bytes and str were wasn't as useful as first thought. Not to mention the whole "code points being your fundamental Unicode element" thing is short-sighted in the same way UCS-2 was short-sighted, though it was the popular choice at the time. Newer languages like Swift use extended grapheme clusters which is a better choice.
|
|
#
?
Jul 13, 2019 16:07
|
|
|
feedmegin posted:Right. Now the user copies a file from a newer system with a name which is in UTF-8. What now? Copies a file from the newer system to that commercial UNIX using EUCJP? I'm probably missing your point now, but if that has to be done in the hypothetical Java program then yes, then you'll need to know so you can switch your locale on the fly as applicable. feedmegin posted:On a UNIX system a filename is a sequence of arbitrary bytes. Trying to coerce it to human text is always going to lead to tears in the edge cases. Well, yes. Particularly in the case of "I want to use bytes that do not represent a legal Unicode character sequence using any known encoding scheme." But the simpler case of "I need to open a file on a system that doesn't use UTF-8 for filenames" is pretty easy.
|
|
#
?
Jul 13, 2019 16:26
|
|
|
Internet Janitor posted:fabrice bellard's new dependency-free embeddable js interpreter kinda owns -7 years https://github.com/charliesome/jsos
|
|
#
?
Jul 13, 2019 16:29
|
|
|
feedmegin posted:What are the chances of the customer having that installed on their AIX 5 box? I just mean it seems to be SOP for python distribution to involve throwing up your hands and saying "gently caress it just include a copy of the whole runtime/stdlib"
|
|
#
?
Jul 13, 2019 22:02
|
|
|
Progressive JPEG posted:I just mean it seems to be SOP for python distribution to involve throwing up your hands and saying "gently caress it just include a copy of the whole runtime/stdlib" because that is the only sensible choice if you intend to at all offer support.
|
|
#
?
Jul 13, 2019 22:07
|
|
|
I'm writing I2C drivers in PYTHON. 
|
|
#
?
Jul 13, 2019 22:53
|
|
|
ratbert90 posted:I'm writing I2C drivers in PYTHON. pro redtext / post combo
|
|
#
?
Jul 14, 2019 00:12
|
|
|
Someone's got to do it.
|
|
#
?
Jul 14, 2019 00:16
|
|
|
Cybernetic Vermin posted:because that is the only sensible choice if you intend to at all offer support. lmao if you dont have a wiki they can look at instead of actual support
|
|
#
?
Jul 14, 2019 01:46
|
|
|
taqueso posted:Someone's got to do it. they actually don't
|
|
#
?
Jul 14, 2019 02:03
|
|
|
Cybernetic Vermin posted:because that is the only sensible choice if you intend to at all offer support. yeah i guess if youre already trying to distribute python code to end users may as well go whole hog crazy with it
|
|
#
?
Jul 14, 2019 02:23
|
|
|
feedmegin posted:Right. Now the user copies a file from a newer system with a name which is in UTF-8. What now? java uses the platform encoding (on unix, easiest way to set is $LANG) for encoding filenames to open(2) do you really, really want to propose that using byte[] for filenames is a superior option when programmers are typically fuzzy on how characters sets work and gently caress it up constantly, using the platform encoding is correct 99.9999% of the time anyway, and the other 0.0001% is supporting complex, difficult functionality on fubar systems. (like, how does your UTF-8 filename get passed to the JVM when LANG=EUCJP?) when you could, you know, push back on the customer a tiny bit and tell them to set LANG and use it properly
|
|
#
?
Jul 14, 2019 02:35
|
|
|
oh and it's not like itd be hard to use some reflection fuckery or jni fuckery to open files using byte[] if you really wanted to. it's just the kind of insanity that imo has no place in a stdlib
|
|
#
?
Jul 14, 2019 02:36
|
|
|
feedmegin posted:On a UNIX system a filename is a sequence of arbitrary bytes. Trying to coerce it to human text is always going to lead to tears in the edge cases. on some filesystems a filename is a sequence of arbitrary bytes other than path decomposition, UNIX will eventually pass whatever you’ve given it through to the underlying filesystem
|
|
#
?
Jul 14, 2019 06:20
|
|
|
Krankenstyle posted:lmao if you dont have a wiki they can look at instead of actual support I’ll make the wiki
|
|
#
?
Jul 14, 2019 07:02
|
|
|
does rust’s OsStr satisfy these wacko filenames?
|
|
#
?
Jul 14, 2019 11:43
|
|
|
Shinku ABOOKEN posted:does rust’s OsStr satisfy these wacko filenames? It should, since that's OsStr's entire raison d'être.
|
|
#
?
Jul 14, 2019 17:04
|
|
|
Progressive JPEG posted:I just mean it seems to be SOP for python distribution to involve throwing up your hands and saying "gently caress it just include a copy of the whole runtime/stdlib" we have always been at war with dynamic linking
|
|
#
?
Jul 15, 2019 14:42
|
|
|
"microservices" are just dynamic linking over HTTP
|
|
#
?
Jul 15, 2019 18:25
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP holy poo poo
|
|
#
?
Jul 15, 2019 23:57
|
|
|
i heard that static linking is more efficient so now i always hardcode the ip addresses
|
|
#
?
Jul 16, 2019 00:39
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP we consider our "service" a remote shared object, you have to match the hash of the protocol to connect to it lol
|
|
#
?
Jul 16, 2019 01:54
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP loving hell
|
|
#
?
Jul 16, 2019 01:57
|
|
|
Sweeper posted:we consider our "service" a remote shared object, you have to match the hash of the protocol to connect to it lol this website is covered by the GNU General Public License. by connecting to it any and all of your knowledge improved as a result is inherently covered by the GPL.
|
|
#
?
Jul 16, 2019 02:00
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP
|
|
#
?
Jul 16, 2019 03:31
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP im screaming
|
|
#
?
Jul 16, 2019 04:06
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP 
|
|
#
?
Jul 16, 2019 07:27
|
|
|
Kazinsal posted:this website is covered by the GNU General Public License. by connecting to it any and all of your knowledge improved as a result is inherently covered by the GPL. GPLv4 preview looks p bad OP
|
|
#
?
Jul 16, 2019 07:37
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP 
|
|
#
?
Jul 16, 2019 11:48
|
|
|
animist posted:"microservices" are just dynamic linking over HTTP New title please.
|
|
#
?
Jul 16, 2019 11:52
|
|
|
ratbert90 posted:New title please.
|
|
#
?
Jul 16, 2019 13:03
|
|
|
ratbert90 posted:New title please.
|
|
#
?
Jul 16, 2019 13:04
|
|
|
ratbert90 posted:New title please.
|
|
#
?
Jul 16, 2019 13:25
|
|
|
|
| # ? May 31, 2024 09:16 |
|
|
animist posted:"microservices" are just dynamic linking over HTTP yeeeoogh
|
|
#
?
Jul 16, 2019 13:28
|
|
