β² 24 βΌ Stop using pickle already. Seriously, stop it! (mina86.com) submitted 9 months ago by mina86@lemmy.wtf to c/python@programming.dev 11 comments fedilink hide all child comments
[+] mina86@lemmy.wtf [S] 4 points 9 months ago* (7 children) [deleted] permalink fedilink source parent hideshow 7 child comments replies: [β] logging_strict@programming.dev 2 points 8 months ago* (6 children) Also there is strictyaml that validates against schemas. Don't touch the builtin yaml module. protobuf needs to be compiled. This introduces possibility of coder error. Just forgetting to compile and commit protobuf files after a change. This affected the electrum btc and ltc (light) wallets. permalink fedilink source parent hideshow 6 child comments replies: [+] mina86@lemmy.wtf [S] 3 points 8 months ago* (5 children) [deleted] permalink fedilink source parent hideshow 5 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (4 children) A better approach That unfortunately isn't a better approach. The compilation step requires protobuf to be installed, by the distro package manager. To my knowledge it's not available from pypi. An uncompiled protobuf file is essentially worthless unless it's compiled. But if it's compiled then it's a binary blob. Not anti-protobuf. Just make the protobuf compiler available without getting a distro package manager involved. Otherwise slower alternatives might be more viable. strictyaml bundles strictyaml.ruamel, which used to be an external unmaintained C package. This reduces strictyaml dependencies to: pyproject.toml dependencies = [ "python-dateutil>=2.6.0" ] Just that one. So can be confident strictyaml will work. Can the same be said for protobuf and Google (over invested in AI and is probably dying underneath a huge debt burden while spending tons of money on AI wash propaganda while not funding Python projects enough. Maintainer leave or burn out while everyone is too busy head fcking us with the AI washing to notice.) permalink fedilink source parent hideshow 4 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago (3 children) [deleted] permalink fedilink source parent hideshow 3 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (2 children) It's a potential single point of failure. Which have experienced first hand. The rest of the app could not run cuz a non-essential piece was non-operable due to the missing compiled message definitions file or message definitions file was updated but not compiled. So protobuf carries a non-zero risk. Could the app have been designed without an essential exploding binary blob? Most definitely yes! permalink fedilink source parent hideshow 2 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago* (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent
[β] logging_strict@programming.dev 2 points 8 months ago* (6 children) Also there is strictyaml that validates against schemas. Don't touch the builtin yaml module. protobuf needs to be compiled. This introduces possibility of coder error. Just forgetting to compile and commit protobuf files after a change. This affected the electrum btc and ltc (light) wallets. permalink fedilink source parent hideshow 6 child comments replies: [+] mina86@lemmy.wtf [S] 3 points 8 months ago* (5 children) [deleted] permalink fedilink source parent hideshow 5 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (4 children) A better approach That unfortunately isn't a better approach. The compilation step requires protobuf to be installed, by the distro package manager. To my knowledge it's not available from pypi. An uncompiled protobuf file is essentially worthless unless it's compiled. But if it's compiled then it's a binary blob. Not anti-protobuf. Just make the protobuf compiler available without getting a distro package manager involved. Otherwise slower alternatives might be more viable. strictyaml bundles strictyaml.ruamel, which used to be an external unmaintained C package. This reduces strictyaml dependencies to: pyproject.toml dependencies = [ "python-dateutil>=2.6.0" ] Just that one. So can be confident strictyaml will work. Can the same be said for protobuf and Google (over invested in AI and is probably dying underneath a huge debt burden while spending tons of money on AI wash propaganda while not funding Python projects enough. Maintainer leave or burn out while everyone is too busy head fcking us with the AI washing to notice.) permalink fedilink source parent hideshow 4 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago (3 children) [deleted] permalink fedilink source parent hideshow 3 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (2 children) It's a potential single point of failure. Which have experienced first hand. The rest of the app could not run cuz a non-essential piece was non-operable due to the missing compiled message definitions file or message definitions file was updated but not compiled. So protobuf carries a non-zero risk. Could the app have been designed without an essential exploding binary blob? Most definitely yes! permalink fedilink source parent hideshow 2 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago* (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent
[+] mina86@lemmy.wtf [S] 3 points 8 months ago* (5 children) [deleted] permalink fedilink source parent hideshow 5 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (4 children) A better approach That unfortunately isn't a better approach. The compilation step requires protobuf to be installed, by the distro package manager. To my knowledge it's not available from pypi. An uncompiled protobuf file is essentially worthless unless it's compiled. But if it's compiled then it's a binary blob. Not anti-protobuf. Just make the protobuf compiler available without getting a distro package manager involved. Otherwise slower alternatives might be more viable. strictyaml bundles strictyaml.ruamel, which used to be an external unmaintained C package. This reduces strictyaml dependencies to: pyproject.toml dependencies = [ "python-dateutil>=2.6.0" ] Just that one. So can be confident strictyaml will work. Can the same be said for protobuf and Google (over invested in AI and is probably dying underneath a huge debt burden while spending tons of money on AI wash propaganda while not funding Python projects enough. Maintainer leave or burn out while everyone is too busy head fcking us with the AI washing to notice.) permalink fedilink source parent hideshow 4 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago (3 children) [deleted] permalink fedilink source parent hideshow 3 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (2 children) It's a potential single point of failure. Which have experienced first hand. The rest of the app could not run cuz a non-essential piece was non-operable due to the missing compiled message definitions file or message definitions file was updated but not compiled. So protobuf carries a non-zero risk. Could the app have been designed without an essential exploding binary blob? Most definitely yes! permalink fedilink source parent hideshow 2 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago* (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent
[β] logging_strict@programming.dev 1 point 8 months ago (4 children) A better approach That unfortunately isn't a better approach. The compilation step requires protobuf to be installed, by the distro package manager. To my knowledge it's not available from pypi. An uncompiled protobuf file is essentially worthless unless it's compiled. But if it's compiled then it's a binary blob. Not anti-protobuf. Just make the protobuf compiler available without getting a distro package manager involved. Otherwise slower alternatives might be more viable. strictyaml bundles strictyaml.ruamel, which used to be an external unmaintained C package. This reduces strictyaml dependencies to: pyproject.toml dependencies = [ "python-dateutil>=2.6.0" ] Just that one. So can be confident strictyaml will work. Can the same be said for protobuf and Google (over invested in AI and is probably dying underneath a huge debt burden while spending tons of money on AI wash propaganda while not funding Python projects enough. Maintainer leave or burn out while everyone is too busy head fcking us with the AI washing to notice.) permalink fedilink source parent hideshow 4 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago (3 children) [deleted] permalink fedilink source parent hideshow 3 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (2 children) It's a potential single point of failure. Which have experienced first hand. The rest of the app could not run cuz a non-essential piece was non-operable due to the missing compiled message definitions file or message definitions file was updated but not compiled. So protobuf carries a non-zero risk. Could the app have been designed without an essential exploding binary blob? Most definitely yes! permalink fedilink source parent hideshow 2 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago* (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent
[+] mina86@lemmy.wtf [S] 2 points 8 months ago (3 children) [deleted] permalink fedilink source parent hideshow 3 child comments replies: [β] logging_strict@programming.dev 1 point 8 months ago (2 children) It's a potential single point of failure. Which have experienced first hand. The rest of the app could not run cuz a non-essential piece was non-operable due to the missing compiled message definitions file or message definitions file was updated but not compiled. So protobuf carries a non-zero risk. Could the app have been designed without an essential exploding binary blob? Most definitely yes! permalink fedilink source parent hideshow 2 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago* (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent
[β] logging_strict@programming.dev 1 point 8 months ago (2 children) It's a potential single point of failure. Which have experienced first hand. The rest of the app could not run cuz a non-essential piece was non-operable due to the missing compiled message definitions file or message definitions file was updated but not compiled. So protobuf carries a non-zero risk. Could the app have been designed without an essential exploding binary blob? Most definitely yes! permalink fedilink source parent hideshow 2 child comments replies: [+] mina86@lemmy.wtf [S] 2 points 8 months ago* (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent
[+] mina86@lemmy.wtf [S] 2 points 8 months ago* (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent
[β] logging_strict@programming.dev 1 point 8 months ago project cost = sigma(1...n)(risk likelihood of occurring * risk cost), but we aren't discussing every possible risk. Only the one risk. The risk of having to: for the app to work, requires compiled components having to be familiar with setup.py. This is referred to as the sewer, which is what is targeted by hackers e.g. xv maintainers who come later being familiar and can maintain packages that incorporate other languages e.g. C or rust possibly neglecting to perform the compile (but lets ignore this) compiler runs a binary written and maintained by the spy agency Google or Just not doing that The only justification for going with protoc, over other methods, could only come down to data serialization speed. But in that case, wouldn't a rust solution be: not only as fast, but also much safer. permalink fedilink source parent