Re: [Python-Dev] urllib.quote and unquote - Unicode issues

> Of course, it's un-Pythonic to enforce pedantry, and we pedants can > use a string->string encoder correctly. Sure. All I was asking was that we not break the existing usage of the standard library "unquote" by producing a string by *assuming* a UTF-8 encoded string is what's in those percent-e

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

Also see . 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

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

> I'm far less concerned about > the decision with regards to unquote_to_bytes/quote_from_bytes, as those are > new features which can wait. Forgive me, but those are the *old* features, which must be there. Bill ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] urllib.quote and unquote - Unicode issues

I suggest we continue this discussion, if at all, on the bug-tracker, where there's code, and more participants. http://bugs.python.org/issue3300 I've now posted my idea of how quote/unquote should work in py3K, there. Bill ___ Python-Dev mailing list

[Python-Dev] why duplicate output lines in verbose tests?

Every so often, running the SSL test suite in verbose mode, I get something like this: server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256) That is, duplicate output lines. Any idea why that is? They're all wri

Re: [Python-Dev] why duplicate output lines in verbose tests?

> Is it using fork()? Threads? No on fork(), yes on threads. 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

Re: [Python-Dev] issue 3582

> It provides platform specific TLS functions on windows. In this context, TLS is "thread-local storage". Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mail

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

> I strongly recommend that we *NOT* make macports.org the main, > official Mac OS X version of Python. Secondary is fine, but not > primary. Macports is what the name says: it's a system of Mac ports of > Linux packages, mostly command-line only. I agree with David about this. > The official Mac

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

> I've certainly heard many tales of Mac users coming to grief because > they decided to overwrite their system Python, or tried to be clever and > run multiple interpreters (which is usually somewhat less disastrous). > > I guess this underlines the fact that Apple don't really want the hoi >

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

> > My understanding is that if there is a system Python, you shouldn't > > change it. Ever. > > Huge, big, honkin' +1 from me on that. Besides, for a system Python, > you want your distribution to manage packages, not setuptools, > otherwise you confuse -- and probably break -- your syste

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

> I don't think the convenience of "batteries *included*" should be > underestimated. Yeah, but bsddb is one of those exploding batteries. I've used it for years, and have had lots and lots of problems with it. Having SQLite in there is great; now we need implementations of anydbm and shelve whi

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

> I have to say I've never had problems with a stock install of Python on > either Mac OS X or Windows (shockingly enough :). I think this is good I agree. I just use the stock Python on OS X and Windows. And it seems to work well for my rather large and complicated (PIL, PyLucene, Medusa, Repo

Re: [Python-Dev] new ssl module is incompatible with servers that drop privileges

