I am personally indifferent to this, even though I had in mind in
PEP309, that compose would probably end up in there too.
On the one hand, some people will keep on expecting it to be there. The
ones that care about it will not be confused: they'll expect
compose(f,g)(x) to be f(g(x)) as is proposed. It can't do any
On the other hand it's not likely to be used even as often as partial,
which I always wanted mostly to make anonymous callables for Tkinter,
not because of any ivory-tower functional programming bias. And the
most common use case of compose() is covered by a one-liner that really
doesn't need to be in the standard library.
I'll say +0, with the + because if new Python programmers run across
compose() in the docs, and aren't familiar with the idea, they can
follow a link from there to Wikipedia, and maybe it will give them an
idea we haven't thought of for something cool to do with it.
I am trying to add a module written in c to python source on Win32 using
VC++ 9 Pro.
I went through the available documentation but there doesn't seem to be any
clear instruction on how to do that.
Basically I opened pcbuild.sln in vc++, added the c file (xxx.c) to Modules/
Building the solution after that works fine: xxx.c is compiled (no errors,
no warnings) and
the python executable gets created. But I am not able to import the module
in xxx.c using that executable.
Do I need to register this module some place else too (setup.py?) ?
Any hints and pointers will be appreciated :)
Is the PEP considering all non-private APIs public even if they are
not documented? If so we might want to be up front about that and say
so to make sure we are all very careful about making all non-essential
APIs private (assuming this PEP gets accepted).
And we might want to say that all code in 'test' sub-packages are not
subject to backwards compatibility unless documented. I have a ton of
support code in importlib.test that I do not want to have to maintain
for public consumption as they are meant solely for testing purposes
by me. If you read the PEP it would suggest that all modules in test
are subject to the PEP's compatibility policy which is obviously
Hi! I'm trying to catch the triple zero (000) key from a numeric keyboard
but, I found that it's the same id that the single zero. So, when I press
the triple zero key once, I receive three events from the single zero key.
I need to make a disctintion between these keys, and use them to different
How can I do?
I once announced that I would be working on releasing 2.4.7 this month.
However, since no patches have been committed to 2.4.6, there is little
point in making a release. As 2.4 is nearing its end-of-life soon, there
likely won't be any 2.4.7 release.
Python 2.5 has seen only two patches since 2.5.4. However, since several
months have been passed since that release, I'll be creating a 2.5.5
release candidate within a few days.
Further security releases of Python 2.5 will be made until September 2011.
There is an interesting suggestion (http://bugs.python.org/issue6749).
to add support to run encrypted zip files as python scripts.
No doubt this is a useful functionality to have but it would be great to
have some comments on whether
this can be(or even should be) feasibly added as an inbuilt support.
Senior Undergraduate, Department of Computer Science and Engineering
Indian Institute of Technology Bombay
I like the idea, but...
Here is a quick list of things to think about and if some of this has
already been mentioned, sorry.
Speed: Encryption speed has been mentioned. For short scripts this may
not be a problem, although algorithms implemented in C would be faster.
Strength: Passwords are [very] weak, especially if of the 6-10
alphanumeric variety. True secret keys where all bit combinations are
used is stronger. Entering passwords has been mentioned but I believe
only passwords were assumed. It is better to not provide any encryption
than to lure novices into believing they are secure when they are not.
Algorithms: Be sure to choose good ones and allow for changing later.
Key distribution: How to distribute secret keys beyond a small group of
friends is problematic. In short it doesn't scale. Looking to
public-private key pairs can be equally problematic. This can get you
into encryption certs, but *how* you use them correctly differs from
signing certs. More on this later if you want.
ZIP: Look beyond just zip files. A scheme that works for any/all files
in the distribution, not just ZIPs, would be better. (IIRC there have
been problems with encrypted zips, but that was years ago. Those issues
may have been fixed.)
Short version: Doing this right is hard. Simply supporting a password
based ZIP file is, in my opinion, not real protection.
Gotta go. Later.
What is the procedure for finding out why an issue hasn't progressed? I
don't want to fill the bug database with such noise.
In the case of <URL:http://bugs.python.org/issue1170> (“shlex have
problems with parsing unicode”), the problem is apparently addressed by
a patch, assigned to that issue since 2007-12-22. There is no indication
in the report why it's not yet applied.
I'd really like this fixed in the 2.x series if possible.
\ “… whoever claims any right that he is unwilling to accord to |
`\ his fellow-men is dishonest and infamous.” —Robert G. |
_o__) Ingersoll, _The Liberty of Man, Woman and Child_, 1877 |