?

Log in

entries friends calendar profile Elf Sternberg's Pendorwright Projects Previous Previous
Elf M. Sternberg

Module Iterators, as defined in pkgutil.py, aren’t really part of the mess that has been imposed on us by PEP-302 and its follow-on attempts to rationalize the loading process, but they’re used by so many different libraries that when we talk about creating a new general class of importers, we have to talk about iterators.


Iterators, after all, are why I started down this project in the first place. It was Django’s inability to find heterogeneously defined modules that I set out to fix.


Iterators are define in the pgkutil module; their entire purpose is, given some kind of reference to an archive, to be able to list the contents of that archive, and to recursively descend into that archive if it happens to be a tree-like structure.


When you call pkgutil.iter_modules(path, prefix), you get back a list of all the modules within that path or, if no path is supplied, all the paths in sys.path. As I pointed out in my last post, the paths is sys.path aren’t necessarily paths on the filesystem or, if they are, they’re not necessarily directory paths. All that matters is that for each path, a path_hook exists that can return a Finder, and that Finder has a method for listing the contents of the path found.


In Python 2, pkgutil depends upon Finders (those things we said were attached to meta_path and path_hooks) to have a special function called iter_modules; if it does, that function is used to list the contents of the “path”.


In Python 3, the functools.singledispatch tools is used to differentiate between different Finders; once a Finder has been identified by path_hooks, the singledispath us used to find a corresponding resource iterator for that Finder. It doesn’t necessarily have to be a method on the Finder, although the default has a classmethod that is its finder.


An iterator is pretty straightforward; once you know the “path” (resource identifier) and the Finder for that path, you can call a function that checks for the presence of modules. In the case of FileFinder, that function is a combination of listdir, isfile, and isdir/isfile' to check fordir/init` pairs indicating a submodule.


For our purposes, of course, we had to provide a path_hook that eclipses the existing path_hook, and we had a provide a Finder that was more precisely ours than the inherited base FileFinder, so that single dispatch would find ours before it found FileFinder‘s and still work correctly.




There is one other module I have to worry about: modulefinder. It’s not used often, it’s not used by Django or any of the other major tools that I usually use, and it’s never been covered by Python Module of the Week. That doesn’t mean that it’s hard-coding of the ‘.py’ suffix isn’t problematic. I’m just not sure what to do about it at this point.

Leave a comment

It’s time to come around to a point that’s been bugging me for a long time: why is the Python import routine so, well, so darned convoluted? The answer is “history,” basically the history of Python and the attempt to turn import foo.bar.baz into a tool that’s incredibly easy to use and understand for the common programmer, yet flexible enough to give the advanced programmer the power to redefine it into whatever else it has to mean.


We’ve talked about how the system has two different loading systems: the sys.meta_path and the sys.path_hooks, and how the latter is just as arbitrary as the former: the last path_hook is for the filesystem, so it runs os.isdir() on every item in sys.path and only offers to handle the ones that returns true, and it only runs after everything else has been run, so:



  • If a meta_path interpreted an import fullname with respect to a path that’s a directory, the default won’t get it,

  • If a path_hook said it could handle it, the default won’t get it,


… and so on.  The whole point of  using first-one-wins priority pathing is to leave the responsibility for not failing up to the developer. The default really is the fallback position, and it uses only a subset of sys.path.  The formal type of a sys.path entry is… no type at all. It could be a string, a filesystem directory iterator, an object that interacts with a path_hook. It could be anything at all. The only consideration is that, if it can’t be coerced into a string that os.isdir() can reject, you had better handle it before it falls through to the default.


It’s really time to call it like it is: sys.path and sys.path_hooks are a special case for loading. They’re the original special case, but that’s what they are. They lead to weird results like one finder saying it can handle foo.bar.baz and another foo.bar.quux, turning the leading elements of the fullname into arbitrary and meaningless tokens.


I wish I could call for a more rational import system, one in which we talked only about resource managers which had the ability to access resource archives, iterate through the contents, identify corresponding resources, load the contents of that resource, and compilers that could identify the text that had just been accessed (via whatever metadata was available) and turn it into a Python module.