> It accept them only as > paths to their location on the file system, which I believe means that a > server can only support SSL if it has read permission to its private key > file when client connections arrive. This is a problem for servers that > bind to their socket and drop privileges as soo

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > 2 - By reading ssl.py code I noticed that when do_handshake_on_connect > flag is False the do_handshake() method is never called. Is it > supposed to be manually called when dealing with non-blocking sockets? Yes. Look at the example client in Lib/t

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > I change my question: how am I supposed to know when the SSL hanshake > is completed? When pending() returns False? When do_handshake() doesn't raise an exception. Bill ___ Python-Dev mailing list Python-D

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > In the meanwhile I noticed something in the ssl.py code which seems to > be wrong: > > def recv (self, buflen=1024, flags=0): > if self._sslobj: > if flags != 0: > raise ValueError( > "non-z

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

nd I never figured out just why that was. This (very rare) re-call of "read" is to handle that. Bill Bill Janssen <[EMAIL PROTECTED]> wrote: > Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > > > In the meanwhile I noticed something in the ssl.py code which s

Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration

Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Wed, 17 Sep 2008 10:40:01 PDT, Bill Janssen <[EMAIL PROTECTED]> wrote: > >Ah, now I remember. It seems that sometimes when SSL_ERROR_WANT_READ > >was returned, things would block; that is, the "handle_read"

Re: [Python-Dev] Update to httplib.py

Eldon Ziegler <[EMAIL PROTECTED]> wrote: > I updated httplib.py, python 2.4, to be able to bind to a specific IP > address when connecting to a remote site. Would that be something like conn = httplib.HTTPConnection('82.94.237.218', 80) Doesn't it already do that? Bill __

Re: [Python-Dev] Patch for an initial support of bytes filename in Python3

Victor Stinner <[EMAIL PROTECTED]> wrote: > - listdir(unicode) -> only unicode, *skip* invalid filenames >(as asked by Guido) Is there an option listdir(bytes) which will return *all* filenames (as byte sequences)? Otherwise, this seems troubling to me; *something* should be returned for f

Re: [Python-Dev] [Python-3000] Patch for an initial support of bytes filename in Python3

Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Tue, Sep 30, 2008 at 8:47 AM, Bill Janssen <[EMAIL PROTECTED]> wrote: > > Victor Stinner <[EMAIL PROTECTED]> wrote: > > > >> - listdir(unicode) -> only unicode, *skip* invalid filenames > >>

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-10-01 09:54, Ulrich Eckhardt wrote: > > On Tuesday 30 September 2008, M.-A. Lemburg wrote: > >> On 2008-09-30 08:00, Martin v. Löwis wrote: > Change the default file system encoding to store bytes in Unicode is > like introducing a new Py

Re: [Python-Dev] [Python-3000] New proposition for Python3 bytes filename issue

[EMAIL PROTECTED] wrote: > > I'm actually sort of liking this idea. A Pathname class, for > > convenience > > a subtype of String, but containing the underlying binary > > representation > >used by the OS. Even non-unicode pathnames could be represented. > > On the one hand, I agree with you -

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

Sidnei da Silva <[EMAIL PROTECTED]> wrote: > https://bugs.edge.launchpad.net/zope2/+bug/280020 I think there are real issues here with both asynchat and Medusa. Asynchat has been heavily re-written, and the "ac_out_buffer" has apparently disappeared. But "ac_out_buffer_size" is still there. Tha

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

Sidnei da Silva <[EMAIL PROTECTED]> wrote: > Great to know. So medusa should be changed similarly to the changes > made to asynchat? Hmmm. Been a long time since a Medusa release, but I need a working Medusa, too. > Your suggestion on the bugtracker is even better: to > subclass asynchat as muc

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

Josiah Carlson <[EMAIL PROTECTED]> wrote: > But yes, zope needs to be changed to reflect the updated > asyncore/asynchat semantics. Trust me; it's faster, cleaner, and > easier to use now. Just for completeness, I built a fresh 2.6, installed Medusa (from http://www.amk.ca/python/code/medusa.htm

[Python-Dev] Packaging the PyPI version of the SSL module for Debian

As some of you know, I've provided a PyPI version of the 2.6/3.x "ssl" module, for use with older versions of Python. I've received this request to tweak it for Debian, and I thought I'd ask those of you who may have already done it for advice on the various issues Cyril raises here. I'm not Debi

Re: [Python-Dev] Python for windows.

Martin v. Löwis <[EMAIL PROTECTED]> wrote: > Perhaps. I wouldn't go so far, though. It's surely puzzling if a system > comes with a pre-installed Python, but if that Python actually works, > I don't think that does much damage. OS X does come with pre-installed Python, so this is a debate we have

Re: [Python-Dev] Python for windows.

Bugbee, Larry <[EMAIL PROTECTED]> wrote: > For most custom apps this is a simple process of adding "#include applink.c" > to the app's main(). The problem for Python developers is that their Python > program is not main(), and if python.exe does not have the OPENSSL_Applink > interface, they c

Re: [Python-Dev] Python + Java Integration

> One thing that would help Python in this "debate" (or, perhaps simply > put it in the running, at least as a "next Java" candidate) would be > if Python had an easier migration path for Java developers that > currently rely upon various third-party libraries. The wealth of > third-party

Re: [Python-Dev] RELEASED Python 3.0 final

Thomas Wouters <[EMAIL PROTECTED]> wrote: > Allow me to paraphrase glyph (with whom I'm in complete agreement, for what > it's worth): many newbies will be disappointed by Python if they start with > Python 3.0 and discover that most of the cool possibilities they had heard > about are 'being work

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Nick Coghlan <[EMAIL PROTECTED]> wrote: > - I think the binary and Unicode APIs should be available (and fully > functional) on all platforms (including Windows) so that app developers > don't create portability problems for themselves when they make the > decision as to which API to use +1 I'm

Re: [Python-Dev] Python 3.0 urllib fails with chunked HTTP responses

Jeremy Hylton wrote: > but I worry that change the self-closing > behavior too dramatically isn't appropriate for a bug fix. Will look > some more at this tomorrow. Reading through the code, it looks like you've already fixed bug 1348. Thanks! Bill

Re: [Python-Dev] Python 3 - Mac Installer?

Nicko van Someren wrote: > On 30 Dec 2008, at 13:45, Barry Scott wrote: > ... > > Since I've been building 3.0 for a while now I looked at the script. > > > > build-install.py seems to have been half converted to py 3.0. > > Going full 3.0 was not hard but then there is the problem of > > the imp

Re: [Python-Dev] Python 3 - Mac Installer?

Martin v. Löwis wrote: > >> As far as I can tell the Carbon and MacOS modules are _only_ used in > >> the setIcon() function, which is used to give pretty icon to the > >> python folder. Perhaps it might be better to have a fully Python 3 > >> build system and loose the prettiness for the time b

Re: [Python-Dev] Python 3 - Mac Installer?

Bill Janssen wrote: > Martin v. Löwis wrote: > > > >> As far as I can tell the Carbon and MacOS modules are _only_ used in > > >> the setIcon() function, which is used to give pretty icon to the > > >> python folder. Perhaps it might be better to hav

Re: [Python-Dev] IO performance

Antoine Pitrou wrote: > There is an SVN branch with a complete rewrite (in C) of the IO stack. You can > find it in branches/io-c. Apart from a problem in _ssl.c, it should be quite > usable. Your tests and observations are welcome! And I'll look at that _ssl.c problem. Bill ___

Re: [Python-Dev] Python 3.0.1 (io-in-c)

> - fix the _ssl bug which prevents some tests from passing (issue #4967) I see you've already got a patch for this. I'll try it out. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Removing tp_compare?

Antoine Pitrou wrote: > Martin v. Löwis v.loewis.de> writes: > > > > > Any thoughts? My own opinion is that it really doesn't matter > > > that much if the slot is left in; it's just a little annoying to have > > > such backwards-compatibility baggage already present in > > > the shiny new 3.

Re: [Python-Dev] teaching the new urllib

İsmail Dönmez wrote: > Hi, > > On Tue, Feb 3, 2009 at 21:56, Brett Cannon wrote: > > Probably the biggest issue will be having to explain string encoding. > > Obviously you can gloss over it or provide students with a simple > > library that just automatically converts the strings. Or even bett

Re: [Python-Dev] teaching the new urllib

Brett Cannon wrote: > On Tue, Feb 3, 2009 at 15:50, Tres Seaver wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Brett Cannon wrote: > >> On Tue, Feb 3, 2009 at 11:08, Brad Miller wrote: > >>> I'm just getting ready to start the semester using my new book (Python > >>> Progr

Re: [Python-Dev] readd u'' literal support in 3.3?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote: > While this is true for FORTRAN, it is not for Python 1.5: no new > Python 1.5 code is written around the world, at least not every day. I don't know about that. I've seen a lot of Python 2 code which was apparently written by folks who learned

Re: [Python-Dev] Unicode re support in Python 3

Michael Foord wrote: > Hey python-devers, > > As I'm sure many of you are aware, Armin Ronacher posted a blog entry > explaining the reasons he dislikes Python 3 in its current form. > > Whilst I don't agree with all of his complaints, he makes a fair point > about the re module Unicode support

Re: [Python-Dev] Fixing the XML batteries

Mike Meyer wrote: > On Fri, 09 Dec 2011 09:02:35 +0100 > Stefan Behnel wrote: > > > a) The stdlib documentation should help users to choose the right > > tool right from the start. > > b) cElementTree should finally loose it's "special" status as a > > separate library and disappear as an accel

