RubyPinch

I honestly prefer it when editing

    <p>
        It naturally acts as a clean way to segment
        paragraphs of text
    <p>
        And most of the tag-closing rules are roughly
        matched with the rules of using p tags altogether.
    <p>
        e.g. you can't have a div within a paragraph, so
        closing or not closing, divs can only come after 
        paragraphs!.

> A p element's end tag may be omitted if the p element is immediately followed by block-ish element, or if there is no more content in the parent element.

> This doesn't apply if you are doing weird stuff in a non-block-ish element, or a media element, or a custom element.

is the easier way to think about it usually

Its optional though.

If you don't want it, don't add it

It still bothers me. I don't know whether I just don't understand the differences in culture (between theirs and mine), or whether I can't remember how I used to socialize back in my high-school days, but the reactions always seems a bit excessive.

I wonder if perhaps misdirection would change things? "You have 8 hours of this remaining" would make one very conscious of the experiment, and when it finishes.

The reduced usecase (story?) is the following

The customer requests the following

    @?
    class somename (?):
        an_attr_a = ADescriptor(somestuff)
        an_attr_1 = ADescriptor(somestuff)
        an_attr_a1 = ADescriptor(somestuff)

One of their expectations is that the attributes have their definition order stored somewhere. You may either use the decorator method, or the metaclass method

> The dev of uBlock directs users to download and use uBlock Origin instead.

They do? still doesn't seem like that, e.g. https://www.ublock.org all links go to ublock, except for one link on the AMO site

https://acceptableads.com/en/ for anyone who was looking for it

what, not using metaclasses in that case caused more "issues" than would of been caused by using metaclasses

multiple global values to track state, since can't bind the state to the class' creation, since the conversion to the final form of the class happened after its creation, vs being able to bind the state to the class' creation, since the conversion happens as the class is created

> No need for metaclasses simply to make the class construction locals dict an ordered dict. ORM library devs will be happy.

understatement with that. Saw someone trying to avoid using a metaclass for that, "had" to use descriptor objects which all used the same global counter to work out their order

> But why do you get to question Facebook's idea of morality?

well, its literally a discussion on facebook's morality. Its a bit hard to talk about that without questioning it.

> To question someone's morality solely due to it being different than yours is, bluntly, a waste of time.

I'm not trying to change facebook here, I don't care /that/ much. I saw a discussion ("its facebook's morality") that I wanted to contribute to ("But its a weird sense of morality innit?"). Isn't that what discussions are for?

Well, it can, but it does still make a weird line in the sand

You can be naked for the following reasons: Breastfeeding, Satire, Comedy, Artistic (but only photos of art), educational, and surgery (but only reconstructive)

but being naked because you didn't exactly have time to grab clothes while fleeing from being burnt up, is too far on the nudity scale?

so, hoster doesn't escape anything the users provide, and is more concerned about CSS instead of JS?

And then their site broke as soon as I clicked a link

Naming and shaming is also going to paint a big target on that company's head, since, you know, they collect plaintext data n' stuff

I think the thing to learn from the article is "how to go deep diving into an operating system's internals"

a 256x256 keyboard icon, is going to look pretty bad at 1cm x 1cm

A bunch of details really close together looks like noise, not information

the excessively excited "omg how could you even be discussing this??" is a bit offputting

Isn't there APIs for safely storing passwords outside of config data?

That is just 2fac, isn't it?

from [3]

> If you're not sure what this means, our product is Not For You.

Please don't do that, its childish and unimpressive.

Generally, if you comment less about Go, then you end up in less discussions about it

But where is the notable negative impact to those two people's lives?

I ain't denying that he was being a goober to them, but "at their expense" implies its at their expense

I don't see how it goes further than, them getting to the next worker at the airport, saying "UGH, your PR on twitter sucks!", and then being told "maam/sir, that is not our twitter account"

How was it at someone else's expense?

Could that not just be shuffled into the CI side of things

issues occur -> redeploy last-1 deployment

is there any compile-to-javascript languages which would be termed as "disgusting" and "impure"?