But we can’t. Python is too well-established to put up with such rationalizing shenanigans, and too many people are dependent upon the existing behavior to help make it so. Python was born when NFS was the thing, when there were no real open-source databases, no object stores. Python was released two years before the Mosaic web browser! It would be far too disruptive. So we’ll keep getting PEPs forever trying to rationalize the irrational.


That’s okay. It gives me something to get paid for.


But, it does point out one major flaw: because Finders and Loaders are so intimately linked, even if we manage to rationalize FileFinder and SourceFileLoader, that’s only with respect to the Filesystem. We’ll have to make equivalent loader/finders for any other sort of accessor, be it Zipfiles or any of the other wacky resource pools that people have come up with.


Unfortunately, I don’t have a good plan for those. Fortunately, filesystems are still the most common way of storing and loading libraries, so concentrating on those gets us 99% of the way there.

Leave a comment

The Semantics of Python Import, Part 3: Loaders


In the last post we discussed Finders. The whole point of a Finder is to find a resource stored somewhere (usually a file on a filesystem, but it could be anything– a row in a database, a webpage, a range in a zip file) and supply the appropriate loader for it.


More accurately, there is a “FinderFinder” mechanism by which sys.meta_path and sys.path are searched to find the best Finder to run against a resource, and then the Finder is invoked to find the loader to load the resource. This lets Python differentiates between the archive (resource type– folder, database, zipfile, etc), the resource itself (file, row/column, zipfile index), and the type of that resource: source code (.py), compiled Python bytecode (.pyc or .pyo), or a compiled binary (.so or .dll) file that conforms to the Python ABI.


The point of the Loader is to take what the Finder has found and convert that resource into a stream of characters, which it then turns into Python executable code. Compared to the Finder, the Loader is pretty simple.


Typically, the Loader does whatever work is necessary to read in and convert (for example, to uncompress) the resource, compile it, attach the resulting compiled code as the executable to a new Module object, decorate the object with metadata, and then attach that new module object to the calling context, as well as caching a copy in sys.modules.


That’s more or less it.


Python 3.4 introduces the idea of a ModuleSpec, which describes the relationship between a module and its loader, in much the same way that the ModuleType describes a relationship between a module and the modules that import it.


Unfortunately for my needs, ModuleSpec doesn’t address several critical issues that we care about for the Heterogeneous Python project. It doesn’t really address the disconnect between Finders, Loaders, and the navigation of archives; Finders and Loaders are still very much related to each other with respect to the way a resource is identified and incorporated into the Python running instance.


Typical import tutorials focus on one of two different issues: loading Python source out of alternative resource types (like databases or websites), or loading alternative source code that cannot ever be confused with or treated as Python source. An example of the latter would be to have a path hook early in sys.path_hooks that says, “That path there belongs to me, and it contains CSV files, and when you import from it, the end result is an array of processed CSV rows.” By putting it before all other path hooks, that prevents Python from Finding inside that path and rejecting its contents for not having any .py files.


Our goals are different: A directory in sys.paths should be able to have a mixed code: CSV files, Hy (lisp) files, regular Python files, and byte-compiled Python files, and the loader/finder pair should be able to understand and interpret all of them correctly.


To do that, the loader has to be able to find the right compiler at load time. But there’s a problem: Python 2 hard-codes what suffixes (filename extensions) it recognizes and compiles as Python in the imp builtin module; in Python 3 these suffixes are constants defined in a private section of importlib; in either case, they are unavailable for modification. This lack of access to the extensions list prevents the discovery of heterogenous source code packages.


We have to get in front of Python’s native handlers, supply our own compilers for our own suffixes and fall back on Python’s native behavior when we encounter native suffixes.


I can now announce that Polyloader accomplishes this.  After you import polyloader, you call polyloader.install(compiler, [extensions]) for files that compiler can handle, and it… works.


It works well with Hy. And it works performantly and without breakage on a modern Django application, allowing you to write Django models, views, urls, management commands, and even manage.hy itself, in Hy.


There are three more posts in this series: Python Package Iterators, the resource-vs-compiler problem, and a really crazy idea that may break Python– or may finally get around all the other code that hard-codes “.py” problematically (I’m looking at you, django.core.migrations.loader, and you, modulefinder).