Re: [Python-Dev] Fixing the XML batteries

Xavier Morel wrote: > On 2011-12-09, at 19:15 , Bill Janssen wrote: > > I use ElementTree for parsing valid XML, but minidom for producing it. > Could you expand on your reasons to use minidom for producing XML? Inertia, I guess. I tried that first, and it seems to work. I

Re: [Python-Dev] Fixing the XML batteries

Stefan Behnel wrote: > Bill Janssen, 09.12.2011 19:15: > > I think another thing that might go into "refreshing the batteries" is a > > feature comparison of BeautifulSoup and HTML5lib against the stdlib > > competition, to see what needs to be added/revised. Hav

Re: [Python-Dev] Hash collision security issue (now public)

Christian Heimes wrote: > Am 29.12.2011 12:13, schrieb Mark Shannon: > > The attack relies on being able to predict the hash value for a given > > string. Randomising the string hash function is quite straightforward. > > There is no need to change the dictionary code. > > > > A possible (*untes

Re: [Python-Dev] PEP 407 / splitting the stdlib

Nick Coghlan wrote: > On Thu, Jan 19, 2012 at 10:19 AM, Steven D'Aprano wrote: > > Brett Cannon wrote: > > Do we have any evidence of this alleged bitrot? I spend a lot of time on the > > comp.lang.python newsgroup and I see no evidence that people using Python > > believe the standard library i

Re: [Python-Dev] Status of Mac buildbots

Nadeem Vawda wrote: > Hi all, > > I've noticed that most of the Mac buildbots have been offline for a while: > > * http://www.python.org/dev/buildbot/all/buildslaves/parc-snowleopard-1 > * http://www.python.org/dev/buildbot/all/buildslaves/parc-tiger-1 > * http://www.python.org/dev/buildbot/all

Re: [Python-Dev] OS X buildbots missing

Antoine Pitrou wrote: > For the record, we don't have any stable OS X buildbots anymore. Sigh. That's me again. We are currently installing a virtual private cloud at our workspace, and I'm seeing a lot of intermittent failures in that server room. I need to work out a way in which buildbot r

Re: [Python-Dev] JITted regex engine from pypy

Maciej Fijalkowski wrote: > On Sun, Jun 3, 2012 at 5:21 PM, "Martin v. Löwis" wrote: > > > On the minus side, the JIT only works on x86 and x86_64, on the plus > >> side, since it's 100% API compatible, it can be used as a _xxx > >> speedup module relatively easy. > >> > >> Do people have opini

Re: [Python-Dev] Status of packaging in 3.3

Nick Coghlan wrote: > On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou wrote: > > Agreed, especially if the "proven in the wild" criterion is required > > (people won't rush to another third-party distutils replacement, IMHO). > > The existence of setuptools means that "proven in the wild" is ne

Re: [Python-Dev] Deprecated xmllib module

> * 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 decima

Re: [Python-Dev] Deprecated xmllib module

> 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.

Re: [Python-Dev] 2.4 news reaches interesting places

> 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 Unsu

Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places

> 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 like

Re: [Python-Dev] Re: super() harmful?

> 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 P

Re: [Python-Dev] Re: No new features

Hear, hear! > Going from > 2.x.y to 2.x.y+1 shouldn't break anything, going from 2.x.y+1 to 2.x.y > shouldn't break anything that doesn't whack into a bug in 2.x.y -- and > "not having bool" isn't a bug in this sense. Micro releases are all about bug fixes. Every micro release of the same minor

Re: [Python-Dev] Adding any() and all()

Guido, I think there should be a PEP. For instance, I think I'd want them to be: def any(S): for x in S: if x: return x return S[-1] def all(S): for x in S: if not x: return x return S[-1] Or perhaps these should be called "first" and "last". Bill _

Re: [Python-Dev] Adding any() and all()

> 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/confus

Re: [Python-Dev] Check out a new way to read threaded conversations.

> 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 Python-Dev@pytho

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

> I prefer 'with'. The 'do' keyword sounds "loopy" and doesn't make > grammatical sense. I agree. "with [VAR =] BLOCK:" just reads better. "with BLOCK [as VAR]:" is OK, too. Or even "within", as in within BLOCK binding VAR: SOMETHING Probably too techy. Bill

[Python-Dev] how to upload new MacPython web page?

We (the pythonmac-sig mailing list) seem to have converged (almost -- still talking about the logo) on a new download page for MacPython, to replace the page currently at http://www.python.org/download/download_mac.html. The strawman can be seen at http://bill.janssen.org/mac/new-macpython-page.ht

Re: [Python-Dev] str object going in Py3K

> 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 o

Re: [Python-Dev] str object going in Py3K

ode switch (I suggest "t") to put a file stream 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

Re: [Python-Dev] bytes.from_hex()

> If implementing a mime packer is really the only use case > for base64, then it might as well be removed from the > standard library, since 99.9% of all programmers will > never touch it. Those that do will need to have boned up I use it quite a bit for image processing (converting to and fr

Re: [Python-Dev] bytes.from_hex()

Greg Ewing wrote: > Bill Janssen wrote: > > > bytes -> base64 -> text > > text -> de-base64 -> bytes > > It's nice to hear I'm not out of step with > the entire world on this. :-) Well, I can certainly understand the bytes->base64->bytes

Re: [Python-Dev] str.count is slow

> As for the question of whether to switch to C++ in 3.0, I'd say > probably not, as it's much harder to interface with C++ from other > languages than to C. An excellent point, and to my mind conclusive. Bill ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] bytes.from_hex()

> 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 sepa

Re: [Python-Dev] defaultdict and on_missing()

> For an example of methods gone horribly wrong, look at Java, where you > have .length, String.length(), and Collection.size(). > Give me len() any day. I believe Ruby has similar confusing diversity > for looping (each/forEach). But Java is plagued with the same disease that hit Modula-3, distru

Re: [Python-Dev] how about adding ping's uuid module to the standard lib ?

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 > wou

Re: [Python-Dev] how about adding ping's uuid module to the standard lib ?

> 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: http://mail.python.org/mailman/option

Re: [Python-Dev] Py3K timescale and stdlib philosophy (was: Re: Py3K thought: use...)

I was sort of hoping that Python would approach Py3K asymptotically... :-). PEP 328, for instance, talks about Python 2.5, 2.6, 2.7. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] pysqlite for 2.5?

