4 ms·

Some Code I Deleted

91 points by rhema 9y ago

vbernat 9y ago
Gmail IMAP is slow as hell. A self-hosted IMAP server is quite fast.
jonenst 9y ago
Couldn't you use plot "./out.csv" using 1:2 with lines to have the same line graph with gnuplot ?
- frioux 9y ago
  For sure! I actually think I prefer the points over the lines, since the lines make you think that there is data where there isn't.
js2 9y ago
Tangent: the post links to https://bugs.python.org/issue11416 https://bugs.python.org/issue11416 That bug makes me sad. It was opened in 2011. It's a trivial bug to fix. Two separate fixes were submitted, one with several iterations addressing all feedback. By my count, at least five people have dealt directly with the issue (contributing or reviewing code, providing feedback, etc). Who knows how many folks have been affected by the bug and found a work-around or gave up on it. Meanwhile, a fix ends up just withering on the vine for years. This is not a complaint specific to Python. I've seen it happen with many projects, both closed and open. What a waste of people's time.
- blowski 9y ago
  If it’s trivial and fixes have been offered, why hasn’t it been fixed? Is it controversial?
  - js2 9y ago
    I have no idea. The patch is less than a dozen lines. It sat from June 2011 to March 2014 with no action. There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible), but that doesn't explain why it didn't go into 3.3. Some minor feedback (that didn't seem to be a blocker in the first place) was addressed in March 2014 and there it's sat. A new patch then came in in April 2016 which has been completely ignored. I guess my answer is: "there seems to be a lot of friction getting a patch into Python and without a strong advocate, patches sometimes die." I will note that the issue has been classified as an enhancement, not a bug, so maybe that has something to do with it. It still seems like a huge waste of time though.
    - dozzie 9y ago
      > There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible) But it was not backwards compatible. "It works in 2.7" does not mean it works in 2.7.8, but if you try using 2.7.7 it falls apart.
      - js2 9y ago
        Backwards compatible means the patch adds new functionality without breaking the API for existing programs. Of course the new functionality would only work in whichever release it was first shipped. Maybe you’re objecting to it being introduced in a 2.7.x patch release, but that's not without precedent for Python. For example, https://bugs.python.org/issue22960 https://bugs.python.org/issue22960 added a new optional argument to xmlrpclib.ServerProxy and was introduced in 2.7.9.
  - pizza234 9y ago
    I have experience on open source projects, and this is the typical open source "limbo" effect. In general, there are different reasons, depending on the project size, and of course the maintainers' personality. On small projects, time is limited. As a consequence, maintainers need to generally take decisions (about merging) in short times. In this case, unless maintainers are very dedicated to expanding the adoption (of developers), or they have very quick decision skills, minor choices will be postponed, possibly indefinitely. On large (/famous) projects, reasons are different. The context is different; in this other end of the spectrum, there is a flurry of patches, and many low quality ones in absolute quantity. Maintainers, and volunteers, again can put a limited/minimal amount of effort. Since on a large project no change is easy, the limited amount of effort is frequently spent on iterating the patch until it's completed or almost, paradoxically causing it to "disappear in the sea of irrelevance" at the right moment. Or maybe it's completed, but not the way a maintainer has in mind, and he has no intention to spending further effort. Of course, those are just factors; I don't imply that all open source projects have [also] these mechanics, but they are frequent reasons why a patch may not be upstreamed even if it's acceptable.
    - js2 9y ago
      I've contributed to a handful of well-known open-source projects over the years, some more, some less. It has always required quite a bit of effort to land patches. That usually gets easier the longer you're involved in a project and the maintainers see that you care about the project and you have a reputation for working with them to contribute quality improvements. I appreciate that a project can't just allow contributors to "throw code over the fence" as it were. There's a delicate balance between maintaining code quality and not accepting everyone's pet feature, moving the project forward, and not turning contributors away. I think sometimes a bit of friction is a good thing insofar as it requires contributors to have some skin in the game. All that said, this really looks like a minor issue here. That's why this one in particular makes me sad. The effort to land it vs effort to fix it is completely out of whack. There ought to be a simpler process for trivial fixes. Yeah, I know sometimes what seems trivial may be hard to assess or ends up introducing regressions. I'm still shedding a tear.
