User Controls

  1. 1
  2. 2
  3. 3
  4. ...
  5. 159
  6. 160
  7. 161
  8. 162
  9. 163
  10. 164
  11. ...
  12. 169
  13. 170
  14. 171
  15. 172

Thanked Posts by Lanny

  1. Lanny Bird of Courage
    TOBACCTERIA ALERT!
    The following users say it would be alright if the author of this post didn't die in a fire!
  2. Lanny Bird of Courage
    Originally posted by Clutch Yeah he's an ex heroin addict, now on methadone, low iq that got passed on.

    Yeah, but what's his email address?
    The following users say it would be alright if the author of this post didn't die in a fire!
  3. Lanny Bird of Courage
    The following users say it would be alright if the author of this post didn't die in a fire!
  4. Lanny Bird of Courage
    Originally posted by Clutch I know you guys are great shitposters so why not put that talent to some good use? Here are some examples of the RETARDED shit that these people think.

    I'm not sure you understand the core concept behind shitposting.
    The following users say it would be alright if the author of this post didn't die in a fire!
  5. Lanny Bird of Courage
    A common use case is when you have some kind of behavior you want to apply to several functions but where directly invoking some new function doesn't make sense. An example might be type sniffing, you could do this:


    def add(a, b):
    assert type(a) == int
    assert tybe(b) == int

    return a + b

    def subtract(a, b):
    assert type(a) == int
    assert tybe(b) == int

    return a - b


    This works but we'd like to lift the type check out of each, so we could refactor as:


    def check_are_ints(*args):
    for arg in args:
    assert type(arg) == int

    def add(a, b):
    check_are_ints(a, b)
    return a + b

    def subtract(a, b):
    check_are_ints(a, b)
    return a - b


    And this is better but on some level we know "check my argument are integers" isn't really the business logic in addition or subtraction, and further we think about this check as being a property of the function instead of part of it's logic. Using decorators we can:


    def args_are_type(fn, arg_type=int):
    def new_func(*args):
    for arg in args:
    assert type(arg) == arg_type

    return fn(*args)
    return new_func

    @args_are_type(int)
    def add(a, b):
    check_are_ints(a, b)
    return a + b

    @args_are_type(int)
    def subtract(a, b):
    return a - b


    This lets us parameterize the type we're checking against and it lifts the check out of the body of the function.

    Another common use case is if you want to "register" a function in some way, for example:


    registered_funcs = []

    def register(fn):
    registered_funcs.append(fn)
    return fn

    @register
    def foo_bar():
    ...

    # registered_funcs == [foo_bar]


    And another example that's actually pretty common to see in the wild:


    def memoize(fn):
    memo = {}

    def new_fn(*args):
    arg_hash = sum([hash(arg) for arg in args])

    if arg_hash not in memo:
    memo[arg_hash] = fn(*args)

    return memo[arg_hash]

    @memoize
    def add(a, b):
    print a, b
    return a + b

    add(1,1)
    add(1,1)
    add(1,2)

    # outputs:
    # 1 1
    # 1 2


    Again, all things you could do before but being able to "wrap" functions like this allows you to program in a more generic way and can help separate facts "about" functions (this function is memoized, this function checks types) from their core logic.
    The following users say it would be alright if the author of this post didn't die in a fire!
  6. Lanny Bird of Courage
    My advice is to not make a thread on the rare occasion you have sex as to avoid looking like a giddy little bitch.
    The following users say it would be alright if the author of this post didn't die in a fire!
  7. Lanny Bird of Courage
    Originally posted by hydromorphone lol Well, at least it's interesting and not boring. I come into a thread to read about some dope ass fried rice, which is cool and all, but then further in get a discussion about huffing starter fluid. You have to see the silver lining, and I think stuff like this is what makes this forum and our community great. Don't be depressed just because it goes off topic, celebrate the fact we can have a thread about fried rice that turns into one about abusing ether ;)

    but to get this shit back on topic: How do you go bout making fried rice? I never have made fried rice that comes out good, or even remotely tasting like fried rice. IDK wtf I'm doing wrong. Advise me on making dope ass fried rice, please.

    If you aren't adding egg (I didn't the first time I tried to make fried rice) then that's definitely a must, wisk some eggs with water or milk like you're making scrambled egg, then once everything else is cooked pour that on and cook on high until it's yellow and not soggy in texture.

    Also soy-sauce while cooking is a must.
    The following users say it would be alright if the author of this post didn't die in a fire!
  8. Lanny Bird of Courage
    Originally posted by Clutch I was a member of the original totse so maybe your the newbie. I've been through totse, totse2, sanctuary, red fern, and now this site so yeah I'm totally a pretender because I didn't post a history of my affiliation, and I don't give a fuck who sophie is.

    Ah, I see the problem sir. I'm sorry I have to inform you that you're a hardcore faggot.
    The following users say it would be alright if the author of this post didn't die in a fire!
  9. Lanny Bird of Courage
    It's not so much an "instead of" relationship. Decorators don't really do what you'd want multi-line lambdas to do nor vice versa. Really both features (and all lambdas, per the python idea of a lambda) don't express anything that couldn't be expressed in the language otherwise, they're just nice syntactic sugar.

    To answer the questions separately, decorators are in the language because Guido liked annotations in Java, decorators are more powerful than annotations but use the same syntax and provide a superset of the annotation functionality. Multi-line lambdas are not in the language because Guido has a wierd dislike of functional programming (same reason map/enhancement/reduce have been relegated to functools), also he's said it will complicate the parser which is true but no one's really satisfied by that because nested list comprehensions are a lot more complexity in the parser (and for the reader) and no one has said that needs to be cut from the language.

    To go into a little more depth: The decorator syntax is just a way of giving a name to the output of a higher order functions, functions that take a function and return a function, we see the equivalence in your second example. Higher order functions don't exist in languages like C and Java, which is where python inherits a lot of its syntax. In these languages naming functions is kind of special, `int foo(int a) { return a*2; }` creates the name `foo` forever as an immutable declaration entirely different from a variable named foo. There is no way in C to say `bar = foo` down the line (yes function pointers exist but that's different). That is important for compiler optimizations like function inlining and metadata discarding (under optimized compilation the string "foo" doesn't exist anywhere in a program defining a function foo, all references are replaced by an address rather than the function's name). This means defining a function called bar in python by doing `bar = decorate(foo)` looks pretty strange to a lot of programmers. Arguably (I'd agree) it hurts readability because when you see a top-level `def` you're like "ok, cool, this package exports this function" but when you see `bar = decorate(foo)` you think "what is this? constant? global? decorated function?" plus you're still exporting the undecorated `foo` as part of the package. The decorator syntax fixes this by keeping the `def ...` syntax for defining decorated functions and prevents the export of the undecorated function, in fact it's impossible to call the undecorated function that way.

    Actually I see now why lambdas get involved, because actually this is kind of like a lambda. Lambdas are un-named functions and the pre-decorated function using the decorator syntax is also unnamed, so yeah, in terms of removing the undesirable creation of an undecorated function under some accessible name both multi-line lambdas and the decorator syntax could accomplish the same goal. The added bonus of decorators is that they read better. They're not as flexible as muti-line lambdas because they're not expressions (you can't assign them to a name with `=` or pass them as an argument) but as someone who would like to see multi-line lambdas added to the language, I don't think they would displace the need for (or at least the utility of) the decorator syntax.

    Originally posted by SBTlauien I never learned lambdas but I started. It didn't seem like something needed. Correct my if I'm wrong.

    "lambda" in the computer science sense is a very important idea, arguably the most powerful single idea in computation. "lambdas" in python are lambdas in the CS sense, but so are functions. The way we use the lambda keyword in python is really kind of a shorthand. Still a useful tool, you see them pretty often in code and they're just a handy too so I'd say it's something worth learning (honestly they're not very complex once you understand that functions are objects) but there's never been a program where you strictly needed to use the lambda keyword.
    The following users say it would be alright if the author of this post didn't die in a fire!
  10. Lanny Bird of Courage
    Yes, and I encourage you to pepper spray the next woman you encounter
    The following users say it would be alright if the author of this post didn't die in a fire!
  11. Lanny Bird of Courage
    Yes
    The following users say it would be alright if the author of this post didn't die in a fire!
  12. Lanny Bird of Courage
    u r vry dum
    The following users say it would be alright if the author of this post didn't die in a fire!
  13. Lanny Bird of Courage
    Originally posted by §m£ÂgØL For the record I have never ever texted Bill Krozby anything of importance. I have very purposely fed Bill Krozby lies to see what he'd run his mouth about and this thing about her being a heroin addict isn't even one of them lol.

    Also the baby is not mine in any which way, so you can leave me right the §m£ÂgØL out of this.

    Somebody should update that Sonic image with another slide pls.

    kthnx bai

    The following users say it would be alright if the author of this post didn't die in a fire!
  14. Lanny Bird of Courage
    Originally posted by Bill Krozby lol, ^ you wish you could a taste of deez nutz queermo.

    but seriously the pile on Bill Krozby post has risen like at least 35 percent since enter left and since I told sophie I didn't need or want his props and since i made a 20 page thread about having another child. haterz gonna hate lol, am i right fam?

    Post last edited by Bill Krozby at 2017-01-04T04:46:36.133023+00:00

    Your victim level went up like 8 points from that post alone. Let's analyze:

    >deez nutz
    victim

    >queermo
    victime

    >but seriously
    something a victim would say

    >run on sentence trying to justify yourself
    victimhood confirmed

    >cry harder faggot.
    victimlogical projection

    > haterz gonna hate
    victim camouflage response

    > i right fam
    victim.

    >Post last edited by Bill Krozby at 2017-01-04T04:46:36.133023+00:00
    UNPRECEDENTED FLOURISH OF UNEQUALED VICTIMHOOD!
    The following users say it would be alright if the author of this post didn't die in a fire!
  15. Lanny Bird of Courage
    why are you trying so hard malice?
    The following users say it would be alright if the author of this post didn't die in a fire!
  16. Lanny Bird of Courage
    better dead than a hiki, like I always say
    The following users say it would be alright if the author of this post didn't die in a fire!
  17. Lanny Bird of Courage
    Originally posted by Bill Krozby I'm not a jedi dude, im hispanic and irish b

    It would make sense that when you fuse the niggers of two different continents Bill Krozby would be the result
    The following users say it would be alright if the author of this post didn't die in a fire!
  18. Lanny Bird of Courage
    Originally posted by reject I went out and bought cider, have a can in front of me yet I'm drinking tea instead. Something's wrong

    My excuse is I'm out of country and haven't really had a chance to drink. Too many people. Drinking alone is the only true drinking.

    Originally posted by Malice I'll stick to all natural. I wouldn't even think about using syncans without combining it with a high CBD strain, at the very least.

    A few weeks ago and you'd be screaming "naturalistic fallacy" and "mental biases REEEE!!!" at the top of your lungs if someone else posted that

    Post last edited by Lanny at 2017-01-04T21:35:59.274504+00:00
    The following users say it would be alright if the author of this post didn't die in a fire!
  19. Lanny Bird of Courage
    ^that, argv is conceptually an array of strings, the arguments passed when the program was invoked. Strings are type *char (pointer to an (array of) char) so an array of them is referenced by type char**. If you want the first arg passed to your program you use argv[1], which is a string. As for getting it into something you can pass to setsockopt() you can't just pass the arg since, as mentioned, it's a string. `AF_INET` is just an integer that has some meaning to the socket library. You need to parse your arg list and figure out what each arg means yourself (you can't do it dynamically because the relationship between the string "AF_INET" and the constant is lost in compilation). Something like (not tested):


    int main(int argc, char ** argv) {
    // Default to AF_INET
    int AF = AF_INET;
    char *IPv6_FLAG = "--AF_INET6";

    for (int i=0; i<argc; i++) {
    if (!strcmp(argv[i], IPv6_FLAG)) {
    AF = AF_INET6;
    }
    }

    socket_fd = socket(AF, SOCK_STREAM, 0);
    }


    Post last edited by Lanny at 2017-01-05T08:51:10.120481+00:00
    The following users say it would be alright if the author of this post didn't die in a fire!
  20. Lanny Bird of Courage
    Wayback machine has most the threads archived.
    The following users say it would be alright if the author of this post didn't die in a fire!
  1. 1
  2. 2
  3. 3
  4. ...
  5. 159
  6. 160
  7. 161
  8. 162
  9. 163
  10. 164
  11. ...
  12. 169
  13. 170
  14. 171
  15. 172
Jump to Top