Wandering Thoughts archives


Sun Support's habit of publicizing private bug reports

I was reminded today of one of the reasons that I am not too fond of Sun Support, by encountering this bug entry through a message in the ZFS mailing list.

This is a public OpenSolaris bug report. Except it is not; almost all of the text is an email message from me to Sun Support that was one part of our ongoing adventure with FAULTED ZFS spares. We have a commercial Sun support contract and we made our bug reports via it (and worked on Sun Support through it). We were very definitely not reporting this bug publicly, and my email was not written for public consumption, or even for consumption without the entire previous email conversation.

(It should go without saying that the 'work around' in that report is in fact completely bogus and inapplicable to our situation. Sun later admitted that there was a race condition adding the same spare disk to multiple ZFS pools in Solaris 10 Update 6, which is perhaps mostly fixed in S10U8.)

Yet there it is, posted publicly, including an URL that was very much intended only for Sun's internal consumption and which reveals a directory that contains (well, contained) configuration information for some of our internal systems.

This is not the first time I have seen Sun Support take our bug reports and post them (or elements of them) into public places. A previous bug report of ours was sent to one of the OpenSolaris web forums in a slightly redacted form; we discovered this by later searching for other people having the same problem. And if they've done it at least twice for us, I'm sure that they've done it for other people too.

Of course, we have never been warned that this would happen with our bug reports or even informed about it. Nor has anyone from Sun Support ever asked us what we consider internal information that cannot be publicly disclosed. And yes, our bug report contains potentially sensitive information; for example, I'm sure that there are environments where the ZFS pool names are sensitive because they refer to things such as non-public projects.

(I want to make it clear that I do not object to public bug databases as such. What I object to is the surprise appearance of private bug reports in those public bug databases. It is especially aggravating in this situation because Sun blew off that particular bug report message, so they were not even tracking what they considered an actual bug here.)

Of course this behavior may have changed now that it is Oracle Support (assuming that you can get support at all).

solaris/PublicizingBugReports written at 18:11:09; Add Comment

Single-level list flattening in Python

I have been writing a bunch of Python code lately which involves turning lists of lists into plain lists. As it happens Python does not have a flatten() built-in, but people have come up with any number of ingenious ways to do this, some of which I actually like.

First, a stupid non-way that is worth writing down for posterity:

reduce(lambda x,y: x.extend(y), somelists, [])

This version is a classic mistake (one I made today, in fact). Your reward for trying this is the cryptic error "AttributeError: 'NoneType' object has no attribute 'extend'". What this really means is that you've forgotten that .extend() doesn't return anything (ie, it returns None), and the function that reduce() uses must return the accumulator variable. You can fix this by picking an equivalent list operation that does return a result:

reduce(lambda x,y: x+y, somelists, [])

This is both ugly and inefficient, although the inefficiency shouldn't bother you for small lists-of-lists. It is also equivalent to the simpler and slightly faster version:

sum(somelists, [])

All addition-based flatteners have the drawback that they only work on actual lists. If you have a list of tuples, or just a list of some sequence type that is not a list, you lose; list addition works only on two lists.

The best solution is a rare good use of a multi-level list comprehension:

[item for sublist in somelists for item in sublist]

This will work on any sequence type and for any mixture of sequence types (or iterables); you can have an iterable that returns a mixture of lists, tuples, and other iterables and everything will work out and you will get a list at the end.

The multi-level list comprehension approach is both the fastest and the most general, but it's kind of verbose and hard to follow if you're not completely up on list comprehensions. I want to like the sum() approach better, but it too is the kind of thing that makes me go 'oh, how clever', which is not necessarily a good idea in general code. All things considered, I'll probably use either the list comprehension approach or just the plain for loop one in future code.

PS: this is the kind of entry that I write in an attempt to make it all stick in my head. And in a demonstration that I repeat myself, the example I used in MultilevelListComps was for list flattening (although back in 2005 it appears that lists did not have .extend(), or at least it slipped my mind).

(I mined here and here for this information.)

Sidebar: the boring plain approach

The most verbose but straightforward approach is of course the classic for loop:

accum = []
for e in somelists:

Just as with the list comprehension version, this works with any sequence types or iterable types; it doesn't require lists. On advantage of this approach is that anyone (your future self included) can easily recognize what the code is doing.

python/FlatteningLists written at 00:32:56; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.