IBM has recently released 500 patents for use in opensource code.
"...In order to foster innovation and avoid the possibility that a
party will take advantage of this pledge and then assert patents or
other intellectual property rights of its own against Open Source
Software, thereby limiting the freedom of IBM or any other Open
Source developer to create innovative software programs, the
commitment not to assert any of these 500 U.S. patents and all
counterparts of these patents issued in other countries is
irrevocable except that IBM reserves the right to terminate this
patent pledge and commitment only with regard to any party who files
a lawsuit asserting patents or other intellectual property rights
against Open Source Software."
Since this includes patents on compression and encryption stuff, we
will definitely be faced with deciding on whether to allow use of these
patents in the main Python library.
Somebody was worried about BSD-style licenses on Groklaw, and said,
"Yes, you can use this patent in the free version... but if you
close the code, you're violating IBM's Patents, and they WILL come
after you. Think of what would have happened if IBM had held a
patent that was used in the FreeBSD TCP/IP stack? Microsoft used
it as the base of the Windows NT TCP/IP stack. IBM could then sue
Microsoft for patent violations."
To which he got the following reply:
"Sorry, but that's not correct. That specific question was asked
on the IBM con-call about this announcement. i.e. if there were a
commercial product that was a derived work of an open source
project that used these royalty-free patents, what would happen?
"IBM answered that, so long as the commercial derived work followed
the terms of the open source license agreement, there was no
problem. (So IBM is fine with a commercial product based on an
open source BSD project making use of these patents.)"
This means to me we can put these in Python's library, but it is
definitely something to start deciding now.
-- Scott David Daniels
This is a collection of responses to various things that don't appear
to have been resolved yet:
> if a target protocol has optional aspects, then lossy adaptation to it is
> okay by definition. Conversely, if the aspect is *not* optional, then
> lossy adaptation to it is not acceptable. I don't think there can really
> be a middle ground; you have to decide whether the information is required
> or not.
I disagree. To belabor Alex's example, suppose LotsOfInfo has first, middle,
and last names; PersonName has first and last, and FullName has first,
middle initial and last. FullName's __doc__ specifically states that if
the middle name is not available or the individual does not have a middle
name, then "None" is acceptable.
Converting LotsOfInfo to FullName via PersonName results in None for the
middle name. But that's just not right... it _should_ be filling in the
middle initial because that information IS available. It's technically
correct in a theoretical sort of a way (FullName never PROMISES that
middle_initial will be available), but it's wrong in a my-program-doesn't-
work-right sort of way, because it HAS the information available yet
doesn't use it.
You're probably going to say "okay, then register a LotsOfInfo->FullName
converter", and I agree. But if no such converter is registered, I
would rather have a TypeError then an automatic conversion which produces
incorrect results. I can explicitly silence it by registering a trivial
person_name = adapt(lots_of_info, PersonName)
return adapt(person_name, FullName)
but if it just worked, I could only discover that by being clever enough
to think of writing unit test for middle name.
Elsewhere, Phillip writes:
> If you derive an interface from another interface, this is supposed to mean
> that your derived interface promises to uphold all the promises of the base
> interface. That is, your derived interface is always usable where the base
> interface is required.
> However, oftentimes one mistakenly derives an interface from another while
> meaning that the base interface is *required* by the derived interface,
> which is similar in meaning but subtly different. Here, you mean to say,
> "IDerived has all of the requirements of IBase", but you have instead said,
> "You can use IDerived wherever IBase is desired".
Okay, that's beginning to make sense to me.
> it's difficult because intuitively an interface defines a *requirement*, so
> it seems logical to inherit from an interface in order to add requirements!
Yes... I would fall into this trap as well until I'd been burned a few times.
Alex summarizes nicely:
> Personally, I disagree with having transitivity at all, unless perhaps
> it be restricted to adaptations specifically and explicitly stated to
> be "perfect and lossless"; PJE claims that ALL adaptations MUST,
> ALWAYS, be "perfect and lossless" -- essentially, it seems to me, he
> _has_ to claim that, to defend transitivity being applied
> automatically, relentlessly, NON-optionally, NON-selectively
> Much the same applies to inheritance, BTW, which as PJE has pointed out
> a few times also induces transitivity in adaptation, and, according to
> him, is a more likely cause of bugs than chains of adapters
But Alex goes on to say that perhaps we need two grades of adaptations
(perfect and real-world) and two grades of interface inheritance (perfect
and otherwise) so that the transitivity can be (automatically) invoked
only for the perfect ones. That feels to me like excessive complexity:
why not just prohibit transitivity? What, after all, is the COST of
For the first case (adapter chains) the cost is a N^2 explosion in the
number of adapters needed. I said I thought that N would be small, but
Phillip (who knows what he's talking about, don't get me wrong here)
says that it's big enough to be mildly annoying at times to Twisted
and Eclipse developers.
For the second case (interface inheritance), I haven't yet thought
through clearly how at affects things... in fact, it sort of seems like
there's no good way to _prevent_ "transitivity" in this case short
of prohibiting interface inheritance entirely. And, as Phillip points
out to me (see above) this is a more common type of error.
Gee... I'm understanding the problem a little better, but elegant
solutions are still escaping me.
-- Michael Chermside
> IMO, it's simpler to handle this use case by letting __conform__
> None, since this allows people to follow the One Obvious Way to not
> to a particular protocol.
> Then, there isn't a need to even worry about the exception name in the
> first place, either...
+1. Writing a default __conform__ for object is reasonable.
> I'd rather not make a change to built-in ``object'' a prereq for PEP
Why not? Seems quite reasonable. Before __conform__ existed, there
one for object; now that it exists, object needs one.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
There's a bunch of jobs we (CSV module maintainers) have been putting
off - attached is a list (in no particular order):
* unicode support (this will probably uglify the code considerably).
* 8 bit transparency (specifically, allow \0 characters in source string
and as delimiters, etc).
* Reader and universal newlines don't interact well, reader doesn't
honour Dialect's lineterminator setting. All outstanding bug id's
(789519, 944890, 967934 and 1072404) are related to this - it's
a difficult problem and further discussion is needed.
* compare PEP-305 and library reference manual to the module as implemented
and either document the differences or correct them.
* Address or document Francis Avila's issues as mentioned in this posting:
* Several blogs complain that the CSV module is no good for parsing
strings. Suggest making it clearer in the documentation that the reader
accepts an iterable, rather than a file, and document why an iterable
(as opposed to a string) is necessary (multi-line records with embedded
newlines). We could also provide an interface that parses a single
string (or the old Object Craft interface) for those that really feel
the need. See:
* Compatability API for old Object Craft CSV module?
For example: "from csv.legacy import reader" or something.
* Pure python implementation?
* Some CSV-like formats consider a quoted field a string, and an unquoted
field a number - consider supporting this in the Reader and Writer. See:
* Add line number and record number counters to reader object?
* it's possible to get the csv parser to suck the whole source file
into memory with an unmatched quote character. Need to limit size of
Also, review comments from Neal Norwitz, 22 Mar 2003 (some of these should
already have been addressed):
* remove TODO comment at top of file--it's empty
* is CSV going to be maintained outside the python tree?
If not, remove the 2.2 compatibility macros for:
PyDoc_STR, PyDoc_STRVAR, PyMODINIT_FUNC, etc.
* inline the following functions since they are used only in one place
get_string, set_string, get_nullchar_as_None, set_nullchar_as_None,
* rather than use PyErr_BadArgument, should you use assert?
(first example, Dialect_set_quoting, line 218)
* is it necessary to have Dialect_methods, can you use 0 for tp_methods?
* remove commented out code (PyMem_DEL) on line 261
Have you used valgrind on the test to find memory overwrites/leaks?
* PyString_AsString() on line 331 could return NULL in which case
you are dereferencing a NULL pointer
* note sure why there are casts on 0 pointers
lines 383-393, 733-743, 1144-1154, 1164-1165
* Reader_getiter() can be removed and use PyObject_SelfIter()
* I think you need PyErr_NoMemory() before returning on line 768, 1178
* is PyString_AsString(self->dialect->lineterminator) on line 994
guaranteed not to return NULL? If not, it could crash by
passing to memmove.
* PyString_AsString() can return NULL on line 1048 and 1063,
the result is passed to join_append()
* iteratable should be iterable? (line 1088)
* why doesn't csv_writerows() have a docstring? csv_writerow does
* any PyUnicode_* methods should be protected with #ifdef Py_USING_UNICODE
* csv_unregister_dialect, csv_get_dialect could use METH_O
so you don't need to use PyArg_ParseTuple
* in init_csv, recommend using
PyModule_AddIntConstant and PyModule_AddStringConstant
Also, review comments from Jeremy Hylton, 10 Apr 2003:
I've been reviewing extension modules looking for C types that should
participate in garbage collection. I think the csv ReaderObj and
WriterObj should participate. The ReaderObj it contains a reference to
input_iter that could be an arbitrary Python object. The iterator
object could well participate in a cycle that refers to the ReaderObj.
The WriterObj has a reference to a writeline callable, which could well
be a method of an object that also points to the WriterObj.
The Dialect object appears to be safe, because the only PyObject * it
refers should be a string. Safe until someone creates an insane string
subclass <0.4 wink>.
Also, an unrelated comment about the code, the lineterminator of the
Dialect is managed by a collection of little helper functions like
get_string, set_string, etc. This code appears to be excessively
general; since they're called only once, it seems clearer to inline the
logic directly in the get/set methods for the lineterminator.
Andrew McNamara, Senior Developer, Object Craft
Now that Python 2.4 is out the door (and the problems with
StreamReader.readline() are hopefully fixed), I'd like bring
up the topic of a feed style codec API again. A feed style API
would make it possible to use stateful encoding/decoding where
the data is not available as a stream.
- xml.sax.xmlreader.IncrementalParser: Here the client passes raw
XML data to the parser in multiple calls to the feed() method.
If the parser wants to use Python codecs machinery, it has to
wrap a stream interface around the data passed to the feed()
- WSGI (PEP 333) specifies that the web application returns the
fragments of the resulting webpage as an iterator. If this result
is encoded unicode we have the same problem: This must be wrapped
in a stream interface.
The simplest solution is to add a feed() method both to StreamReader
and StreamWriter, that takes the state of the codec into account,
but doesn't use the stream. This can be done by simply moving a
few lines of code into separate methods. I've uploaded a patch to
There are other open issues with the codec changes: unicode-escape,
UTF-7, the CJK codecs and probably a few others don't support
decoding imcomplete input yet (although AFAICR the functionality
is mostly there in the CJK codecs).
> I just was asking. Who gave you the advise?
someon in a german python forum. I'll change the license asap.
I'm just curious, but do I really have to use the contributor agreement etc.? I mean I'm just trying to submit a small class, no big framework.
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193
I have started writing a patch that replaces PyOS_InputHook with
PyOS_AddInputHook and PyOS_RemoveInputHook. I am a bit confused though on how
hook functions are supposed to work with threads.
PyOS_InputHook is a pointer to a hook function, which can be defined for example
in a C extension module.
When Python is running in a single thread, PyOS_InputHook is called ten times
per second while Python is waiting for the user to type something. This is
achieved by setting readline's rl_event_hook function to PyOS_InputHook.
When Python uses multiple threads, each thread has its own PyOS_InputHook (I am
not sure if this was intended). However, with IDLE I noticed that the subprocess
thread doesn't call its PyOS_InputHook. In IDLE (if I understand correctly how
it works), one thread takes care of the GUI and the interaction with the user,
while another thread executes the user's commands. If an extension module sets
PyOS_InputHook, the PyOS_InputHook belonging to this second thread is set.
However, this PyOS_InputHook does not get called. Is this simply an oversight?
What would be a suitable place to add the call to PyOS_InputHook? In other
words, where does the second thread go idle?
> On Thu, Dec 09, 2004, Michiel Jan Laurens de Hoon wrote:
>>> My suggestion is therefore to replace PyOS_InputHook by two functions
>>> PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of
>>> which hooks are installed. This way, an extension module can add a hook
>>> function without having to worry about other extension modules trying
>>> to use the same hook.
>>> Any comments? Would I need to submit a PEP for this proposal?
> Because this is only for the C API, your best bet is to write a patch
> and submit it to SF. If people whine or it gets rejected, then write a
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
I'm trying to understand the relation between Guido's posts on optional
static typing and PEP 245 (interfaces) and 246 (adaptation). I have a
couple of questions
PEP 245 proposes to introduce a fundamental distinction between type and
interface. However, 245 only introduces a syntax for interfaces, and
says very little about the semantics of interfaces. (Basically only that
if X implements Y then implements(X, Y) will return True). The
semantics of interfaces are currently only implied by PEP 246, and by
Guido's posts referring to 246.
Unfortunately PEP 246 explicitly refuses to decide that protocols are
245-style interfaces. Therefore, it is not clear to me how acceptance of
245 would impact on 246? Specifically, what would be the difference
x = adapt(obj, a_245_style_interface)
x = adapt(obj, a_protocol_type)
and, if there is no difference, what would the use-case of interfaces be?
Put another way: explicit interfaces and adaptation based typing seem to
be about introducing rigor (dynamic, not static) to Python. Yet, PEP
245 and 246 seems to go out of their way to give interfaces and
adaptation as little baggage as possible. So, where is the rigor going
to come from?
On the one hand this seems very Pythonic - introduce a new feature with
as little baggage as possible, and see where it evolves from there. Let
the rigor flow, not from the restrictions of the language, but from the
expressive power of the language.
On the other hand: why not, at least:
- explore in 245 how the semantics of interfaces might introduce rigor
into the language. It would be particularly illuminating to find out in
what way implementing an interface differs from deriving from an ABC
and in what way an interface hierarchy differs semantically from a
hierarchy of ABCs
- rewrite 246 under the assumption that 245 (including semantics) has
I would volunteer, but, for those of you who hadn't noticed yet, I don't
know what I'm talking about.
David Ascher writes:
> Terminology point: I know that LiskovViolation is technically correct,
> but I'd really prefer it if exception names (which are sometimes all
> users get to see) were more informative for people w/o deep technical
> background. Would that be possible?
I don't see how. Googling on Liskov immediately brings up clear
and understandable descriptions of the principle that's being violated.
I can't imagine summarizing the issue more concisely than that! What
would you suggest? Including better explanations in the documentation
is a must, but "LiskovViolation" in the exception name seems unbeatably
clear and concise.
-- Michael Chermside