>From: Gustavo Niemeyer <niemeyer(a)conectiva.com>
>Subject: [Python-Dev] Small additions to optparser
>Date: Thu, 29 Apr 2004 16:47:35 -0300
>I have two small customizations I've used in most projects I've
>plugged optparse into. Since they're simple and generic, I'd
>like to integrate them back in optparser. These features are:
>- Add a help formatter which uses capitalized headers.
>- Add a "help" keyword in OptionParser, allowing straightforward
> addition of a custom help messages.
It would be nice to have a way for the white space to be cleaned up in the
help string. This would be useful when using multiline triple quoted
strings to pass in help text to the option parser and you want to indent the
help text on each line so the source code reads well.
Getting married? Find tips, tools and the latest trends at MSN Life Events.
At the C level,
is just a shortcut for
PyDict_Merge(old, new, override)
C extensions can use PyDict_Merge directly with override=0,
which keeps the current value in case of duplicate keys.
Python code can only use update, which means that override
is always true. Is there a good reason this?
[Gustavo Niemeyer wrote]
>> Hi Folks,
>> I have two small customizations I've used in most projects I've
>> plugged optparse into. [...]
[Dan Gass wrote]
> It would be nice to have a way for the white space to be cleaned up in
> the help string. This would be useful when using multiline triple
> quoted strings to pass in help text to the option parser and you want to
> indent the help text on each line so the source code reads well.
There's already code to do this type of clean-up in inspect.getdoc().
Maybe it could be copied (or moved out of getdoc() into its own function
i have tried to run Mozpython 0.1.1 on my i386 running Python 2.3.3 and Mozilla 1.6. The compilation is successful but when i try to run a python script in Mozilla it gives me a lost sys.stderr
ny comments r most welcome.
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com
Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now!
I have just read PEP-320 and noticed the following comments regarding
the "collections" package:
- ? bag (only if use cases established)
I would like to argue for such a use case. We at designtheory.org are
working on a (maths / stats / comp. sci.) project in the area of Design
Theory. Design theory intersects with many fields, to mention a few:
combinatorics, graph theory, finite geometry, coding theory, and the
design of statistical experiments (from which then name of the field
comes). Most of our software development will be in Python, although
the released python software so far is very modest.
To show why bags are important for us and, in general, for discrete
mathematicians, here is the definition of the most important type of
designs. A binary block design is a multiset (that is a 'bag') of
subsets of a 'base' set; the elements of the base set are called
'points' and its subsets are called 'blocks'. (Personally, I prefer the
name bag but most mathematicians use multiset.) A non-binary block
design is one whose blocks can also be multisets.
The computations we are facing are very much combinatorial in nature so
we are happy to see that Sets became a builtin and, of course, would
like to see a C implementation for bags too. Our pydesign package (will)
heavily use C extensions. So far we use numarray to compute statistical
properties of designs, but many more combinatorial functionalities will
be implemented in C.
In particular, we are planning to implement a basic permutation group
package whose core will eventually be a C extension. We would like to
deal with automorphism groups and isomorphisms of designs on at least a
basic level within the pydesign package without having to resort to
specialized mathematical packages like GAP. These functionalities can be
useful not only for design theorist, but for anybody using Python to
deal with combinatorial structures, like graphs for example.
In all of these areas the use of multisets (bags) is pervasive.
Please, implement it -- so we don't have to :-)
For more details on our project, please visit http://designtheory.org/
The collections module will be offering
new datatypes, including a double-ended
Right now, these are new elemental types,
inheriting directly from object. I believe
they should be subclassed from existing
classes where this makes sense. Even if
no actual methods are inherited, the API
For instance, should:
list([1,2,3]) == deque([1,2,3])
deque() < list([1,2]) < deque()
If deque inherits directly from object,
then the only comparison available is
based on address. If deque subclasses
list (or at least pretends to), then
sensible comparisons can be made.
All list operations make sense on a deque
(and vice versa). Operations may be more
(or less) efficient depending on the type,
but they do make sense. Even if the concern
is to avoid encouraging inefficient code,
the methods should still be available.
d = deque(...)
d[4:11] = ('x', 'y')
is inefficient, but still better than
d = deque(...)
temp = list(d)
temp[4:11] = ('x', 'y')
d = deque(temp)
As an additional benefit, making deque a
subclass of list with the same API gives
later python implementations more freedom;
in theory, the compiler could determine
which internal representation made more
sense for each particular case.
I have put on-line some slides from the Python UK conference at ACCU 2004,
explaining how Psyco works. It is actually a Pygame application... As far as
I can tell, it is the first time someone in the room actually understood
something at the end :-)
I hope it should help to make Psyco a bit less mysterious, and also explain
why it is difficult to have a general idea about what kind of speed-up you can
expect for specific kinds of code: it is, after all, a pretty low-level
"local" process that Psyco does, and it sometimes pays off and sometimes not.
It also explains why this process is very much like the usual interpretation
that CPython does. If you think about it you might see how useful it would be
for Psyco to build on top of an interpreter in a better language than C (i.e.
one that can be analysed, not just blindly run).
When I tried "cvs update" today, I got an error from ssh:
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
The RSA1 host key for cvs.python.sourceforge.net has changed,
and the key for the according IP address 220.127.116.11
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA1 host key has just been changed.
The fingerprint for the RSA1 key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/guido/.ssh/known_hosts to get rid of this message.
Offending key in /home/guido/.ssh/known_hosts:1
RSA1 host key for cvs.python.sourceforge.net has changed and you have requested strict checking.
Host key verification failed.
cvs [update aborted]: end of file from server (consult above messages if any)
After deleting the key from my known_hosts file, all I get is requests
for a password, which I refuse to give (since it shouldn't be
necessary and I don't want to rule out a man-in-the-middle attack
yet). I've tried both ssh -1 and ssh -2.
Has this happened to anybody else? The SF.net Site Status Page shows
--Guido van Rossum (home page: http://www.python.org/~guido/)
Edward C. Jones writes:
> # According to
> # http://www.cafepy.com/articles/python_attributes_and_methods/ch03s02.html
> # the correct ways to subtype mutable and immutable built-in types are
> # This warty stuff needs documenting.
The use of __init__ and __new__ with immutable classes is already
documented at "http://www.python.org/2.2/descrintro.html#__new__".
If you have a suggestion of a another place this should be described,
let us know or better yet file a bug report at SourceForge.
-- 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.
I've been working with gettext support in Python, and found some
issues I'd like to discuss with you.
First, I've noticed that there's a difference in the internal
implementation of gettext and GNU gettext regarding the returned
encoding on non-unicode strings. Notice the difference in the
result of this code:
print locale.gettext("Choose the available CDROMs from the list below")
print gettext.gettext("Choose the available CDROMs from the list below")
This has shown the following:
Escolha os CDROMs disponíves na lista abaixo
Escolha os CDROMs disponÃves na lista abaixo
The reason for this difference is clear: GNU gettext defaults to the
current locale when returning encoded strings, while gettext.py
returns strings in the encoding used in the .mo file. The fix is
simply changing the following code
# Encode the Unicode tmsg back to an 8-bit string, if possible
to use the system encoding (sys.getdefaultencoding()) instead of
Regarding a similar issue, I've also noticed that we're currently
missing bind_textdomain_codeset() support. This function changes
the codeset used to return the translated strings.
So, I'd like to implement the following changes:
- Change the default codeset used by gettext.py in functions
returning an encoded string to match the system encoding.
- Introduce bind_textdomain_codeset() in locale.
- Introduce bind_textdomain_codeset() in gettext.py implementing
an equivalent functionality.