On Fri, 21 Oct 2005 18:32:22 + (UTC)
nas at arctrix.com (Neil Schemenauer) wrote:
> > Does it just allow us to do new and interesting manipulations of
> > the code during compilation?
>
> Well, that's a pretty big deal, IMHO. For example, adding
> pychecker-like functionality should be straig
Guido writes:
> Oh, I don't doubt that they want it. But often they don't *need* it,
> and the higher-level goal they are trying to accomplish can be dealt
> with better in a different way. (Sort of my response to people asking
> for static typing in Python as well. :-)
I suppose that's true. But
Guido van Rossum wrote:
> Python's slice-and-dice model pretty much ensures that indexing is
> common. Almost everything is ultimately represented as indices: regex
> search results have the index in the API, find()/index() return
> indices, many operations take a start and/or end index.
Maybe th
Guido van Rossum wrote:
> I think the API should reflect the representation *to some extend*,
> namely it shouldn't claim to have operations that are typically
> thought of as O(1) that can only be implemented as O(n).
Maybe a compromise could be reached by using a
btree of chunks or something, s
On 10/24/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > - yet others think: "I want all of Unicode, with proper, efficient
> > >indexing, so I want four bytes per char".
> >
> > I doubt the last one though. Probably they really don't want efficient
> > indexing, they want to perform higher-l
> > - yet others think: "I want all of Unicode, with proper, efficient
> >indexing, so I want four bytes per char".
>
> I doubt the last one though. Probably they really don't want efficient
> indexing, they want to perform higher-level operations that currently
> are only possible using effic
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 you encoded
> using combining code points.
> ...
> next_(u, index) -> integer
>
> Returns th
Antoine Pitrou wrote:
>>There are many design alternatives:
>
> Wouldn't it be simpler to use:
> - one-byte representation if every character <= 0xFF
> - two-byte representation if every character <= 0x
> - four-byte representation otherwise
As I said: there are many alternatives. This one ha
On 10/24/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Changing the APIs would be much work, although perhaps not impossible
> > of Python 3000. For example, Raymond Hettinger's partition() API
> > doesn't refer to indices at all, and can replace many uses of find()
Guido van Rossum wrote:
> Changing the APIs would be much work, although perhaps not impossible
> of Python 3000. For example, Raymond Hettinger's partition() API
> doesn't refer to indices at all, and can replace many uses of find()
> or index().
I think Neil's proposal is not to make them go awa
On 10/24/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Indeed. My guess is that indexing is more common than you think,
> especially when iterating over the string. Of course, iteration
> could also operate on UTF-8, if you introduced string iterator
> objects.
Python's slice-and-dice model p
> There are many design alternatives: one option would be to support
> *three* internal representations in a single type, generating the
> others from the one operation existing as needed. The default, initial
> representation might be UTF-8, with UCS-4 only being generated when
> indexing occurs,
M.-A. Lemburg wrote:
> There seems to be a general misunderstanding here: even if you
> have UCS4 storage, it is still possible to slice a Unicode
> string in a way which makes rendering it correctly.
[impossible?]
> Unicode has the concept of
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.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
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.
I think memory usage caused is measurable (I estimated 4KiB per
dictionary). More i
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?
Not sure. Unfortunately, the tables being used as source are not part of
the Python source, so nobody except MAL can faithfully regenerate them.
If they wer
Neil Hodgson wrote:
>For Windows, the code will get a little uglier, needing to perform
> an allocation/encoding and deallocation more often then at present but
> I don't think there will be a speed degradation as Windows is
> currently performing a conversion from 8 bit to UTF-16 inside many
>
On Monday 24 October 2005 7:39 pm, Guido van Rossum wrote:
> On 10/24/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > A concern I'd have with fixing this is that Unicode objects also
> > > support the buffer API. In any situation where either str or unicode
> > > is a
On 10/24/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > A concern I'd have with fixing this is that Unicode objects also
> > support the buffer API. In any situation where either str or unicode
> > is accepted I'd be reluctant to guess whether a buffer object was
> > mea
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
Guido van Rossum wrote:
> A concern I'd have with fixing this is that Unicode objects also
> support the buffer API. In any situation where either str or unicode
> is accepted I'd be reluctant to guess whether a buffer object was
> meant to be str-like or Unicode-like. I think this covers all the
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 interface. For most
> things thi
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 interface. For most
things this is fine, but there are a small number of methods in
stri
> Python should allow strings to
> contain any Unicode character and should be indexable yielding
> characters rather than half characters. Therefore Python strings
> should appear to be UTF-32.
+1.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
> >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 data type. But I could
> >use some validation or feedback on this idea from actual
> >practitioners.
[Barry Warsaw]
> I've had this PEP laying around for quite a few months. It was
inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects.
* FWIW, the _as_immutable() protocol was dropped from sets.py for a
reason. User reports indicated that
Fredrik Lundh wrote:
>does a plain
>
>a = -100.0
>
>still work on your machine?
>
D'oh - I seriously broke something, then, because it didn't.
funny_falcon commented on the patch in SF and suggested a change that
took care of that. I've uploaded the corrected version of the patch,
wh
On Oct 23, 2005, at 6:43 PM, Barry Warsaw wrote:
> I've had this PEP laying around for quite a few months. It was
> inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP,
> uploaded
> a sample patch (albe
On 10/24/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> That makes the resolutions for the posted issues:
>
> 1. The slot name "__context__" will be used instead of "__with__"
> 2. The builtin name "context" is currently offlimits due to its ambiguity
> 3a. generator-iterators do NOT hav
I'm not sure I understood completely the idea but deriving freeze
function from hash gives hash a wider importance.
Is __hash__=id inside a class enough to use a set (sets.Set before 2.5)
derived class instance as a key to a mapping?
Sure I missed the point.
Regards Paolino
___
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:
> Right. That was my point. Nick's worried about undecorated __context__
> because he wants to endow generators with a different default
> __context__. I say no to both proposals and the worries cancel each
> other out. EIBTI.
Works for me.
That makes the resolutions for t
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
Professional Python Services direct
On 10/24/05, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> I'd say using a class statement to define a property is metaclass
> abuse, as would
> anything that wouldn't define something class-like. The same is true
> for other
> constructs, using an decorator to define something that is not a
> calla
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.org and
>>>I only recreated codecs from the mapping files availab
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
On 24-okt-2005, at 12:54, Josiah Carlson wrote:
>>
>
> Metaclass abuse? Oh, I'm sorry, I thought that the point of
> metaclasses
> were to offer a way to make "magic" happen in a somewhat pragmatic
> manner, you know, through metaprogramming. I would call this
> particular
> use a practica
Michele Simionato <[EMAIL PROTECTED]> wrote:
>
> On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > I would criticise it for being dangerously close to worthless. With the
> > minor support code that I (and others) have offered, no new syntax is
> > necessary.
> >
> > You can get the sam
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I think having dicts and sets automatically invoke freeze would be a mistake,
> because at least one of the following two cases would behave unexpectedly:
I'm pretty sure that the PEP was only aslomg if one would freeze the
contents of dicts IF the dict
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Josiah Carlson wrote:
>> You can get the same semantics with...
>>
>> class NAME(_(TYPE), ARGS):
>> BLOCK
>>
>> And a suitably defined _. Remember, not every X line function should be
>> made a builtin or syntax.
>
> And this would be an extremely
M.-A. Lemburg wrote:
> 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.
Please let me know if yo
Christopher Armstrong <[EMAIL PROTECTED]> wrote:
>
> On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Should dicts and sets automatically freeze their mutable keys?"
> >
> > Dictionaries don't have mutable keys,
>
> Since when?
>
> Maybe you meant something else? I can't think of any
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > You can get the same semantics with...
> >
> > class NAME(_(TYPE), ARGS):
> > BLOCK
> >
> > And a suitably defined _. Remember, not every X line function should be
> > made a builtin or syntax.
>
> And this would be an
On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Should dicts and sets automatically freeze their mutable keys?"
>
> Dictionaries don't have mutable keys,
Since when?
class Foo:
def __init__(self):
self.x = 1
f = Foo()
d = {f: 1}
f.x = 2
Maybe you meant something else? I ca
Barry Warsaw wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a bit incomplete), and I'm posting i
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
Josiah Carlson wrote:
> You can get the same semantics with...
>
> class NAME(_(TYPE), ARGS):
> BLOCK
>
> And a suitably defined _. Remember, not every X line function should be
> made a builtin or syntax.
And this would be an extremely fragile hack that is entirely dependent on the
murky
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.
>>>
>>> Please let me know if you find any problems.
>>
>>
>>
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.
>>
>>Please let me know if you find any problems.
>
> I think we should work on eliminating t
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
On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> I would criticise it for being dangerously close to worthless. With the
> minor support code that I (and others) have offered, no new syntax is
> necessary.
>
> You can get the same semantics with...
>
> class NAME(_(TYPE), ARGS):
> BLOC
Michele Simionato <[EMAIL PROTECTED]> wrote:
>
> On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Very nice indeed. I'd be more supportive if it was defined as a new
> > statement
> > such as "create" with the syntax:
> >
> >create TYPE NAME(ARGS):
> > BLOCK
>
> I like it, but
Alan McIntyre wrote:
> When running "make test" I get some errors in test_array and
> test_compile that did not occur in the build from CVS. Given the inputs
> to long() have '.' characters in them, I assume that these tests really
> should be failing as implemented, but I haven't dug into them t
On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Very nice indeed. I'd be more supportive if it was defined as a new statement
> such as "create" with the syntax:
>
>create TYPE NAME(ARGS):
> BLOCK
I like it, but it would require a new keyword. Alternatively, one
could abuse 'def':
Martin v. Löwis:
> That's very tricky. If you have multiple implementations, you make
> usage at the C API difficult. If you make it either UTF-8 or UTF-32,
> you make PythonWin difficult. If you make it UTF-16, you make indexing
> difficult.
For Windows, the code will get a little uglier, nee
55 matches
Mail list logo
