Fredrik Lundh wrote:
> today's Python supports "locale aware" 8-bit strings; e.g.
>
> >>> import locale
> >>> "åäö".isalpha()
> False
> >>> locale.setlocale(locale.LC_ALL, "sv_SE")
> 'sv_SE'
> >>> "åäö".isalpha()
> True
>
> to what extent should this be supported by Py
An interesting idea, although I suspect a leading try keyword would make
things clearer.
(try expr1 except expr2 if exc_type)
print (try letters[7] except "N/A" if IndexError)
f = (try open(filename) except open(filename2) if IOError)
print (try eval(expr) except "Can not divide by zero!" if
On 9/1/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I would just rip it out.
>
> I don't understand this business about ripping out
> exec. I thought that exec had to be a statement so
> the compiler can tell whether to use fast locals.
> Do you have a different way of ha
Guido van Rossum wrote:
> I would just rip it out.
I don't understand this business about ripping out
exec. I thought that exec had to be a statement so
the compiler can tell whether to use fast locals.
Do you have a different way of handling that in mind
for Py3k?
--
Greg
___
Talin wrote:
> So for example, any string operation which produces a subset of the
> string (such as partition, split, index, slice, etc.) will produce a
> string of the same width as the original string.
It might be possible to represent it in a narrower format,
however. Perhaps there should b
Guido van Rossum wrote:
> On 9/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > I would just rip it out.
>>
>> It turns out that it's not so easy. The exec statement currently can
>> modify the locals, which means that
>>
>> def f():
>> exec "a=1"
>> print a
>
On 9/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I would just rip it out.
>
> It turns out that it's not so easy. The exec statement currently can
> modify the locals, which means that
>
> def f():
> exec "a=1"
> print a
>
> succeeds. To make that possible,
Guido van Rossum wrote:
> I would just rip it out.
It turns out that it's not so easy. The exec statement currently can
modify the locals, which means that
def f():
exec "a=1"
print a
succeeds. To make that possible, the compiler flags scopes containing
exec statements as unoptimized a
I would just rip it out.
On 9/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> in process of ripping out the exec statement, I stumbled over the
> following function in symtable.c (line 468ff):
>
>
> /* Che
Hi,
in process of ripping out the exec statement, I stumbled over the
following function in symtable.c (line 468ff):
/* Check for illegal statements in unoptimized namespaces */
static int
check_unoptimized(const
I say not at all.
On 9/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> today's Python supports "locale aware" 8-bit strings; e.g.
>
> >>> import locale
> >>> "והצ".isalpha()
> False
> >>> locale.setlocale(locale.LC_ALL, "sv_SE")
> 'sv_SE'
> >>> "והצ".isalpha()
> True
>
On 9/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> just noticed that PEP 3100 says that PyString_AsEncodedString and
> PyString_AsDecodedString is to be removed, but it doesn't mention
> any other PyString (or PyUnicode) functions.
>
> how large changes can we make here, really ?
I don't know i
Calvin Spealman writes:
> I thought I felt in the mood for some abuse today, so I'm proposing
> something sure to give me plenty of crap, but maybe someone will enjoy
> the idea, anyway.
[...]
> expr1 except expr2 if exc_type
This is wonderful!
In combination with conditional expressi
I think in a sense Python *will* continue to support multiple
character sets -- as byte streams. IMO that's the only reasonable
approach. Unlike apparently Matz I've never heard complaints that
Python 2 doesn't have enough support for character sets larger than
Unicode, and that is effectively what
On 8/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 8/31/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> > On 8/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > So this feels like the Perl idiom of using die: ``open(file) or die``
> > "Ouch" on the associated my idea with perl!
> =) Th
I thought that others might find this reference interesting. It is Matz (the inventor of Ruby) talking about why he thinks that Unicode is good for what it does but not sufficient in general, along with some hints of what he plans for multinationalization in Ruby. The translation is rough and is li
Barry Warsaw wrote:
> I recently emerged in several packages.
good thing dictionary.com includes wikipedia articles, or I'd never figured out
if that was a typo or a rather odd spiritual phenomenon.
___
Python-3000 mailing list
Python-3000@python.
On Sep 1, 2006, at 2:49 AM, Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
>> I think it would be best to do this as a CPython configuration option
>> just like it's done today. You can choose 4-byte or 2-byte Unicode
>> (essentially UCS-4 or UTF-16) in order to be compatible with other
>> pack
just noticed that PEP 3100 says that PyString_AsEncodedString and
PyString_AsDecodedString is to be removed, but it doesn't mention
any other PyString (or PyUnicode) functions.
how large changes can we make here, really ?
(I'm not going to sketch on a concrete proposal here; I'm more interested
i
"tomer filiba" <[EMAIL PROTECTED]> writes:
>> Encoding conversion and newline conversion should be performed a
>> block at a time, below buffering, so not only I/O syscalls, but
>> also invocations of the recoding machinery are amortized by
>> buffering.
>
> you have a good point, which i also stu
> spending that theorizing.
make that "spending that time theorizing about what you could, in theory, do."
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/
today's Python supports "locale aware" 8-bit strings; e.g.
>>> import locale
>>> "åäö".isalpha()
False
>>> locale.setlocale(locale.LC_ALL, "sv_SE")
'sv_SE'
>>> "åäö".isalpha()
True
to what extent should this be supported by Python 3000 ?
_
very well, i'll use it. thanks.
On 9/1/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> tomer filiba wrote:
>
> > [...]
> > besides, encoding suffers from many issues. suppose you have a
> > damaged UTF8 file, which you read char-by-char. when we reach the
> > damaged part, you'll never be able to
Talin wrote:
> (Another option is to simply make all strings UTF-32 -- which is not
> that unreasonable, considering that text strings normally make up only a
> small fraction of a program's memory footprint. I am sure that there are
> applications that don't conform to this generalization, howeve
24 matches
Mail list logo
