Phillip J. Eby wrote:
At 10:55 AM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip.eby wrote:
Author: phillip.eby
Date: Tue Apr 18 02:59:55 2006
New Revision: 45510
Modified:
python/trunk/Lib/pkgutil.py
python/trunk/Lib/pydoc.py
Log:
Second phase of refactoring for runpy
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be hot-fixing the standard
Python distribution ?
Because setuptools installs things in zip files, and older versions of
pydoc don't work for packages zip files.
That doesn't answer my
Tim Peters wrote:
[M.-A. Lemburg]
I could contribute pybench to the Tools/ directory if that
makes a difference:
+1. It's frequently used and nice work. Besides, then we could
easily fiddle the tests to make Python look better ;-)
That's a good argument :-)
Note that the tests
Martin v. Löwis wrote:
Neal Norwitz wrote:
I'll leave this decision to Martin or someone else, since I'm not
familiar with the ramifications. Since it was documented as unsigned,
I think it's reasonable to consider changing. Though it could create
signed-ness warnings in other modules. I'm
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I'd argue that such code is broken anyway: 3rd party code simply
cannot make any assumptions on the typedef behind Py_UNICODE.
The code would work just fine now, but will stop working with the
change. Users of the code might not be open
Neal Norwitz wrote:
On 3/31/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
Neal Norwitz wrote:
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can
Guido van Rossum wrote:
Go ahead and fix it. This was probably never changed since 1990 or
so... Do expect some code brakage where people rely on the old
behavior. :-(
--Guido
On 4/9/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Someone on IRC (who refuses to report bugs on sourceforge, so
Martin Blais wrote:
Hi all
I got an evil idea for Python this morning -- Guido: no, it's not
about linked lists :-) -- , and I'd like to bounce it here. But
first, a bit of context.
This has been discussed a few times before, see e.g.
Martin v. Löwis wrote:
Neal Norwitz wrote:
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can crash the interpreter.
The problem is that the string is converted
Anthony Baxter wrote:
On Thursday 30 March 2006 22:31, M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that
you are talking about adding a *very* popular module name to
the top-level Python namespace if you go for db or database.
Why can't we just have
Anthony Baxter wrote:
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite',
instead.
Anything, but please no db or database top-level module or
package :-)
How about sql? wink
I can't think of a better name right now - can
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
And we still have someone actively interested in maintaining the OS2
port, it seems.
Dito for BeOS, now under the name Zeta OS.
Who is the one interested in maintaining the BeOS port? the last
checkins related to BeOS seem to originate from
Would it be possible to redirect these buildbot messages to the
python-checkins or a separate python-buildbot list ?
Original Message
Subject: [Python-Dev] buildbot warnings in amd64 gentoo trunk
Date: Wed, 22 Mar 2006 15:18:20 +
From: [EMAIL PROTECTED]
Reply-To:
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Would it be possible to redirect these buildbot messages to the
python-checkins or a separate python-buildbot list ?
Sure. They are sent to python-dev, because I think Tim Peters
wanted them here.
For the Snake-Farm we had a separate mailing list
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
It's not a waste of time at all: you'd be helping lots and
lots of developers out there who want to fix their extensions.
This is free software, anybody is free to decide what they do.
With due respect for other developers, yes.
I don't believe
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Here's a grep of all the changed/new APIs, please include it
in the PEP.
You want me to include that *literally*? Are you serious?
Feel free to format it in a different way.
Please go ahead and commit that change yourself: I consider
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Interesting: A few mails ago you suggested that developers
do exactly what I did to get the list of changes. Now you
gripe about the output format of the grep.
Developers which use grep can read the output of grep. Developers
which use other
Martin v. Löwis wrote:
Fernando Perez wrote:
So I think M.A. is right on the money here with his statement. Unless you
consider the Linux/64bit camp insignificant. But if that is the case, it
might be worth putting a big statement in the 2.5 release notes indicating
there is a good chance,
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I really don't understand why you put so much effort into
trying to argue that the ssize_t patch isn't going to break
extensions or that fixing compiler warnings is good enough.
Well, in *this* thread, my main point is that I don't want
Ronald Oussoren wrote:
On 17-mrt-2006, at 22:14, M.-A. Lemburg wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
I'm not sure if this is what Marc-Andre means, but maybe these
definitions
could go into a new include file:
How would that include file be used? You would have to copy
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Since this change is going to affect a lot of 3rd party extensions,
I'd also like to see a complete list of public APIs that changed and
how they changed (including the type slots)
You can construct this list easily by comparing the header files
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I think it's only fair that I ask the patch authors to complete
the PEP, since the ssize_t patch is causing extension authors
enough trouble already.
Well, the PEP is complete as it stands. It's possible to provide
more guidelines
Martin v. Löwis wrote:
Thomas Heller wrote:
I'm not sure if this is what Marc-Andre means, but maybe these definitions
could go into a new include file:
How would that include file be used? You would have to copy it into your
own source base, and include it, right?
We could put it into a
Thomas Heller wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
BTW: Is a porting guide to make extension modules compatible with 2.5
available somewhere? PEP 353 scratches only the surface...
Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which
particular aspect are you
guido.van.rossum wrote:
Author: guido.van.rossum
Date: Wed Mar 15 05:33:54 2006
New Revision: 43033
Modified:
python/trunk/Lib/distutils/sysconfig.py
python/trunk/Lib/encodings/__init__.py
Log:
Use relative imports in a few places where I noticed the need.
(Ideally, all packages
Is anyone interested in having a Python track at this conference ?
PS: The EuroPython conference takes place in Geneva, one week
later.
Original Message
Subject: FrOSCon 2006 - Call for {Papers|Projects}
Date: Fri, 03 Mar 2006 16:39:08 +0100
From: Sebastian Bergmann
Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Hye-Shik Chang wrote:
On 2/19/06, Walter Dörwald [EMAIL PROTECTED] wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Anyway, I've started implementing a patch that just adds
codecs.StatefulEncoder/codecs.StatefulDecoder
Neal Norwitz wrote:
PEP 263 states that in Phase 2 the default encoding will be set to
ASCII. Although the PEP is marked final, this isn't actually
implemented. The warning about using non-ASCII characters started in
2.3. Does anyone think we shouldn't enforce the default being ASCII?
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Note that this does not mean that we should forget about memory
consumption issues. It's just that if there's only marginal
interest in certain special builds of Python, I don't see the
requirement for the Python core developers to maintain them
Jeff Rush wrote:
M.-A. Lemburg wrote:
I'd say that the parties interested in non-Unicode versions of
Python should maintain these branches of Python. Dito for other
stripped down versions.
I understand where you're coming from but the embedded market I
encounter tends to focus
Jeff Rush wrote:
Guido van Rossum wrote:
On 2/19/06, Jeff Rush [EMAIL PROTECTED] wrote:
[Quoting Neal Norwitz]
I've heard of a bunch of people using --disable-unicode. I'm not sure
if it's curiosity or if there are really production builds without
unicode. Ask this on c.l.p too.
Do you
Why are these new features being backported to 2.4 ?
georg.brandl wrote:
Author: georg.brandl
Date: Sun Feb 19 10:51:33 2006
New Revision: 42490
Modified:
python/branches/release24-maint/Lib/fileinput.py
python/branches/release24-maint/Lib/test/test_fileinput.py
Georg Brandl wrote:
M.-A. Lemburg wrote:
Why are these new features being backported to 2.4 ?
georg.brandl wrote:
Author: georg.brandl
Date: Sun Feb 19 10:51:33 2006
New Revision: 42490
Modified:
python/branches/release24-maint/Lib/fileinput.py
python/branches/release24-maint/Lib
Martin, v. Löwis wrote:
How are users confused?
Users do
py Martin v. Löwis.encode(utf-8)
Traceback (most recent call last):
File stdin, line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
ordinal not in range(128)
because they want to convert the
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Just because some codecs don't fit into the string.decode()
or bytes.encode() scenario doesn't mean that these codecs are
useless or that the methods should be banned.
No. The reason to ban string.decode and bytes.encode is that
it confuses users
Thomas Wouters wrote:
On Sat, Feb 18, 2006 at 12:06:37PM +0100, M.-A. Lemburg wrote:
I've already explained why we have .encode() and .decode()
methods on strings and Unicode many times. I've also
explained the misunderstanding that can codecs only do
Unicode-string conversions. And I've
Barry Warsaw wrote:
On Wed, 2006-02-15 at 22:07 +0100, M.-A. Lemburg wrote:
Those are not pseudo-encodings, they are regular codecs.
It's a common misunderstanding that codecs are only seen as serving
the purpose of converting between Unicode and strings.
The codec system is deliberately
Aahz wrote:
On Sat, Feb 18, 2006, Ron Adam wrote:
I like the bytes.recode() idea a lot. +1
It seems to me it's a far more useful idea than encoding and decoding by
overloading and could do both and more. It has a lot of potential to be
an intermediate step for encoding as well as being
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I've already explained why we have .encode() and .decode()
methods on strings and Unicode many times. I've also
explained the misunderstanding that can codecs only do
Unicode-string conversions. And I've explained that
the .encode() and .decode
Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
I'd suggest we keep codecs.lookup() the way it is and
instead add new functions to the codecs module, e.g.
codecs.getencoderobject() and codecs.getdecoderobject().
Changing the codec registration is not much of a problem:
we
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
True. However, note that the .encode()/.decode() methods on
strings and Unicode narrow down the possible return types.
The corresponding .bytes methods should only allow bytes and
Unicode.
I forgot that: what is the rationale for that restriction
Guido van Rossum wrote:
On 2/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
This could be a replacement for PEP 332. At least I hope it can
serve to summarize the previous discussion and help focus on the
currently undecided issues.
I'm too tired to dig up the rules for assigning it a PEP
Guido van Rossum wrote:
On 2/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
What will be the explicit way to open a file in bytes mode
and in text mode (I for one would like to move away from
open() completely as well) ?
Will we have a single file type with two different modes
or two
Bengt Richter wrote:
If str becomes unicode for PY 3000, and we then have bytes as out
coding-agnostic
byte data, then I think bytes should have the str translation method, with a
tweak
that I would hope could also be done to str now.
BTW, str.translate will presumably become
Martin v. Löwis wrote:
Josiah Carlson wrote:
I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex',
and likely a few others that the two of you may be arguing against
should stay as encodings, because strictly speaking, they are defined as
encodings of data. They may not
a deprecation warning for that in
Py 2.5 and then remove the hundreds of
#idef Py_USING_UNICODE
from the source code in time for Py 2.6.
n
--
On 2/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
neal.norwitz wrote:
Author: neal.norwitz
Date: Thu Feb 16 06:25:37 2006
New Revision: 42396
Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
Guido van Rossum wrote:
[...]
Years ago I wrote a prototype; checkout sandbox/sio/.
However sio.DecodingInputFilter and sio.EncodingOutputFilter don't work
for encodings that need state (e.g. when reading/writing UTF-16
Walter Dörwald wrote:
I'd suggest we keep codecs.lookup() the way it is and
instead add new functions to the codecs module, e.g.
codecs.getencoderobject() and codecs.getdecoderobject().
Changing the codec registration is not much of a problem:
we could simply allow 6-tuples to be passed into
Neil Schemenauer wrote:
On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote:
On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote:
from __future__ import unicode_strings
Didn't we have a command-line option to do this? I believe it was
removed because nobody could
Giovanni Bajo wrote:
Thomas Wouters [EMAIL PROTECTED] wrote:
from __future__ import unicode_strings
Didn't we have a command-line option to do this? I believe it was
removed because nobody could see the point. (Or am I hallucinating?
After several days of non-stop discussing bytes that
Jean-Paul Calderone wrote:
On Thu, 16 Feb 2006 11:24:35 +0100, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Neil Schemenauer wrote:
On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote:
On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote:
from __future__ import
Guido van Rossum wrote:
On 2/15/06, Alex Martelli [EMAIL PROTECTED] wrote:
I agree, or, MAL's idea of bytes.open() and unicode.open() is also
good.
No, the bytes and text data types shouldn't have to be tied to the I/O
system. (The latter tends to evolve at a much faster rate so should be
Guido van Rossum wrote:
On 2/15/06, Nick Coghlan [EMAIL PROTECTED] wrote:
If we went with longer names, a slight variation on the opentext/openbinary
idea would be to use opentext and opendata.
After some thinking I don't like opendata any more -- often data is
text, so the term is wrong.
Barry Warsaw wrote:
On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
Maybe a weird idea, but why not use static methods on the
bytes and str type objects for this ?!
E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
renamed to str.openfile())
That's also not a bad idea
Jason Orendorff wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(), which
works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227,
131,
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers. For example, nobody
James Y Knight wrote:
Kill the encoding argument, and you're left with:
Python2.X:
- bytes(bytes_object) - copy constructor
- bytes(str_object) - copy the bytes from the str to the bytes object
- bytes(sequence_of_ints) - make bytes with the values of the ints,
error on overflow
Guido van Rossum wrote:
On 2/13/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
It'd be cruel and unusual punishment though to have to write
bytes(abc, Latin-1)
I propose that the default encoding (for basestring instances) ought
to be ascii just like everywhere else
Guido van Rossum wrote:
One recommendation: for starters, I'd much rather see the bytes type
standardized without a literal notation. There should be are lots of
ways to create bytes objects from string objects, with specific
explicit encodings, and those should suffice, at least initially.
Guido van Rossum wrote:
On 2/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:55 AM 2/13/2006 -0800, Guido van Rossum wrote:
One recommendation: for starters, I'd much rather see the bytes type
standardized without a literal notation. There should be are lots of
ways to create bytes
Tim Peters wrote:
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
[Tim]
If he had _stuck_ to that, we wouldn't be having this discussion :-)
(that is, nobody passes string literals to
PyArg_ParseTupleAndKeywords's kws
Phillip J. Eby wrote:
Why not just have the constructor be:
bytes(initializer [,encoding])
Where initializer must be either an iterable of suitable integers, or a
unicode/string object. If the latter (i.e., it's a basestring), the
encoding argument would then be required. Then,
Guido van Rossum wrote:
PEP 328: Absolute/Relative Imports
Yes, please.
+0 for adding relative imports. -1 for raising errors for
in-package relative imports using the current notation
in Python 2.6.
See:
http://mail.python.org/pipermail/python-dev/2004-September/048695.html
for a
BJörn Lindqvist wrote:
This seems to be the only really major issue with the PEP. Everything
else is negotiable, IMHO. But the string inheritance seem to be such a
critical issue it deserves its own thread. I have tried to address all
criticism of it here:
I don't see why this is critical for
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Please note that inheritance from string will cause the C type
checks of the form PyString_Check(obj) to return true.
C code will then assume that it has an object which is
compatible to string C API which instances aren't.
Oh, sure
Neal Norwitz wrote:
On 1/10/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
We'd also have to make sure that old extensions don't
just import with a warning, since the change will introduce
buffer overflows and seg faults in extensions that are not
aware of the change.
I agree that on 64-bit
Alex Martelli wrote:
On 1/17/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Alex, I think you're missing a point here: what you are looking
for is an interface, not a base class - simply because the
I expect numbers to support arithmetic operators, c -- no need for
basenumber to spell this out
Alex, I think you're missing a point here: what you are looking
for is an interface, not a base class - simply because the
assumptions you make when finding a KnownNumberTypes instance
are only related to an interface you expect them to provide.
A common case class won't really help all that much
Alex Martelli wrote:
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
gives 5? I'm not sure why str has never allowed this obvious use --
any bright beginner assumes it's there and it's awkward to
David Goodger wrote:
On 1/12/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
I know, but I wouldn't expect SVN to query other servers
than svn.python.org inside the standard repository
directories.
AFAIK, this is a first in the Python repository.
True, and worth discussing. Luckily the PEPs
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
What if x64 has a 64-bit value ? How do you catch
and process the truncation error ?
We were *both* discussing a scenario where no sizes
exceed 2**31, right?
Right, but I don't see the point of each and every
extension having to go through
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
... and then the type change of that variable propagates
throughout the extension.
That depends on the usage of the code. If the variable
is passed by value, no further changes are necessary.
If a pointer to the variable is passed, you could
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
If it were this easy, I wouldn't have objections. But it's
not.
It is so easy. Can you should me an example where it isn't?
The variables you use with these APIs tend to propagate
through the extension, you use them in other calls,
make
David Goodger wrote:
Author: david.goodger
Date: Thu Jan 12 04:33:16 2006
New Revision: 42015
Modified:
peps/trunk/ (props changed)
Log:
add external link to Docutils public repo -- always up-to-date
I just deleted the static copy of the docutils directory from the peps
David Goodger wrote:
[M.-A. Lemburg]
Question: why do we need docutils in the peps/trunk/ directory
in the first place ?
It's a convenience, so that a separate Docutils download install
( maintain) isn't necessary for those who process reST-format PEPs.
Hmm, shouldn't these things
David Goodger wrote:
On 1/12/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Hmm, shouldn't these things be tracked under external/ ?!
What do you mean exactly? A new external directory?
Yes.
SVN provides a built-in mechanism for tracking external
repositories, via the svn:externals property
Martin v. Löwis wrote:
Armin Rigo wrote:
This would do the right thing for = 2.4, using ints everywhere; and the
Python.h version 2.5 would detect the #define and assume it's a
2.5-compatible module, so it would override the #define with the real
thing *and* turn on the ssize_t interpretation
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I don't see a good solution for these other than introducing
a set of new APIs (and maybe doing some macro magic as Martin
did for PyArg_ParseTuple()). Due to the fact that changes in
the types of output parameters require changes in the
extension
I haven't followed the thread, so many I'm repeating things.
Has anyone considered using e.g. MediaWiki (the wiki used for
Wikipedia) for Python documentation ?
I'm asking because this wiki has proven to be ideally suited
for creating complex documentation tasks and offers many features
which
Hi Armin,
On Wed, Dec 28, 2005 at 09:56:43PM +0100, M.-A. Lemburg wrote:
d += 1.2
d
NotImplemented
The PEP documenting the coercion logic has complete tables
for what should happen:
Well, '+=' does not invoke coercion at all, with new-style classes like
Decimal.
True, it doesn't invoke
Armin Rigo wrote:
Hi Facundo,
On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
d += 1.2
d
NotImplemented
The situation appears to be a mess. Some combinations of specific
operators fail to convert NotImplemented to a TypeError, depending on
old- or
Fredrik Lundh wrote:
Aahz wrote:
class file(object)
| file(name[, mode[, buffering]]) - file object
|
| Open a file. The mode can be 'r', 'w' or 'a' for reading (default),
[...]
| Note: open() is an alias for file().
This is confusing. I suggest that we make ``open()`` a factory
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
can we add a opentext factory for file/codecs.open while we're at it ?
Why a new factory function ? Can't we just redirect to codecs.open()
in case an encoding keyword argument is passed to open() ?!
I think open is overloaded enough
Phillip J. Eby wrote:
At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
M.-A. Lemburg wrote:
can we add a opentext factory for file/codecs.open while we're at it ?
Why a new factory function ? Can't we just redirect to codecs.open()
in case an encoding keyword argument is passed to open
Phillip J. Eby wrote:
At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
M.-A. Lemburg wrote:
can we add a opentext factory for file/codecs.open while we're at
it ?
Why a new factory function ? Can't we just
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Here's a rough draft:
def textopen(name, mode=r, encoding=None):
if U not in mode:
mode += U
The U is not needed when opening files using codecs -
these always break lines using .splitlines() which
breaks lines according
Josiah Carlson wrote:
Jim Fulton [EMAIL PROTECTED] wrote:
Jim Jewett wrote:
PEP 3000 now suggests that dropping default comparison has become more
than an idle what-if.
Unfortunately, one very common use case of comparisons is to get a
canonical order. If the order is sensible, all the
Aahz wrote:
On Tue, Dec 20, 2005, M.-A. Lemburg wrote:
Josiah Carlson wrote:
New superclasses for all built-in types (except for string and unicode,
which already subclass from basestring).
int, float, complex (long) : subclass from basenumber
tuple, list, set : subclass from basesequence
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
Some questions:
* Are you going to contribute cElementTree as well ?
yes, but there are some build issues we need to sort out first (both pyexpat
and cET link to their own copies of expat)
Great !
we also need to figure out how to import
Neal Norwitz wrote:
While running regrtest with -R to find reference leaks I found a usage
issue. When a codec is registered it is stored in the interpreter
state and cannot be removed. Since it is stored as a list, if you
repeated add the same search function, you will get duplicates in the
Neal Norwitz wrote:
On 11/24/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Should users have access to the search path (through a
codecs.unregister())?
Maybe, but why would you want to unregister a search function ?
If so, should it search from the end of the
list to the beginning to remove
Noam Raphael wrote:
Following Avi's suggestion, can I raise this thread up again? I think
that Reinhold's .dedent() method can be a good idea after all.
The idea is to add a method called dedent to strings. It would do
exactly what the current textwrap.indent function does.
You are missing
Fredrik Lundh wrote:
the runtime warning you get when you use non-ascii characters in
python source code points the poor user to this page:
http://www.python.org/peps/pep-0263.html
which tells the user to add a
# -*- coding: encoding name -*-
to the source, and then provides
Guido van Rossum wrote:
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
* PEP 328 - absolute/relative import
I assume that references to 2.4 in that PEP should be changed to 2.5, and
so on.
For the part that hasn't been implemented
Martin v. Löwis wrote:
Steve Holden wrote:
Therefore, if such steps are really going to be considered, I would
really like to see them introduced in such a way that no breakage occurs
for existing users, even the parochial ones who feel they (and their
programs) don't need to understand
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
You even argued against having non-ASCII identifiers:
http://mail.python.org/pipermail/python-list/2002-May/102936.html
I see :-) It seems I have changed my mind since then (which
apparently predates PEP 263).
One issue I apparently
Greg Ewing wrote:
M.-A. Lemburg wrote:
If you are told to debug a program
written by say a Japanese programmer using Japanese identifiers
you are going to have a really hard time.
Or you could look upon it as an opportunity to
broaden your mental horizons by learning some
Japanese
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
A few years ago we had a discussion about this on python-dev
and agreed to stick with ASCII identifiers for Python. I still
think that's the right way to go.
I don't think there ever was such an agreement.
You even argued against having non-ASCII
Neil Hodgson wrote:
M.-A. Lemburg:
Unicode has the concept of combining code points, e.g. you can
store an é (e with a accent) as e + '. Now if you slice
off the accent, you'll break the character that you encoded
using combining code points.
...
next_indextype(u, index) - integer
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I just left them in because I thought they wouldn't do any harm
and might be useful in some applications.
Removing them where not directly needed by the codec would not
be a problem.
I think memory usage caused is measurable (I estimated 4KiB
801 - 900 of 989 matches
Mail list logo