Leave a comment
Out of curiousity I installed Pokémon GO on my phone a couple of days ago and... it's addictive. I'm already a walker who enjoys wandering around my city for my lunch break and taking different routes to get from the office to the light rail station, so having another reason to look around and register the landmarks, learn about ones I haven't seen before, and learn their names was particularly compelling.

The light rail passes over two dozen pokestops (a landmark that you can visit, learn about, and often get Pokémon GO tools from) between the sports arenas and the airport. Just attentively ticking each one as you pass is a great way to restore all your pokeballs (the primary tool of the game) after dealing with yet another effin' Zubat (that's a kind of Pokemon).

Vox tried to explain why Pokémon GO was "destined to go viral," but its explanation— that the thirtysomethings playing it now were ten-year-olds when it came out and so are going through a nostalgia kick enhanced by alternate reality— doesn't really work for me. I already

was thirty when Pokemon first came out. So why do I like it? It can't be just the grand tour; I could have downloaded any app at all for that.

I like it because I like talking to people, but I'm bad at it. Tragically so. I never know what to say. Like most people, I have a limited amount of time to cultivate hobbies and culture, but my culture and those of most people don't overlap— I don't watch much TV and when I do it's not Game of Thrones, my music tastes are weird, and I don't watch sports. My own interests are either deeply geeky or distinctly uncomfortable topics for small talk.

You can tell a Pokémon GO player from the way they hold their phone while walking and looking around. There's a combination of situational awareness and attitudinal intensity that's different from someone reading messages or even navigating with a map app. Best of all, they often want acknowledgement; talk to a Pokémon GO player and they'll tell you all about the best catch they've had that day, or where the richest pokestop of the morning was.

Pokémon GO gives people an excuse to interact with each other, to get out of our shells and see each other for a moment. It's surprisingly humanizing in that way. It gives you a rich context for conversation that's not just about the banality of the weather or the

touchiness of local politics, while at the same time constraining that conversation so that embarrassing other details can be put off. It's just silly enough to get you over the hump of introduction, and having adults acknowledging each other's ridiculousness, the ways we manage our stressful lives by being ridiculous, is empowering all on its own. It gives me a rare chance to do something I enjoy while constraining the risks of doing so to the point where any anxiety I have is manageable.

I'm not sure if I'll stick with it. I've stuck with Neko Atsume for a couple of months, although now I'm down to that one last cat, so I'm almost to the end, and maybe Pokémon GO will be my new "casual" game for a while.

Tags: , ,
Current Mood: happy happy

Leave a comment
I grew up in the kink community. This is only vaguely true, but it's got a ring of truthiness to it. I was first introduced to The Lesbian SM Safety Manual when I was 24 years old, and have never looked back since. It gave me a vocabulary for asking for what I wanted, for asking the other person what he or she wanted, and for negotiating safety. That power, to say clearly what I needed from my partners to be and feel safe, got me through the height of the AIDS crisis while indulging in pretty extreme kinks without ever catching so much as a cold, much less HIV or hepatitis. Today I'm 50, still whole, still kinky, still disease-free.

Not every kink party is a paragon of virtue. (Shocking, I know!) Over those years I attended more than a few where alcohol, marijuana, amyl, and even cocaine and methamphetamines were readily available. The buzzword "chemsex" for having sex while high became a thing.

Here's the thing, though: at the parties at least, safewords and boundaries were still sacrosanct. It didn't matter how high you were, how out of your mind your were, you were still responsible for your actions and you would lose the privilege of attending future events if you violated them. I can't speak for how people behave in private settings, obviously, but in the public settings there are cultural requirements you only ever get once chance to violate.

It was everyone else's responsibility to step in and say, "Hey, that's not right. I don't think he's awake enough, aware enough to consent."

This does happen. I've seen it happen. I've seen it happen often enough that I believe ordinary human beings are perfectly capable of it. But more than that, I've seen ordinary kinky people in the deep heat of mid-scene hear a safeword and honor it. Top or bottom, master or slave, flogger or flagellant, fist fucker or lube puppet, everyone in a scene has a right to use their safeword and a responsibility to hear it when others use it. This is drilled into everyone who comes into The Scene. And when you're too far gone, whether by drugs or emotion or exhaustion, it's your responsibility to know that and not play.

