1. 3

    Maybe Google should show only ads to people using the Chrome browser while being logged in to their Google account. Would become easier to stop fraud and would leave the rest of us alone! :-)

    1. 3

      If you think about it, at the moment Google has a significant incentive to get people to use chrome while logged in, and most people from “the rest of us” group mostly see it as misaligned with values and ideals we would prefer and criticise a lot of their decisions. Thinking about your suggestion a few steps into the consequences of pushing that incentive much further in the “wrong” direction is really quite scary… maybe now is already them relatively leaving us alone 😬

    1. -2

      Using open() is an anti-pattern now? Eventually people stop taking this crap seriously.

      1. 5

        That’s not what it said, it said it’s best practice to use with open() as file: because that way it’s guaranteed that the file will be gracefully closed/etc. if there’s an exception thrown within the with block. If you just use f = open() then there’s no guarantee everything will be handled gracefully if your program just dies with the file opened.

        1. 0

          It’s a bit more complicated than that, and @WilhelmVonWeiner is partly right.

          I would totally agree that opening a file for writing warrants using with every time. Because you never want to end up with an un-flushed write buffer in case of an accident. But opening a file for reading only is always safe. Even if your program crashes all your open descriptors will be cleaned up by the OS, there’s nothing “noble” in closing them all yourself. In this case insisting on a with prevents short, readable call compositions like cvs.reader(open('filename')) or return sys.stdin if filename is None else open(filename).

          1. 5

            I’m not sure this is always a good idea on Windows. IIRC that OS will prevent operations like removing a file if any process has it open. I can imagine getting annoyed with the above in, for example, the case of a config file for a long-running program.

            1. 5

              But opening a file for reading only is always safe.

              Unless you do it a lot in a short period of time and run over your OS’s limit of how many open files you can have. And yes, I’ve seen that actually happen with a python program that was written with the “opening for reading is safe” mentality and didn’t use with open and of course also ran into bugs of not closing files. (You can imagine that wasn’t the only thing wrong with how that program was written, but it was a big one.)

              1. 1

                Wait, are you seriously advocating not cleaning up allocated resources after you are done with them with the argument that you can sometimes get away with it without your program breaking?!

                Is this a common idea of how to manage resources? No wonder modern software runs out of them so quickly…

          1. 2

            another interesting one that’s not mentioned there, that I only learned recently. Instead of the “try…except: pass” anti pattern - use with contextlib.suppress when you want to ignore a possible exception.

            1. 1

              What makes try ... except: pass an anti pattern? Is it that except is supposed to be used for handling exceptions, and by passing you’re not actually doing it? Because I would probably find contextlib.suppress less obvious, unless I was familiar with the function already (suppress? suppress what?) than try ... except: pass.

              (I’m assuming that in either case you will want to comment on why you’re supressing / passing on the exception)

              1. 2
                1. While I don’t find suppress less obvious I get that it might seem so to some. You’re asking “suppress what” - well you call suppress with the exception type you want to suppress just like the except clause you’d write. is with contextlib.suppress(OSError):... less obvious than try...except OSError:pass.
                  Also consider that the op’s link mentions for..else. One of the least obvious things that you need to know about this somewhat obscure language feature. But I agree with them that it’s better than the alternative, and for idiomatic python code it should be that not using them is an anti-pattern.

                2. I think try...except:pass as an anti-pattern because it defines an error-handling clause without any error handling in it. Instead it means “there’s no error to handle, this shouldn’t be considered an error”. And “suppressing an error” is a logical term for it and is a much cleaner solution.

                3. Sometimes you’ll want to comment on what you are suppressing. sometimes it should be obvious. The documentation of suppress brings up the case of trying to open a file and suppressing FileNotFoundError as an example of use. I wouldn’t feel the need to comment about that (either when using suppress or in an empty except clause). What do you do when the file wasn’t found and why you don’t handle that error case is up to your program’s logic, sometimes it would make obvious sense. Other times it won’t.

                1. 1

                  Thanks for the explanation, that all makes sense to me 🙂

            1. 1

              not to forget for people with accessability issues

              The article is mentioning VR a lot, so please don’t forget people (like me) who cannot use VR because of VR/motion sickness :)

              1. 1

                You bring up a good point! I go on a bit about the genius of John Carmack quite a bit, but his take on the VR situation being primarily a problem of latency is related to this.

                (He has a writeup and there is a great talk on youtube with him which is brilliant, I’ll get some links when I can be bothered to look up sources, but I’’’m sure you can find it)

                So compare using a bad architecture for VR with being drunk. While being intoxicated you are well as you can hear from the word poisoned, as such your sensory inputs are not handled properly. Introducing a latency gives exactly the same feeling.

                As such eliminate lag and delays from a way to deep software stack and the problem is greatly mitigated.

                One of my hopes is to make a prototype for cheap VR sets that can be used for practical work. I don’t think the problem is throwing money on the issue. Especially since we are dealing with text and simple objects for visualising huge graphs of data. Rather the key would be to create a clever piece of code that hides the latency.

                1. 0

                  The older headsets used to make me extremely sick, and the new ones have no such effect. There will come a point where nobody gets sick from vr because it will be indistinguishable from your normal visual perception. We may already be there, provided you don’t move your avatar without moving your body :). The focus on VR in the article is likely because VR creates new needs in terms of UX. However I agree if this actually is planning on being a framework for ALL input methods it should represent all input methods. As I noted in a comment above, I was surprised to see that it missed the second most common text input device.

                  1. 3

                    The older headsets used to make me extremely sick, and the new ones have no such effect. There will come a point where nobody gets sick from vr because it will be indistinguishable from your normal visual perception.

                    No amount of graphical fidelity will fool peoples’ inner ears, which is the actual source of the issue for a lot of people. Graphical improvements might even intensify the nauseating impact of eye vs inner ear input conflicts.

                    1. 1

                      Really interesting point you are making. I thought most of it boiled down to a laggy experience, but this sounds really interesting.

                      I do have memorizes of when being really really young and introduced to 3d games they gave me nausea but now that has passed. Wonder why?

                      Surely there must be research on this subject?

                      1. 1

                        I think the main point here is about accessibility and inclusion. While some of the problems might be of technical nature, not all of them will be solved with better tech. Just think of those visually impaired. Using your favorite search engine will find you many results (including actual research :)) if you type in “vr 3d visually impaired”.

                        1. 1

                          The solution for VR interfaces for the blind is simple, better UX, more audio and tactile cues. In fact if I could have an effective non-visual VR solution I would be extremely excited. Any solution that lets me interface with a virtual space without eyes is one that lets me interface with a virtual space while existing in my normal space. Imagine if haptic feedback gave us information about the affordances we were working with, letting us know where in space different buttons and knobs are.

                        2. 1

                          From what I’ve been told motion sickness is your body thinking you’ve been poisoned, as poisons have a similar sensation of disagreement between inner ear and visual information. If you’ve ever been so drunk the room was spinning you might be able to relate to this. Similarly the reason why we can acclimate to 3d games and vr is the same reason we can acclimate to the sea. It takes as much as 36 hours though to acclimate to sea sickness or (vr sickness), and if you’re sensitive to motion sickness you may not desire to overcome that. In rare cases, some people can’t and they have to take an over the counter medicine if they want to enjoy those kinds of activities.

                        3. 1

                          You are completely correct. The issue comes from the disagreement with the visual information and the inner ear information. Removing all disagreement is entirely possible (provided you don’t move in vr without your body moving irl). For general purpose computing this is completely doable. For games, it may not be.

                          1. 1

                            VR does not imply movement decoupled from physical movement. In fact, many VR applications do not allow such movement, opting instead for a teleportation mechanic.

                            1. 1

                              Yes, I’m aware that teleportation mechanics are an often-implemented mechanic to avoid triggering motion sickness/inner ear issues.

                              Not sure why your phrasing indicates you’re disagreeing with anything I posted.

                              1. 1

                                Not disagreeing, just highlighting that VR doesn’t necessarily need to fool the inner ear to avoid motion sickness, particularly if all motion is also real-world motion.

                          2. 2

                            I don’t think we’ll get to the point where “nobody gets sick from VR”. Plenty of real-life activities give me motion sickness (a long bus ride for example). The motion sickness problem is a problem in our body and VR technology can get better at not exacerbating it as much, but it will not cure it, unfortunately.

                            I’ve tried some of the older and some of the newer VR sets and it’s true that the newer ones are better, but I still can use them for only a few minutes before feeling queasy.

                            1. 2

                              To clarify, I meant nobody gets more sick from VR than they would from normal motions. Additionally our VR environments can be tailored to those needs so that you don’t need to move around so for general purpose computing. Motion sickness becomes a non issue because you aren’t moving. So for example I get queasy in VR when my body moves but I’m not moving, however I don’t actually have to do that for general purpose computing. I can just sit in a virtual chair managing a wide array of virtual interfaces in front of me. I still benefit from the new affordances however I am not moving and therefore not nauseous throughout the whole experience. I do have roomscale vr so I can get up and walk around without nausea, however typically I find it most comfortable to use while seated. The experience is still much more useful than no VR, even though I can’t necessarily use it to the extent that someone who had no nausea whatsoever could.

                              1. 1

                                Maybe for productive purposes it would be better. Basically what I want to produce here is visualisation for code and tree visualisations.

                                Simplest approach present a grid of 6 workspaces at the same time.

                                A lot of my own ideas and there are a lot of them. Revolves around visualising keyboards as trees. I do believe that this would have applications for visualising other data in a useful manner. Say File System, DOM object tree and just about anything within comp. sci.

                                Again I do not expect to actually create the mother of all demos for VR but rather just to extend the bounds of what is thought to be possible ever so slightly and maybe maybe give some inspiration to some one else. Most of the work consists of compiling other peoples thought into one volume.

                              2. 1

                                Oh my God, there are so many things! I am loosely following an iterative approach with this project. My thought is to write something post it to great forums (read lobste.rs) adjust the aim. Then rinse and repeat. My aim is to create a publishable book from all of this in the mention.

                                Half of it consisting of honourable mentions to people that have helped me online, at this rate! Every time I post I feel as if I have missed something huge. Can’t stress enough how much I value all of your input!!

                                For a skeleton roadmap of the project, check out the README https://github.com/TBF-RnD/alpha/README.md