Guido van Rossum wrote:
> My first response to the PEP, however, is that instead of a new
> built-in function, I'd rather relax the requirement that str() return
> an 8-bit string -- after all, int() is allowed to return a long, so
> why couldn't str() be allowed to return a Unicode string?
The pr
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>BTW, in one of your replies I read that you had a problem with
>>how cvs2svn handles trunk, branches and tags. In reality, this
>>is no problem at all, since Subversion is very good at handling
>>moves within the rep
Guido van Rossum wrote:
> [Guido]
>
>>>My first response to the PEP, however, is that instead of a new
>>>built-in function, I'd rather relax the requirement that str() return
>>>an 8-bit string -- after all, int() is allowed to return a long, so
>>>why couldn't str() be allowed to return a Unicod
Michael Hudson wrote:
> "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
>
>
>>Set the external encoding for stdin, stdout, stderr:
>>
>>(also an example for adding encoding support to an
>>exi
Guido van Rossum wrote:
> Ouch. Too much discussion to respond to it all. Please remember that
> in Jythin and IronPython, str and unicode are already synonyms.
I know, but don't understand that argument: aren't we talking
about Python in general, not some particular implementation ?
Why should
James Y Knight wrote:
> On Aug 17, 2005, at 2:55 PM, Timothy Fitz wrote:
>
>
>>On 8/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>
>>
>>>-0 The behavior of dir() already a bit magical. Python is much
>>>simpler
>>>to comprehend if we have direct relationships like dir() and vars()
>>>
Thomas Heller wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes:
>
>
>>[Please mail followups to [EMAIL PROTECTED]
>>
>>The PEP has been rewritten based on a suggestion by Guido to change
>>str() rather than adding a new built-in function. Based on my
>>testing, I believe the idea is feasible
Walter Dörwald wrote:
> I wonder if we should switch back to a simple readline() implementation
> for those codecs that don't require the current implementation
> (basically every charmap codec).
That would be my preference as well. The 2.4 .readline() approach
is really only needed for codecs
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I think it's worthwhile reconsidering this approach for
>>character type queries that do no involve a huge number
>>of code points.
>
>
> I would advise against that. I measure both versions
> (your ve
I must have missed this one:
>
> Style for raising exceptions
>
>
> Guido explained that these days exceptions should always be raised as::
>
> raise SomeException("some argument")
>
> instead of::
>
> raise SomeException, "some
Guido van Rossum wrote:
> On 8/25/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>I must have missed this one:
>>
>>
>>>
>>>Style for raising exceptions
>>>
>>>
>&g
Raymond Hettinger wrote:
> [Guido]
>
>>Another observation: despite the derogatory remarks about regular
>>expressions, they have one thing going for them: they provide a higher
>>level of abstraction for string parsing, which this is all about.
>>(They are higher level in that you don't have to b
Raymond Hettinger wrote:
> [Marc-Andre Lemburg]
>
>>I may be missing something, but why invent yet another parsing
>>method - we already have the re module. I'd suggest to
>>use it :-)
>>
>>If re is not fast enough or you want more control over the
>>parsing process, you could also have a look at
Ronald Oussoren wrote:
>
> On 22-sep-2005, at 5:26, Guido van Rossum wrote:
>
>> The platform module has a way to map system names such as returned by
>> uname() to marketing names. It maps SunOS to Solaris, for example. But
>> it doesn't map Darwin to Mac OS X. I think I know how to map Darwin
>
Bob Ippolito wrote:
> /usr/bin/sw_vers technically calls a private (at least undocumented)
> CoreFoundation API, it doesn't parse that plist directly :)
>
> On further inspection, it looks like parsing the plist directly is
> supported API these days (see the bottom of developer.apple.com/doc
Steven Bethard wrote:
> On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
>
>>Yesterday I ran into a bug in the C API docs. The top of this page:
>>
>> http://docs.python.org/api/unicodeObjects.html
>>
>>says:
>>
>>Py_UNICODE
>> This type represents a 16-bit unsigned storage type which
Bob Ippolito wrote:
> On Sep 29, 2005, at 3:53 PM, M.-A. Lemburg wrote:
>
>
>>Perhaps a flag that fires up Python and runs platform.py
>>would help too.
>
>
> python -mplatform
Cool :-)
Now we only need to add some more information to it (like e.g.
the Uni
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>
>>* Unicode variant (UCS2, UCS4)
>
>
> don't forget the "Py_UNICODE is wchar_t" subvariant.
True, but that's not relevant for binary compatibility of
Python package (at least not AFAIK).
UCS2 vs. U
Michael Hudson wrote:
> Martin Blais <[EMAIL PROTECTED]> writes:
>
>
>>What if we could completely disable the implicit conversions between
>>unicode and str? In other words, if you would ALWAYS be forced to
>>call either .encode() or .decode() to convert between one and the
>>other... wouldn't
Reinhold Birkenfeld wrote:
> Martin v. Löwis wrote:
>>>Whether we think it should be supported depends
>>on who "we" is, as with all these minor features: some think it is
>>a waste of time, some think it should be supported if reasonably
>>possible, and some think this a conditio sine qua non. It
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>Is the added complexity needed to support not having Unicode support
>>compiled into Python really worth it ?
>
> If there are volunteers willing to maintain it, and the other volunteers
> are not affected: certainly.
Martin Blais wrote:
> On 10/3/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
If that's how things were designed, then Python's entire standard
brary (not to mention third-party libraries) is not "unicode safe" -
to quote your own words - since many functions may return 8-bit strings
>
Walter Dörwald wrote:
> Am 04.10.2005 um 04:25 schrieb [EMAIL PROTECTED]:
>
>
>>As the OP suggests, decoding with a codec like mac-roman or
>>iso8859-1 is very
>>slow compared to encoding or decoding with utf-8. Here I'm working
>>with 53k of
>>data instead of 53 megs. (Note: this is a lapt
Martin v. Löwis wrote:
>>Another option would be to generate a big switch statement in C
>>and let the compiler decide about the best data structure.
>
> I would try to avoid generating C code at all costs. Maintaining the
> build processes will just be a nightmare.
We could automate this usi
Hye-Shik Chang wrote:
> On 10/5/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>Of course, a C version could use the same approach as
>>the unicodedatabase module: that of compressed lookup
>>tables...
>>
>>http://aggregate.org/TechPub/lcpc2002.p
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>> I would try to avoid generating C code at all costs. Maintaining the
>>> build processes will just be a nightmare.
>>
>>
>>
>> We could automate this using distutils; however I'm not
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>>OK, here's a patch that implements this enhancement to
>>PyUnicode_DecodeCharmap(): http://www.python.org/sf/1313939
>
> Looks nice!
Indeed (except for the choice of the "map this character
to undefined" code point).
Hye-Shik, could you please
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>> It wouldn't.
>>
>>
>>
>> Could you elaborate why not ? Using distutils on Windows is really
>> easy...
>
>
> The current build process for Windows simply doesn't provide it
Walter Dörwald wrote:
> Martin v. Löwis wrote:
>
>> Hye-Shik Chang wrote:
>>
>>> If the encoding optimization can be easily done in Walter's approach,
>>> the fastmap codec would be too expensive way for the objective because
>>> we must maintain not only fastmap but also charmap for backward
>>>
Hye-Shik Chang wrote:
> On 10/6/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>Hye-Shik, could you please provide some timeit figures for
>>the fastmap encoding ?
>>
Thanks for the timings.
> (before applying Walter's patch, charmap decoder)
>
> %
Robey Pointer wrote:
> On 29 Sep 2005, at 12:06, Steven Bethard wrote:
>
>
>>On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
>>
>>
>>>Yesterday I ran into a bug in the C API docs. The top of this page:
>>>
>>> http://docs.python.org/api/unicodeObjects.html
>>>
>>>says:
>>>
>>>Py_UNICODE
Walter Dörwald wrote:
> We've already taken care of decoding. What we still need is a new
> gencodec.py and regenerated codecs.
I'll take care of that; just haven't gotten around to it yet.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 14 2005
Neal Norwitz wrote:
> Jeremy,
>
> There are a bunch of mods from the AST branch that got integrated into
> head. Hopefully, by doing this on python-dev more people will get
> involved. I'll describe high level things first, but there will be a
> ton of details later on. If people don't want to
I've checked in a whole bunch of newly generated codecs
which now make use of the faster charmap decoding variant added
by Walter a short while ago.
Please let me know if you find any problems.
Some codecs (esp. the Mac OS X ones) have minor changes.
These originate from updated mapping files on
Neil Hodgson wrote:
> Guido van Rossum:
>
>
>>Folks, please focus on what Python 3000 should do.
>>
>>I'm thinking about making all character strings Unicode (possibly with
>>different internal representations a la NSString in Apple's Objective
>>C) and introduce a separate mutable bytes array da
Walter Dörwald wrote:
> Martin v. Löwis wrote:
>
>> M.-A. Lemburg wrote:
>>
>>> I've checked in a whole bunch of newly generated codecs
>>> which now make use of the faster charmap decoding variant added
>>> by Walter a short while ago.
&
Bengt Richter wrote:
> Please bear with me for a few paragraphs ;-)
Please note that source code encoding doesn't really have
anything to do with the way the interpreter executes the
program - it's merely a way to tell the parser how to
convert string literals (currently on the Unicode ones)
into
Walter Dörwald wrote:
>>> Why should koi_u.py be defined in terms of koi8_r.py anyway? Why not put
>>> a complete decoding_table into koi8_u.py?
>>
>>
>> KOI8-U is not available as mapping on ftp.unicode.org and
>> I only recreated codecs from the mapping files available
>> there.
>
>
> OK, so we
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>
>>>>Why should koi_u.py be defined in terms of koi8_r.py anyway? Why not put
>>>>a complete decoding_table into koi8_u.py?
>>>
>>>
>>>KOI8-U is not available as mapping on ftp.unicode.
M.-A. Lemburg wrote:
> Here's a mapping file for KOI9-U - please check whether
> it's correct.
I missed one codec point change: 0xB4.
Here's the updated version which matches the codec we currently
have in Python 2.3 and 2.4.
--
Marc-Andre Lemburg
eGenix.com
Profess
Walter Dörwald wrote:
>>>I'd like to suggest a small cosmetic change: gencodec.py should output
>>>byte values with two hexdigits instead of four. This makes it easier to
>>>see what is a byte values and what is a codepoint. And it would make
>>>grepping for stuff simpler.
>>
>>True.
>>
>>I'll reru
Guido van Rossum wrote:
> On 10/24/05, Phil Thompson <[EMAIL PROTECTED]> wrote:
>
>>I'm implementing a string-like object in an extension module and trying to
>>make it as interoperable with the standard string object as possible. To do
>>this I'm implementing the relevant slots and the buffer int
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 yo
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>
>>I had to create three custom mapping files for cp1140, koi8-u
>>and tis-620.
>
>
> Can you please publish the files you have used somewhere? They
> best go into the Python CVS.
Sure; I'll check in the wh
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.
>
>
Bengt Richter wrote:
> At 11:43 2005-10-24 +0200, M.-A. Lemburg wrote:
>
>>Bengt Richter wrote:
>>
>>>Please bear with me for a few paragraphs ;-)
>>
>>Please note that source code encoding doesn't really have
>>anything to do with the way the
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>
>>I don't follow you here. The source code encoding
>>is only applied to Unicode literals (you are using string
>>literals in your example). String literals are passed
>>through as-is.
>
>
> ho
M.-A. Lemburg wrote:
> Martin v. Löwis wrote:
>
>>M.-A. Lemburg wrote:
>>
>>
>>
>>>I had to create three custom mapping files for cp1140, koi8-u
>>>and tis-620.
>>
>>
>>Can you please publish the files you have used somewhere? T
Josiah Carlson wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>>Fredrik Lundh wrote:
>>
>>>however, for Python 3000, it would be nice if the source-code encoding
>>>applied
>>>to the *entire* file (XML-style), rather than just unicode string literals
>>>and (hope-
>>>fully) comments and
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 ag
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
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
> broade
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 unders
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
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: -*-
>
> to the source, and then provides a mo
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 m
Gareth McCaughan wrote:
> On Sunday 2005-11-13 17:43, Marc-Andre Lemburg wrote:
>
> [Noam Raphael:]
>
>>>The idea is to add a method called "dedent" to strings. It would do
>>>exactly what the current textwrap.indent function does.
>
>
> [Marc-Andre:]
>
>>You are missing a point here: string
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
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 ?
>>
>>
>>
Guido van Rossum wrote:
> Happened to see this commit. What's the magic about 10MB? Is there any
> understanding of what causes it to fail? What is the failure mode?
> Could it just be fragmentation causing the malloc or realloc to fail?
> Should we perhaps use a more conservative buffer size, e.g.
Nice that we now have ElementTree in the stdlib :-)
Some questions:
* Are you going to contribute cElementTree as well ?
* What was the motivation to not include the whole ElementTree
package ?
* I'm missing the usual "Licensed to PSF under a Contributor Agreement."
in the copyright notices
Fred L. Drake, Jr. wrote:
> On Tuesday 13 December 2005 18:40, A.M. Kuchling wrote:
> > +1; it's what should have been done in the first place.
>
> If only I'd understood that when I added the xml/PyXML hack to the stdlib
> years ago. :-(
>
> Fixed now. I'll deal with the documentation in a f
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 !
&g
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 se
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 fr
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 ``op
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 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
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
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 &q
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 ne
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,
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 wou
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 inter
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> I don't believe the change is major. It only affects a few extensions,
>>> and for these, it is only a minor change. A single line of changing
>>> will be enough.
>>
>> This is true for all the chang
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 p
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
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
>>
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 t
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 proce
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 tr
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
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
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 muc
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 e
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, &
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
>
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
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 inst
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 pr
1001 - 1090 of 1090 matches
Mail list logo
