* The average quality of the library improves as we take out junk (the
tzparse module for example) and put in high quality modules like
logging, csv, decimal, etc.
Yes and no. The added modules have to be relevant to what users want
to do. While (relatively) minor stuff like csv and decimal
Statements like this are pretty common, but there's no evidence (that I've
ever seen pointed to) that someone has *measured* how many people want
modules for X.
I almost didn't send this in, because I figured someone would have to
argue with it.
If there are that many people that want (e.g.)
The other thing that might work is to change the name of the language
to C plus optional punctuation.
You mean C@@ (pronounced C-pie-pie)?
Bill
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
That's right -
when I talk to fellow programmers that I'm writing software in Python,
many of them are amazed and ask me, but isn't it slow?. I've heard
it more than once...
I heard it last month.
In the last couple of months, an acquaintance of mine has been trying
out Python. He likes the
Then why is the title Python's Super Considered Harmful ???
Here's my final offer. Change the title to something like Multiple
Inheritance Pitfalls in Python and nobody will get hurt.
Or better yet, considering the recent thread on Python marketing,
Multiple Inheritance Mastery in Python
Over time, I've gotten feedback about these and other itertools recipes.
No one has objected to the True/False return values in those recipes or
in Guido's version.
Guido's version matches the normal expectation of any/all being a
predicate. Also, it avoids the kind of errors/confusion
http://zesty.ca/threadmap/pydev.cgi
Very reminiscent of Paula Newman's work at PARC several years ago.
Check out
http://www2.parc.com/istl/groups/hdi/papers/psn_emailvis01.pdf,
particularly page 5.
Bill
___
Python-Dev mailing list
There are basically two ways for a system, such as a
Python function, to indicate 'I cannot give a normal response. One (1a)
is to give an inband signal that is like a normal response except that it
is not (str.find returing -1). A variation (1b) is to give an inband
response that is
Don't know *what* I wasn't thinking :-).
Bill
On 8/26/05, Bill Janssen [EMAIL PROTECTED] wrote:
Doubt it. The problem with returning None is that it tests as False,
but so does 0, which is a valid string index position. The reason
string.find() returns -1 is probably to allow a test
(*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
Sounds right to me, and it *should* be orthogonally added to the 're'
module coincidentally simultaneously with the change to the string
object :-).
I have
And good riddance! The print statement harks back to ABC and even
(unvisual) Basic. Out with it!
Guido,
After reviewing the PEP 3000 notes, I can find no justification there
for removing print other than your statement here -- that it has
served honorably and well in many programming languages
I see this is Fredrik's earlier suggestion.
Bill
I (reduntantly) wrote:
Is there a syntax trick here? Suppose start-of-the-line function
names not followed by an open-paren, but followed by comma-separated
lists of expressions, were treated as if the rest of the line were
arguments to a
I don't use print myself much, but for the occasional 3-line script.
But I think the user-friendliness of it is a good point, and makes up
for the weirdness of it all. There's something nice about being able
to write
print the answer is, 3*4+10
which is one of the reasons ABC and BASIC have
Providing you can live with adding a pair of parentheses to that, you can
have:
def print(*args):
sys.stdout.write(' '.join(args) + '\n')
I think the language would be cleaner if it lacked this weird exception for
`print`.
Charles,
I agree that it would be cleaner. I just
To me, the main objection seems to revolve around the fact that people would
like to be able to future-proof Python 2.x code so that it will also run on
Py3k.
Nick,
You seem to be dreaming. People like the print statement for many
and varied reasons, it seems. Skip's point about
Just to add a bit more perspective (though I continue to believe that
print should be retained as-is):
In my UpLib code, I no longer use print. Instead, I typically use a
variant of logging called note instead of print:
note ([LEVEL, ] FORMAT-STRING [, *ARGS])
It works just like C printf,
I do hate having to write two parentheses -- it's more than the extra
keystrokes. It's that I have to use two shifted characters and I have
to be sure to close the construct, which can be a PITA when the start of
the function call is separated from the end by many lines.
What I found is
Guido writes:
* Gratuitous breakage: IMO it's not gratuitous. The *extensions* to
the print statement (trailing comma, stream) are ugly, and because
it's all syntax, other extensions are hard to make. Had it been a
function from the start it would have been much easier to add keyword
args,
Or perhaps:
print [with FORMAT-STRING] [ STREAM] *ARGS
as an alternative to
printf [@ STREAM] FORMAT-STRING *ARGS
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
LOL! That's a great solution for the 5 of us dinosaurs still using the
One True Editor. :)
And who also still program in C now and then :-). I think there are
more than 5 of us, though.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
Some languages have picture formats, where the structure
of the format string more closely mimics that of the desired
output. (This is true, e.g., of some Basics and of one variety
of Perl output.) The trouble with this is that it limits how
much information you can provide about *how* each
Guido van Rossum wrote:
So let's call it the Swiss Army Knife
(...Not) API design pattern.
IIRC, this is one of the design principles which inspired Lisp mixins.
The idea was that different interfaces should be separated into
different classes. If you needed a class which combined them, you'd
perhaps the Python 3 executable should have a different name as part
of the standard distribution? I suggest py / py.exe
Perhaps the renaming should be more radical, to indicate the extent of
the change.
I suggest second, to commemorate Second City in Chicago, another
famous comedy troupe.
This [text/binary] distinction is
supported by the basic file operations in the C library. To open a
text file in binary mode is technically an error (although in many OSs
you'll get away with it).
It's one of those technical errors that really isn't an error (from
Python). On the other
I agree with Skip.
Bill
I suppose this is a dead horse now, but I will kick it one more time.
Under the rubrics of explicit is better than implicit and there should
only be one wat to do it, I would rather see
bool_val = bool(foo or bar)
instead of having the or operator
The best way to make people stop complaining about the GIL and start
using
process-based multiprogramming is to provide solid, standardized support
for process-based multiprogramming.
And the model provided by the thread abstraction is a good API for that
support...
Bill
Sokolov Jura writes:
It is so simple to write application server in Python.
It is so difficult to make it scallable in CPython.
CPython will not be wide popular without real multithreading.
He's right.
Bill
___
Python-Dev mailing list
1) It works by default, so that novices can use it without falling
into the deep well of threading. That is, a program that you write
using threading is broken by default, and the tool you have to fix it
is inspection. I want something that allows me to say this is a
task. Go. and have it
The problem with threads is at first glance they appear easy...
Anyone who thinks that a glance is enough to understand something is
too far gone to worry about. On the other hand, you might be
referring to a putative brokenness of the Python documentation on
Python threads. I'm not sure
Skip,
With the Mojam middleware stuff I suffered quite awhile with a
single-threaded implementation that would hang the entire webserver if a
backend query took too long. I realized I needed to do something (threads,
asyncore, whatever), but didn't think I understood the issues well enough
Guido writes:
Given the tendency of Python developers to build layers of
abstractions I don't think [non-preemptive threads] will help much.
I think that's right, although I think adding priorities to Python's
existing preemptive threads might be useful for real-time programmers
(yes, as
I'm thinking about making all character strings Unicode (possibly with
different internal representations a la NSString in Apple's Objective
C) and introduce a separate mutable bytes array data type. But I could
use some validation or feedback on this idea from actual
practitioners.
+1 from
Python should allow strings to
contain any Unicode character and should be indexable yielding
characters rather than half characters. Therefore Python strings
should appear to be UTF-32.
+1.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
- yet others think: I want all of Unicode, with proper, efficient
indexing, so I want four bytes per char.
I doubt the last one though. Probably they really don't want efficient
indexing, they want to perform higher-level operations that currently
are only possible using efficient
Guido writes:
Oh, I don't doubt that they want it. But often they don't *need* it,
and the higher-level goal they are trying to accomplish can be dealt
with better in a different way. (Sort of my response to people asking
for static typing in Python as well. :-)
I suppose that's true. But
I think he was more interested in the invariant Martin proposed, that
len(\U0001)
should always be the same and should always be 1.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Might be more interesting to think about replacing ints and Decimal
with implicit-denominator rational type. In the HTTP-NG typing
proposal, we called this a fixed-point type. See Section 4.5.1 of
http://www.w3.org/Protocols/HTTP-NG/1998/08/draft-frystyk-httpng-arch-00.txt
for details.
The
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z FILE.ZIP, and
2) the use of zipfiles is so poorly documented.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
This should work on a few platforms:
env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
Yeah, that's not bad, but I hate setting PYTHONPATH. I was thinking
more along the line of
python -z ZIPFILE
where python would look at the ZIPFILE to see if there's a top-level
module called
Brett,
How about building a system that compiles a Python program (possibly
annotated) to an AJAX program? That is, it analyzes the program to
determine what's appropriate and possible for client-side and
server-side, figures out the optimal network API (reduce latency,
reduce calls, reduce data
Or the Web-SIG mailing list.
Bill
___
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
The data: scheme would be a good one.
Bill
Barry Warsaw wrote:
On Fri, 2006-01-20 at 21:43 +0100, Thomas Wouters wrote:
I don't believe this belongs in 2.4, since it can, actually, break code.
Code that depends on the current situation, _TestCase__attributename.
Fragile code, to be
After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I've not had the time to follow the
most recent rounds, but I propose that we keep lambda, so as to stop
wasting everybody's talent and time on an impossible quest.
+1.
This would remove my
what other reactive socket framework is there that would fit well into
the standard library ? is twisted really simple enough ?
I've been very happy with Medusa, which is asyncore-based.
Perhaps the right idea is to fix the various problems of asyncore. We
might lift the similar code from
Not terrible. I think I may try re-working Medusa to use this.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
If we go with two functions, I'd much rather hang them off of the file
type object then add two new builtins. I really do think file.bytes()
and file.text() (a.k.a. open.bytes() and open.text()) is better than
opentext() or openbytes().
+1.
The default behavior of the current open() in
in 'text' mode.
Bill
On 2/15/06, Bill Janssen [EMAIL PROTECTED] wrote:
The default behavior of the current open() in opening files as text is
particularly grating.
Why? Are you perhaps one of those rare folks who read more binary data
than text?
--
--Guido van Rossum (home page: http
Huh... just joining here but surely you don't mean a text string that
doesn't use every character available in a particular encoding is
really bytes... it's still a text string...
No, once it's in a particular encoding it's bytes, no longer text.
As you say,
Keep these two concepts separate
Having UUID in the stdlib would be very helpful.
Philip Eby writes:
I like the idea of having RFC-compliant UUIDs in the stdlib, but I really
want immutable ones, preferably without {} in their standard string
representation. And efficient use of platform-local UUID generation APIs
would
Philip Eby writes:
...
I completely agree with Philip.
Sorry, I mean of course Phillip.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Yup; I'd be happy to see db.mysql and db.pgsql or whatnot added as
appropriate, and having a nice new namespace ready for them is a good idea.
I really wish that that namespace would be database, not db.
Bill
___
Python-Dev mailing list
I think short names are more more consistent with the existing naming in
the standard library.
Which doesn't make it a good idea. +1 on adding longer top-level
package names as aliases for existing shorter top-level package names.
Bill
___
from a user perspective, adding this to the standard library is a no-brainer.
the only reason not to add it would be if the release managers don't have
time to sort out the build issues.
I agree with Fredrik here.
On the package naming issue: using em for email would be wrong,
just as db for
Fredrik writes:
are you aware of the fact that the module implements the db-api ?
db-api is just an earlier version of the same naming mistake. I'd
be happy with database_api instead of database.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
Charles Cabazon writes:
On the package naming issue: using em for email would be wrong,
Eh, that should be import electronic_mail, then. And
import simple_mail_transport_protocol_lib.
just as db for database would be wrong.
People who are familiar with Extensible Markup Language
Charles Cabazon writes:
Whoops! Should be Cazabon.
Bill
___
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
I think sqlite is just fine.
I do, too.
Bill
___
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
seq = [1,2,3,4,5]
if any(seq, lambda x: x==5):
...
which is clearly more readable than
reduce(seq, lambda x,y: x or y==5, False)
How about this?
if any(x==5 for x in seq):
Aren't all of these equivalent to:
if 5 in seq:
...
Yeah, but you can't do more
By the way, check out the new Python/Mac iconography that Jacob Rus
has put together (with lots of advice from others :-), at
http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png.
Tim Parkin's new logo sure started something.
Bill
___
Python-Dev
I'm inviting people to discuss the addition of wsgiref to the standard
library. I'd like the discussion to be finished before a3 goes out;
+1.
I think it's faily low-risk. WSGI has been discussed and implemented
for well over a year; there are many working implementations of the
spec. Adding
It still looks like an application of WSGI, not part of a reference
implementation.
It seems to me that canonical exemplars are part of what a reference
implementation should include. Otherwise it would be a standard
implementation, which is considerably different.
Bill
Perhaps this could go in Demo/wsgiref/?
Perhaps both Ian's and Phillip's examples could go into Demo/wsgiref/?
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
For most built-in types, the conversion specifiers will be the
same or similar to the existing conversion specifiers used with
the '%' operator. Thus, instead of '%02.2x, you will say
'{0:2.2x}'.
Don't you mean, {0:02.2x}?
Bill
the difference in Jython is deliberate. I think the reason was to mimic
more the Java style for this, in java fully qualified names always work.
In jython importing the top level packages is enough to get a similar
effect.
This is unlikely to change for backward compatibility reasons, at
/F writes:
what [Python] specification?
Good meta-point.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
this is mildy insulting, to the people that spent time trying to find
the best compromises between various issues and keep jython alive.
Sorry, didn't mean to disparage that work.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
A colleague recently posted this message:
I'm trying to build a Python extension, and Python 2.4 insists on the MS
Visual C++ compiler version 7.1, which is included with the MS VC++ 2003
toolkit. This toolkit is no longer available for download from
Microsoft (superseded by the 2005
Yep, it would be. Then again, Mark Hammond has already done a bunch of work
for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't
be too bad.
Of course, that's the road Sun first went down with Java, and that
turned out not-so-well for them. I think the plug-in approach
a = []
for i in range(10):
... a.append(lambda: i)
...
print [x() for x in a]
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
Isn't this exactly what you'd expect? Maybe I've been writing Python
for too long... :-).
Bill
___
Python-Dev mailing list
See also the Cedar Ropes work:
http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Perhaps pyinstall?
Bill
On Nov 30, 2006, at 9:49 AM, Talin wrote:
I really don't like all these cute names, simply because they are
obscure. Names that only make sense once you've gotten the joke may
be self-gratifying but not good HCI.
Warsaw's Fifth Law :)
How about:
Maybe instead of considering a match object to be a sequence, a match
object should be considered a map? After all, we do have named, as well
as numbered, groups...?
To me, that makes a lot more sense.
Bill
___
Python-Dev mailing list
If this sounds like a terrible idea, let fly the n00b-seeking missiles.
Sounds like a good idea. We did this with ILU, and it helped manage
the overhead of threads quite a bit. Brett's comments on the next step
are right on target.
Bill
___
Guido Since idel timeout is not a commonly understood term it would
Guido be even better if it was explained without using it.
I think it's commonly understood, but it doesn't mean what the socket
timeout is used for. It's how long a connection can be idle (the client
doesn't
Guido van Rossum wrote:
Is it time for a sockettools module, maybe?
+1!
-1. The new module would be just as much a jumble of unrelated APIs as
the socket module already is, so there's no particularly good reason
to create an arbitrary separation. Also, KISS.
I agree with Guido on this
Could this be a language-independent documenting toolkit? Could
we document LISP or Ruby code with it?
Might want to look at noweb, http://www.eecs.harvard.edu/~nr/noweb/:
``...noweb works ``out of the box'' with any programming language, and
supports TeX, latex, HTML, and troff back ends.''
We are developing a programming language here, not a typesetting
system.
Good point, Martin. Are you implying that the documentation should be
kept in LaTeX, a widely-accepted widely-disseminated stable
documentation language, which someone else maintains, rather than
ReST, which elements of
Emacs will probably go the way of the vinyl record (though the latter
is seeing a resurgence lately :).
Doubt it. Even as we speak, there's probably a student planning to
implement Python 3 in ELisp as a SOC project...
Bill
___
Python-Dev mailing
The term French Spacing is used for two spaces after a period ending
a sentence, for those wishing to do more research. I have not found
any authoritative answer.
This phrase sounded to me like one of the slurs the English invented
during their various wars with the Dutch and the French (e.g.
Sounds like a good plan. I'm not a great coach though since I didn't
write _ssl.c and I've never used openssl directly. But I can help you
with the Python stuff of course!
Thanks (though I think I can handle the Python end of it, too :-).
It's been a while since I wrote any Python C code,
Barry Warsaw suggested:
It's been a while since I wrote any Python C code, though -- are there
better tools these days for debugging reference counting? Anyone
know?
No, but /that/ would make an awesome sprint topic wink.
Indeed!
Bill
___
Maybe one of the three existing Python/SSL libraries should be stdlib-
ified instead of starting another new one from scratch?
Yep, that's my intent. This should just be a change to _ssl.c.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
The idea is that if you call socket.ssl() on a socket that's bound to
an address, the socket is assumed to be server-side, the cert passed
in is assumed to be a server-side cert, and the SSLObject returned has
a couple of extra methods, listen() and accept(). Calling accept() does
the SSL
I'm very tempted to add an optional parameter to socket.ssl(), which
will be a callback function which will be passed the remote side's IP
address and credentials, and which may raise an exception if it
doesn't like the credentials. The exception would then be re-raised
from socket.ssl() (on
All right, here's my current design :-).
We add to the socket module a subtype of socket.socket,
socket.SSLSocket. It has the following constructor:
SSLSocket (family=AF_INET, type=SOCK_STREAM, proto=0,
cert_filename=None, key_filename=None,
cert_policy=CERT_NONE,
That's somewhat limiting - you should be able to do connection
upgrades (e.g. SMTP STARTTLS, or HTTP Connection: Upgrade); with
that design, such usages would not be possible, no?
Yes, you're right. Of course, STARTTLS is properly regarded as a
terrible hack :-).
The actual functionality
I view TLS as a wrapper around / layer on top of TCP, and so I think the
API should look like, as well.
I think Martin raises a valid point here, which should at least be
discussed more thoroughly. Should there be an SSL socket, which is
just like a regular socket? Does that really provide
The simplest way to do verification is to allow the application to
provide a set of root certs that it would like to verify against, and
use the built-in OpenSSL verification procedure.
That's good. I don't recall whether you planned for this, however,
it would then be necessary to find
This is a self-signed cert, and it's still an open question whether
they should verify, and under what circumstances. I'm currently
thinking that in the CERT_OPTIONAL regime, they could, but with
CERT_REQUIRED, they shouldn't.
If an application wanted self-signed certs to verify under
Can the TLS handshake be made to respect timeouts on sockets, or would
this require changes deep inside OpenSSL?
I'm not sure. Good test case to try. I believe it will work.
By the way, interested parties should read
http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html
and think about
I'd like to be able to backport this server-side SSL support to older
Pythons, like the 2.3.4 in CentOS 4 and the 2.3.5 in OS X 10.4.
So I'd like to move all the SSL stuff out of the socket module, and
add a new top-level module called ssl (or networking.ssl, or
whatever the Py3K naming scheme
I'd like to be able to backport this server-side SSL support to older
Pythons, like the 2.3.4 in CentOS 4 and the 2.3.5 in OS X 10.4.
That would have to be a private fork or a 3rd party extension module;
python.org is committed to keeping existing releases stable
(feature-wise).
Yes,
getpeercert() -- analogue to getpeeraddr, but returns cert details
This would return three kinds of values:
No certificate received -- None
Certificate received but not validated -- {}
Certificate received and validated -- { full details }
Bill
For those of you following along at home, there's now a patch at
http://bill.janssen.org/python/ssl-update-diff which applies against
the current trunk. Working code, though I still need to tweak some
import statements for backwards compatibility. I've started updating
the test suite, see
I've been trying to reset my password on the new RoundUp tracker,
and it isn't working. Then I tried to register for a new account,
and I got mail from
[EMAIL PROTECTED]
to confirm. When I did, I got access to a small 27-issue tracker,
which seems to be the bug-tracker for the bug-tracker.
I've created the documentation patch for the new SSL module.
It's attached to issue 1024.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I've gone through the other open SSL issues. Looks like some can be
closed with the adoption of 1018 and 1024:
1027394 4 months agosocket.ssl should explain that it is a 2/3 connection
889813 4 months agomaking the version of SSL configurable when creating
sockets
1583946 9 months ago
This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
ppc, and hppa). Here's one example:
Unfortunately, I don't have Ubuntu or Debian machines. But I'd bet
it's a variation in the specific version of OpenSSL being used. I
just tested on Fedora Core 7, though, and test_ssl
This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
ppc, and hppa). Here's one example:
http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832/step-test/0
If I'm reading this right, it's passing tests on amd64 gentoo trunk,
x86 gentoo trunk, g4 osx.4
But I think this exposes a more generic bug in test_ssl.py, which is
that the server thread doesn't die when one of these failures occurs.
It probably should. I'll make a patch -- but I don't have a system
that this fails on, how will I test it?
Here's a patch which makes test_ssl a better
1 - 100 of 502 matches
Mail list logo
