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
[email protected]
http://mail.python.org/mailman/list
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, 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
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
- 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
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
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
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
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@
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
>>> 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')
_
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
26 matches
Mail list logo