This is an important cultural standard for me. Safewords and honest negotiation were critical to goddamn survival when I came out during the mid-90s at the height of the AIDS crisis. Even aside from the risk of disease, there was always the risk of dealing with an incompetent, or someone arrogantly stupid. Being able to talk ahead of time, being allowed a public space in which to negotiate, being able to call on help, all helped ensure my well-being and comforted my anxiety when I was putting myself out there.

Which brings me to Brock Turner and the Stanford sexual assault case, because there is no place to place the blame for what happened anywhere other than Brock Turner. You can't blame the alcohol. You can't blame his peers. You'd better not blame the girl for drinking. You can't even blame the people who supplied the alcohol. Turner knew what he was doing. The women on his swim team knew he was "a creep." He took pictures of his victim's naked body before he digitally penetrated her.

If you can imagine yourself in Turner's shoes, imagining alcohol taking you over to the point where you rape someone, there's something seriously wrong with you. Get help. If you say to yourself, "When I was young and stupid, that could have been me," it still could be you. Get help.

Consent culture matters more than ever. Claiming that there are exceptions or mitigating circumstances is to claim a privilege for your sex, or your class, that you haven't earned and don't deserve. And if you want to blame his youth, or his peers, or the alcohol, well, you're not stupid.

No, you're just cruel.

Get help.

Current Mood: annoyed annoyed

Leave a comment

In the last post, I introduced the concepts of the module object, module, and package, concrete objects that exist within the Python runtime, as well as some basic ideas about packaging, finding, and loading.


In this post, I’ll go over the process of finding, what it means to find something, and what happens next.


A Clarifying point


I’ve been very careful to talk about finding vs. loading vs. listing in this series of posts. There’s a reason for that: in Python 2, the terms "Finder" and "Importer" were used interchangeably, leading to (at least on my part) massive confusion. In actual fact, finders, hooks, loaders, and listers are all individual objects, each with a single, unique method with a specific signature. The method name is different for each stage, so it is theoretically possible to define a single class that does all three for a given category of module object, and only in that case, I believe, should we talk about an "Importer."


In Python 2.6 and 2.7, the definitive Finder class is called pkgutil.ImpImporter, and the Loader is called pkgutil.ImpLoader; this was a source of much of my confusion. In Python 3, the term "Importer" is deprecated and "Finder" is used throughout importlib. I will be using "Finder" from now on.


Finding


When the import <fullname> command is called, a procedure is triggered. That procedure then:



  • attempts to find a corresponding python module

  • attempts to load that corresponding module into bytecode

  • Associates the bytecode with the name via sys.modules[fullname]

  • Exposes the bytecode to the calling scope.

  • Optionally: writes the bytecode to the filesystem for future use


Finding is the act of identifying a resource that corresponds to the import string and that can be compiled into a meaningful Python module. The import string is typically called the fullname.


Finding typically involves scanning a collection of resources against a collection of finders. Finding ends when finder A, given fullname B, reports that a corresponding module can be found in resource C, and that the resource can be loaded with loader D."


MetaFinders


Finders come first, and MetaFinders come before all other kinds of finders.


Most finding is done in the context of sys.path; that is, Python’s primary means of organizing Python modules is to have them somewhere on the local filesystem. This makes sense. Sometimes, however, you want to get in front of that scan and impose your own logic: you want the root of an import string to mean something else. Maybe instead of directory.file, you want it to mean table.row.cell, or you want it to mean website.path.object, to take one terrifying example.


That’s what you do with a MetaFinder: A MetaFinder may choose to ignore the entire sys.path mechanism and do something that has nothing to do with the filesystem, or it may have its own filesystem notion completely separate from sys.path, or it may have its own take on what to do with sys.path.


A Finder (both MetaFinder and FileFinder) is any object with the following method:


[Loader|None] find_module([self|cls], fullname:string, path:[string|None])

The find_module method returns None if it cannot find a loader resource for the provided fullname. The path is optional; in the standard Python implementation, when the path is None it means “use `sys.path`”; when it’s set, it’s the path in which to look.


A MetaFinder is placed into the list sys.meta_path by whatever code needs the MetaFinder, and it persists for the duration of the runtime, unless it is later removed or replaced. Being a list, the search is ordered; first match wins. MetaFinders may be instantiated in any way the developer desires before being added into sys.meta_path.


