ubernostrum

Joined 18 years ago

Karma
12,994
Submissions
4,639
Member since
Jun 4
View on Hacker News

Recent submissions

Comment · 7 years ago
Your key flaw, and HN's key flaw -- and to be fair, one shared by a lot of other people! -- is the pursuit of civility as an end in itself. Horrendously evil people can accomplish their goals while publicly conducting themselves with perfect civility, as history has taught us again and again. And HN's stance is that that's OK, because all that really matters is they're civil about it.

This isn't the first time you've been told this. It's not going to be the last time you'll be told this. And I know telling you this isn't going to change anything, but I have to try anyway. We know now beyond any doubt (and a legion of Cassandras were telling us long ago) just how easily social-media sites (and yes, HN is one) can turn into instruments and enablers of radicalization despite openly enforcing "civility".

You know what the solution is. You know, on some level, that civility isn't an end in itself; you know that the actual ends to which people use civility as a means matter. You know some of those ends are very, very bad. And you know how to recognize the people doing it. You also hold in your hand the power to do something about it.

Abandon the civility-at-any-cost policy. Stop being an enabler for the stuff I've been responding to in this thread. Take it from an "experienced user" who's had to learn this the hard way when moderating elsewhere. Or, in keeping with the season, treat this as a visitation by a spirit who warns you of the chain you're winding about yourself, link by link, and change it while you still can.

Comment · 7 years ago
Comment · 7 years ago
[flagged]
Comment · 7 years ago
So to prevent an angry mob from taking away someone's platform, you insist we need the ability for an angry mob to take away someone's platform.

I think you need to think this through a bit more.

Comment · 7 years ago
[flagged]
Comment · 7 years ago
I don't know for certain, but what I would guess is that strptime() without a day-of-week indicator is ambiguous.

strptime() produces a datetime object, which consists of year, month, day, hour, minute, second, microsecond, time zone, fold. If you do something like "2008-12" with format "%Y-%m", strptime() will fill in the remaining arguments with day=1 and all time components set to zero, so what you get is datetime(year=2018, month=12, day=1, hour=0, minute=0, second=0, microsecond=0).

That works because it's unambiguous -- there aren't multiple possible numbering schemes for the day of the month in the strptime() formatting options.

But there are multiple possible numbering schemes for the day of the week, which means a year + week with no day-of-week format code is ambiguous. Worse, the two options don't even share a start: one of them begins numbering at 0 (Sunday) and the other at 1 (Monday).

So I'd guess the insistence on a day-of-week format code is to force you to indicate which day-numbering scheme you want, in order to avoid the possible ambiguity.

