> From: Guido van Rossum [mailto:email@example.com]
> > Why is the Python development team introducing bugs into Python and
> > then expecting the user community to fix things that used to work?
> I resent your rhetoric, Glyph. Had you read the rest of this thread,
> you would have seen that the performance regression only happens for
> sending data at maximum speed over the loopback device, and is
> negligeable when receiving e.g. data over a LAN. You would also have
> seen that I have already suggested two different simple fixes.
Indeed - the primary purpose of a beta is IMO to discover these issues by use in as great a number of scenarios as possible before the final release is made.
I would be extremely surprised if this cannot be fixed before 2.3 final (in fact, I would be extremely surprised if such a known regression were allowed in 2.3 final).
A beta should (excluding implementation bugs) have *correct* behaviour. Performance is not the #1 priority for a beta.
iam new to python and tkinter. I have created a
canvas of size 300m * 300m (in millimeter). I bind
mouse move method to canvas. when i move the mouse
over the canvas the mouse position gets printed in
pixel unit. But i want to get mouse position values
interms of canvas unit (ie, millimeter). How can i get
mouse position values interms of canvas unit?
My program is given below.
from Tkinter import *
root = Tk()
c = Canvas(root,width="300m",height="300m",background
print c.canvasx(event.x), c.canvasy(event.y)
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
From: M.-A. Lemburg [mailto:firstname.lastname@example.org]
> In reality is probably is for most parts of the world. But
> why put this burden on the casual user ?
Speaking as a "casual user", I very rarely need or use crypto
software. However, when I do need it, having it "built in" is
a major benefit - most of the crypto packages either have
dependencies I'm not familiar with or don't have, or go far
too deep into crypto theory for me to follow. At the end of
the day, all I want is simple stuff, like for urllib to get a
"https" web page for me, "just like my browser does" (ie, with
no thought on my part...)
>>> Crypto is just too much (legal) work if you're serious
>>> about it.
>> So then you would advise to remove the OpenSSL support
>> from the Windows distribution, and from Python altogether?
> Hmm, I didn't know that the Windows installer comes with an SSL
> module that includes OpenSSL. I'd strongly advise to make that
> a separate download.
If you did, I'd expect that 99% of Windows users would perceive
that as "Python can't handle https URLs". Having a separate
download might be enough, as long as it was utterly trivial -
download the package, click to install, done. All dependencies
included, no extra work.
> Is there ? pycrypto is all you need if you're into deep crypto.
But pycrypto (at least when I've looked into it) definitely *isn't*
just a 1-click install, and a quick Google search reveals no way
of getting a prebuilt Windows binary. Of course, you say "if you're
into deep crypto", so maybe you'd say that expecting users to build
their own isn't unreasonable at that level.
Actually, m2crypto is another candidate, and it does include
Windows binaries (but they are a bit fiddly to install)...
> The standard SSL support is enough crypt for most people and
> that's already included in the distribution.
But you were arguing to take it out...
Personally, I'd like the existing stuff to stay as-is. I don't
particularly see the need for more crypto stuff in the core, but I'd
like to see a well-maintained, easy to install, "sanctioned" crypto
package for people who want to either use crypto "for real", or just
Guido van Rossum wrote:
> Please don't spread these around; I've made this response
> non-archivable by including an "X-Archive: No" header. (It's okay IMO
> for folks receiving python-dev to see this, but not to spread it
What is creating accesses to URLs like
Antigen for Exchange found Unknown infected with
The file is currently Removed. The message, "Why doesn't the uu module give
you the filename?", was
sent from python-list-admin(a)python.org and was discovered in IMC
located at Netsys International/NETSYS/NETSYS-NT-SERV.
Using the latest version from CVS, on Solaris 8 test_logging hangs. Lots of
INFO:root:Info index = 99
-- logging 100 at INFO, messages should be seen every 10 events --
-- logging 101 at INFO, messages should be seen every 10 events --
INFO:root:Info index = 100
INFO:root:Info index = 101
-- log_test2 end ---------------------------------------------------
-- log_test3 begin ---------------------------------------------------
Filtered with 'a.b'...
-- log_test3 end ---------------------------------------------------
and it just sits there. ^C doesn't terminate it. I have to stop it w/ ^Z,
then "kill %1" it. I have the very latest source checked out. Any ideas?
While it's simple enough to get the uu module to uudecode a string
(using StringIO), it's impossible to get it to handle you the filename
the uuencoded thing specifies.
begin 644 a.ii.gz
Their is no way to get the decode function to tell you the thing is
Of course, it uses this filename itself in creating an output file if
you don't specify one. It just won't tell *you* what the filename is.
I could just give it no output file, and let it create it, then
determine the name of the file it created, but this seems like a very
Besides, I am decoding from/to a string, in memory. I don't want to
start have it write things to the disk for no reason.
The context of all of this is that I have a program that is converting
text that possibly contains uuencoded attachments into a bunch of SQL
statements to insert into a database (It's converting a GNATS bug
database to a Bugzilla one. It's a rewrite of an incredibly ugly, slow,
barely functional perl script that spews errors at random and leaks
memory for no reason :P).
I had to cut/paste the decode function from the uu module into a new
module and make it return the filename, just so that i could get access
This seems a bit silly.
The decode function has no return value right now, so giving it one
shouldn't break existing applications (since none of them should be
expecting it to return anything).
I believe it should return the filename specified in the begin line.
As an added bonus, it would be even nicer if it also returned the start
and end position of the decoded portion inside the input text. that
way if one wants to replace the entire uuencoded text with something
like, say, "See bug attachments for <filename>", you can do it easily.
As i said, i've got a version of uu.decode that does all of this, i'll
happily submit it as a patch if people agree i'm right.
I've been upgrading a few machines to Redhat 9 from 7.3 and I've run
into a few minor problems with Python on the 2.2 maint branch. Both
dbmmodule and _socket fail to build properly. Neither problems exist in
The socket problem is fairly shallow I think: including ssl.h eventually
includes krb5.h. Python 2.3's setup.py has a couple of lines of code to
deal with this, and that just needs to go into 2.2 maint's setup.py, so
I checked this in.
The dbm problem is just a bit deeper. dbm ends up linking against gdbm,
so the library has to be specified in setup.py. I'm nervous about
adding the stuff to setup.py because I don't want to break other
platforms. Looking at 2.3's setup.py shows this section to be more
complicated and I'm too tired to tease everything out tonight. I'll
attach a diff to this message in case anybody else feels like mucking
with it in the meantime.