PathHooks and PathFinders


PathHooks are how sys.path is scanned to determine the which Finder should be associated with a given directory path.


A PathHook is a function (or callable):


[Finder|None] <anonymous function>(path:string)

A PathHook takes a given directory path and, if the PathHook can identify a corresponding FileFinder for the modules in that directory path and return a constructed instance of that FileFinder, otherwise it returns None.


If no sys.meta_path finder returns a Loader, the full array of sys.paths ⨯ sys.path_hooks is compared until a PathHook says it can handle the path and the corresponding finder says it can handle the fullname. If no match happens, Python’s default FileFinder class is instantiated with the path.


This means that for each path in sys.paths, the list of sys.path_hooks is scanned; the first function to return an importer is handed responsibility for that path; if no function returns, the default FileFinder is returned; the default FileFinder returns only the default SourceFileLoader which (if you read to the end of part one) blocks our path toward heterogeneous packages.


PathHooks are placed into the list sys.path_hooks; like sys.meta_path, the list is ordered and first one wins.


The Takeaway


There’s some confusion over the difference between the two objects, so let’s clarify one last time.


Use a meta_finder (A Finder in sys.meta_path) when you want to redefine the meaning of the import string so it can search alternative paths that may have no reference to a filesystem path found in sys.path; an import string could be redefined as a location in an archive, an RDF triple of document/tag/content, or table/row_id/cell, or be interpreted as a URL to a remote resource.


Use a path_hook (A function in sys.path_hooks that returns a FileFinder) when you want to re-interpret the meaning of an import string that refers to a module object on or accessible by sys.path; PathHooks are important when you want to add directories to sys.path that contain something other than .py, .pyc/.pyo, and .so modules conforming to the Python ABI.


A MetaFinder is typically constructed when it is added to sys.meta_path; a PathHook instantiates a FileFinder when the PathHook function lays claim to the path. The developer instantiates a MetaFinder before adding it to sys.meta_path; it’s the PathHook function that instantiates a FileFinder.


Next


Note that PathHooks are for paths containing something other than the traditional (and hard-coded) source file extensions. The purpose of a heterogeneous source file finder and loader is to enable finding in directories within sys.path that contain other source files syntaxes alongside those traditional sources. I need to eclipse (that is, get in front of) the default FileFinder with one that understands more suffixes than those listed in either imp.get_suffixes() (Python 2) or importlib._bootstrap.SOURCE_SUFFIXES (Python 3). I need one that will return the Python default loader if it encounters the Python default suffixes, but will invoke our own source file loader when encountering one of our suffixes.


We’ll talk about loading next.

Leave a comment
Yesterday afternoon I made my usual commute home, but it was not the pleasant ride I've come to expect. I walk from my office through downtown to the underground, where I hop on the light rail that runs from the University of Washington through downtown, then up the Martin Luther King corridor to the airport. It's usually a very pleasant ride, 35 minutes. Sometimes its crowded, and rarely crowded enough I have to stand.

There has been an effort by the local press, egged on by the always anti-transit conservative press, to document a spate of assaults on public transit in the past year. So that's also very much on my mind.

As the train exited the underground and started through the light industrial zone, a man got on with a bicycle. He was white, scruffy and dirty, dressed in overalls and carrying a bucket and squeegee. I was sitting on the bench next to the doors, and an attractive young woman in her mid-20s was sitting next to me.

He started talking at her. He got louder and louder. She started to look away uncomfortably, and other people on the train were getting equally uncomfortable. I decided to try something: I very deliberately pulled out my cell phone and took his photograph.

"Hey, you! You think you can just take my picture like that?" He turned his attention to me. He didn't move any closer, fortunately. But he then went on a rant. "You. I never forget a face. I will never forget you. If I see you twenty years from now, if some fool like you even lives that long, I will deliver my punishment on you. I will. I never forget. Never. You can't just take someone's picture like that without permission." On and on like that for the entire rest of the ride. I managed to deflect his attention from the woman, but that didn't make the rest of the ride at all pleasant. He went from demanding attention to making vague but abusive threats.