- 8_hours_ago 9y ago
  I came here to post something similar to this. I have seen this happen many times on open source projects, and it is especially depressing for the person who volunteered to write the patch. Going back and forth many times over several months to make small adjustments to your code and never having it committed is very demoralizing. I don't know what the solution is, and it is probably just an inherit flaw with volunteer-run open source projects. Without someone being paid to get the bug count down it's easy for bugs like this to get forgotten about.
  - nine_k 9y ago
    I think the answer here could be decentralization. Do not try fixing the canonical module past some reasonable effort. Make a separate version, let interested people `pip install` it. This, of course, does not work with core libraries on which many other standard libraries depend. But its not the case with netrc.
- emmelaich 9y ago
  FWIW, a workaround is to use the rarely used account field of netrc. You make the machine unique and use the account field to identify the real host. Not a solution for all purposes but for code you're writing yourself it is fine. I use this technique in a Python program which hits REST apis on the same endpoint but under different usernames / privileges / credentials. You can also put things like ssh key, saml, encrypted passwords etc into account and have a fake password for slightly better security. I've seen a proposal for a better netrc format (e.g. integrated with gpg) but I can't find it right now. PS. about the only documentation you'll find on most machines for netrc is the Perl Net::Netrc manual page.
jwilk 9y ago
Re Python netrc bug, you shouldn't put valuable passwords in ~/.netrc: http://jwilk.net/blog/20131104-netrc-security http://jwilk.net/blog/20131104-netrc-security
- phyzome 9y ago
  Sure, there are a lot of reasons not to use netrc for valuable passwords, starting with "don't put valuable passwords in plaintext especially in a predictable location"! I use it quite sparingly. At work, sometimes I need to make a large number of calls to a password-authenticated API. My approach there is to `sudo mount -t tmpfs -o size=5M tmpfs ~/tmp/secret/`, put a .netrc in there, and use curl's `--netrc-file` option to point to it. When I'm done, I umount the ramdisk. The password never hits the disk unencrypted, modulo swap.
  - jwilk 9y ago
    You could make curl read netrc from a pipe. Something like this should work: #!/bin/bash password=$(...) # replace with code to extract password from the the password manager generate_netrc() { printf 'machine www.example.org login foo password "%s"\n' "$password" } curl -v --netrc-file <(generate_netrc) http://www.example.org No need for sudo and no risk of hitting swap. :-)
- emmelaich 9y ago
  per my comment above, you can put arbitrary stuff in account field (e.g. encrypted) passwords. Works fine if you write the code that uses it.
nerdponx 9y ago
One of my friends is fond of saying “no code is better than no code”. I tend to agree. Code is fun to write, but it’s such a liability, especially if you have less time than when you initially wrote it. This is why I think so much time can be spent on automation or documentation; because it helps out future me. But the most foolproof way to win is to just not play, given the option. In my experience, you sometimes need to write code in order to realize that you didn't need to write it in the first place. Maybe that's one of the things that separates a senior developer: they know what code not to write.
- maxxxxx 9y ago
  I always tell people that deleted code is the best code.
- w8rbt 9y ago
  Deleted code has no bugs. Similar to the old phrase 'Dead men tell no tales'
tzs 9y ago
Is there some specification that covers what it is supposed to mean if a host is listed more than once in .netrc? The man page for netrc on most Unix or Unix-like systems that I checked includes this for how the "machine" token is handled: > Identify a remote machine name. The auto-login process searches the .netrc file for a machine token that matches the remote machine specified on the ftp command line or as an open command argument. Once a match is made, the subsequent .netrc tokens are processed, stopping when the end of file is reached or another machine or a default token is encountered That specifically talks about ftp's use of .netrc, and as described only the first entry for a host is ever processed. I can think of two ways to take that, from the point of view of a programmer thinking of using .netrc for a program that is not ftp. 1. .netrc was designed for ftp. If I'm going to use another programs' file I should use it exactly like it is documented to use it...so I should only look at the first matching machine too. 2. .netrc was designed for ftp, but it is explicitly documented as only looking at the first matching machine. What that tells me is that I can go ahead and tell my users to use .netrc for my program too, and if they need different credentials for my service than they do for ftp on a given machine, go ahead and make a separate machine entry for my program. Just make sure it is not the FIRST machine entry for that machine. I can add some way for them to tell my program which entry to use when there are multiple machine entries that match. Either a command line argument, an environment variable, or since ftp is guaranteed to not process other than the first match I could even add a new token in .netrc that marks my entry.