(and you might think it's reasonable to assume if someone uses ISO year + ISO week number, they'd also want ISO day-of-week number, but we're talking about dates and times here, and "reasonable" left the building a long time ago)

Comment · 7 years ago
It could just as easily be argued that, instead of "flipping", or swinging back and forth like a pendulum, the consistent trend of the past 400 years or so is toward increased tolerance of everything except intolerance.

There are people trying to reverse that trend, of course, but the volume at which they're currently screaming that they've been silenced is, I think, a pretty good indicator of the trouble they're having trying to pull it off.

Comment · 7 years ago
Inventing your own pseudo-normalization of Unicode is a worse idea than using the actual normalization forms Unicode defines.

Also, if you think you can decompose without allocating memory... well, try a code point like U+FDFA.

For reference, its decomposition is:

U+0635 U+0644 U+0649 U+0020 U+0627 U+0644 U+0644 U+0647 U+0020 U+0639 U+0644 U+064A U+0647 U+0020 U+0648 U+0633 U+0644 U+0645

(and that doesn't begin to touch any of the potential issues with variant forms, homoglyph attacks, etc.)

Comment · 7 years ago
Comment · 7 years ago
[flagged]
Comment · 7 years ago
I'm always a bit surprised by people who want to bring up historical analogies without admitting that the US has a long history of censorship; if anything, the type of hard-line free-speech stance assumed by many internet forum posters is an incredibly recent development in American law. And both public (enforced by law) and private (enforced by industry associations or the like) censorship regimes continue to exist in the US today.
Comment · 7 years ago
And just to clarify a bit: the specific restriction Python imposes is that if a strptime() format string contains one of %G (ISO year) or %V (ISO week number), it must also contain the other one, and must contain a day-of-week format code (%A, %a, %u, or %w).

Examples:

'%G/%m' is illegal; it contains %G without %V, and does not contain a weekday format code. Attempting to call strptime() with this format raises ValueError.

'%V/%u' is illegal; it contains a weekday format, but has %V without %G. Raises ValueError.

'%G/%V' is illegal; it contains both %G and %V, but does not contain a weekday format code. Raises ValueError.

'%G/%V/%u' is legal; it contains both %G and %V, and contains a weekday format code.

'%G/%V/%w' is legal; it contains %G and %V and a weekday format code. It's a bad idea, though, because %w numbers days 0-6 starting Sunday, while ISO (%u) numbers them 1-7 starting Monday.

If you need to work with ISO week date formats for some reason, you should stick to one of these two format strings:

'%G-W%V-%u'

or

%GW%V%u

The date of this comment (December 26, 2018) comes out as either '2018-W52-3' or '2018W523' using those format strings.

Comment · 7 years ago
From the perspective of Unicode, no. What you're looking for here is what Unicode calls "equivalence", and it comes in two variations: canonical equivalence and compatibility equivalence.

For example, "é" can be written as either U+00E9 LATIN SMALL LETTER E WITH ACUTE, or as the sequence U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT. These two options have canonical equivalence; what this means is that Unicode treats them as two ways of specifying exactly the same thing.

Now, consider "½". That's U+00BD VULGAR FRACTION ONE HALF. Generally you can replace that with the sequence U+0031 DIGIT ONE, U+002F SOLIDUS, U+0032 DIGIT TWO ("1/2"). This is not quite the same thing; most places where someone writes "½" can safely be replaced by "1/2", but not necessarily all, and it definitely doesn't work in reverse. This is compatibility equivalence, and under compatibility equivalence "½" maps to "1/2".

So to get to your actual question: U+017F LATIN SMALL LETTER LONG S has compatibility equivalence with U+0073 LATIN SMALL LETTER S. But U+03C2 GREEK SMALL LETTER FINAL SIGMA does not have any type of equivalence with U+03C3 GREEK SMALL LETTER SIGMA.

If you follow the general recommendations for things like comparing Unicode identifiers, you'll apply normalization to form NFKC (which decomposes by canonical equivalence, then recomposes by compatibility equivalence); this will turn a "ſ" into a "s". It will never turn a "ς" into a "σ".

Comment · 7 years ago
A lot of languages take their date/time formatting from C strftime (and quite a few simply use light wrappers around actual strftime), where the format code for ISO year is %G.

And FWIW, Python's (strftime-based) datetime library won't let you mix ISO and non-ISO format codes. Trying to use %G with %m, for example, raises an exception, as does trying to use %Y with %V (%V is the ISO week number format code).

Comment · 7 years ago
Only if you churn -- signing up for a card, redeeming the signup bonus, then signing up for another, and so on.

And card issuers know about churning. The highest-value cards also have limits to how often you can churn. Chase's "5/24" rule (if you've opened 5 or more new credit cards in the past 24 months, anywhere, Chase will automatically decline you on any application for one of their cards) is one of the more well-known anti-churning tactics, but not the only one. You have to immerse yourself in the churning/manufactured spending world to really get much more than one or two free tickets from card signup bonuses.

On the other hand, if you already travel enough to reach at least mid-tier status with one airline, it's often worth it to do so; that's when you start getting into large RDM bonus territory. Combine with the airline's branded card and you can easily generate enough mileage to take a nice vacation every year.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton