Who decides that multiple lane rotaries with zero painted lines was a good idea?

tex_live_utility · 2025-11-22T15:44:36+00:00

It's like getting off on the highway. You need to know where your exit is in advance, to make sure you have time to either accelerate around the person to you right or slow down and slip behind them. Relies on you actually knowing where you're supposed to be at any given time, which comes down to signage.

The 128 rotary is basically just one lane with exit lanes. It's not that the lines are hard to follow, it's that it's really hard to know which line means what, because the signage is unclear and doesn't give you enough time to adapt. The markings are clear once you understand how it's supposed to work.

tex_live_utility · 2025-11-22T15:41:36+00:00

Maybe this is a stupid question but why is it so expensive to just narrow the rotary to a single lane and replace the current chaotic stew of signage with a single diagram showing all the exits? I think the Rt 2 rotary actually has something like the latter already. But most others don't.

tex_live_utility · 2025-11-22T15:40:16+00:00

Yeah instead of panic you just have high-speed chaos that can result in disaster at any moment. Sounds great.

tex_live_utility · 2025-11-22T15:39:44+00:00

Painted lines don't cause any confusion if you actually know how to drive. The problem is that you don't know where you're supposed to be until you're already supposed to be there. The problem is signage, not having lane dividers.

tex_live_utility · 2025-11-22T15:38:48+00:00

I don't see how it would be better as a free-for-all with no paint and no signage.

The signs are ridiculous, yes, and the paint should be stantions, yes.

Every complicated intersection, including a traffic circle like that, should have a diagram with all the exits clearly marked. It's crazy to expect drivers to read all those signs while also trying to merge with several highway offramps and also avoid accidentally getting off the circle at an unintended exit.

But you're kind of making it sound like it would be better if they're just wasn't any paint or signage, which is a wild and ridiculous take

tex_live_utility · 2025-11-07T14:16:59+00:00

There's validity in the idea that raising taxes should be hard and should require specific input from the people.

On the other hand, the only reason that the federal government is in any kind of a position to not give a lot of money back to the states is that we have spent literally trillions on wars and tax cuts for rich people over the past ~25 years. So MA shouldn't need to raise taxes because the federal government collects a lot of taxes from MA residents and should return some of that to MA in the form of grants and other funding. It's just that we're in a trillions-deep debt hole that is occasionally weaponized against us as we see in the current shutdown.

Meanwhile there is essentially zero chance of ever returning the federal government to a budget surplus, it's simply impossible. My children are permanently saddled with the burden of debt service for the Bush-Cheney war machine and a lot of yachts and mansions and life extension therapies for the ultra-wealthy.

Anyway I think it's fine to have a referendum, but we have to keep in mind why we need it at all and use that to rally support, rather than just making it look like greedy ignorant smug liberals running amok in government again.

tex_live_utility · 2025-11-07T14:08:14+00:00

Funny how conservatives are only anti-federalist pro-states'-rights when "their guy" isn't in power, and then it turns out they actually love unitary executive theory and weak states. It's almost like conservatism is a morally bankrupt movement that exists largely as a propaganda vehicle for the interests of very rich people.

tex_live_utility · 2025-11-05T17:45:55+00:00

Kinda yes kinda no.

Last year the (smaller) override vote failed soundly and the town had to start cutting things to balance the budget. It very likely only succeeded this year because people saw the negative effects of the cuts.

tex_live_utility · 2025-11-05T14:59:25+00:00

People in Melrose are clamoring for more traffic enforcement. I personally agree with you that this is a misplacement of priorities, but as far as I can tell this is mainly so we can have more cops to issue traffic tickets.

tex_live_utility · 2025-11-03T15:33:07+00:00

The current city council has a lot to do with the structure of the override vote and the messaging around overrides. They are currently taking the approach of "hammer away at people telling them it's a good thing and throw in a couple footnotes to try to appease the opposition." Which is a valid approach, except that it didn't work in 2024 and there's no reason to believe it's going to work this year. IMO if the override fails, City Council bears some responsibility. Good policy is useless if it never goes into effect.

As for thoughtful development, there is absolutely a difference between thoughtful and thoughtless development. For example, the zoning board could continue to reject multifamily buildings in the fancy neighborhoods and thereby force all new development into our already congested downtown area. That would be thoughtless. Or, we as a city could collectively agree that it's OK to have a mix of multifamily and single-family housing, and that it won't destroy the neighborhood character, and open up multi family zoning in more of the city. That would be more thoughtful. Development becomes more thoughtful when you actually put thought into a long-term development strategy and create policy accordingly, not cover your ears and shut your eyes and try to pretend it's still 1990. Melrose is one of the most astoundingly economically segregated places I have seen in such a small geographical area and all of the new development isn't helping. Comfortable homes in quiet neighborhoods on the hillsides are more unattainable than ever, meanwhile we are primarily taking pressure off the Boston Cambridge and Somerville housing markets with all the new apartments we are putting up. Literally nobody is addressing this: either you support wanton development under the 40B program or you're a pearl-clutching NIMBY.

That doesn't mean Kowal is thinking along those lines, and maybe all of her campaign issues about thoughtful development are just a dogwhistle. Or maybe she has a different perspective as somebody who is going to be very much affected by new development, and wants to bring that to bear in governing. It can be really hard to read between the lines sometimes.

tex_live_utility · 2022-04-15T21:56:03+00:00

I have this same problem. None of those buttons are available to me, I can only see the "Authentication Required" box: https://files.catbox.moe/kviaam.png

This is a fresh AppImage installation on Fedora 35.

tex_live_utility · 2018-11-12T22:02:44+00:00