Some Code I Deleted

91 points by rhema 9y ago

vbernat 9y ago

Gmail IMAP is slow as hell. A self-hosted IMAP server is quite fast.

jonenst 9y ago

Couldn't you use plot "./out.csv" using 1:2 with lines to have the same line graph with gnuplot ?

frioux 9y ago
For sure! I actually think I prefer the points over the lines, since the lines make you think that there is data where there isn't.

js2 9y ago

Tangent: the post links to https://bugs.python.org/issue11416 https://bugs.python.org/issue11416 That bug makes me sad. It was opened in 2011. It's a trivial bug to fix. Two separate fixes were submitted, one with several iterations addressing all feedback. By my count, at least five people have dealt directly with the issue (contributing or reviewing code, providing feedback, etc). Who knows how many folks have been affected by the bug and found a work-around or gave up on it. Meanwhile, a fix ends up just withering on the vine for years. This is not a complaint specific to Python. I've seen it happen with many projects, both closed and open. What a waste of people's time.

blowski 9y ago
If it’s trivial and fixes have been offered, why hasn’t it been fixed? Is it controversial?
- js2 9y ago
  I have no idea. The patch is less than a dozen lines. It sat from June 2011 to March 2014 with no action. There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible), but that doesn't explain why it didn't go into 3.3. Some minor feedback (that didn't seem to be a blocker in the first place) was addressed in March 2014 and there it's sat. A new patch then came in in April 2016 which has been completely ignored. I guess my answer is: "there seems to be a lot of friction getting a patch into Python and without a strong advocate, patches sometimes die." I will note that the issue has been classified as an enhancement, not a bug, so maybe that has something to do with it. It still seems like a huge waste of time though.
  - dozzie 9y ago
    > There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible) But it was not backwards compatible. "It works in 2.7" does not mean it works in 2.7.8, but if you try using 2.7.7 it falls apart.
    - js2 9y ago
      Backwards compatible means the patch adds new functionality without breaking the API for existing programs. Of course the new functionality would only work in whichever release it was first shipped. Maybe you’re objecting to it being introduced in a 2.7.x patch release, but that's not without precedent for Python. For example, https://bugs.python.org/issue22960 https://bugs.python.org/issue22960 added a new optional argument to xmlrpclib.ServerProxy and was introduced in 2.7.9.
- pizza234 9y ago
  I have experience on open source projects, and this is the typical open source "limbo" effect. In general, there are different reasons, depending on the project size, and of course the maintainers' personality. On small projects, time is limited. As a consequence, maintainers need to generally take decisions (about merging) in short times. In this case, unless maintainers are very dedicated to expanding the adoption (of developers), or they have very quick decision skills, minor choices will be postponed, possibly indefinitely. On large (/famous) projects, reasons are different. The context is different; in this other end of the spectrum, there is a flurry of patches, and many low quality ones in absolute quantity. Maintainers, and volunteers, again can put a limited/minimal amount of effort. Since on a large project no change is easy, the limited amount of effort is frequently spent on iterating the patch until it's completed or almost, paradoxically causing it to "disappear in the sea of irrelevance" at the right moment. Or maybe it's completed, but not the way a maintainer has in mind, and he has no intention to spending further effort. Of course, those are just factors; I don't imply that all open source projects have [also] these mechanics, but they are frequent reasons why a patch may not be upstreamed even if it's acceptable.
  - js2 9y ago
    I've contributed to a handful of well-known open-source projects over the years, some more, some less. It has always required quite a bit of effort to land patches. That usually gets easier the longer you're involved in a project and the maintainers see that you care about the project and you have a reputation for working with them to contribute quality improvements. I appreciate that a project can't just allow contributors to "throw code over the fence" as it were. There's a delicate balance between maintaining code quality and not accepting everyone's pet feature, moving the project forward, and not turning contributors away. I think sometimes a bit of friction is a good thing insofar as it requires contributors to have some skin in the game. All that said, this really looks like a minor issue here. That's why this one in particular makes me sad. The effort to land it vs effort to fix it is completely out of whack. There ought to be a simpler process for trivial fixes. Yeah, I know sometimes what seems trivial may be hard to assess or ends up introducing regressions. I'm still shedding a tear.