When I reached the commuter station, I was able to get off. He stayed on, with the woman. There was only one more stop left.

This is the United States. Where the fucking homeless are armed. In fucking Seattle. Where anyone and everyone could be a target because of our gun culture. And where anyone can become a poorly trained, adrenaline-activated "good guy with a gun" and actually create more injury. "Terrified" doesn't begin to cover what situations like this begin to be with that kind of awareness floating around just days after the Orlando massacre. Where I end up on a train looking at some scruffy lowlife who could end me and everyone else on this train if he got pissed off enough.

America is a horror show. So many things, enforced by guns at the low level, and by courts controlled by the powerful at the high, work to keep us cowed.

Tags:
Current Mood: scared scared

6 comments or Leave a comment

A minor bug in the Hy programming language has led me down a rabbit hole of Python’s internals, and I seem to have absorbed an awful lot of Python’s import semantics. The main problem can best be described this way: In Python, you call the import function with a string; that string gets translated in some way into python code. So: what are the exact semantics of the python import command?


Over the next couple of posts, I’ll try to accurately describe what it means when you write:


import alpha.beta.gamma
from alpha import beta
from alpha.beta import gamma
from .delta import epsilon

In each case, python is attempting to resolve the collection of dotted names into a module object.


module object: A resource that is or can be compiled into a meaningful Python module. This resource could a file on a filesystem, a cell in a database, a remote web object, a stream of bytes in an object store, some content object in a compressed archive, or anything that can meaningfully be described as an array of bytes (Python 2) or characters (Python 3). It could even be dynamically generated!


module: The organizational unit of Python code. A namespace containing Python objects, including classes, functions, submodules, and immediately invoked code. Modules themselves may be collected into packages.


package: A python module which contains submodules or even subpackages. The most common packaging scheme is a directory folder; in this case the folder is a module if it contains an __init__.py file, and it is a package if it contains other modules. The name of the package is the folder name; the name of a submodule would be foldername.submodule. This is called regular packaging. An alternative method (which I might cover later) is known as namespace packaging.


Python has a baroque but generally flexible mechanism for defining how the dotted name is turned into a module object, which it calls module finding, and for how that module object is turned into a code object within the current Python session, called module loading.


Python also has a means for module listing. Listing is usually done on a list of paths, using an appropriate means for finding (identifying) the contents at the end of a path as Python modules.


The technical definition of a package is a module with a __path__, a list of paths that contain submodules for the package. Subpackages get their own__path__. A package can therefore accommodate . and .. prefixes in submodules, indicating relative paths to sibling modules. A package can also and to its own __path__ collection to enable access to submodules elsewhere.


 




The problem I am trying to solve:


Python module listing depends upon finder resolving a path to a container of modules, usually (but not necessarily) a package. The very last finder is the default one: after all alternatives provided by users have been exhausted, Python reverts to the default behavior of analyzing the filesystem, as one would expect. The default finder is hard-coded to use the Python builtin imp.get_suffixes() function, which in turn hard-codes the extensions recognized by the importer.


If one wants to supply alternative syntaxes for Python and have heterogenous packages (for examples, packages that contain some modules ending in .hy, and others .py, side-by-side)… well, that’s just not possible.


Yet.


In the next post, I’ll discuss Python’s two different finder resolution mechanisms, the meta_path and the path_hook, and how they differ, and which one we’ll need to instantiate to solve the problem of heterogenous Python syntaxes. The actual solution will eventually involve eclipsing Python’s default source file handler with one that enables us to define new source file extensions at run-time, recognize the source file extensions, and supply the appropriate compilers for those source files, while falling back on the default behavior correctly when the extension is one Python can handle by itself.


My hope is that, once solved, this will further enable the development of Python alternative syntaxes. Folks bemoan the explosion of Javascript precompilers, but the truth is that it has in part led to a revival in industrial programming languages and a renaissance in programming language development in general.   Python, with its AST available and exposed at runtime, is eminently suitable as an alternative language research platform– except for this one little problem.


I am trying to solve that problem.

1 comment or Leave a comment
I ought to be a Sad Puppy.

No, I'm not a supporter of snot-nosed Vox Day's ridiculous and stupid campaign to overwrite the will of Hugo voters. I'm not going to say that he and his ilk deserve anything over than public opprobrium in the face of their self-serving and malign campaign to deprive the science fiction community of its next level up.

