Hacker Timesnew | past | comments | ask | show | jobs | submit | testuser66's commentslogin

It's hard to move browsers permanently if you're not prepared. I moved to FF Quantom for a bit, but had to regularly open Chrome to get passwords etc. And the Chrome assholes removed the password export (or at least I could not for the life of me get it to work at the time)

I ended up going back for a bit and added a password manager, and now I can move between browsers easily - but as I said, it's not always straightforward, especially for _most_ non-tech users.


> And the Chrome assholes removed the password export (or at least I could not for the life of me get it to work at the time)

Chrome Settings > Passwords > "Export passwords..." (under the three-dots menu).

Not sure when you last checked but the option has been available since at least Chrome 66, which was released almost two years ago: https://www.ghacks.net/2018/04/18/google-chrome-66-password-...

I distinctly recall the option to manually import passwords being harder to find (solution is to either import them from another browser or enable a flag to import passwords from a CSV file).

Ironically Firefox currently still lacks the native ability to manually export passwords, relying on add-ons or third-party tools: https://www.nytimes.com/2018/07/20/technology/personaltech/f...


> It's hard to move browsers permanently if you're not prepared.

I find it rather easy, at least in my case. Passwords are all managed via a password manager, I barely use bookmarks, so most of the work is re-installing and configuring a few plugins, which I also don't use many of


Firefox has a built in import of browser data from other browsers such as Chrome. Does this no longer work?


It doesn't exist on Linux. When I moved from Chrome to Firefox, I used https://github.com/louisabraham/ffpass.


Everyone that is fully against killing insects has likely never lived anywhere that has insects.


OP isn't "fully against killing insects", just said that "it should not be fun or recreational."


And thus, a new law was born.


You do realise that storing them (be it Google, LastPass, or any other hopefully trusty manager) is safer than carrying them around on you, right?


The parent is concerned about privacy, not security.


Have been using Ecosia and I have to do a `g` search pretty much daily. Though the use Bing underneath, so maybe it's worth giving DuckDuckGo a try


I've been using both VSCode and JetBrains IDEs with their VIM plugins. The VSCode one is kind of shitty, but overall both do the job well enough that as a not-super-proficient-vim-master-guru I don't really lack any features.

And you get all the IDE stuff as well. Pretty much a win-win there. (if the vim functionality is good enough for you)


> within couple of decades

We already do.


On one hand - I agree, overloading isn't great. On the other hand having a `def func(args, kwargs)` is a pain the ass for everyone involved (people & IDEs): you have no idea what the args or kwargs could be without reading the source.

If you can get away with just a bunch of named kwargs after the arguments that is fine, but I'd take overloading over the `args, kwargs` garbage any day, even if that is the more "pythonic" way.


I think the kwargs approach is fine for when you’re reading your code. When you’re writing I think you’ll always have to consult the docs, or headers. In a strongly typed language IDE can pick up the hint but in a more dynamic language like python it can get confused.


My bad - I meant this but didn't know how to format code so that is showed the stars

    def func(*args, **kwargs)
I am in full support of actual kwargs with names, it's the wildcard ones that I don't like.


by "kwargs" the usual approach is to have optional arguments ("keyword arguments") that aren't just kwargs, but are named optional arguments:

    def func(args, flag=False, flag2=True)


I fully agree that named kwargs is perfectly acceptable, but this is the version I think is horrible:

    def func(*args, **kwargs) 
is valid and completely ambiguous - you have no idea what it's doing unless you read the source, and track down how it branches out. IDEs are stopped dead in their tracks as they aren't going to parse the logic to figure it out

And yes it's not the most common approach, but I have seen it enough times to despise it. This overloading approach removes the need for it so I'm all for that.


> This overloading approach removes the need for it so I'm all for that.

Ish, see if your IDE supports it (hint: it won't, but it will support named kwargs).


And it doesn't really need to. Consider this:

    from functools import singledispatch
    from typing import Union

    @singledispatch
    def myfunc(arg:Union[int, str]):
        print("Called with something else")
    
    @myfunc.register
    def _(arg:int):
        print("Called the one with int")
    
    @myfunc.register
    def _(arg:str):
        print("Called the one with str")

    myfunc(123)
    myfunc("123")
Everything works as you'd expect, and the IDE's type hints are accurate as long as you actually put the correct type hint

    def myfunc(arg:Union[int, str]):


Is this any different than the debugger visualisations that other editors/IDEs have?

Genuinely curious, because if I'm understanding this correctly, it's just another front-end like what VSCode/Atom(probably)/CLion/Visual Studio have been doing for years if not decades.

I guess what I'm asking is: does this do a better job than the others?


I mean sure that's better, but now Apple is tracking you instead and you got ripped off $340 for it


Apple’s tracking opt-outs don’t silently reset themselves to “share everything” on each update the way Wacom does.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: