Re: [Python-Dev] Re: Zen of Python
On 2005 Jan 20, at 02:47, Skip Montanaro wrote: Phillip> Actually, this is one of those rare cases where optimization Phillip> and clarity go hand in hand. Human brains just don't handle Phillip> nesting that well. It's easy to visualize two levels of nested Phillip> structure, but three is a stretch unless you can abstract at Phillip> least one of the layers. Also, if you think about nesting in a class/instance context, something like self.attr.foo.xyz() says you are noodling around in the implementation details of self.attr (you know it has a data attribute called "foo"). This provides for some very tight coupling between the implementation of whatever self.attr is and your code. If there is a reason for you to get at whatever xyz() returns, it's probably best to publish a method as part of the api for self.attr. Good point: this is also known as "Law of Demeter" and relevant summaries and links are for example at http://www.ccs.neu.edu/home/lieber/LoD.html . Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unix line endings required for PyRun* breaking embedded Python
Skip Montanaro wrote:
> Just re.sub("[\r\n]+", "\n", s) and I think you're good to go.
I don't think that in general you want to fold multiple empty lines into
one. This would be my prefered regex:
s = re.sub(r"\r\n?", "\n", s)
Catches both DOS and old-style Mac line endings. Alternatively, you can
use s.splitlines():
s = "\n".join(s.splitlines()) + "\n"
This also makes sure the string ends with a \n, which may or may not be
a good thing, depending on your application.
Just
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Unix line endings required for PyRun* breaking embedded Python
Just van Rossum wrote:
> I don't think that in general you want to fold multiple empty lines into
> one. This would be my prefered regex:
>
>s = re.sub(r"\r\n?", "\n", s)
>
> Catches both DOS and old-style Mac line endings. Alternatively, you can
> use s.splitlines():
>
>s = "\n".join(s.splitlines()) + "\n"
>
> This also makes sure the string ends with a \n, which may or may not be
> a good thing, depending on your application.
s = s.replace("\r", "\n"["\n" in s:])
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated Monkey Typing pre-PEP
[Phillip J. Eby] > I've revised the draft today to simplify the terminology, discussing only > two broad classes of adapters. Since Clark's pending proposals for PEP 246 > align well with the concept of "extenders" vs. "independent adapters", I've > refocused my PEP to focus exclusively on adding support for "extenders", > since PEP 246 already provides everything needed for independent adapters. > > The new draft is here: > http://peak.telecommunity.com/DevCenter/MonkeyTyping On the plane to the Amazon.com internal developers conference in Seattle (a cool crowd BTW) I finally got to read this. I didn't see a way to attach comments to Phillip's draft, so here's my response. (And no, it hasn't affected my ideas about optional typing. :) The Monkey Typing proposal is trying to do too much, I believe. There are two or three separate problem, and I think it would be better to deal with each separately. The first problem is what I'd call incomplete duck typing. There is a function that takes a sequence argument, and you have an object that partially implements the sequence protocol. What do you do? In current Python, you just pass the object and pray -- if the function only uses the methods that your object implements, it works, otherwise you'll get a relatively clean AttributeError (e.g. "Foo instance has no attribute '__setitem__'"). Phillip worries that solving this with interfaces would cause a proliferation of "partial sequence" interfaces representing the needs of various libraries. Part of his proposal comes down to having a way to declare that some class C implements some interface I, even if C doesn't implement all of I's methods (as long as implements at least one). I like having this ability, but I think this fits in the existing proposals for declaring interface conformance: there's no reason why C couldn't have a __conform__ method that claims it conforms to I even if it doesn't implement all methods. Or if you don't want to modify C, you can do the same thing using the external adapter registry. I'd also like to explore ways of creating partial interfaces on the fly. For example, if we need only the read() and readlines() methods of the file protocol, maybe we could declare that as follows:: def foo(f: file['read', 'readlines']): ... I find the quoting inelegant, so maybe this would be better:: file[file.read, file.readlines] Yet another idea (which places a bigger burden on the typecheck() function presumed by the type declaration notation, see my blog on Artima.com) would be to just use a list of the needed methods:: [file.read, file.readlines] All this would work better if file weren't a concrete type but an interface. Now on to the other problems Phillip is trying to solve with his proposal. He says, sometimes there's a class that has the functionality that you need, but it's packaged differently. I'm not happy with his proposal for solving this by declaring various adapting functions one at a time, and I'd much rather see this done without adding new machinery or declarations: when you're using adaptation, just write an adapter class and register it; without adaptation, you can still write the adapter class and explicitly instantiate it. I have to admit that I totally lost track of the proposal when it started to talk about JetPacks. I believe that this is trying to deal with stateful adapters. I hope that Phillip can write something up about these separately from all the other issues, maybe then it's clearer. There's one other problem that Phillip tries to tackle in his proposal: how to implement the "rich" version of an interface if all you've got is a partial implementation (e.g. you might have readline() but you need readlines()). I think this problem is worthy of a solution, but I think the solution could be found, again, in a traditional adapter class. Here's a sketch:: class RichFile: def __init__(self, ref): self.__ref = ref if not hasattr(ref, 'readlines'): self.readlines = self.__readlines # Other forms of this magic are conceivably def __readlines(self): # Ignoring the rarely used optional argument # It's tempting to use [line for line in self.__ref] here but that doesn't use readline() lines = [] while True: line = self.__ref.readline() if not line: break lines.append(line) return lines def __getattr__(self, name): # Delegate all other attributes to the underlying object return getattr(self.__ref, name) Phillip's proposal reduces the amount of boilerplate in this class somewhat (mostly the constructor and the __getattr__() method), but apart from that it doesn't really seem to do a lot except let you put pieces of the adapter in different places, which doesn't strike me as such a great idea. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing lis
Re: [Python-Dev] Updated Monkey Typing pre-PEP
On Thu, 2005-01-20 at 11:07, Guido van Rossum wrote: > I'd also like to explore ways of creating partial interfaces on the > fly. For example, if we need only the read() and readlines() methods > of the file protocol, maybe we could declare that as follows:: > > def foo(f: file['read', 'readlines']): ... > > I find the quoting inelegant, so maybe this would be better:: > > file[file.read, file.readlines] Could you not just have a builtin which constructs an interface on the fly, so you could write: def foo(f: interface(file.read, file.readlines)): ... For commonly used subsets of course you'd do something like: IInputStream = interface(file.read, file.readlines) def foo(f: IInputStream): ... I can't see that interface() would need much magic - I would guess you could implement it in python with ordinary introspection. Mark Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
Hi, Removing unbound methods also breaks the 'py' lib quite a bit. The 'py.test' framework handles function and bound/unbound method objects all over the place, and uses introspection on them, as they are the objects defining the tests to run. It's nothing that can't be repaired, and at places the fix even looks nicer than the original code, but I thought that it points to large-scale breakage. I'm expecting any code that relies on introspection to break at least here or there. My bet is that even if it's just for fixes a couple of lines long everyone will have to upgrade a number of their packages when switching to Python 2.5 -- unheard of ! For reference, the issues I got with the py lib are described at http://codespeak.net/pipermail/py-dev/2005-January/000159.html Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Unix line endings required for PyRun* breaking embedded Python
Fredrik> s = s.replace("\r", "\n"["\n" in s:])
This fails on admittedly weird strings that mix line endings:
>>> s = "abc\rdef\r\n"
>>> s = s.replace("\r", "\n"["\n" in s:])
>>> s
'abcdef\n'
where universal newline mode or Just's re.sub() gadget would work.
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unix line endings required for PyRun* breaking embedded Python
Just> Skip Montanaro wrote:
>> Just re.sub("[\r\n]+", "\n", s) and I think you're good to go.
Just> I don't think that in general you want to fold multiple empty
Just> lines into one.
Whoops. Yes.
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch review [ 723201 ] PyArg_ParseTuple problem with 'L' format
Patch review [ 723201 ] PyArg_ParseTuple problem with 'L' format
The PyArg_ParseTuple function (PyObject *args, char *format, ...) parses the
arguments args and stores them in the variables specified following the format
argument. If format=="i", indicating an integer, but the corresponding Python
object in args is not a Python int or long, a TypeError is thrown:
TypeError: an integer is required
For the "L" format, indicating a long long, instead a SystemError is thrown:
SystemError: Objects/longobject.c:788: bad argument to internal function
The submitted patch fixes this, however I think it is not the best way to do it.
The original code (part of the convertsimple function in Python/getargs.c) is
case 'L': {/* PY_LONG_LONG */
PY_LONG_LONG *p = va_arg( *p_va, PY_LONG_LONG * );
PY_LONG_LONG ival = PyLong_AsLongLong( arg );
if( ival == (PY_LONG_LONG)-1 && PyErr_Occurred() ) {
return converterr("long", arg, msgbuf, bufsize);
} else {
*p = ival;
}
break;
}
In the patch, a PyLong_Check and a PyInt_Check are added:
case 'L': {/* PY_LONG_LONG */
PY_LONG_LONG *p = va_arg(*p_va, PY_LONG_LONG *);
PY_LONG_LONG ival;
/* ** patch starts here ** */
if (!PyLong_Check(arg) && !PyInt_Check(arg))
return converterr("long", arg, msgbuf, bufsize);
/* ** patch ends here ** */
ival = PyLong_AsLongLong(arg);
if (ival == (PY_LONG_LONG)-1 && PyErr_Occurred()) {
return converterr("long", arg, msgbuf, bufsize);
} else {
*p = ival;
}
break;
}
However, the PyLong_AsLongLong function (in Objects/longobject.c) also contains
a call to PyLong_Check and PyInt_Check, so there should be no need for another
such check here:
PY_LONG_LONG
PyLong_AsLongLong(PyObject *vv)
{
PY_LONG_LONG bytes;
int one = 1;
int res;
if (vv == NULL) {
PyErr_BadInternalCall();
return -1;
}
if (!PyLong_Check(vv)) {
if (PyInt_Check(vv))
return (PY_LONG_LONG)PyInt_AsLong(vv);
PyErr_BadInternalCall();
return -1;
}
A better solution would be to replace the PyErr_BadInternalCall() in the
PyLong_AsLongLong function by
PyErr_SetString(PyExc_TypeError, "an integer is required");
This would make it consistent with PyInt_AsLong in Objects/intobject.c:
long
PyInt_AsLong(register PyObject *op)
{
PyNumberMethods *nb;
PyIntObject *io;
long val;
if (op && PyInt_Check(op))
return PyInt_AS_LONG((PyIntObject*) op);
if (op == NULL || (nb = op->ob_type->tp_as_number) == NULL ||
nb->nb_int == NULL) {
PyErr_SetString(PyExc_TypeError, "an integer is required");
return -1;
}
By the way, I noticed that a Python float is converted to an int (with a
deprecation warning), while trying to convert a Python float into a long long
int results in a TypeError. Also, I'm not sure about the function of the calls
to converterr (in various places in the convertsimple function); none of the
argument type errors seem to lead to the warning messages created by converterr.
--Michiel.
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Strange segfault in Python threads and linux kernel 2.6
Donovan Baarda <[EMAIL PROTECTED]> writes: > On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote: >> Donovan Baarda <[EMAIL PROTECTED]> writes: > [...] >> You've left out a very important piece of information: which version >> of Python you are using. I'm guessing 2.3.4. Can you try 2.4? > > Debian Python2.3 (2.3.4-18), Debian kernel-image-2.6.8-1-686 (2.6.8-10), > and Debian kernel-image-2.4.27-1-686 (2.4.27-6) > >> I'd be astonished if this is the same bug. >> >> The main oddness about python threads (before 2.3) is that they run >> with all signals masked. You could play with a C wrapper (call >> setprocmask, then exec fop) to see if this is what is causing the >> problem. But please try 2.4. > > Python 2.4 does indeed fix the problem. That's good to hear. > Unfortunately we are using Zope 2.7.4, and I'm a bit wary of > attempting to migrate it all from 2.3 to 2.4. That's not so good to hear, albeit unsurprising. > Is there any way this "Fix" can be back-ported to 2.3? Probably not. It was quite invasive and a bit scary. OTOH, it hasn't been the cause of any bug reports yet, so it can't be all bad. > Note that this problem is being triggered when using > Popen3() in a thread. Popen3() simply uses os.fork() and os.execvp(). > The segfault is occurring in the excecvp'ed process. I'm sure there must > be plenty of cases where this could happen. I think most people manage > to avoid it because the processes they are popen'ing or exec'ing happen > to not use signals. Indeed. > After testing a bit, it seems the fork() in Popen3 is not a contributing > factor. The problem occurs whenever os.execvp() is executed in a thread. > It looks like the exec'ed command inherits the masked signals from the > thread. Yeah. I could have told you that, sorry :) > I'm not sure what the correct behaviour should be. The fact that it > works in python2.4 feels more like a byproduct of the thread mask change > than correct behaviour. Well, getting rid of the thread mask changes was one of the goals of the change. > To me it seems like execvp() should be setting the signal mask back > to defaults or at least the mask of the main process before doing > the exec. Possibly. I think the 2.4 change -- not fiddling the process mask at all -- is the Right Thing, but that doesn't help 2.3 users. This has all been discussed before at some length, on python-dev and in various bug reports on SF. In your situation, I think the simplest thing you can do is dig out an old patch of mine that exposes sigprocmask + co to Python and either make a custom Python incorporating the patch and use that, or put the code from the patch into an extension module. Then before execing fop, use the new code to set the signal mask to something sane. Not pretty, particularly, but it should work. >> > BTW, built in file objects really could use better non-blocking >> > support... I've got a half-drafted PEP for it... anyone interested in >> > it? >> >> Err, this probably should be in a different mail :) > > The verboseness of the attached test code because of this issue prompted > that comment... so vaguely related :-) Oh right :) Didn't actually read the test code, not having fop to hand... Cheers, mwh -- The ability to quote is a serviceable substitute for wit. -- W. Somerset Maugham ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ANN: Free Trac/Subversion hosting at Python-Hosting.com (fwd)
Thought I'd pass this along for people who don't read comp.lang.python. Skip --- Begin Message --- Hello everyone, To celebrate its second anniversary, Python-Hosting.com is happy to announce that it is now offering free Trac/Subversion hosting. This offer is limited to open-source, python projects. Trac and Subversion make a great combination for project management. More information about Trac can be found here: http://www.edgewall.com/trac The free offer includes: - Your own Trac site with HTTP and HTTPS access - Your own Subversion repository with HTTP and HTTPS access - Access to trac-admin through a web interface - Access to Trac and Subversion user configuration through a web interface - Web usage statistics of your Trac site - Nightly backups of your data to external servers If you want to know more about this offer and find out how to sign up, check out the following page: http://www.python-hosting.com/freetrac Remi. -- http://mail.python.org/mailman/listinfo/python-list --- End Message --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated Monkey Typing pre-PEP
At 03:07 AM 1/20/05 -0800, Guido van Rossum wrote:
Phillip worries that solving this with interfaces would cause a
proliferation of "partial sequence" interfaces representing the needs
of various libraries. Part of his proposal comes down to having a way
to declare that some class C implements some interface I, even if C
doesn't implement all of I's methods (as long as implements at least
one). I like having this ability, but I think this fits in the
existing proposals for declaring interface conformance: there's no
reason why C couldn't have a __conform__ method that claims it
conforms to I even if it doesn't implement all methods. Or if you
don't want to modify C, you can do the same thing using the external
adapter registry.
There are some additional things that it does in this area:
1. Avoids namespace collisions when an object has a method with the same
name as one in an interface, but which doesn't do the same thing. (A
common criticism of duck typing by static typing advocates; i.e. how do you
know that 'read()' has the same semantics as what this routine expects?)
2. Provides a way to say that you conform, without writing a custom
__conform__ method
3. Syntax for declaring conformance is the same as for adaptation
4. Allows *external* (third-party) code to declare a type's conformance,
which is important for integrating existing code with code with type
declarations
I'd also like to explore ways of creating partial interfaces on the
fly. For example, if we need only the read() and readlines() methods
of the file protocol, maybe we could declare that as follows::
def foo(f: file['read', 'readlines']): ...
FYI, this is similar to the suggestion from Samuele Pedroni that lead to
PyProtocols having a:
protocols.protocolForType(file, ['read','readlines'])
capability, that implements this idea. However, the problem with
implementing it by actually having distinct protocols is that declaring as
few as seven methods results in 127 different protocol objects with
conformance relationships to manage.
In practice, I've also personally never used this feature, and probably
never would unless it had meaning for type declarations. Also, your
proposal as shown would be tedious for the declarer compared to just saying
'file' and letting the chips fall where they may.
Now on to the other problems Phillip is trying to solve with his
proposal. He says, sometimes there's a class that has the
functionality that you need, but it's packaged differently. I'm not
happy with his proposal for solving this by declaring various adapting
functions one at a time, and I'd much rather see this done without
adding new machinery or declarations: when you're using adaptation,
just write an adapter class and register it; without adaptation, you
can still write the adapter class and explicitly instantiate it.
In the common case (at least for my code) an adapter class has only one or
two methods, but the additional code and declarations needed to make it an
adapter can increase the code size by 20-50%. Using @like directly on an
adapting method would result in a more compact expression in the common case.
I have to admit that I totally lost track of the proposal when it
started to talk about JetPacks. I believe that this is trying to deal
with stateful adapters. I hope that Phillip can write something up
about these separately from all the other issues, maybe then it's
clearer.
Yes, it was for per-object ("as a") adapter state, rather than per-adapter
("has a") state, however. The PEP didn't try to tackle "has a" adapters at
all.
Phillip's proposal reduces the amount of boilerplate in this class
somewhat (mostly the constructor and the __getattr__() method),
Actually, it wouldn't implement the __getattr__; a major point of the
proposal is that when adapting to an interface, you get *only* the
attributes from the interface, and of those only the ones that the adaptee
has implementations for. So, arbitrary __getattr__ doesn't pass down to
the adapted item.
but
apart from that it doesn't really seem to do a lot except let you put
pieces of the adapter in different places, which doesn't strike me as
such a great idea.
The use case for that is that you are writing a package which extends an
interface IA to create interface IB, and there already exist numerous
adapters to IA. As long as IB's additional methods can be defined in terms
of IA, then you can extend all of those adapters at one stroke.
In other words, external abstract operations are exactly equivalent to
stateless, lossless, interface-to-interface adapters applied
transitively. But the point of the proposal was to avoid having to explain
to somebody what all those terms mean, while making it easier to do such an
adaptation correctly and succinctly.
One problem with using concrete adapter classes to full interfaces rather
than partial interfaces is that it leads to situations like Alex's adapter
diamond examples, because
Re: [Python-Dev] a bunch of Patch reviews
Irmen de Jong wrote: That sounds very convenient, thanks. Ok, welcome to the project! Please let me know whether it "works". Does the status of 'python project member' come with certain expectations that must be complied with ? ;-) There are a few conventions that are followed more or less stringently. You should be aware of the things in the developer FAQ, http://www.python.org/dev/devfaq.html Initially, "new" developers should follow a "write-after-approval" procedure, i.e. they should not commit anything until they got somebody's approval. Later, we commit things which we feel confident about, and post other things to SF. For CVS, I'm following a few more conventions which I think are not documented anywhere. - Always add a CVS commit message - Add an entry to Misc/NEWS, if there is a new feature, or if it is a bug fix for a maintenance branch (I personally don't list bug fixed in the HEAD revision, but others apparently do) - When committing configure.in, always remember to commit configure also (and pyconfig.h.in if it changed; remember to run autoheader) - Always run the test suite before committing - If you are committing a bug fix, consider to backport it to maintenance branches right away. If you don't backport it immediately, it likely won't appear in the next release. At the moment, backports to 2.4 are encouraged; backports to 2.3 are still possible for a few more days. If you chose not to backport for some reason, document that reason in the commit message. If you plan to backport, document that intention in the commit message (I usually say "Will backport to 2.x") - In the commit message, always refer to the SF tracker id. In the tracker item, always refer to CVS version numbers. I use the script attached to extract those numbers from the CVS commit message, to paste them into the SF tracker. I probably forgot to mention a few things; you'll notice few enough :-) HTH, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
[Martin v. Löwis] ... > - Add an entry to Misc/NEWS, if there is a new feature, > or if it is a bug fix for a maintenance branch > (I personally don't list bug fixed in the HEAD revision, > but others apparently do) You should. In part this is to comply with license requirements: we're a derivative work from CNRI and BeOpen's Python releases, and their licenses require that we include "a brief summary of the changes made to Python". That certainly includes changes made to repair bugs. It's also extremely useful in practice to have a list of repaired bugs in NEWS! That saved me hours just yesterday, when trying to account for a Zope3 test that fails under Python 2.4 but works under 2.3.4. 2.4 NEWS pointed out that tuple hashing changed to close bug 942952, which I can't imagine how I would have remembered otherwise. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Tim Peters wrote: It's also extremely useful in practice to have a list of repaired bugs in NEWS! I'm not convinced about that - it makes the NEWS file almost unreadable, as the noise is now so high if every tiny change is listed; it is very hard to see what the important changes are. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
[Tim Peters] >> It's also extremely useful in practice to have a list of repaired >> bugs in NEWS! [Martin v. Löwis] > I'm not convinced about that - it makes the NEWS file almost > unreadable, as the noise is now so high if every tiny change is > listed; it is very hard to see what the important changes are. My experience disagrees, and I gave a specific example from just the last day. High-level coverage of the important bits is served (and served well) by Andrew's "What's New in Python" doc. (Although I'll note that when I did releases, I tried to sort section contents in NEWS, to put the more important items at the top.) In any case, you snipped the other part here: a brief summary of changes is required by the licenses, and they don't distinguish between changes due to features or bugs. If, for example, we didn't note that tuple hashing changed in NEWS, we would be required to note that in some other file. NEWS is the historical place for it, and works fine for this purpose (according to me ). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A short introduction
Martin v. Löwis wrote: Irmen de Jong wrote: That sounds very convenient, thanks. Ok, welcome to the project! Please let me know whether it "works". It looks that it works, I seem to be able to add a new attachment to the spwd patch- which I will do shortly. * Now that I'm part of the developers group I feel obliged to tell a little bit about myself. I'm a guy from the Netherlands, 30 years old, currently employed at a company designing and developing front- and mid-office web based applications (mostly). We do this in Java (j2ee). I'm using Python where the job allows it, which is much too little IMO :) and for my private stuff, or hobby if you wish. I've been introduced to Python in 1995-6, I think, wanted it at home too, ported it to AmigaDOS (voila AmigaPython), and got more and more involved ever since (starting mostly as a lurker in comp.lang.python). My interests are broad but there's two areas that I particularly like: internet/networking and web/browsers. Over the course of the past few years I developed Pyro, which many of you will probably know (still doing small improvements on that) and more recently, Snakelets and Frog (my own web server and blog app). My C/C++ skills are getting a bit rusty now because I do almost all of my programming in Java or Python, but it's still good enough to be able to contribute to (C)Python, I think. My interest in contributing to Python itself was sparked by the last bug day organized by Johannes Gijsbers. I hope to be able to find time to contribute more often. Well, that about sums it up I think ! Does the status of 'python project member' come with certain expectations that must be complied with ? ;-) There are a few conventions that are followed more or less stringently. You should be aware of the things in the developer FAQ, http://www.python.org/dev/devfaq.html Initially, "new" developers should follow a "write-after-approval" procedure, i.e. they should not commit anything until they got somebody's approval. Later, we commit things which we feel confident about, and post other things to SF. I don't think I will be committing stuff any time soon. But thanks for mentioning. Bye -Irmen de Jong ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Tim Peters wrote: My experience disagrees, and I gave a specific example from just the last day. High-level coverage of the important bits is served (and served well) by Andrew's "What's New in Python" doc. (Although I'll note that when I did releases, I tried to sort section contents in NEWS, to put the more important items at the top.) I long ago stopped reading the NEWS file, because it is just too much text. However, if it is desirable to list any change in the NEWS file, I'm willing to comply. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Updated Monkey Typing pre-PEP
[Guido van Rossum] > There's one other problem that Phillip tries to tackle in his > proposal: how to implement the "rich" version of an interface if all > you've got is a partial implementation (e.g. you might have readline() > but you need readlines()). I think this problem is worthy of a > solution, but I think the solution could be found, again, in a > traditional adapter class. Here's a sketch:: > > class RichFile: > def __init__(self, ref): > self.__ref = ref > if not hasattr(ref, 'readlines'): > self.readlines = self.__readlines # Other forms of this > magic are conceivably > def __readlines(self): # Ignoring the rarely used optional argument > # It's tempting to use [line for line in self.__ref] here but > that doesn't use readline() > lines = [] > while True: > line = self.__ref.readline() > if not line: > break > lines.append(line) > return lines > def __getattr__(self, name): # Delegate all other attributes to > the underlying object > return getattr(self.__ref, name) Instead of a __getattr__ solution, I recommend subclassing from a mixin: class RichMap(SomePartialMapping, UserDict.DictMixin): pass class RichFile(SomePartialFileClass, Mixins.FileMixin): pass Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Strange segfault in Python threads and linux kernel 2.6
On Thu, 2005-01-20 at 14:12 +, Michael Hudson wrote: > Donovan Baarda <[EMAIL PROTECTED]> writes: > > > On Wed, 2005-01-19 at 13:37 +, Michael Hudson wrote: > >> Donovan Baarda <[EMAIL PROTECTED]> writes: [...] > >> The main oddness about python threads (before 2.3) is that they run > >> with all signals masked. You could play with a C wrapper (call > >> setprocmask, then exec fop) to see if this is what is causing the > >> problem. But please try 2.4. > > > > Python 2.4 does indeed fix the problem. > > That's good to hear. [...] I still don't understand what Linux 2.4 vs Linux 2.6 had to do with it. Reading the man pages for execve(), pthread_sigmask() and sigprocmask(), I can see some ambiguities, but mostly only if you do things they warn against (ie, use sigprocmask() instead of pthread_sigmask() in a multi-threaded app). The man page for execve() says that the new process will inherit the "Process signal mask (see sigprocmask() )". This implies to me it will inherit the mask from the main process, not the thread's signal mask. It looks like Linux 2.4 uses the signal mask of the main thread or process for the execve(), whereas Linux 2.6 uses the thread's signal mask. Given that execve() replaces the whole process, including all threads, I dunno if using the thread's mask is right. Could this be a Linux 2.6 kernel bug? > > I'm not sure what the correct behaviour should be. The fact that it > > works in python2.4 feels more like a byproduct of the thread mask change > > than correct behaviour. > > Well, getting rid of the thread mask changes was one of the goals of > the change. I gathered that... which kinda means the fact that it fixed execvp in threads is a side effect...(though I also guess it fixed a lot of other things like this too). > > To me it seems like execvp() should be setting the signal mask back > > to defaults or at least the mask of the main process before doing > > the exec. > > Possibly. I think the 2.4 change -- not fiddling the process mask at > all -- is the Right Thing, but that doesn't help 2.3 users. This has > all been discussed before at some length, on python-dev and in various > bug reports on SF. Would a simple bug-fix for 2.3 be to have os.execvp() set the mask to something sane before executing C execvp()? Given that Python does not have any visibility of the procmask... This might be a good idea regardless as it will protect against this bug resurfacing in the future if someone decides fiddling with the mask for threads is a good idea again. > In your situation, I think the simplest thing you can do is dig out an > old patch of mine that exposes sigprocmask + co to Python and either > make a custom Python incorporating the patch and use that, or put the > code from the patch into an extension module. Then before execing > fop, use the new code to set the signal mask to something sane. Not > pretty, particularly, but it should work. The extension module that exposes sigprocmask() is probably best for now... -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCon Preliminary Program Announced!
Dear Python Colleague: You will be happy to know that the PyCon Program Committee, after lengthy deliberations, has now finalized the program for PyCon DC 2005. I can tell you that the decision-making was very difficult, as the standard of submissions was even higher than last year. You can see the preliminary program at http://www.python.org/pycon/2005/schedule.html and it's obvious that this year's PyCon is going to be even fuller than the last. On innovation is that there will be activities of a more social nature on the Wednesday (and perhaps the Thursday) evening, as well as keynote speeches from Guido and two other luminaries. Remember that the early bird registration rates end in just over a week, so hurry on down to http://www.python.org/pycon/2005/register.html to be sure of your place in what will surely be the premier Python event of the year. As always, I would appreciate your help in getting the word out. Please forward this message to your favorite mailing lists and newsgroups to make sure that everyone has a chance to join in the fun! regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
Hello, I would like to add here another small thing which I encountered this week, and seems to follow the same logic as does Guido's proposal. It's about staticmethods. I was writing a class, and its pretty-printing method got a function for converting a value to a string as an argument. I wanted to supply a default function. I thought that it should be in the namespace of the class, since its main use lies there. So I made it a staticmethod. But - alas! After I declared the function a staticmethod, I couldn't make it a default argument for the method, since there's nothing to do with staticmethod instances. The minor solution for this is to make staticmethod objects callable. This would solve my problem. But I suggest a further step: I suggest that if this is done, it would be nice if classname.staticmethodname would return the classmethod instance, instead of the function itself. I know that this things seems to contradict Guido's proposal, since he suggests to return the function instead of a strange object, and I suggest to return a strange object instead of a function. But this is not true; Both are according to the idea that class attributes should be, when possible, the same objects that were created when defining the class. This is more consistent with the behaviour of modules (module attributes are the objects that were created when the code was run), and is more consistent with the general convention, that running A = B causes A == B to be true. Currently, Class.func = staticmethod(func), and Class.func = func, don't behave by this rule. If the suggestions are accepted, both will. I just think it's simpler and cleaner that way. Just making staticmethods callable would solve my practical problem too. Noam Raphael ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
> It's about staticmethods. I was writing a class, and its > pretty-printing method got a function for converting a value to a > string as an argument. I wanted to supply a default function. I > thought that it should be in the namespace of the class, since its > main use lies there. So I made it a staticmethod. > > But - alas! After I declared the function a staticmethod, I couldn't > make it a default argument for the method, since there's nothing to do > with staticmethod instances. > > The minor solution for this is to make staticmethod objects callable. > This would solve my problem. But I suggest a further step: I suggest > that if this is done, it would be nice if classname.staticmethodname > would return the classmethod instance, instead of the function itself. > I know that this things seems to contradict Guido's proposal, since he > suggests to return the function instead of a strange object, and I > suggest to return a strange object instead of a function. But this is > not true; Both are according to the idea that class attributes should > be, when possible, the same objects that were created when defining > the class. This is more consistent with the behaviour of modules > (module attributes are the objects that were created when the code was > run), and is more consistent with the general convention, that running > A = B > causes > A == B > to be true. Currently, Class.func = staticmethod(func), and Class.func > = func, don't behave by this rule. If the suggestions are accepted, > both will. Well, given that attribute assignment can be overloaded, you can't depend on that requirement all the time. > I just think it's simpler and cleaner that way. Just making > staticmethods callable would solve my practical problem too. The use case is fairly uncommon (though not invalid!), and making staticmethod callable would add more code without much benefits. I recommend that you work around it by setting the default to None and substituting the real default in the function. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
> Removing unbound methods also breaks the 'py' lib quite a bit. The 'py.test' > framework handles function and bound/unbound method objects all over the > place, and uses introspection on them, as they are the objects defining the > tests to run. OK, I'm convinced. Taking away im_class is going to break too much code. I hereby retract the patch. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated Monkey Typing pre-PEP
Phillip, it looks like you're not going to give up. :) I really don't want to accept your proposal into core Python, but I think you ought to be able to implement everything you propose as part of PEAK (or whatever other framework). Therefore, rather than continuing to argue over the merits of your proposal, I'd like to focus on what needs to be done so you can implement it. The basic environment you can assume: an adaptation module according to PEP 246, type declarations according to my latest blog (configurable per module or per class by defining __typecheck__, but defaulting to something conservative that either returns the original object or raises an exception). What do you need then? [My plane is about to leave, gotta run!] -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch review [ 1093585 ] sanity check for readline remove/replace
Patch review [ 1093585 ] sanity check for readline remove/replace The functions remove_history_item and replace_history_item in the readline module respectively remove and replace an item in the history of commands. As outlined in bug [ 1086603 ], both functions cause a segmentation fault if the item index is negative. This is actually a bug in the corresponding functions in readline, which return a NULL pointer if the item index is larger than the size of the history, but does not check for the item index being negative. I sent a patch to [EMAIL PROTECTED], so this will probably be fixed in future versions of readline. But for now, we need a workaround in Python. The patched code checks if the item index is negative, and issues an error message if so. I have run the test suite after applying this patch, and I found no problems with it. Note that there is one more way to fix this bug, which is to interpret negative indeces as counting from the end (same as lists and strings for exampe). So remove_history_item(-1) removes the last item added to the history etc. In that case, get_history_item should change as well. Right now get_history_item(-1) returns None, so the patch introduces a small (and probably insignificant) inconsistency: get_history_item(-1) returns None but remove_history_item(-1) raises an error. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unix line endings required for PyRun* breaking embedded Python
Just van Rossum wrote:
Skip Montanaro wrote:
Just re.sub("[\r\n]+", "\n", s) and I think you're good to go.
I don't think that in general you want to fold multiple empty lines into
one. This would be my prefered regex:
s = re.sub(r"\r\n?", "\n", s)
Catches both DOS and old-style Mac line endings. Alternatively, you can
use s.splitlines():
s = "\n".join(s.splitlines()) + "\n"
This also makes sure the string ends with a \n, which may or may not be
a good thing, depending on your application.
Do people consider this a bug that should be fixed in Python 2.4.1 and
Python 2.3.6 (if it ever exists), or is the resposibility for doing this
transformation on the application that embeds Python?
--
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Unix line endings required for PyRun* breakingembedded Python
Stuart Bishop wrote: > Do people consider this a bug that should be fixed in Python 2.4.1 and Python > 2.3.6 (if it ever > exists), or is the resposibility for doing this transformation on the > application that embeds > Python? the text you quoted is pretty clear on this: It is envisioned that such strings always have the standard \n line feed, if the strings come from a file that file can be read with universal newlines. just add the fix, already (you don't want plpythonu to depend on a future release anyway) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
> > and is more consistent with the general convention, that running > > A = B > > causes > > A == B > > to be true. Currently, Class.func = staticmethod(func), and Class.func > > = func, don't behave by this rule. If the suggestions are accepted, > > both will. > > Well, given that attribute assignment can be overloaded, you can't > depend on that requirement all the time. > Yes, I know. For example, I don't know how you can make this work for classmethods. (although I have the idea that if nested scopes were including classes, and there was a way to assign names to a different scope, then there would be no need for them. But I have no idea how this can be done, so never mind.) I just think of it as a very common convention, and I don't find the exceptions "aesthetically pleasing". But of course, I accept practical reasons for not making it that way. > I recommend that you work around it by setting the default to None and > substituting the real default in the function. That's a good idea, I will probably use it. (I thought of a different way: don't use decorators, and wrap the function in a staticmethod after defining the function that uses it. But this is really ugly.) Thanks for your reply, Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