8_hours_ago 9y ago
I came here to post something similar to this. I have seen this happen many times on open source projects, and it is especially depressing for the person who volunteered to write the patch. Going back and forth many times over several months to make small adjustments to your code and never having it committed is very demoralizing. I don't know what the solution is, and it is probably just an inherit flaw with volunteer-run open source projects. Without someone being paid to get the bug count down it's easy for bugs like this to get forgotten about.
- nine_k 9y ago
  I think the answer here could be decentralization. Do not try fixing the canonical module past some reasonable effort. Make a separate version, let interested people `pip install` it. This, of course, does not work with core libraries on which many other standard libraries depend. But its not the case with netrc.
emmelaich 9y ago
FWIW, a workaround is to use the rarely used account field of netrc. You make the machine unique and use the account field to identify the real host. Not a solution for all purposes but for code you're writing yourself it is fine. I use this technique in a Python program which hits REST apis on the same endpoint but under different usernames / privileges / credentials. You can also put things like ssh key, saml, encrypted passwords etc into account and have a fake password for slightly better security. I've seen a proposal for a better netrc format (e.g. integrated with gpg) but I can't find it right now. PS. about the only documentation you'll find on most machines for netrc is the Perl Net::Netrc manual page.

jwilk 9y ago

Re Python netrc bug, you shouldn't put valuable passwords in ~/.netrc: http://jwilk.net/blog/20131104-netrc-security http://jwilk.net/blog/20131104-netrc-security

phyzome 9y ago
Sure, there are a lot of reasons not to use netrc for valuable passwords, starting with "don't put valuable passwords in plaintext especially in a predictable location"! I use it quite sparingly. At work, sometimes I need to make a large number of calls to a password-authenticated API. My approach there is to `sudo mount -t tmpfs -o size=5M tmpfs ~/tmp/secret/`, put a .netrc in there, and use curl's `--netrc-file` option to point to it. When I'm done, I umount the ramdisk. The password never hits the disk unencrypted, modulo swap.
- jwilk 9y ago
  You could make curl read netrc from a pipe. Something like this should work: #!/bin/bash password=$(...) # replace with code to extract password from the the password manager generate_netrc() { printf 'machine www.example.org login foo password "%s"\n' "$password" } curl -v --netrc-file <(generate_netrc) http://www.example.org No need for sudo and no risk of hitting swap. :-)
emmelaich 9y ago
per my comment above, you can put arbitrary stuff in account field (e.g. encrypted) passwords. Works fine if you write the code that uses it.

nerdponx 9y ago

One of my friends is fond of saying “no code is better than no code”. I tend to agree. Code is fun to write, but it’s such a liability, especially if you have less time than when you initially wrote it. This is why I think so much time can be spent on automation or documentation; because it helps out future me. But the most foolproof way to win is to just not play, given the option. In my experience, you sometimes need to write code in order to realize that you didn't need to write it in the first place. Maybe that's one of the things that separates a senior developer: they know what code not to write.

maxxxxx 9y ago
I always tell people that deleted code is the best code.
w8rbt 9y ago
Deleted code has no bugs. Similar to the old phrase 'Dead men tell no tales'

tzs 9y ago

Is there some specification that covers what it is supposed to mean if a host is listed more than once in .netrc? The man page for netrc on most Unix or Unix-like systems that I checked includes this for how the "machine" token is handled: > Identify a remote machine name. The auto-login process searches the .netrc file for a machine token that matches the remote machine specified on the ftp command line or as an open command argument. Once a match is made, the subsequent .netrc tokens are processed, stopping when the end of file is reached or another machine or a default token is encountered That specifically talks about ftp's use of .netrc, and as described only the first entry for a host is ever processed. I can think of two ways to take that, from the point of view of a programmer thinking of using .netrc for a program that is not ftp. 1. .netrc was designed for ftp. If I'm going to use another programs' file I should use it exactly like it is documented to use it...so I should only look at the first matching machine too. 2. .netrc was designed for ftp, but it is explicitly documented as only looking at the first matching machine. What that tells me is that I can go ahead and tell my users to use .netrc for my program too, and if they need different credentials for my service than they do for ftp on a given machine, go ahead and make a separate machine entry for my program. Just make sure it is not the FIRST machine entry for that machine. I can add some way for them to tell my program which entry to use when there are multiple machine entries that match. Either a command line argument, an environment variable, or since ftp is guaranteed to not process other than the first match I could even add a new token in .netrc that marks my entry.