I wonder if it would make sense to start installing the Python
standard library as a .zip file by default. Some benefits would be
a tidier and more compact install and slightly faster startup times.
One downside is that it becomes more difficult to look at the source
of modules. That's an importa
Greg Ewing <[EMAIL PROTECTED]> wrote:
> There's something reassuring about the fact that things
> with no "obvious" textual representation stick out like
> a sore digit when you try to print them. I wouldn't like
> to lose that.
I agree with this and support the status quo (i.e. repr(int) ==
str(i
Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> There's still one thing I still don't understand about pickle,
> persistent_id. I haven't found any useful use-cases for it. Using
> Google's code search, only Zope (or variant of) seems to have found
> some obscure way to use it.
Durus (an object
On Thu, Oct 04, 2007 at 02:49:16AM -0400, Alexandre Vassalotti wrote:
> Could you elaborate on what you are trying to do?
I'm trying to efficiently pickle a 'unicode' subclass. I'm
disappointed that it's not possible to be as efficient as the
built-in unicode class, even when using an extension c
I guess the library overhaul hasn't really started it but it would
be nice if the pickle module could get some work. Today I'm trying
to efficiently store a class using pickle and the documentation is
making my head hurt. I don't think the documentation itself is the
problem, just the fact that t
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> However there's quite a bit of Python 2.x code around that manipulates
> *bytes* in the guise of 8-bit strings, and it uses tests like "if s[0]
>== 'x': ..." frequently.
I think it would be useful to do a survey and see how much code
would be affected
Larry Hastings <[EMAIL PROTECTED]> wrote:
> I am opposed to using LGPL- or GPL-licensed code in Python.
Me too. Also, I don't see the point. Python's current long integer
performance is good enough for the large majority of Python users.
For the few specialized users, an extension module should
On Mon, Aug 27, 2007 at 11:21:21AM -0600, Adam Olsen wrote:
> This would complicate the work of various packaging systems.
You're not getting it. The tarball that we distribute as a Python
release would look basically like it does now (i.e. it would include
things like the "email" package). I ca
Aahz <[EMAIL PROTECTED]> wrote:
> -0 on the idea of making "batteries included" include PyPI packages.
> Anything part of "batteries included" IMO should just be part of the
> standard install.
I think you misunderstand the proposal. The "batteries" would be
included as part of the final Python r
Brett Cannon <[EMAIL PROTECTED]> wrote:
> I don't like the former, but the latter is intriguing. If we could
> host large packages (e.g., email, sqlite, ctypes, etc.) on python.org
> by providing tracker, svn, and web space they could be developed and
> released on their own schedule. Then the Py
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Now, there's plenty of pure Python (or Python-specific) functionality
> for which "batteries included" makes total sense, including the email
> package, wsgiref, XML processing, and more; it's often a judgement
> call. But I want to warn against the des
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However we select between Python and native module versions, the build
> bots need be set up to run the modules both ways (with and without C
> optimisation).
If there is a way to explictly import each module separately then I
think that meets both needs
Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> Hmmm. Should we being using the email package to parse HTTP headers?
> RFC 2616 says that HTTP headers follow the "same generic format" as
> RFC 822, but RFC 822 says headers are ASCII and RFC 2616 says headers
> are arbitrary 8-bit values. You'd need to
On Thu, Jul 12, 2007 at 10:04:44AM +0300, Guido van Rossum wrote:
> There are lots of things we do that could theoretically be bad C. I
> doubt that this particular one will ever bite us. Are there any other
> reasons for such a change?
I think Python is one of the only open source projects to use
It's a small detail but I wonder if it's time to stop using a
leading underscore for internal APIs. I'm not sure what would be a
good replacement, perhaps a trailing underscore. In case people
don't remember, the _Py prefix could, theoretically, be invalid C on
some platforms.
Regards,
Neil
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> I propose the PEP below for Py3k.
I think it's a good idea. It would be nice if the PEP included
something about forwards compatibility. Ideally, there should be a
way to write a module that works with both 2.x and 3.x (e.g. using
preprocessor macros)
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> This is exactly why the iterator protocol method should be named
> __next__: so it can't collide with method names used for other
> purposes.
And yet people are suggesting that __call__ be used instead of
__next__. If people believe iterators should be sep
On Sun, Feb 25, 2007 at 05:40:12PM -0600, Guido van Rossum wrote:
> Thomas is correct. You can only assign ints in range(256) to a single
> index.
Yes, I understand that. I think the error message is bad though.
> The error comes from the call to PyNumber_AsSsize_t() in
> bytes_setitem(), which
>>> x = b'a'
>>> x[0] = b'a'
Traceback (most recent call last):
File "", line 1, in
TypeError: 'bytes' object cannot be interpreted as an index
Huh? 0 is not a 'bytes' object and I don't see how the RHS is being
used as an index. Obviously I wanted something like:
>>> x[0] = ord(b'a')
_
Greg Ewing <[EMAIL PROTECTED]> wrote:
> That's my point -- you *don't* know how any given bytes
> object was created, so there's no reason to display it
> in anything other than the most generic way.
Practicality beats purity here, I think. For example, if I'm
debugging a network protocol, I'd pr
tomer filiba <[EMAIL PROTECTED]> wrote:
> it ought to have at least a nicer API, for instance,
> tbtext = traceback.format_current()
Do you know about traceback.format_exc()? I think I added it for
2.4.
Neil
___
Python-3000 mailing list
Python-3000@
- Forwarded message from Antti Louko <[EMAIL PROTECTED]> -
Date: Fri, 17 Nov 2006 08:25:03 +0200
From: Antti Louko <[EMAIL PROTECTED]>
Subject: Python bytes object
To: [EMAIL PROTECTED]
Python bytes object is useful.
I would add bitwise logical operations. They would be most useful in
cr
Bob Ippolito <[EMAIL PROTECTED]> wrote:
> The point is that legitimate __ usage is supposedly so rare that this
> verbosity doesn't matter. If it's verbose, people definitely won't use
> it until they need to, where right now people do it all the time cause
> it's "private".
It's very rare, in my
On Tue, May 02, 2006 at 09:44:06AM -0700, Guido van Rossum wrote:
> Oops. I lost track of the bytes proto-PEP. CC'ing Neil now -- Neil,
> did you submit that to the PEP editors?
No, just before I wrote it, you suggested that we didn't need to
contact the editors to add a new PEP to the index (just
Erno Kuusela <[EMAIL PROTECTED]> wrote:
> The refcounting vs generational GC reasoning I've heard argues that
> refcounting is less cache-friendly
I believe that's correct. A state of the art generational GC would
outperform reference counting, even given Python's enormous
allocation rate. Howev
On Tue, Apr 04, 2006 at 06:51:48PM -0500, Ian Bicking wrote:
> Using {} instead of $/${} doesn't seem like a big win.
Big enough to be worth considering, IMO.
Neil
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/list
26 matches
Mail list logo
