06:54 | <rkirsling> | "this is so not zen" |
08:03 | <Domenic> | The version I heard was that the comparison was between comprehensions and arrow functions, and people felt comprehensions didn't really add much once you had arrow functions and map/filter/etc. |
08:04 | <Domenic> | I think it was https://github.com/dherman/sudoku |
08:40 | <rkirsling> | that would make sense |
08:40 | <rkirsling> | Python picked a weird horse in that race |
13:02 | <TabAtkins> | Given the limited power of lambdas in Python, I think they made the right one for them |
14:27 | <rkirsling> | ah I'd always viewed it as "they made lambdas intentionally cumbersome such that comprehensions would be 'the one obvious way to do it'" |
14:28 | <rkirsling> | not sure if that's a post-hoc rationalization though |
14:29 | <jmdyck> | I think Python lambdas long predate comprehensions. |
14:32 | <rkirsling> | I think either not existing must be prior to Python's popularity but I don't see a justification for making lambdas deliberately hard to use otherwise |
14:32 | <jmdyck> | lambdas were 1.0, comprehensions were 2.0 |
14:33 | <annevk> | Whenever I write Python I tend to avoid lambdas and comprehensions, though I won't rewrite them away after some copypasta. Certainly aspects of the language I like less. (Though the 2 to 3 switch I still dislike the most of all things Python ever did.) |
16:16 | <James M Snell> | Hey all... trying to decide if a new proposal is worthwhile... Node.js recently received a request to add APIs to the
would become
Or something similar, with the There is, however, a preference within Node.js to avoid adding further to the
|
16:16 | <James M Snell> | This idea is that by building this into DataView , user code could avoid potentially buggy bookkeeping around the position |
16:16 | <James M Snell> | But it's certainly not clear if there's enough motivation to formulate a full proposal |
16:30 | <ljharb> | i don't think it would be a good idea to add statefulness anywhere, personally |
16:30 | <ljharb> | the pos++ code seems pretty simple as it is |
16:32 | <James M Snell> | it becomes a bit awkward and error prone when writing multiple values of different sizes but I share the concern about the statefulness. |
16:34 | <James M Snell> | fwiw, here's the relevant issue in Node.js https://github.com/nodejs/node/issues/58348 |
17:17 | <Michael Ficarra> | I was just gonna say "this sounds like they were inspired by Java's ByteBuffer", then I open the issue and that's exactly what they said |
17:23 | <Michael Ficarra> | I'd say they should use DataView and if they're concerned about the bookkeeping being messy, they should separate their business logic from the code that's responsible for serialisation to a bytestring so they're not interleaved |
17:28 | <Aapo Alasuutari> | This seems like it'd be awkward to fit onto the DataView API; either you'd have new APIs that move the cursor, or have some mode that makes the cursor move when the existing write APIs are called... At index 0? No, I guess new APIs are the only choice. |
17:30 | <Aapo Alasuutari> | 8 bytes more memory on DataView isn't too horrible, it's a rare object after all, but I guess the non-interaction between the cursor and the existing APIs would be somewhat weird. |
17:36 | <nicolo-ribaudo> | That seems similar to how RegExp has .lastIndex, do we consider it something good or a mistake? |
17:39 | <bakkot> | I definitely consider it a mistake |
17:39 | <bakkot> | but a wrapper class which took a regexp and also kept an index would be fine |
17:40 | <bakkot> | similarly, I don't think DataView should have an offset, but I would be fine with having a different class which kept an offset |
17:41 | <shu> | we shouldn't retrofit DataView |
17:41 | <bakkot> |
https://gist.github.com/bakkot/6726adcf9ed361790d1063b41dbf4148 |
17:41 | <shu> | this seems perfectly fine to be done in userland? |
17:41 | <shu> | not sure why it warrants a built-in |
17:41 | <bakkot> | that said I don't think this is worth adding to the language; the current state of things is fine and it's not hard to do |
17:43 | <shu> | not even done in userland, actually, Node can ship a thing if it thinks it's useful |
17:43 | <shu> | (unless it also doesn't want to do so unilaterally anymore due to other server runtimes. not sure what the situation is) |
18:21 | <kriskowal> | DataViewWithCursor is certainly useful and I’ve written one at least twice, for whichever methods the format demanded, most notably Zip. Same taste as bakkot for read/write methods, plus seek to rhyme with files. Agree with shu it’s not particularly important for it to be in the language. Not particularly important that it be omitted. There’s an async analogue (File ) if it’s backed by I/O. |
18:26 | <James M Snell> | (unless it also doesn't want to do so unilaterally anymore due to other server runtimes. not sure what the situation is) |
18:27 | <James M Snell> | This could also be a web platform API consideration |
18:27 | <James M Snell> | That is, we could ask whatwg to consider a standard API here |
18:29 | <shu> | it also doesn't feel like a web api |
18:30 | <James M Snell> | Ok, I'll take this as a sign that a proposal is unlikely to advance ;-) ... appreciate the feedback all |
18:30 | <shu> | yeah, my read on the feedback for "overlap with standard options" you're getting in this room is "unlikely to overlap, because people don't think it's worth adding to the language" |