On Nov 24, 2010, at 10:55 PM, Stephen J. Turnbull wrote:
> Greg Ewing writes:
>> On 24/11/10 22:03, Stephen J. Turnbull wrote:
>>> But
>>> if you actually need to remember positions, or regions, to jump to
>>> later or to communicate to other code that manipulates them, doing
>>> this stuff the st
On Nov 24, 2010, at 4:03 AM, Stephen J. Turnbull wrote:
> You end up proliferating types that all do the same kind of thing. Judicious
> use of inheritance helps, but getting the fundamental abstraction right is
> hard. Or least, Emacs hasn't found it in 20 years of trying.
Emacs hasn't even
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have installed GDB 7.2 32 bits and 32 bits buildslaves are green.
Nevertheless 64 bits buildslaves are failing test_gdb.
Is there any expectation that a 32 bits GDB be able to debug a 64 bits
python?. If not, gdb test should compare "platform.archit
M.-A. Lemburg writes:
> Please note that we can only provide one way of string indexing
> in Python using the standard s[1] notation and since we don't
> want that operation to be fast and no more than O(1), using the
> code units as items is the only reasonable way to implement it.
AFAICT, t
M.-A. Lemburg writes:
> That would be a possibility as well... but I doubt that many users
> are going to bother, since slicing surrogates is just as bad as
> slicing combining code points and the latter are much more common in
> real life and they do happen to mostly live in the BMP.
That's
On Fri, Nov 26, 2010 at 02:32:43AM +0100, Éric Araujo wrote:
> Shouldn’t his name rather be in Misc/ACKS too? Modules typically
> (warning: non-scientific data) include the name of the author or first
> contributors but not the name of every contributor.
>
> I think these cool features deserve a
Hello,
> Author: senthil.kumaran
> Log:
> Mouse support and colour to Demo/curses/life.py by Dafydd Crosby
>
> Modified:
>python/branches/py3k/Demo/curses/life.py
Okay, this time I’m reacting to the right branch
> Modified: python/branches/py3k/Demo/curses/life.py
>
On Friday 19 November 2010 23:25:03 you wrote:
> > Python is unclear about non-BMP characters: narrow build was called
> > "ucs2" for long time, even if it is UTF-16 (each character is encoded to
> > one or two UTF-16 words).
>
> No, no, no :-)
>
> UCS2 and UCS4 are more appropriate than "narrow"
>>> Modified:
>>>python/branches/py3k-urllib/Lib/http/client.py
>>>python/branches/py3k-urllib/Lib/urllib/request.py
>> No tests? Misc/NEWS? :)
>
> Note that this is work in a separate branch.
Ah, didn’t notice that! Senthil replied as much in private email:
> That was in a different
On 11/25/2010 08:30 AM, Emile Anclin wrote:
hello,
working on Pylint, we have a lot of voluntary corrupted files to test
Pylint behavior; for instance
$ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py
# -*- coding: IBO-8859-1 -*-
""" check correct unknown encoding declaration
hello,
working on Pylint, we have a lot of voluntary corrupted files to test
Pylint behavior; for instance
$ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py
# -*- coding: IBO-8859-1 -*-
""" check correct unknown encoding declaration
"""
__revision__ = ''
and we try to f
Am 25.11.2010 12:47, schrieb Éric Araujo:
>> Author: senthil.kumaran
>> New Revision: 86748
>>
>> Log:
>> Experimental - Transparent gzip Encoding in urllib2. There should be a good
>> way to deal with Content-Length.
> Cool feature! But...
>
>> Modified:
>>python/branches/py3k-urllib/Lib/h
On 25/11/2010 03:46, Greg Ewing wrote:
On 25/11/10 12:38, average wrote:
Is immutability a general need that should have general solution?
Yes, I have sometimes thought this. Might be nice to have a "mutable"
attribute that could be read and could be changed from True to False,
though pre
> Author: senthil.kumaran
> New Revision: 86748
>
> Log:
> Experimental - Transparent gzip Encoding in urllib2. There should be a good
> way to deal with Content-Length.
Cool feature! But...
> Modified:
>python/branches/py3k-urllib/Lib/http/client.py
>python/branches/py3k-urllib/Lib/url
On 25/11/2010 09:34, Glenn Linderman wrote:
So the following code defines constants with associated names that get
put in the repr.
I'm still a Python newbie in some areas, particularly classes and
metaclasses, maybe more.
But this Python 3 code seems to create constants with names ... works
On 25/11/2010 10:12, Nadeem Vawda wrote:
On Thu, Nov 25, 2010 at 11:34 AM, Glenn Linderman wrote:
So the following code defines constants with associated names that get put
in the repr.
The code you gave doesn't work if the constant() function is moved
into a separate module from the code that
On Thu, Nov 25, 2010 at 11:34 AM, Glenn Linderman wrote:
> So the following code defines constants with associated names that get put
> in the repr.
The code you gave doesn't work if the constant() function is moved
into a separate module from the code that calls it. The globals()
function, as I
Alexander Belopolsky wrote:
> On Wed, Nov 24, 2010 at 9:17 PM, Stephen J. Turnbull
> wrote:
> ..
>> > I note that an opinion has been raised on this thread that
>> > if we want compressed internal representation for strings, we should
>> > use UTF-8. I tend to agree, but UTF-8 has been repeat
Terry Reedy wrote:
> On 11/24/2010 3:06 PM, Alexander Belopolsky wrote:
>
>> Any non-trivial text processing is likely to be broken in presence of
>> surrogates. Producing them on input is just trading known issue for
>> an unknown one. Processing surrogate pairs in python code is hard.
>> Softw
So the following code defines constants with associated names that get
put in the repr.
I'm still a Python newbie in some areas, particularly classes and
metaclasses, maybe more.
But this Python 3 code seems to create constants with names ... works
for int and str at least.
Special case for
All,
When I configure python to enable shared libraries, none of the
extensions are getting built during the make step due to this error.
building 'cStringIO' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/u01/home/apli/wm/GDD/Python-2.
21 matches
Mail list logo