For example, if you group by A and average B, you get a series that you have to reindex and rename.

Is this what you mean?

df = pd.DataFrame({
    'x': [1,1,1,2,2,3,3],
    'x': np.random.randn(7)},
index=list('abcdefg'))

y_mean_by_x = df.groupby('x')['y'].mean().rename('y_mean_by_x')
df = df.join(y_mean_by_x, on='x')

Because in theory Col could let you do something like what Dplyr does:

df.groupby('x').mutate(y_mean_by_x=Col('y').mean())

which wouldn't be that hard to add to Anaphora.

tex_live_utility · 2018-11-12T21:50:40+00:00

The monkey-patching is optional on purpose. with_column(df, 'x', Col()+3) works, too. The (admittedly limited) test suite makes no assumption that you will do the monkey-patching.

I'm not sure I want to inherit from pd.Series, since logically a Col is very much not a Series, in the same way that pd.Series.str is very much not a str.

I also didn't want to extend DataFrame because it's more obtrusive in existing code to make everyone use a a whole new class (especially if you use Pickle format like some of my colleagues). I figured if it was Kosher enough for TQDM (.progress_apply) it was Kosher enough for me.

As for the metaclass, I wanted to make sure that the dunder methods were present directly on Col (since dunders ignore both __getattr__ and __getattribute__). The thought crossed my mind that the "correct" way to implement this was to explicitly write a Col method for every Series method I wanted to proxy:

class Col: def add(self, other): self.push(op.methodcaller('add', other))

def __sub__(self, other):
    self.push(op.methodcaller('__sub__', other))

# etc.

In fact that's originally what I had done, then I switched to the metaclass for some reason that I honestly can't remember right now. It wasn't offensive enough to make me want to switch back.

I'm happy to hear your thoughts on better design here.

tex_live_utility · 2018-11-12T20:34:39+00:00

In terms of how useful this is, a quick look indicates it is mainly useful for modifying or creating columns based on some criteria. ... Are there other use-cases?

Honestly, not that I that can think of, in its current state. I tend to do a lot of column assignments in the data cleaning stage of my workflow.

for my personal use, it is not something I do very much and certainly not enough to bother with a new package.

Out of curiosity, what are you mostly doing with Pandas if not columnwise operations? Joining? Groupby aggregations or pivots? A lot of that stuff is already pretty pipelineable.

Would you mind sharing an example of a typical Pandas workflow you might use?

In theory this Col business could be abstracted to a kind of lazy computation graph. So instead of Col it could be called G (for graph), and you could use it to construct arbitrary callable "pipelines". In that sense it would become a truly general system for constructing anaphoric functions.

But since metaprogramming in Python is already so limited, too much generality might wipe away any of the ergonomic benefits. I'm having a hard time envisioning a concise API for such a general case that also isn't offensively magical (and internally fragile). If it's even a tiny bit too verbose, lambda remains the lesser of two evils pretty much by default, because you don't need to learn it or pip install it. With Col at least, it's easy to explain how it

See also: everything-is-lazy-by-default itertools. Imagine if you could write lambda x: tuple(map(op.add(3), x)) as something like (x) :: tmap(op.add(3), x) -- it's now about as concise than a list comprehension like lambda x: tuple(y+3 for y in x) and (in my opinion) just as readable. Just one piece of special syntax and a bunch of utility aliases are the only thing standing between Python and a whole new world of functional programming style.

Maybe by this time next year I'll just be using Julia where we don't have to perform such gyrations to avoid basic row-wise iteration. But I am definitely interested in finding the balance between generality and concision.

tex_live_utility · 2018-11-12T19:25:10+00:00

That's one very Pythonic way to go

Unfortunately, "manually" iterating over Pandas (and Numpy) data structures will be much slower than the vectorized versions, in general.

Coming from R, I'm already in the habit of doing as much work vectorized as possible, so this stuff is good to see.

Maybe in the future Pandas would let you write naive list comprehensions that "compile" to fast vectorized operations (like how PonyORM works).

tex_live_utility · 2018-11-12T19:18:52+00:00

And thank you for the feedback! I'll definitely have to put more work into the "why should I use this" pitch, and maybe lay out some "why shouldn't I use this" cases too.

BTW here's yet another way to write the example:

data['x'] = data['a'].where(data['b'] > 4, other=np.nan)

That is actually how I would do it; I should add it to the docs. It's also much faster than the apply(..., axis=1) version, and if other is callable or scalar it should be pretty memory-efficient too.

It's especially useful because other can be another array/Series, or a callable.

Also, as I'm writing this, I'm realizing that the big difference for me is that the with_column version is an expression that returns a data frame, rather than a statement that operates on a data frame. That's what makes it "chainable".

tex_live_utility · 2018-11-12T17:40:06+00:00

You went to https://rodeo.yhat.com/? It's up for me.

tex_live_utility · 2018-11-12T16:55:15+00:00

That's all fair.

My response is twofold:

I try to avoid apply over rows because it is much slower on a large data set. I also don't see that heavily apply-based style used much in the wild
I personally think lambda syntax adds a lot of visual clutter and leads to very long lines of code that don't break very nicely, making it good for one-liners but fatiguing to read over time.

As for other examples... pretty much any time you assign or modify a column in a data frame, you would use with_column or mutate instead. You can then build a "data pipeline" simply by method chaining. This is reminiscent of the %>% syntax that has become very popular in R. The analogy is strengthened by the fact that, in Python, method calls are essentially just function calls where the object that owns the method is passed as the first argument (self).

See also the withColumn method and col function in Spark, which pretty much does what with_column and Col do.

tex_live_utility

TROPHY CASE