Raymond Hettinger wrote:
Based on some ideas from Skip, I had tried transforming the likes of "x
in (1,2,3)" into "x in frozenset([1,2,3])". When applicable, it
substantially simplified the generated code and converted the O(n)
lookup into an O(1) step. There were substantial savings even if the
Raymond Hettinger wrote:
Wouldn't it help a lot more if the compiler would detect that
(1,2,3) is immutable and convert it into a constant at
compile time ?!
Yes. We've already gotten it to that point:
Python 2.5a0 (#46, Feb 15 2005, 19:11:35) [MSC v.1200 32 bit (Intel)] on
win32
import dis
dis.d
Raymond Hettinger wrote:
Hmm, what if you'd teach tuples to do faster contains lookups for
string or integer only content, e.g. by introducing sub-types for
string-only and integer-only tuples ?!
For a linear search, tuples are already pretty darned good and leave
room for only microscopic O(n) im
Brett C. wrote:
Martin v. Löwis wrote:
Apparently, os.access was forgotten when the file system encoding
was introduced in Python 2.2, and then it was again forgotten in
PEP 277.
I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder
whether this is a backport candidate. People who try
Neil Schemenauer wrote:
On Sat, Apr 04, 1998 at 07:04:02AM +, Tim Peters wrote:
[Martin v. L?wis]
I can't see any harm by supporting this operation also if __str__ returns
a Unicode object.
It doesn't sound like a good idea to me, at least in part because it
would be darned messy to implement s
Neil Schemenauer wrote:
On Wed, Mar 09, 2005 at 11:10:59AM +0100, M.-A. Lemburg wrote:
The patch implements the PyObjbect_Text() idea (an API that
returns a basestring instance, ie. string or unicode) and
then uses this in '%s' (the string version) to properly propogate
to u'%
Nick Coghlan wrote:
Guido van Rossum wrote:
No, the reason is that if we did this with exceptions, it would be
liable to mask errors; an exception does not necessarily originate
immediately with the code you invoked, it could have been raised by
something else that was invoked by that code. The spe
Martin v. Löwis wrote:
Skip Montanaro wrote:
> I say backport. If people were trying to call os.access with unicode
filenames it would have been failing and they were either avoiding
unicode
filenames as a result or working around it some other way. I can't
see how
making os.access work with u
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
The question is whether it would encourage conditional work-arounds.
-1. That only makes the code more complicated.
You misunderstand. I'm not proposing that the work-around is added
to Python. I'm saying that Python *users* might introduce
Raymond Hettinger wrote:
BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code.
+1 on the PEP
-1 on removing those tools - breaks too much code.
I suspect that la
Guido van Rossum wrote:
Here's my take on the key issues brought up:
Alternative names anytrue(), alltrue(): before I posted to my blog I
played with these names (actually anyTrue(), allTrue(), anyFalse(),
allFalse()). But I realized (1) any() and all() read much better in
their natural context (an
Evan Jones wrote:
> I recently rediscovered this strange behaviour in Python's Unicode
> handling. I *think* it is a bug, but before I go and try to hack
> together a patch, I figure I should run it by the experts here on
> Python-Dev. If you understand Unicode, please let me know if there are
> pr
Martin v. Löwis wrote:
> Stephen J. Turnbull wrote:
>
>> So there is a standard for the UTF-8 signature, and I know of
>> applications which produce it. While I agree with you that Python's
>> codecs shouldn't produce it (by default), providing an option to strip
>> is a good idea.
>
> I would p
Stephen J. Turnbull wrote:
>>"MAL" == M <[EMAIL PROTECTED]> writes:
>
>
> MAL> The BOM (byte order mark) was a non-standard Microsoft
> MAL> invention to detect Unicode text data as such (MS always uses
> MAL> UTF-16-LE for Unicode text files).
>
> The Japanese "memopado" (Notep
Nicholas Bastin wrote:
>
> On Apr 5, 2005, at 6:19 AM, M.-A. Lemburg wrote:
>
>> Note that the UTF-16 codec is strict w/r to the presence
>> of the BOM mark: you get a UnicodeError if a stream does
>> not start with a BOM mark. For the UTF-8-SIG codec, this
>>
Nicholas Bastin wrote:
>
> On Apr 7, 2005, at 5:07 AM, M.-A. Lemburg wrote:
>
>>> The current implementation of the utf-16 codecs makes for some
>>> irritating gymnastics to write the BOM into the file before reading it
>>> if it contains no BOM, which
Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>
>>It would be nice if you could optionally specify that the codec would
>>assume UTF-16BE if no BOM was present, and not raise UnicodeError in
>>that case, which would preserve the current behaviour as well as allow
>>users' to ask for behaviour wh
Eyal Lotem wrote:
I would like to experiment with security based on Python references as
security capabilities.
Unfortunatly, there are several problems that make Python references
invalid as capabilities:
* There is no way to create secure proxies because there are no
private attributes.
* Lots of
Fredrik Lundh wrote:
PS. a side effect of the for-in pattern is that I'm beginning to feel
that Python
might need a nice "switch" statement based on dictionary lookups, so I can
replace multiple callbacks with a single loop body, without writing too
many
if/elif clauses.
PEP 275 anyone ? (http://
Shannon -jj Behrens wrote:
> On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>Fredrik Lundh wrote:
>>
>>>PS. a side effect of the for-in pattern is that I'm beginning to feel
>>>that Python
>>>might need a nice "switch" s
Martin v. LÃwis wrote:
S.ÃaÄlar Onur wrote:
I want to know status of
http://mail.python.org/pipermail/python-dev/2004-December/050193.html
this thread.
The status is that they are still there.
Due to lack of time on my part.
Will python remove wctype functions support from its core?
I don't know
Nicholas Bastin wrote:
> The documentation for Py_UNICODE states the following:
>
> "This type represents a 16-bit unsigned storage type which is used by
> Python internally as basis for holding Unicode ordinals. On platforms
> where wchar_t is available and also has 16-bits, Py_UNICODE is a
Nicholas Bastin wrote:
>
> On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
>
>>> At the very least, if we can't guarantee the internal representation,
>>> then the PyUnicode_FromUnicode API needs to go away, and be replaced
>>> with something capable o
Nicholas Bastin wrote:
> On May 4, 2005, at 6:20 PM, Shane Hathaway wrote:
>
>>>Nicholas Bastin wrote:
>>>
>>>
"This type represents the storage type which is used by Python
internally as the basis for holding Unicode ordinals. Extension
module
developers should make no assumptio
Fredrik Lundh wrote:
> Thomas Heller wrote:
>
>
>>AFAIK, you can configure Python to use 16-bits or 32-bits Unicode chars,
>>independend from the size of wchar_t. The HAVE_USABLE_WCHAR_T macro
>>can be used by extension writers to determine if Py_UNICODE is the same as
>>wchar_t.
>
>
> note th
Nicholas Bastin wrote:
> On May 4, 2005, at 6:03 PM, Martin v. Löwis wrote:
>
>
>>Nicholas Bastin wrote:
>>
>>>"This type represents the storage type which is used by Python
>>>internally as the basis for holding Unicode ordinals. Extension
>>>module
>>>developers should make no assumptions abo
Nicholas Bastin wrote:
> On May 6, 2005, at 3:17 AM, M.-A. Lemburg wrote:
>
>
>>You've got that wrong: Python let's you choose UCS-4 -
>>UCS-2 is the default.
>
>
> No, that's not true. Python lets you choose UCS-4 or UCS-2. What the
> defa
Shane Hathaway wrote:
> Martin v. Löwis wrote:
>
>>Shane Hathaway wrote:
>>
>>
>>>I agree that UCS4 is needed. There is a balancing act here; UTF-16 is
>>>widely used and takes less space, while UCS4 is easier to treat as an
>>>array of characters. Maybe we can have both: unicode objects start w
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>Hmm, looking at the configure.in script, it seems you're right.
>>I wonder why this weird dependency on TCL was added.
>
>
> If Python is configured for UCS-2, and Tcl for UCS-4, then
> Tkinter would not w
Nicholas Bastin wrote:
> On May 7, 2005, at 9:29 AM, Martin v. Löwis wrote:
>>With --enable-unicode=ucs2, Python's Py_UNICODE does *not* start
>>supporting the full Unicode ccs the same way it supports UCS-2.
>>Individual surrogate values remain accessible, and supporting
>>non-BMP characters is le
Nicholas Bastin wrote:
> On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote:
>
>
>>However, I don't understand all the excitement
>>about Py_UNICODE: if you don't like the way this Python
>>typedef works, you are free to interface to Python using
&
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>Unicode has many code points that are meant only for composition
>>and don't have any standalone meaning, e.g. a combining acute
>>accent (U+0301), yet they are perfectly valid code points -
>>regardless of UCS-2
[Python used to always default to UCS2-Unicode builds;
this was changed to default to whatever a possibly installed
TCL system is using - hiding the choice from the user
and in effect removing the notion of having a Python
Unicode default configuration]
Martin v. Löwis wrote:
> M.-A. Lemb
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I think we should remove the defaulting to whatever
>>TCL uses and instead warn the user about a possible
>>problem in case TCL is found and uses a Unicode
>>width which is incompatible with Python's choice.
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>On sre character classes: I don't think that these provide
>>a good approach to XML lexical classes - custom functions
>>or methods or maybe even a codec mapping the characters
>>to their XML lexical class ar
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>If all you're interested in is the lexical class of the code points
>>in a string, you could use such a codec to map each code point
>>to a code point representing the lexical class.
>
>
> How can I efficie
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>Martin, please reconsider... the choice is between:
>
>
> The point is that this all was discussed, and decided the
> other way 'round. There is no point in going back and forth
> between the two choices:
>
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I'm not breaking anything, I'm just correcting the
>>way things have to be configured in an effort to
>>bring back the cross-platforma configure default.
>
> Your proposed change will break the build of
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 creat
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_ParseTuple
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 the
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+
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")
>>>
>>>
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
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
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,
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
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 discus
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:
> 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 sh
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 assign
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 si
Walter Dörwald wrote:
> 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
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 unico
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 m
e-unicode
switch.
We should probably add 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:
>&g
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.EncodingOutpu
Walter Dörwald wrote:
> M.-A. Lemburg wrote:
>> Walter Dörwald wrote:
>>> M.-A. Lemburg wrote:
>>>
>>>> [...]
>>>> Like I suggested in the patch discussion, such functionality could
>>>> be factored out of the implementations of Stre
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-t
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 "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 11:
> ordinal not in range(128)
>
> because they want to
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
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 onl
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
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 a
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&#
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.getencoderobje
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
>>>>
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
>python/br
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:
>
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
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
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 embe
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
>>
Microsoft has recently released their express version of the Visual C++.
Given that this version is free for everyone, wouldn't it make sense
to ship Python 2.5 compiled with this version ?!
http://msdn.microsoft.com/vstudio/express/default.aspx
I suppose this would make compiling extensions
Alex Martelli wrote:
> On 2/27/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Microsoft has recently released their express version of the Visual C++.
>> Given that this version is free for everyone, wouldn't it make sense
>> to ship Python 2.5 compiled wit
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?
>
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
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
Organizatio
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 p
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
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 t
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 possi
Thomas Heller wrote:
> 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
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 i
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
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
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* threa
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 ot
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 tha
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>> Here's a grep of all the changed/new APIs, please include it
>> in the PEP.
>
> I've posted a simple-minded source scanner here:
>
> http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck
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 g
Michael Hudson wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>
>> neal.norwitz wrote:
>>
>>> +Outstanding Issues
>>> +==
>>> +
>>> +* Require C99, so we can use // comments, named initializers, declare
>>> variables
>>> + without introducing a new scope, among other benefi
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: python-dev@p
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 Snak
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
Hye-Shik Chang wrote:
> We got an inconsistency for __repr__() returning unicode as
> reported in http://python.org/sf/1459029 :
>
> class s1:
> def __repr__(self):
> return '\\n'
>
> class s2:
> def __repr__(self):
> return u'\\n'
>
> print repr(s1()), repr(s2())
>
> Un
Bill Janssen wrote:
>> from a user perspective, adding this to the standard library is a no-brainer.
>> the only reason not to add it would be if the release managers don't have
>> time to sort out the build issues.
>
> I agree with Fredrik here.
>
> On the package naming issue: using "em" for "e
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
801 - 900 of 1090 matches
Mail list logo
