Michael Foord voidspace.org.uk> writes:
>
> Earlier this year I was at a pypy sprint helping to work on Python 2.7
compatibility. The bytearray type has much of the string interface, including
swapcase… So there was effort to implement this method with the correct
semantics for pypy. Doubtless th
Le 06/09/2011 07:50, Antoine Pitrou a écrit :
On Tue, 06 Sep 2011 01:53:32 +0200
victor.stinner wrote:
http://hg.python.org/cpython/rev/b1e03d10391e
changeset: 72297:b1e03d10391e
user:Victor Stinner
date:Tue Sep 06 01:53:03 2011 +0200
summary:
Issue #12567: Add curses.unget
Le 06/09/2011 02:25, Nick Coghlan a écrit :
On Tue, Sep 6, 2011 at 10:01 AM, victor.stinner
wrote:
Fix also spelling of the null character.
While these cases are legitimately changed to 'null' (since they're
lowercase descriptions of the character), I figure it's worth
mentioning again that
On Tue, Sep 6, 2011 at 6:04 PM, Victor Stinner
wrote:
> "NUL" is an abbreviation used in tables when you don't have enough space to
> write the full name: "null character".
Yep, fair description.
> Where do you want to mention this abbreviation?
Sorry, I meant worth mentioning on the list, not
I benchmarked some of the bigmemtests when run with -M 80G. They run really
slow, because they try to use all available memory, and then take a lot of
time processing it. Here are some runtimes:
test_capitalize (test.test_bigmem.StrTest) ... ok (420.490846s)
test_center (test.test_bigmem.StrTest)
Hello Martin,
> In the test suite, we have the bigmemtest and precisionbigmemtest
> decorators. I think bigmemtest cases should all be changed to
> precisionbigmemtest, giving sizes of just above 2**31. With that
> change, the runtime for test_capitalize would go down to 42s.
I have started work
On Mon, Sep 5, 2011 at 8:56 AM, Michael Foord wrote:
> Hey all,
> A while ago there was a discussion of the value of apis like str.swapcase,
> and it was suggested that even though it was acknowledged to be useless the
> effort of deprecating and removing it was thought to be more than the value
>
For the record, I've disabled automatic builds on the bigmem buildbot
until things get sorted out a bit (no need to eat huge amounts of RAM
and eight hours of CPU each time a commit is pushed, only to have the
process killed :-)). It's still possible to run custom builds, of
course.
Regards
Anto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2011 04:04 AM, Victor Stinner wrote:
> Le 06/09/2011 02:25, Nick Coghlan a écrit :
>> On Tue, Sep 6, 2011 at 10:01 AM, victor.stinner
>> wrote:
>>> Fix also spelling of the null character.
>>
>> While these cases are legitimately changed t
Le 06/09/2011 00:11, victor.stinner a écrit :
> http://hg.python.org/cpython/rev/56ab3257ca13
> changeset: 72296:56ab3257ca13
> user:Victor Stinner
> date:Tue Sep 06 00:11:13 2011 +0200
> summary:
> Issue #9561: packaging now writes egg-info files using UTF-8
>
> instead of th
Le 06/09/2011 17:17, Éric Araujo a écrit :
Le 06/09/2011 00:11, victor.stinner a écrit :
http://hg.python.org/cpython/rev/56ab3257ca13
changeset: 72296:56ab3257ca13
user:Victor Stinner
date:Tue Sep 06 00:11:13 2011 +0200
summary:
Issue #9561: packaging now writes egg-info fi
Joao S. O. Bueno writes:
> Removing it would mean explicitly "batteries removal".
That's what we usually do with a dead battery, no?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2011 12:59 PM, Stephen J. Turnbull wrote:
> Joao S. O. Bueno writes:
>
>> Removing it would mean explicitly "batteries removal".
>
> That's what we usually do with a dead battery, no?
Normally one "replaces" dead batteries. :)
Tres.
- --
On 9/6/2011 11:11 AM, Tres Seaver wrote:
FWIW, the RFC 20 (the ASCII spec) really really defines 'NUL' as the
*name* of the \0 character, not just an "abbreviation used in tables":
http://tools.ietf.org/html/rfc20#section-5.2
As I read the text, the 2 or 3 capital letter *symbols* are
abb
On 9/6/2011 12:58 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2011 12:59 PM, Stephen J. Turnbull wrote:
Joao S. O. Bueno writes:
Removing it would mean explicitly "batteries removal".
That's what we usually do with a dead battery, no?
Normally one "replac
Terry Reedy wrote:
On 9/6/2011 12:58 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2011 12:59 PM, Stephen J. Turnbull wrote:
Joao S. O. Bueno writes:
Removing it would mean explicitly "batteries removal".
That's what we usually do with a dead battery, no?
On 6 Sep 2011, at 20:36, Steven D'Aprano wrote:
> Terry Reedy wrote:
>> On 9/6/2011 12:58 PM, Tres Seaver wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 09/06/2011 12:59 PM, Stephen J. Turnbull wrote:
Joao S. O. Bueno writes:
> Removing it would mean explici
On Tue, Sep 6, 2011 at 3:36 PM, Steven D'Aprano wrote:
> pERSONNALLY, i THINK THAT A SWAPCASE COMMAND IS ESSENTIAL FOR TEXT EDITOR
> APPLICATIONS, TO AVOID THOSE LITTLE cAPS lOCK ACCIDENTS.
There's a better solution to that, but the caps lock lobby has a stranglehold
on keyboard manufacturers.
On Sep 06, 2011, at 03:42 PM, Fred Drake wrote:
>On Tue, Sep 6, 2011 at 3:36 PM, Steven D'Aprano wrote:
>> pERSONNALLY, i THINK THAT A SWAPCASE COMMAND IS ESSENTIAL FOR TEXT EDITOR
>> APPLICATIONS, TO AVOID THOSE LITTLE cAPS lOCK ACCIDENTS.
>
>There's a better solution to that, but the caps lock
>> Perhaps I missed something early on, but why are we proposing
>> removing a function which (presumably) is stable and tested and
>> works and is not broken? What maintenance is needed here?
>
>
> The maintenance burden is on other implementations.
It's not a maintenance burden (at least not i
On 6 Sep 2011, at 21:18, Martin v. Löwis wrote:
>>> Perhaps I missed something early on, but why are we proposing
>>> removing a function which (presumably) is stable and tested and
>>> works and is not broken? What maintenance is needed here?
>>
>>
>> The maintenance burden is on other implement
> Which applications? I'm not sure the number of applications using
> str.swapcase gets even as high as ten.
I think this is what people underestimate. I can't name
applications either - but that doesn't mean they don't exist.
I'm deeply convinced that the majority of Python code (and
I mean *larg
On Sep 6, 2011, at 1:36 PM, Martin v. Löwis wrote:
> I think this is what people underestimate. I can't name
> applications either - but that doesn't mean they don't exist.
Google code search is pretty good indicator that this method
has near zero uptake. If it dies, I don't think anyone will
Victor Stinner wrote:
"NUL" is an abbreviation used in tables when you don't have enough space
to write the full name: "null character".
It's also the official name of the character, for when you want
to be unambiguous about what you mean (e.g. "null character" as
opposed to "empty string" or
On Wed, Sep 7, 2011 at 7:23 AM, Raymond Hettinger
wrote:
>
> On Sep 6, 2011, at 1:36 PM, Martin v. Löwis wrote:
>
> I think this is what people underestimate. I can't name
> applications either - but that doesn't mean they don't exist.
>
> Google code search is pretty good indicator that this meth
Raymond Hettinger wrote:
On Sep 6, 2011, at 1:36 PM, Martin v. Löwis wrote:
I think this is what people underestimate. I can't name
applications either - but that doesn't mean they don't exist.
Google code search is pretty good indicator that this method
has near zero uptake. If it dies, I
On Wed, 7 Sep 2011 10:47:16 +1000
Nick Coghlan wrote:
>
> However, a big +1 for deprecation in the case of bytes and bytearray.
> That's nothing to do with the maintenance burden though, it's to do
> with the semantic confusion between binary data and ASCII-encoded text
> implied by the retention
Nick Coghlan writes:
> However, a big +1 for deprecation in the case of bytes and bytearray.
> That's nothing to do with the maintenance burden though, it's to do
> with the semantic confusion between binary data and ASCII-encoded text
> implied by the retention of methods like upper(), lower(
Antoine Pitrou writes:
> Bytes objects are often used for partly ASCII strings,
All I can say to that phrase is, "urk, ISO 2022 anyone?"
> not arbitrary "arrays of bytes". And making indexing of bytes
> objects return ints was IMHO a mistake.
Bytes objects are not ASCII strings, even though
On Wed, Sep 7, 2011 at 11:53 AM, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
> > The case-related methods, though, have no place in sane wire
> > protocol handling.
>
> RFC 822 headers are a somewhat insane but venerable (isn't that true
> of anything that's reached age 350 in dog-years?),
This is all speculation and no hint of implementation at this point ...
redirecting this subthread to Python-Ideas. Reply-To set accordingly.
Nick Coghlan writes:
> Heh, I knew as soon as I sent that message that someone would be able
> to point out a counter example. I agree that RFC 822 (and
31 matches
Mail list logo