When it comes to what I like to read, well... I generally like what Baen has to offer. Sad, but true. I bounce off women writers more often than I do men, I like bad space opera and ridiculous tales of derring-do, and I cheer when the hero gets laid. One of my favorite writers is David Friggin Weber, which is about as silly as its sounds.

I'm a little more sensitive now that I was in my 20s. Admittedly, in my 20s I was living through the early Cyberpunk era and its post-New Wave backlash, which both embraced and attacked the mores and ethics of New Wave feminist SF 1970s. I wince if the story is too obviously written by a an old white guy who thinks a homogeneous, conservative version of Southern California in space!, where the men are men and the women are pliant, is paradise. But the truth is I'm an old white guy who likes reading stories written by other old white guys.

Which is why I really can't stand the Sad Puppy / Rabid Puppy thing at all. Look, boys, we're old. Like, really old. Kids these days are going to forge their own worlds, with their own stories, and there ain't a damn thing we can do about it. You can poison some awards processes and wreck a fine time you could have otherwise enjoyed. The kids will have this world long after we're gone, and the only thing we can do is try to hand off a world of faith, hope and caritas... or, in the case of the SP/RP crowd, a burning cinder, a hellscape fixed forever in a universe of pure hatred.

Nobody is stopping anyone from writing. No one is preventing you from buying John C. Wright's books. (I wouldn't encourage anyone to give Wright money, though; his hackneyed, ridiculous style would disqualify him long before we start discussing his manifest personal cruelty.)

Go ahead, write the swash and the buckle. Just remember that you're outnumbered. Your niche rose to prominence because of the privileges we white, English-speaking guys had in the early 20th century. But in the age of the Internet, you are outnumbered, you are a minority, and you are an embarrassment if you continue to write with the kind of deft wit and narrative grace that brought Ken Robeson or Victor Appleton fame.

Tags: ,
Current Mood: amused amused
Current Music: Hamilton, Farmer Refuted

Leave a comment

The weirdest interview I ever had was shortly after I got laid off from Isilon. One-fifth of Isilon had been laid off in one brutal morning, and I was among them. The economy was deep into the recession, and like everyone else who had been laid off recently I had put out my resume and my shingle, then settled into my basement to teach myself everything I hadn’t learned in the previous eight years.


A large hardware-based American computer company whose name I won’t repeat, but which was once headed by a former US presidential contender infamous for an ad featuring demon sheep, reached out through its recruitment efforts and asked if I would come in for an interview. They said my skills were a perfect fit for a new product they had in mind.


The interview was way the hell out in Bellevue, hours and miles from my house, and utterly inconvenient for me. When I got there, I learned that their “new product” was basically a direct competitor for Isilon’s; they were trying to get into the mass storage market, and were having a hard time of it.


I was scheduled to be there all day. But as the first hour wound down, I already knew the job wasn’t for me. I didn’t really have the skills they wanted; I wasn’t all that familiar with the C/C++ side of the business, after all. I knew more about the Isilon product from the configuration side than anyone outside of field support, but not much about the internals. More than that, the job didn’t sound interesting. Java and Swing weren’t technologies I was particularly interested in. The office environment seemed cold and unfriendly. The commute was murderous. And I’d just gotten cut from an infrastructure job; why would I want another one?


When the second interviewer came in, I said to him, “I’m sorry, but this job isn’t really for me. I think we should call it here.”


He looked at me, confused. “You mean you just want to… stop?”


I said, “I’m not going to take the job.”


“But…” He stopped, utterly still, for a few moments, then rose and left. A few minutes later, he came back and said, “The candidate isn’t allowed to end the interview process.”


I told him flatly, “I don’t think you can legally stop me from leaving the building.”


He stopped for a moment and looked very confused.  “No, that’s true,” he said. “Okay, I guess I’ll, um, escort you out.”


“Thank you.”


To this day, I have no idea what he meant by “The candidate isn’t allowed to end the interview process.”  I suspect that what he got from the higher ups he went to talk to was “There’s no process for the candidate ending the interview,” and went from there, but… weird.

2 comments or Leave a comment