Re: [Python-Dev] Plea to distribute debugging lib
David Abrahams wrote: >>I would go a step further than Tim: Send me (*) a patch to msi.py (which >>is used to build the distribution) that picks up the files and packages >>them in the desired way, and I will include the files it outputs >>in the official distribution. This is how the libpython24.a got in >>(and this is also the way in which it will get out again). > > > Not to look a gift horse in the mouth, but won't that cause the > problem that Tim was worried about, i.e. a bloated Python installer? Not if done properly: it would, of course, *not* add the desired files in to the msi file, but create a separate file. It is pure Python code, and called msi.py because that's it main function. It does several other things, though (such as creating a .cab file and a .a file); it could well create another zip file. As to how it would work: preferably by invoking the Python zip library, but invoking external programs to package up everything might be acceptable as well (assuming I'm told what these tools are, and assuming it falls back to doing nothing if the tools are not available). The separate file would have a name similar to the MSI file, so that the debug file has the same version number as the MSI file. > I s'pose that means, "put it in the patches tracker." > Exactly. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >>> Just to clarify - what we are asking for is library built with >>> _DEBUG and no BOOST_DEBUG_PYTHON, that is the one compatible with >>> default Python distribution. >> I know you're trying to help, but I'm sure that's not making >> anything >> clearer for these people. They don't know anything about >> BOOST_DEBUG_PYTHON and would never have cause to define it. >> > > Actually, I'm truly puzzled. I was afraid this would happen. Really, you're better off ignoring Bronek's message. > Why would a library that has _DEBUG defined > be compatible with the standard distribution? Doesn't _DEBUG cause > linkage with msvcr71d.dll? Unless you do the hacks that I mentioned in my opening message. Read http://www.boost.org/libs/python/doc/building.html#variants for details. > In addition (more correctly: for that reason), the debug build causes > python2x_d.dll to be build, instead of python2x.dll, which definitely > is incompatible with the standard DLL. It not only uses a different > C library; it also causes Py_DEBUG to be defined, which in turn creates > a different memory layout for PyObject. Exactly. > So in the end, I would assume you are requesting what you call a > debug-python, i.e. one that (in your system) *has* > BOOST_DEBUG_PYTHON defined. What I am requesting is the good old python2x_d.dll and any associated extension modules that get built as part of the Python distro, so I can stop doing the hack, drop BOOST_DEBUG_PYTHON, and tell people use _DEBUG in the usual way. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Who knows what the whiny babies will accept? That said, I think >> people would be happy with a .zip file containing whatever is built by >> selecting the debug build in the VS project and asking it to build >> everything. (**) > > I would go a step further than Tim: Send me (*) a patch to msi.py (which > is used to build the distribution) that picks up the files and packages > them in the desired way, and I will include the files it outputs > in the official distribution. This is how the libpython24.a got in > (and this is also the way in which it will get out again). Not to look a gift horse in the mouth, but won't that cause the problem that Tim was worried about, i.e. a bloated Python installer? > In the patch, preferably state whom to contact for the specific feature, > as I won't be able to answer questions about it. > > I don't have a personal need for the feature (I do have debug builds > myself, and it takes only 10 minutes or so to create them), I know, me too. It's easy enough once you get started building Python. I just think it's too big a hump for many people. > so I won't even have a way to test whether the feature works > correctly. > > Regards, > Martin > > (*) that is, sf.net/projects/python I s'pose that means, "put it in the patches tracker." grateful-ly y'rs, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators vs metaclasses
On 11/4/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> I have a few claims, some unrelated, and some built on top of each
> other. I would like to hear your responses as to which are
> convincing, which arne't, and why. I think that if these claims are
> true, Python 3000 should change quite a bit.
>
> A. Metaclass code is black magic and few understand how it works,
> while decorator code is mostly understandable, even by non-gurus.
I disagree. I've held many presentations and classes on both
subjects, and while people may INITIALLY feel like metaclasses are
black magic, as soon as I've explained it the fear dissipates. It all
boils down do understanding that:
class Name(Ba,Ses): <>
means
Name = suitable_metaclass('Name', (Ba,Ses), <>)
which isn't any harder than understanding that
@foo(bar)
def baz(args): ...
means
def baz(args): ...
baz = foo(bar)(baz)
> B. One of Decorators' most powerful features is that they can
> mixed-and-matched, which makes them very powerful for many purposes,
> while metaclasses are exclusive, and only one can be used. This is
Wrong. You can mix as many metaclasses as you wish, as long as
they're properly coded for multiple inheritance (using super, etc) --
just inherit from them all. This is reasonably easy to automate (see
the last recipe in the 2nd ed of the Python Cookbook), too.
> especially problematic as some classes may assume their subclasses
> must use their respective metaclasses. This means classdecorators are
> strictly more powerful than metaclasses, without cumbersome
> convertions between metaclass mechanisms and decorator mechanisms.
The assertion that classdecorators are strictly more powerful than
custom metaclasses is simply false. How would you design
classdecorator XXX so that
@XXX
class Foo: ...
allows 'print Foo' to emit 'this is beautiful class Foo', for example?
the str(Foo) implicit in print calls type(Foo).__str__(Foo), so you
do need a custom type(Foo) -- which is all that is meant by "a custom
metaclass"... a custom type whose instances are classes, that's all.
> C. Interesting uses of classdecorators are allowing super-calling
> without redundantly specifying the name of your class, or your
> superclass.
Can you give an example?
>
> D. Python seems to be incrementally adding power to the core language
> with these features, which is great, but it also causes significant
> overlapping of language features, which I believe is something to
> avoid when possible. If metaclasses are replaced with class
> decorators, then suddenly inheritence becomes a redundant feature.
And how do you customize what "print Foo" emits, as above?
> E. If inheritence is a redundant feature, it can be removed and an
> "inherit" class decorator can be used. This could also reduce all the
> __mro__ clutter from the language along with other complexities, into
> alternate implementations of the inherit classdecorator.
How do you propose to get exactly the same effects as inheritance
(affect every attribute lookup on a class and its instances) without
inheritance? Essentially, inheritance is automated delegation
obtained by having getattr(foo, 'bar') look through a chain of objects
(essentially the __mro__) until an attribute named 'bar' is found in
one of those objects, plus a few minor but useful side effects, e.g.
on isinstance and issubclass, and the catching of exceptions in
try/except statements. How would any mechanism allowing all of these
uses NOT be inheritance?
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
David Abrahams wrote: >>Just to clarify - what we are asking for is library built with _DEBUG >>and no BOOST_DEBUG_PYTHON, that is the one compatible with default >>Python distribution. > > > I know you're trying to help, but I'm sure that's not making anything > clearer for these people. They don't know anything about > BOOST_DEBUG_PYTHON and would never have cause to define it. > Actually, I'm truly puzzled. Why would a library that has _DEBUG defined be compatible with the standard distribution? Doesn't _DEBUG cause linkage with msvcr71d.dll? In addition (more correctly: for that reason), the debug build causes python2x_d.dll to be build, instead of python2x.dll, which definitely is incompatible with the standard DLL. It not only uses a different C library; it also causes Py_DEBUG to be defined, which in turn creates a different memory layout for PyObject. So in the end, I would assume you are requesting what you call a debug-python, i.e. one that (in your system) *has* BOOST_DEBUG_PYTHON defined. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Class decorators vs metaclasses
I have a few claims, some unrelated, and some built on top of each other. I would like to hear your responses as to which are convincing, which arne't, and why. I think that if these claims are true, Python 3000 should change quite a bit. A. Metaclass code is black magic and few understand how it works, while decorator code is mostly understandable, even by non-gurus. B. One of Decorators' most powerful features is that they can mixed-and-matched, which makes them very powerful for many purposes, while metaclasses are exclusive, and only one can be used. This is especially problematic as some classes may assume their subclasses must use their respective metaclasses. This means classdecorators are strictly more powerful than metaclasses, without cumbersome convertions between metaclass mechanisms and decorator mechanisms. C. Interesting uses of classdecorators are allowing super-calling without redundantly specifying the name of your class, or your superclass. D. Python seems to be incrementally adding power to the core language with these features, which is great, but it also causes significant overlapping of language features, which I believe is something to avoid when possible. If metaclasses are replaced with class decorators, then suddenly inheritence becomes a redundant feature. E. If inheritence is a redundant feature, it can be removed and an "inherit" class decorator can be used. This could also reduce all the __mro__ clutter from the language along with other complexities, into alternate implementations of the inherit classdecorator. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
David Abrahams wrote: > Who knows what the whiny babies will accept? That said, I think > people would be happy with a .zip file containing whatever is built by > selecting the debug build in the VS project and asking it to build > everything. (**) I would go a step further than Tim: Send me (*) a patch to msi.py (which is used to build the distribution) that picks up the files and packages them in the desired way, and I will include the files it outputs in the official distribution. This is how the libpython24.a got in (and this is also the way in which it will get out again). In the patch, preferably state whom to contact for the specific feature, as I won't be able to answer questions about it. I don't have a personal need for the feature (I do have debug builds myself, and it takes only 10 minutes or so to create them), so I won't even have a way to test whether the feature works correctly. Regards, Martin (*) that is, sf.net/projects/python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
Bronek Kozicki <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Who knows what the whiny babies will accept? That said, I think >> people would be happy with a .zip file containing whatever is built by >> selecting the debug build in the VS project and asking it to build >> everything. (**) > > Just to clarify - what we are asking for is library built with _DEBUG > and no BOOST_DEBUG_PYTHON, that is the one compatible with default > Python distribution. Bronek, I know you're trying to help, but I'm sure that's not making anything clearer for these people. They don't know anything about BOOST_DEBUG_PYTHON and would never have cause to define it. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
Tim Peters <[EMAIL PROTECTED]> writes: > [David Abrahams] >> For years, Boost.Python has been doing some hacks to work around the >> fact that a Windows Python distro doesn't include the debug build of >> the library. >> ... >> MS is recommending that we (Boost) start distributing a debug build of the >> Python DLL with Boost, but Boost really seems like the wrong place to host >> such a thing. Is there any way Python.org can make a debug build more >> accessible? > > Possibly. I don't do this anymore (this == build the Python Windows > installers), but I used to. For some time I also made available a zip > file containing various debug-build bits, captured at the time the > official installer was built. We didn't (and I'm sure we still don't) > want to include them in the main installer, because they bloat its > size for something most users truly do not want. > > I got sick of building the debug zip file, and stopped doing that too. > No two users wanted the same set of stuff in it, so it grew to > contain the union of everything everyone wanted, and then people > complained that it was "too big". This is one of the few times in > your Uncle Timmy's life that he said "so screw it -- do it yourself, > you whiny baby whiners with your incessant baby whining you " ;-) > > Based on that sure-to-be universal reaction from anyone who signs up > for this, I'd say the best thing you could do to help it along is to > define precisely (a) what an acceptable distribution format is; and, > (b) what exactly it should contain. Who knows what the whiny babies will accept? That said, I think people would be happy with a .zip file containing whatever is built by selecting the debug build in the VS project and asking it to build everything. (**) > That, and being nice to Martin, I'm always as nice as Davidly possible to Martin! > would go a long way. My fingers and toes are crossed. Thanks! (**) If you could build the ability to download the debugging binaries into the regular installer, that would be the shiznit, but I don't dare ask for it. ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
Guido van Rossum <[EMAIL PROTECTED]> writes: > I vaguely recall that there were problems with distributing the debug > version of the MS runtime. Right: the debug runtime dlls are not disributable. > Anyway, why can't you do this yourself for all Boost users? It's all > volunteer time, you know... Doesn't any boost user need a C compiler anyway, so it should not really be a problem to compile Python? Anyway, AFAIK, the activestate distribution contains Python debug dlls. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
[David Abrahams] > For years, Boost.Python has been doing some hacks to work around the > fact that a Windows Python distro doesn't include the debug build of > the library. > ... > MS is recommending that we (Boost) start distributing a debug build of the > Python DLL with Boost, but Boost really seems like the wrong place to host > such a thing. Is there any way Python.org can make a debug build more > accessible? Possibly. I don't do this anymore (this == build the Python Windows installers), but I used to. For some time I also made available a zip file containing various debug-build bits, captured at the time the official installer was built. We didn't (and I'm sure we still don't) want to include them in the main installer, because they bloat its size for something most users truly do not want. I got sick of building the debug zip file, and stopped doing that too. No two users wanted the same set of stuff in it, so it grew to contain the union of everything everyone wanted, and then people complained that it was "too big". This is one of the few times in your Uncle Timmy's life that he said "so screw it -- do it yourself, you whiny baby whiners with your incessant baby whining you " ;-) Based on that sure-to-be universal reaction from anyone who signs up for this, I'd say the best thing you could do to help it along is to define precisely (a) what an acceptable distribution format is; and, (b) what exactly it should contain. That, and being nice to Martin, would go a long way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
I vaguely recall that there were problems with distributing the debug version of the MS runtime. Anyway, why can't you do this yourself for all Boost users? It's all volunteer time, you know... --Guido On 11/4/05, Charles Cazabon <[EMAIL PROTECTED]> wrote: > David Abrahams <[EMAIL PROTECTED]> wrote: > > > > For years, Boost.Python has been doing some hacks to work around the fact > > that a Windows Python distro doesn't include the debug build of the library. > [...] > > Having to download the Python source and build the debug DLL was deemed > > unacceptable. > > I'm curious: why was this "deemed unacceptable"? Python's license is about as > liberal as it gets, and the code is almost startlingly easy to compile -- > easier than any other similarly-sized codebase I've had to work with. > > Charles > -- > --- > Charles Cazabon <[EMAIL PROTECTED]> > GPL'ed software available at: http://pyropus.ca/software/ > --- > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
David Abrahams <[EMAIL PROTECTED]> wrote: > > For years, Boost.Python has been doing some hacks to work around the fact > that a Windows Python distro doesn't include the debug build of the library. [...] > Having to download the Python source and build the debug DLL was deemed > unacceptable. I'm curious: why was this "deemed unacceptable"? Python's license is about as liberal as it gets, and the code is almost startlingly easy to compile -- easier than any other similarly-sized codebase I've had to work with. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Plea to distribute debugging lib
For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library. http://www.boost.org/libs/python/doc/building.html#variants explains. We wanted to make it reasonably convenient for Windows developers (and our distributed testers) to work with a debug build of the Boost.Python library and of their own code. Having to download the Python source and build the debug DLL was deemed unacceptable. Well, those hacks have run out of road. VC++8 now detects that some of its headers have been #included with _DEBUG and some without, and it will refuse to build anything when it does. We have several new hacks to work around that detection, and I think we _might_ be able to get away with them for one more release. But it's really time to do it right. MS is recommending that we (Boost) start distributing a debug build of the Python DLL with Boost, but Boost really seems like the wrong place to host such a thing. Is there any way Python.org can make a debug build more accessible? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] No more problems with new SVN repository
[Guido van Rossum] > Is there a way to prevent this kind of thing in the future, e.g. by > removing or rejecting change log messages with characters that are > considered invalid in XML? Suppose TOP is the top of the Subversion repository. The easiest way is providing a TOP/hook/pre-commit script. If the script exits with non-zero status, usually with some clear diagnostic on stderr, the whole commit aborts, and the diagnostic is shown to the committing user. The tricky part is getting the tentative log message from within the script. This is done by popening "svnlook log -t ARG2 ARG1", where ARG1 and ARG2 are arguments given to the pre-commit script. -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding examples to PEP 263
M.-A. Lemburg wrote: > Fredrik Lundh wrote: > >>the runtime warning you get when you use non-ascii characters in >>python source code points the poor user to this page: >> >>http://www.python.org/peps/pep-0263.html >> >>which tells the user to add a >> >># -*- coding: -*- >> >>to the source, and then provides a more detailed syntax description >>as a RE pattern. to help people that didn't grow up with emacs, and >>don't speak fluent RE, and/or prefer to skim documentation, it would >>be a quite helpful if the page also contained a few examples; e.g. >> >># -*- coding: utf-8 -*- >># -*- coding: iso-8859-1 -*- >> >>can anyone with SVN write access perhaps add this? > > > Good point. I'll add some examples. > > >>(I'd probably add a note to the top of the page for anyone who arrives >>there via a Python error message, which summarizes the pep and provides >>an example or two; abstracts and rationales are nice, but if you're just a >>plain user, a "do this; here's how it works; further discussion below" style >>is a bit more practical...) > > > The PEP isn't all that long, so I don't think a summary would > help. However, we might want to point the user to a different > URL in the error message, e.g. a Wiki page with more user-friendly > content. > Under NO circumstances should a Wiki page be used as the destination for a link in a runtime error message. If the page happens to be spammed when the user follows the link they'll wonder why the error message is pointing to a page full of links to hot babes, or whatever. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
On 11/3/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > 3. If someone does want to associate values with objects, he can > > explicitly use id: > > dct[id(x)] = 3. > > This is fragile. Once all references to x are dropped, > it is possible for another object to be created having > the same id that x used to have. The dict now > unintentionally references the new object. > You are right. Please see the simple "ref" class that I wrote in my previous post, which solves this problem. Noam ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding examples to PEP 263
Fredrik Lundh wrote: > the runtime warning you get when you use non-ascii characters in > python source code points the poor user to this page: > > http://www.python.org/peps/pep-0263.html > > which tells the user to add a > > # -*- coding: -*- > > to the source, and then provides a more detailed syntax description > as a RE pattern. to help people that didn't grow up with emacs, and > don't speak fluent RE, and/or prefer to skim documentation, it would > be a quite helpful if the page also contained a few examples; e.g. > > # -*- coding: utf-8 -*- > # -*- coding: iso-8859-1 -*- > > can anyone with SVN write access perhaps add this? Good point. I'll add some examples. > (I'd probably add a note to the top of the page for anyone who arrives > there via a Python error message, which summarizes the pep and provides > an example or two; abstracts and rationales are nice, but if you're just a > plain user, a "do this; here's how it works; further discussion below" style > is a bit more practical...) The PEP isn't all that long, so I don't think a summary would help. However, we might want to point the user to a different URL in the error message, e.g. a Wiki page with more user-friendly content. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 04 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2005-10-17: Released mxODBC.Zope.DA 1.0.9http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding examples to PEP 263
the runtime warning you get when you use non-ascii characters in python source code points the poor user to this page: http://www.python.org/peps/pep-0263.html which tells the user to add a # -*- coding: -*- to the source, and then provides a more detailed syntax description as a RE pattern. to help people that didn't grow up with emacs, and don't speak fluent RE, and/or prefer to skim documentation, it would be a quite helpful if the page also contained a few examples; e.g. # -*- coding: utf-8 -*- # -*- coding: iso-8859-1 -*- can anyone with SVN write access perhaps add this? (I'd probably add a note to the top of the page for anyone who arrives there via a Python error message, which summarizes the pep and provides an example or two; abstracts and rationales are nice, but if you're just a plain user, a "do this; here's how it works; further discussion below" style is a bit more practical...) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