https://github.com/dropbox/pyxl for python comes to mind as something more enjoyable than manually doing tree-shaped OOP

    login = : //"read variable from indented block" symbol of magicness
        <form>
            <input type=email>
            <input type=pass>
            <button>{_("Sign in")}<button> //gotta have an excuse to inline code!
        </form>
    login.events({
        onsubmit (whatever, i dunno) {
            blap
        }
    });

seems a lot more fun!

All great and dandy, but I can't help to think what the continued fallout is going to be.

If someone is willing to smash your door down because you called them out on their dealings or perceived dealings, then that person is a threat to your safety.

I noticed (in the original article) an almost complete lack of entertaining the thought that they mite have (edit: fixed grammer) been acting maliciously on someone else's behalf. So that is exactly what happened.

And man, I don't know, his whole business gets shutdown automatically, and he end up liking it for any reason? I think the picture that BI is painting here is really not properly representative of his views (or at least I'd assume this is the case)

I feel like a person should be able to back their opinion up (for a specific case, not in general), instead of just mindlessly quoting a line from a bible.

its "safe" to say that, like its also "safe" to say that <article> will be used to denote articles in HTML

Yes, decorators can do whatever they want, but, in practical usage I'd say a majority of decorator usages do not mutate the class/function significantly from its original typed-out intent (like, they don't often add 8+ methods to a class for example, but of course they can)

not literally "safe" to say.

I know how decorators work and you might be missing the point I was making by a fair mile

The following don't mutate the mental map of how the function works, its "this function is still what I typed": "add logging" "add tracing" "register functions/objects for various reasons"

The following act as a filtering role, the inside isn't "changed", the mental map becomes "This function will operate within this feature in some way, but otherwise is still what I typed": "enable type validation" "change output formats to json/xml/yaml" "swap out implementations for global functions/vars" (assuming the implementations are comparable)

The following is "What I've typed is not a proper representation, and some things may act differently than usual" e.g. things that can take lists can no longer, due to needing to be serializable (and the least common decorator case):

"take a class, inspect a database schema and bind various internal attributes to update items in a row for that schema (somewhat common in ORMs)"

(and that is usually implemented via a subclassing of a Model class, which then in turn can implement a metaclass, to get the full mutate-class-on-creation funs, iirc)

- - -

> In particular, I don't see why mutating a type via a metaclass is preferable to using a decorator.

Its not a technical topic, its a semantics topic. while both can do whatever silliness they want, decorators are usually reserved for incidental tasks on the side, and wrapping the original function in some light filtering. Metaclasses are expected to do mutation to the class (hence requiring a metaclass), so semantically a subclass or metaclass would be more appropriate to use for this task, compared to a decorator (from the standard library, Enums come to mind as an example for this)

It feels a bit hampered by "bad" design decisions to me

I think its safe to say that the current view of what decorators do is, a) filter things going to functions (so they error, or hit a cache), or b) register a function with another library (e.g. flask path decorator)

This library does a lot more than that, so it seems that maybe a metaclass (which exists to mutate the class's creation) would be more appropriate?

This seems to act as a __init__ replacement, but it would be cool to act as a __init__ assistant (in other words, run the attr.s __init__, then run the user defined __init__)

The ordering of attrs matters a bit more than one would expect, not only does it define the attribute order for creating a new instance, it also defines the order of attributes when sorting against other classes. You would not want a id=attr.ib() at the top of the class definition, where it most makes sense!

The ordering of attrs is done through the .ib() call itself (which gives itself a number, and increments a global counter). This is a way of doing it, and practically might be the best way (it won't lead to any inconsistencies within a class), but it still feels weird

I personally won't use it, but I might make a competitor to it for personal use

I'd be asking the question of wether anything depended on `more` that couldn't depend on `less` already, but instead depends on more because more is not less.

Or, in other words, maybe the issue is cultural instead of technical, which would in practice, result in new users going to either more (the relic) or less (the bloated), depending on their views, instead of all new users going to less

edit: reading through the rest of the comments here, it seems a lot of people prefer more, for various reasons!