> 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 Python-D

Re: [Python-Dev] pysqlite for 2.5?

> 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 ___ Python-

Re: [Python-Dev] pysqlite for 2.5?

> 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 "

Re: [Python-Dev] pysqlite for 2.5?

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@pyth

Re: [Python-Dev] pysqlite for 2.5?

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

Re: [Python-Dev] pysqlite for 2.5?

> 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

Re: [Python-Dev] pysqlite for 2.5?

> 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

Re: [Python-Dev] Any reason that any()/all() do not take a predicateargument?

> >> 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: > ...

Re: [Python-Dev] New-style icons, .desktop file

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

Re: [Python-Dev] Adding wsgiref to stdlib

> 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. Addin

Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib

> 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

Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib

> 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: http://mail.python.o

Re: [Python-Dev] PEP 3101: Advanced String Formatting

> 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 _

Re: [Python-Dev] Import semantics

> 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 reason

Re: [Python-Dev] Import semantics

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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Import semantics

> 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 http://mail.p

[Python-Dev] Python 2.4 extensions require VC 7.1?

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 vers

Re: [Python-Dev] doc for new restricted execution design for Python

> The plan is to allow pure Python code to be embedded into web pages like > JavaScript. I am not going for the applet approach like Java. Java support is now just a plug-in. Should be easy to make a Python plug-in system that works the same way. If only we had a GUI... :-) Bill __

Re: [Python-Dev] doc for new restricted execution design for Python

> 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 approa

Re: [Python-Dev] 2.5 and beyond

> >>> 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 maili

Re: [Python-Dev] Remove str.find in 3.0?

> 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

Re: [Python-Dev] Remove str.find in 3.0?

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.fin

Re: [Python-Dev] Proof of the pudding: str.partition()

> >(*) 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

Re: [Python-Dev] Proof of the pudding: str.partition()

Reinhold Birkenfeld writes: > And it's horrible, for none of the other string methods accept a RE. I suppose it depends on your perspective as to what exactly is horrible. I tend to think it's too bad that none of the other string methods accept appropriate RE patterns. Strings are thought of as

Re: [Python-Dev] Replacement for print in Python 3.0

> 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 langua

Re: [Python-Dev] Replacement for print in Python 3.0

I have to agree with Barry, Paul, Fredrik, Reinhold, etc. Removing the "print" statement would immediately break at a fundamental level 15 years of tutorials, books, and examples, many of which start with >>> print "Hello, World!" Of course, maybe that's the idea -- this is not your father's Pyt

Re: [Python-Dev] Replacement for print in Python 3.0

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

<    1   2   3   4   5   6   >