Neil Hodgson wrote:
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_indextype(u, index) - integer
Simon Burton [EMAIL PROTECTED] wrote:
Is there a python interface ?
Not yet.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Martin v. Löwis wrote:
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
Josiah Carlson wrote:
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
On Tue, Oct 25, 2005 at 01:36:26PM +1000, Simon Burton wrote:
Is there a python interface ?
Not yet, as far as I know.
FYI, all: please see the following weblog entry for a description of
the AST branch:
http://www.amk.ca/diary/2005/10/the_ast_branch_lands_1
If I got anything wrong,
The submission deadline for PyCon 2006 is now a week away. PyCon 2006
will be in Dallas, Texas, February 24-26 2006.
For 2006, I'd like to see more tutorial-style talks on the program.
This means that your talk doesn't have to be about something entirely
new; you can show how to use a particular
Bengt Richter wrote:
At 11:43 2005-10-24 +0200, M.-A. Lemburg wrote:
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
M.-A. Lemburg wrote:
I don't follow you here. The source code encoding
is only applied to Unicode literals (you are using string
literals in your example). String literals are passed
through as-is.
however, for Python 3000, it would be nice if the source-code encoding applied
to the *entire*
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
I don't follow you here. The source code encoding
is only applied to Unicode literals (you are using string
literals in your example). String literals are passed
through as-is.
however, for Python 3000, it would be nice if the source-code
M.-A. Lemburg wrote:
Martin v. Löwis wrote:
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.
Sure; I'll check in the whole build machinery I'm
Almost there - this is the only issue I have left on my list :)
Guido van Rossum wrote:
On 10/24/05, Nick Coghlan [EMAIL PROTECTED] wrote:
However, those resolutions bring up the following issues:
5 a. What exception is raised when EXPR does not have a __context__
method?
b. What
M.-A. Lemburg wrote:
Done.
In order to rebuild the codecs, cd Tools/unicode; make
then check the codecs in the created build/ subdir (e.g.
using comparecodecs.py) and copy them over to the
Lib/encodings/ directory.
Thanks!
Martin
___
Python-Dev
David Abrahams wrote:
Is the instruction at
http://www.python.org/dev/doc/devel/inst/tweak-flags.html#SECTION000622000
still relevant? I am not 100% certain I didn't make one myself, but
it looks to me as though my Windows Python 2.4.1 distro came with a
libpython24.a. I am
Bill Janssen wrote:
I just got mail this morning from a researcher who wants exactly what
Martin described, and wondered why the default MacPython 2.4.2 didn't
provide it by default. :-)
If all he wants is to represent Deseret, he can do so in a 16-bit
Unicode type, too: Python supports
Fredrik Lundh wrote:
however, for Python 3000, it would be nice if the source-code encoding applied
to the *entire* file (XML-style), rather than just unicode string literals
and (hope-
fully) comments and docstrings.
As MAL explains, the encoding currently does apply to the entire file.
Nick Coghlan [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
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
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
Is the instruction at
http://www.python.org/dev/doc/devel/inst/tweak-flags.html#SECTION000622000
still relevant? I am not 100% certain I didn't make one myself, but
it looks to me as though my Windows Python 2.4.1
Martin v. Löwis [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
however, for Python 3000, it would be nice if the source-code encoding
applied
to the *entire* file (XML-style), rather than just unicode string literals
and (hope-
fully) comments and docstrings.
As MAL explains, the
Guido van Rossum wrote:
It is true though that AttributeError is somewhat special. There are
lots of places (perhaps too many?) where an operation is defined using
something like if the object has attribute __foo__, use it, otherwise
use some other approach. Some operations explicitly check
On 10/25/05, Eric Nieuwland [EMAIL PROTECTED] wrote:
Hmmm... Would it be reasonable to introduce a ProtocolError exception?
And which perceived problem would that solve? The problem of Nick
Guido disagreeing in public?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
On 10/25/05, Eric Nieuwland [EMAIL PROTECTED] wrote:
Hmmm... Would it be reasonable to introduce a ProtocolError exception?
And which perceived problem would that solve? The problem of Nick
Guido disagreeing in public?
;-)
No, that will go on in other fields, I
[Eric are all your pets called Eric? Nieuwland]
Hmmm... Would it be reasonable to introduce a ProtocolError exception?
[Guido]
And which perceived problem would that solve?
[Eric]
It was meant to be a bit more informative about what is wrong.
ProtocolError: lacks __enter__ or __exit__
I have a deep suspicion that this has been done to death already, but
my searching ability isn't up to finding the reference. So I'll simply
ask the question, and not offer a long discussion:
Has the option of letting the with statement admit multiple context
managers been considered (and
On 10/20/05, Neal Norwitz [EMAIL PROTECTED] wrote:
The Grammar is (was at one point at least) shared between Jython andwould allow more tools to be able to share infrastructure.The ideais to eventually be able to have [JP]ython output the same AST totools.
Hello Python-dev,
My name is Frank
On 10/25/05, Frank Wierzbicki [EMAIL PROTECTED] wrote:
My name is Frank Wierzbicki and I'm working on the Jython project. Does
anyone on this list know more about the history of this Grammar sharing
between the two projects? I've heard about some Grammar sharing between
Jython and Python,
I think he was more interested in the invariant Martin proposed, that
len(\U0001)
should always be the same and should always be 1.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 10/25/05, Bill Janssen [EMAIL PROTECTED] wrote:
I think he was more interested in the invariant Martin proposed, that
len(\U0001)
should always be the same and should always be 1.
Yes but why? What does this invariant do for him?
--
--Guido van Rossum (home page:
Frank Wierzbicki wrote:
On 10/20/05, *Neal Norwitz* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
The Grammar is (was at one point at least) shared between Jython and
would allow more tools to be able to share infrastructure. The idea
is to eventually be able to have
Josiah Carlson wrote:
It seems that removing this restriction may cause serious issues, at
least in the case when using cyrillic characters in names. See recent
security issues in regards to web addresses in web browsers for the
confusion (and/or name errors) that could result in their use.
Guido van Rossum wrote:
On 10/25/05, Frank Wierzbicki [EMAIL PROTECTED] wrote:
My name is Frank Wierzbicki and I'm working on the Jython project. Does
anyone on this list know more about the history of this Grammar sharing
between the two projects? I've heard about some Grammar sharing
On 10/25/05, Samuele Pedroni [EMAIL PROTECTED] wrote:
Your best bet is to track down Jim Hugunin and see if he remembers.
He's jimhug at microsoft.com or jim at hugunin.net.
no. this is all after Jim, its indeed a derived effort from the CPython
own AST effort, just that we started using it
Guido van Rossum wrote:
Yes but why? What does this invariant do for him?
I don't know about this person, but there are a few things that
don't work properly in UTF-16 mode:
- the Unicode character database fails to lookup things.
u\U0001D670.isupper() gives false, but should give true
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
It seems that removing this restriction may cause serious issues, at
least in the case when using cyrillic characters in names. See recent
security issues in regards to web addresses in web browsers for the
confusion
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 accepted I'd
Josiah Carlson wrote:
Martin v. Löwis [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
however, for Python 3000, it would be nice if the source-code encoding
applied
to the *entire* file (XML-style), rather than just unicode string literals
and (hope-
fully) comments and docstrings.
As MAL
On 10/25/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Identically drawn glyphs are a problem, and pretending that they aren't
a problem, doesn't make it so. Right now, all possible name glyphs are
visually distinct, which would not be the case if any unicode character
could be used as a name
Josiah Carlson wrote:
And how users could say, name error? But I typed in window.draw(PEN) as
I was told to, and it didn't work!
Ah, so the serious issues you are talking about are not security
issues, but usability issues.
I don't think extending the range of acceptable characters will
cause
Guido van Rossum wrote:
On 10/25/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Almost there - this is the only issue I have left on my list :)
[,,,]
Why are you so keen on TypeError? I find AttributeError totally
appropriate. I don't see symmetry with for-loops as a valuable
property here.
M.-A. Lemburg wrote:
A few years ago we had a discussion about this on python-dev
and agreed to stick with ASCII identifiers for Python. I still
think that's the right way to go.
I don't think there ever was such an agreement.
Regards,
Martin
___
On 10/25/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Maybe there's a design principle in there somewhere:
Failed duck-typing - AttributeError (or TypeError for complex checks)
Failed instance or subtype check - TypeError
Doesn't convince me.
If there are principles at work here (and not
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
And how users could say, name error? But I typed in window.draw(PEN) as
I was told to, and it didn't work!
Ah, so the serious issues you are talking about are not security
issues, but usability issues.
Indeed, it was a
On 10/25/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Indeed, they are similar, but_ different_ in my font as well. The trick
is that the glyphs are not different in the case of certain greek or
cyrillic letters. They don't just /look/ similar they /are identical/.
Well, in the font I'm using
Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/25/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Indeed, they are similar, but_ different_ in my font as well. The trick
is that the glyphs are not different in the case of certain greek or
cyrillic letters. They don't just /look/ similar
Martin v. Löwis:
This aspect of rendering is often not implemented, though. Web browsers
do it correctly, see
...
GUI frameworks sometimes do it correctly, sometimes don't; most
notably, Tk has no good support for RTL text.
Scintilla does a rough job with this. RTL text is displayed
Martin v. Löwis wrote:
For window.draw, people will readily understand that
they are supposed to use Latin letters. More generally, they will know
what script to use just from looking at the identifier.
Would it help if an identifier were required to be
made up of letters from the same
At the moment, I see make testall hanging in test_timeout. In
addition, test_curses is leaving the tty in a hosed state:
test_crypt
test_csv
test_curses
test_datetime
test_dbm
test_decimal
test_decorators
ditto on the curses problem, but test_timeout completed just fine, at least
the first time around.
fedora core 4, x86_64
[GCC 4.0.1 20050727 (Red Hat 4.0.1-5)] on linux2
Jeff
pgpTesSunOdI7.pgp
Description: PGP signature
___
Python-Dev mailing list
M.-A. Lemburg:
You mean a slice that slices out the next indextype ?
Yes.
This sounds a lot like you'd want iterators for the various
index types. Should be possible to implement on top of the
proposed APIs, e.g. itergraphemes(u), itercodepoints(u), etc.
Iterators may be helpful, but
48 matches
Mail list logo
