On 2007-02-12 16:19, Georg Brandl wrote:
Tim Delaney asked in particular:
Have you checked if [the existing uses of getattr, where getattr in
that scope is a function argument with default value the built-in
getattr] are intended to bring the getattr name into local scope
for fast lookup, or
Hi Skip,
On 2007-03-12 03:01, [EMAIL PROTECTED] wrote:
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
* It will probably be easier to add Unicode support to a Python version
* More people will be able to
On 2007-03-15 07:45, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
And yet, that incorrect behavior was clearly intended by the author(s)
of the code, test, and docstrings.
As it happens, Guido wrote that code (16 years ago) and the docstring (9
years ago), in the case of the posixpath
On 2007-03-23 19:18, Jason Orendorff wrote:
Scheme is adding Unicode support in an upcoming standard:
(DRAFT) http://www.r6rs.org/document/lib-html/r6rs-lib-Z-H-3.html
I have two questions for the python-dev team about Python's Unicode
experiences. If it's convenient, please take a moment
Hi Walter,
if the bytes type does turn out to be a mutable type as suggested
in PEP 358, then please make sure that no code (C code in
particular), relies on the constantness of these byte objects.
This is especially important when it comes to codecs, since
the error callback logic would allow
On 2007-05-01 02:29, Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
Could you add a section that explains the side effects of
importing pkg_resources ?
The documentation of
On 2007-05-04 18:53, Georg Brandl wrote:
M.-A. Lemburg schrieb:
Hi Walter,
if the bytes type does turn out to be a mutable type as suggested
in PEP 358, then please make sure that no code (C code in
particular), relies on the constantness of these byte objects.
This is especially important
On 2007-05-04 19:51, Guido van Rossum wrote:
[-python-dev]
On 5/4/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Friday 04 May 2007, M.-A. Lemburg wrote:
I also suggest making all bytes literals immutable to avoid running
into any issues like the above.
+1 from me.
Rather than
On 2007-05-05 18:11, Steven Bethard wrote:
On 5/5/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2007-05-04 19:51, Guido van Rossum wrote:
[-python-dev]
On 5/4/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Friday 04 May 2007, M.-A. Lemburg wrote:
I also suggest making all bytes
On 2007-05-10 20:53, Paul Moore wrote:
On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I just discovered that, in all versions of Python as far back as I
have access to (2.0), \u escapes are interpreted inside raw
unicode strings. Thus:
[...]
Does anyone remember why it is done
On 2007-05-11 00:11, Guido van Rossum wrote:
On 5/10/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2007-05-10 20:53, Paul Moore wrote:
On 10/05/07, Guido van Rossum [EMAIL PROTECTED] wrote:
I just discovered that, in all versions of Python as far back as I
have access to (2.0), \u escapes
On 2007-05-11 07:52, Martin v. Löwis wrote:
This is what prompted my question, actually: in Py3k, in the
str/unicode unification branch, r\u1234 changes meaning: before the
unification, this was an 8-bit string, where the \u was not special,
but now it is a unicode string, where \u *is*
On 2007-05-11 13:05, Thomas Heller wrote:
M.-A. Lemburg schrieb:
On 2007-05-11 07:52, Martin v. Löwis wrote:
This is what prompted my question, actually: in Py3k, in the
str/unicode unification branch, r\u1234 changes meaning: before the
unification, this was an 8-bit string, where the \u
On 2007-05-12 02:42, Andrew McNabb wrote:
On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote:
I wonder how we managed to survive all these years with
the existing consistent and concise definition of the
raw-unicode-escape codec ;-)
There are two options:
* no one really uses
On 2007-05-13 18:04, Martin v. Löwis wrote:
* without the Unicode escapes, the only way to put non-ASCII
code points into a raw Unicode string is via a source code encoding
of say UTF-8 or UTF-16, pretty much defeating the original
requirement of writing ASCII code only
That's no
On 2007-05-21 12:30, Kristján Valur Jónsson wrote:
[Py_UNICODE being #defined as unsigned short on Windows]
I'd rather make it a platform-specific definition (for platform=Windows
API). Correct me if I'm wrong, but isn't wchar_t also available in VS
2003 (and even in VC6?). And doesn't it
On 2007-05-21 00:07, Talin wrote:
Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
PEP: 365
Title: Adding the pkg_resources module
I'm really surprised that there
On 2007-05-21 16:05, Phillip J. Eby wrote:
At 01:43 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 00:07, Talin wrote:
Phillip J. Eby wrote:
I wanted to get this in before the Py3K PEP deadline, since this is a
Python 2.6 PEP that would presumably impact 3.x as
well. Feedback
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP with detailed documentation
(the link you provided doesn't really explain the concepts, reading
On 2007-05-21 22:48, Phillip J. Eby wrote:
At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
On 2007-05-21 20:01, Phillip J. Eby wrote:
At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP
Hi Mark,
+1 from me.
I think this is simply a bug introduced with the UCS4 patches in
Python 2.2.
unicodeobject.h already has this code:
#ifndef PY_UNICODE_TYPE
/* Windows has a usable wchar_t type (unless we're using UCS-4) */
# if defined(MS_WIN32) Py_UNICODE_SIZE == 2
# define
On 2007-06-19 14:40, Walter Dörwald wrote:
Georg Brandl wrote:
A minuscule nit: the rot13 codec has no library equivalent, so it won't be
supported anymore :)
Given that there are valid use cases for bytes-to-bytes translations,
and a common API for them would be nice, does it make sense to
Nick Maclaren wrote:
Ah, the makefile. I don't think you use it create the Unicode database.
It's only good for generating the codecs (Lib/encodings)
Yes, but it DOES attempt to download the mappings, and is the ONLY
script which attempts to do so.
Of course it does. The
On 2007-10-26 05:41, Barry Warsaw wrote:
On Oct 22, 2007, at 11:30 PM, [EMAIL PROTECTED] wrote:
It's not clear that any of these implementations is going to be
perfect.
Maybe none ever will be.
I would agree with this. You write a program and know you need to
implement some kind of
On 2007-11-09 14:10, Walter Dörwald wrote:
Martin v. Löwis wrote:
Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
codecs to do the encoding. There's no need to create a magical
mystery codec to pick out which though.
So the code is good, if it is inside an XML parser, and
Martin v. Löwis wrote:
It makes working with XML data a lot easier: you simply don't have to
bother with the encoding of the XML data anymore and can just let the
codec figure out the details. The XML parser can then work directly
on the Unicode data.
Having the functionality indeed makes
Martin v. Löwis wrote:
Not really, but the codec has more control over what happens to
the stream, ie. it's easier to implement look-ahead in the codec
than to do the detection and then try to push the bytes back onto
the stream (which may or may not be possible depending on the
nature of the
On 2007-11-11 14:51, Martin v. Löwis wrote:
A non-seekable stream is not all that uncommon in network processing.
Right. But what is the relationship to XML encoding autodetection?
It pops up whenever you need to detect the encoding of the
incoming XML data on the network connection, e.g. in
On 2007-11-11 18:56, Martin v. Löwis wrote:
First, XML-RPC is not the only mechanism using XML over a network
connection. Second, you don't want to do this if you're dealing
with several 100 MB of data just because you want to figure
out the encoding.
That's my original claim/question: what
On 2007-11-11 23:22, Martin v. Löwis wrote:
First, XML-RPC is not the only mechanism using XML over a network
connection. Second, you don't want to do this if you're dealing
with several 100 MB of data just because you want to figure
out the encoding.
That's my original claim/question: what
On 2007-11-23 16:59, Christian Heimes wrote:
Paul Moore wrote:
_ssl
Christian has been making changes to allow this to build without Perl,
so I gave it a try. I used openssl 0.9.8g, which I extracted to the
build directory (I noticed afterwards that this is the same version as
in
On 2007-11-23 23:12, Paul Moore wrote:
On 23/11/2007, Christian Heimes [EMAIL PROTECTED] wrote:
bsddb is automatically build by a build step. But you have to convert
the project files in build_win32 to VS 2008 first. Simply open the
solution file and let VS convert the projects.
VS 2008
On 2007-11-29 11:52, Titus Brown wrote:
Hi all,
is there a good, or standard memory benchmarking system for Python?
pybench doesn't return significantly different results when Python 2.6
is compiled with pymalloc and without pymalloc. Thinking on it, I'm not
too surprised -- pybench
On 2008-01-07 14:57, Fred Drake wrote:
On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote:
Next, we add a per-user site-packages directory to the standard
sys.path, and then we could get rid of most of the setuptools
import and sys.path hackery, making it a lot cleaner.
PYTHONPATH already
On 2008-01-07 17:24, Barry Warsaw wrote:
On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote:
On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
We could easily resolve that issue, if we add a per-user site-packages
dir to sys.path
On 2008-01-10 14:31, Eric Smith wrote:
(I'm posting to python-dev, because this isn't strictly 3.0 related.
Hopefully most people read it in addition to python-3000).
I'm working on backporting the changes I made for PEP 3101 (Advanced
String Formatting) to the trunk, in order to meet the
On 2008-01-14 22:23, Christian Heimes wrote:
The PEP is now available at http://www.python.org/dev/peps/pep-0370/.
The reference implementation is in svn, too:
svn+ssh://[EMAIL PROTECTED]/sandbox/trunk/pep370
Thanks for the effort, Christian. Much appreciated.
Regarding the recent ~/bin vs.
I don't really understand what all this has to do with per user
site-packages.
Note that the motivation for having per user site-packages
was to:
* address a common request by Python extension package users,
* get rid off the hackery done by setuptools in order
to provide this.
As such
On 2008-01-20 19:30, Christian Heimes wrote:
Yet another python executable could solve the issue, named pythons as
python secure.
/*
gcc -DNDEBUG -g -O2 -Wall -Wstrict-prototypes -IInclude -I. -pthread
-Xlinker -lpthread -ldl -lutil -lm -export-dynamic -o pythons2.6
pythons.c
On 2008-01-25 21:26, Steve Holden wrote:
Antoine Pitrou wrote:
Raymond Hettinger python at rcn.com writes:
Go ask a dozen people if they are surprised that int(3.7) returns 3.
No one will be surprised (even folks who just use Excel or VB). It
is foolhardy to be a purist and rage against the
On 2008-01-27 08:14, Raymond Hettinger wrote:
. You may disagree, but that doesn't make it nuts.
Too many thoughts compressed into one adjective ;-)
Deprecating int(float)--int may not be nuts, but it is disruptive.
Having both trunc() and int() in Py2.6 may not be nuts, but it is
Hi Christian,
could you explain how you came up with the 256 entry limit ?
It appears to be rather low and somehow arbitrary.
I understand that some limit is required, but since these
objects get created a lot (e.g. for bound methods), setting the
limit too low will significantly slow down the
On 2008-02-07 14:09, Andrew MacIntyre wrote:
Probably in response to the same stimulus as Christian it occurred to me
that the freelist approach had been adopted long before PyMalloc was
enabled as standard (in 2.3), and that much of the performance gains
between 2.2 and 2.3 were in fact due
On 2008-02-08 08:21, Martin v. Löwis wrote:
One of the hopes of having a custom allocator for Python was to be
able to get rid off all free lists. For some reason that never happened.
Not sure why. People were probably too busy with adding new
features to the language at the time ;-)
On 2008-02-08 19:28, Christian Heimes wrote:
In addition to the pure performance aspect, there is the issue of memory
utilisation. The current trunk code running the int test case in my
original post peaks at 151MB according to top on my FreeBSD box, dropping
back to about 62MB after the dict
On 2008-02-13 08:02, Andrew MacIntyre wrote:
Christian Heimes wrote:
Andrew MacIntyre wrote:
I tried a LIFO stack implementation (though I won't claim to have done it
well), and found it slightly slower than no freelist at all. The
advantage of such an approach is that the known size of the
On 2008-02-13 12:56, Andrew MacIntyre wrote:
I'm not that interested in debating the detail of exactly how big the
prospective LIFO freelists are - I just want to see the situation
resolved with maximum utilisation of memory for minimum performance
penalty. To that end, +1 from me for
On 2008-02-23 00:46, Colin Walters wrote:
On Fri, Feb 22, 2008 at 4:23 PM, John Dennis [EMAIL PROTECTED] wrote:
Python programs which use Unicode string objects for their i18n and
which link to C libraries expecting UTF-8 but which have a CPython
binding which only uses 's' or 's#'
On 2008-03-02 14:47, Christian Heimes wrote:
Alex Martelli wrote:
Yep, but please do keep the PyUnicode for str and PyString for bytes
(as macros/synonnyms of PyStr and PyBytes if you want!-) to help the
task of porting existing extensions... the bytearray functions should
no doubt be
On 2008-03-02 20:39, Bill Janssen wrote:
Why not also make unicode() the default type constructor and only
keep str() as alias to simplify porting (perhaps with a warning) ?
The term string is just too overloaded with all kinds of
misinterpretations. The term string just refers to a string of
On 2008-03-02 23:11, Greg Ewing wrote:
M.-A. Lemburg wrote:
Why not also make unicode() the default type constructor and only
keep str() as alias to simplify porting (perhaps with a warning) ?
-1 on making us type 7 characters instead of
3 all over the place.
Oh well... how about text
On 2009-01-05 23:17, Mark Hammond wrote:
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
See above. Assertions are not meant to be checked in a production
build. You use debug builds for debugging such low-level things.
Although ironically, assertions have been disabled in debug builds
to debug the MS CRT,
only Python ;-)
Kristj'an
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
M.-A. Lemburg
Sent: 6. janúar 2009 13:23
To: mhamm...@skippinet.com.au
Cc: python
On 2009-01-07 16:34, Guido van Rossum wrote:
Sounds like yet another remnant of the old philosophy, which indeed
supported encode and decode operations on both string types. :-(
No, that's something I explicitly readded to Python 3k, since the
codecs interface is independent of the input and
On 2009-01-07 19:32, Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
No, that's something I explicitly readded to Python 3k, since the
codecs interface is independent of the input and output types (the
codecs decide which combinations to support).
But why would the utf8
On 2009-01-08 01:01, Collin Winter wrote:
On Wed, Jan 7, 2009 at 2:35 PM, Brett Cannon br...@python.org wrote:
On Wed, Jan 7, 2009 at 10:57, M.-A. Lemburg m...@egenix.com wrote:
[SNIP]
BTW: The _codecsmodule.c file is a 4 spaces indent file as well (just
like all Unicode support source files
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
M.-A. Lemburg
Sent: 8. janúar 2009 09:49
To: Collin Winter
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] Fixing incorrect
On 2009-01-20 00:56, Raymond Hettinger wrote:
Why does numbers.py say:
# Copyright 2007 Google, Inc. All Rights Reserved.
# Licensed to PSF under a Contributor Agreement.
Because that's where that file originated, I guess. This is part
of what you have to do for things that are
On 2009-01-20 11:02, Michael Foord wrote:
M.-A. Lemburg wrote:
[snip...]
Does the copyright concept even apply to an
abstract base class (I thought APIs were not
subject to copyright, just like database layouts
and language definitions)?
It applies to the written program text. You
On 2009-01-20 16:54, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
On 2009-01-20 11:02, Michael Foord wrote:
Mere collections of facts are not copyrightable as they are not
creative (the basis of copyright)
That's incorrect in the U.S.; what is copyrightable is an *original
On 2009-01-27 22:19, Raymond Hettinger wrote:
From: Martin v. Löwis mar...@v.loewis.de
Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
I think it should be released earlier and completely supplant 3.0
before
On 2009-01-29 01:59, Stephen J. Turnbull wrote:
I think there is definitely something to the notion that the 3.x
vs. 3.0.y distinction should signal something, and I personally like
MAL's suggestion that 3.0.x should be marked some sort of beta in
perpetuity, or at least until 3.1 is ready to
On 2009-01-30 11:40, Antoine Pitrou wrote:
Aahz aahz at pythoncraft.com writes:
There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
You're probably right that what Raymond wants to is best not done for
3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
On 2009-02-01 19:44, Reto Schüttel wrote:
Hi
While helping Brandon Rhodes to port PyEphem[1] to Python 3 we struggled
over a
strange locale-related problem on OS X. PyEphem is a library which can do
astronomical computations like tracking the position of stars, planets and
earth satellites
On 2009-02-08 11:15, Tarek Ziadé wrote:
Hello
To avoid confusion, as suggested by Akira who works on cleaning the
Distutils pages on the python.org website,
I would like to move http://svn.python.org/view/distutils/trunk into a
branch and add a README.txt in an empty trunk
to explain the
On 2009-02-16 17:54, Tarek Ziadé wrote:
2009/2/9 M.-A. Lemburg m...@egenix.com:
On 2009-02-08 11:15, Tarek Ziadé wrote:
Hello
To avoid confusion, as suggested by Akira who works on cleaning the
Distutils pages on the python.org website,
I would like to move http://svn.python.org/view
On 2009-02-16 18:50, Daniel (ajax) Diniz wrote:
Hi,
I've marked some issues (25 now) to close, mostly because:
- there was no reply from OP, nor a clear justification for the issue;
- there are messages explaining why the issue is invalid;
- the OSes/versions of the report suggest the issue
On 2009-03-24 23:47, Martin v. Löwis wrote:
An installer for a pure-python package that made no attempt
to bundle dependencies might be nice, but I don't quite see how that
falls outside the scope of distutils/setuptools/etc. In other words, I
don't see why the installer can't bootstrap the
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete
Should this
On 2009-03-27 13:58, David Cournapeau wrote:
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg m...@egenix.com wrote:
I think that esp. the bdist_* commands help developers a lot by
removing the need to know how to build e.g. RPMs or Windows
installers and let distutils deal with it.
I think
On 2009-03-27 15:00, Ronald Oussoren wrote:
On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality
On 2009-03-27 17:01, Eric Smith wrote:
Martin v. Löwis wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
On the packaging summit yesterday, people agreed that yes, we should
have something like that in the standard library, and it should be more
On 2009-03-27 17:07, P.J. Eby wrote:
At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
P.J. Eby wrote:
As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help. Most of the code, though, deals with
locating/inspecting installed distributions,
On 2009-03-27 17:19, P.J. Eby wrote:
At 01:49 PM 3/27/2009 +0100, M.-A. Lemburg wrote:
(*) I've had a go at this a few months ago and then found out
that the egg format itself is not documented anywhere.
It's been documented for just under three years now. Here's where you
quoted the email
On 2009-03-27 20:56, Guido van Rossum wrote:
On Fri, Mar 27, 2009 at 8:02 AM, Eric Smith e...@trueblade.com wrote:
M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try
On 2009-03-27 21:49, gl...@divmod.com wrote:
On 07:59 pm, fdr...@acm.org wrote:
I'm actually in favor of removing the bdist_* from the standard
library, and allowing 3rd-party tools to implement whatever they need
for the distros. But I don't think what you're presenting there
supports it.
On 2009-03-27 20:24, s...@pobox.com wrote:
mal Zip files are great for shipping packages to the end-user, but
mal there's no need to keep them zipped once they get there.
I thought one of the arguments for zip files was a performance increase
(reduced stat(2) calls, etc). I may
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to extend the proposal to Python 2.7 and later.
Please comment.
Regards,
Martin
Specification
=
Rather than using an imperative
On 2009-04-03 18:06, Thomas Wouters wrote:
On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou solip...@pitrou.net wrote:
Thomas Wouters thomas at python.org writes:
Pystone is pretty much a useless benchmark. If it measures anything, it's
the
speed of the bytecode dispatcher (and it doesn't
On 2009-04-06 15:21, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
Thanks for picking this up.
I'd like to extend the proposal to Python 2.7
[Resent due to a python.org mail server problem]
On 2009-04-03 22:07, Martin v. Löwis wrote:
I'd like to extend the proposal to Python 2.7 and later.
I don't object, but I also don't want to propose this, so
I added it to the discussion.
My (and perhaps other people's) concern is that 2.7
On 2009-04-03 02:44, P.J. Eby wrote:
At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
Alternative Approach:
-
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1) check ?
One of the namespace
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages using that O(1)
check ?
Again - this wouldn't be O(1). More importantly, it breaks
On 2009-04-07 19:46, P.J. Eby wrote:
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages
On 2009-04-07 18:19, Guido van Rossum wrote:
On Tue, Apr 7, 2009 at 5:25 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-06 15:21, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following
On 2009-04-14 18:27, P.J. Eby wrote:
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way
On 2009-04-15 16:44, P.J. Eby wrote:
At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-15 02:32, P.J. Eby wrote:
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that
lives in
site-packages into smaller distribution
On 2009-04-15 19:59, P.J. Eby wrote:
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK
On 2009-04-15 21:22, P.J. Eby wrote:
At 02:52 PM 4/15/2009 -0400, A.M. Kuchling wrote:
On Wed, Apr 15, 2009 at 01:59:34PM -0400, P.J. Eby wrote:
Please see the large number of Zope and PEAK distributions on PyPI as
minimal examples that disprove this being the common use case. I
expect
On 2009-04-22 22:06, Walter Dörwald wrote:
Martin v. Löwis wrote:
correct - corrected
Thanks, fixed.
To convert non-decodable bytes, a new error handler python-escape is
introduced, which decodes non-decodable bytes using into a private-use
character U+F01xx, which is believed to not
On 2009-05-03 19:39, Martin v. Löwis wrote:
If the error handler is supposed to be used for codecs other than utf-8,
perhaps it should renamed something more generic, e.g. surrogate-escape?
Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
it's an algorithm based on
Martin v. Löwis wrote:
I have three substantive comments. First, although consequences for
Python 3 byte interfaces (ie, none) are explicitly stated, as far as
I can see this PEP could apply to Python 2 as well. I don't think
it's intended that way. Either way, I think you should clarify
Martin v. Löwis wrote:
The name utf8b suggested in the PEP is not in line with the codec
design
Where is that design documented, and how exactly violates the name
the design (chapter and verse, please).
Martin, I designed the whole Python codec machinery, so even if
this is not explicitly
Martin v. Löwis wrote:
The name utf8b suggested in the PEP is not in line with the codec
design
Where is that design documented, and how exactly violates the name
the design (chapter and verse, please).
Martin, I designed the whole Python codec machinery
Not true. PEP 293 was written and
Martin v. Löwis wrote:
The error handler for undoing this operation (ie. when converting
a Unicode string to some other encoding) should probably use the
same name based on symmetry and the fact that the escaping
scheme is meant to be used for enabling round-trip safety.
Could you please
Martin v. Löwis wrote:
Thomas Wouters reminded me of a long-standing idea; I finally
found the time to write it down.
Please comment!
...
Up until this PEP proposal, we had a very simple scheme for
the Python C-API: all documented functions and variables with
a Py prefix were part of the
Nick Coghlan wrote:
M.-A. Lemburg wrote:
Now, with the PEP, I have a feeling that the Python C-API
will in effect be limited to what's in the PEP's idea of
a usable ABI and open up the non-inluded public C-APIs
to the same rate of change as the private APIs.
Not really - before this PEP
Martin v. Löwis wrote:
Now, with the PEP, I have a feeling that the Python C-API
will in effect be limited to what's in the PEP's idea of
a usable ABI and open up the non-inluded public C-APIs
to the same rate of change as the private APIs.
That's certainly not the plan. Instead, the plan
Nick Coghlan wrote:
[PEP]
Function-like macros (in particular, field access macros) remain
available to applications, but get replaced by function calls
(unless their definition only refers to features of the ABI, such
as the various _Check macros)
[MAL]
Including Py_INCREF()/Py_DECREF() ?
301 - 400 of 989 matches
Mail list logo
