On 6/5/07, Talin <[EMAIL PROTECTED]> wrote:
> Thanks so much for this excellent roundup from the RoundUp Master :)
> Seriously, I've been staying well away from the PEP 3131 threads, and I
> was hoping that someone would post a summary of the issues so I could
> catch up.
I agree that the roundup
On 6/4/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 6/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > However, what would that mean wrt. non-Unicode source encodings.
>
> > Say you have a Latin-1-encoded source code. Is that in NFC or not?
The path of least surprise for legacy encodings m
> The PEP assumes NFC, but I haven't really understood why, unless that
> is required for compatibility with other systems (in which case, it
> should be made explicit).
It's because UAX#31 tells us to use NFC, in section 5
"Generally if the programming language has case-sensitive identifiers,
th
Josiah Carlson writes:
> gone ahead and mangled names in a consistant fashion using the tokenize
> module. Can you guess what it does?
OK, here's your straight line:
Throw a lot of "AttributeError: rInCXzn is not defined"?
___
Python-3000 mailing l
On Jun 4, 2007, at 3:43 PM, Josiah Carlson wrote:
> Here is some code borrowed right from the Python standard library.
> I've
> gone ahead and mangled names in a consistant fashion using the
> tokenize
> module. Can you guess what it does?
Nope, it's absolutely inscrutable. And actually, aft
Ka-Ping Yee wrote:
> Hi,
>
> Here's a summary of some of the remaining open issues and unaddressed
> arguments regarding PEP 3131. These are the ones I'm familiar with,
> so I don't claim this to be complete. I hope it helps give some
> perspective on this huge thread, though.
Thanks so much fo
Ligatures, such as IJ and ij (unicode 0x0132, 0x0133) are considered
acceptable identifier characters unless explicitly tailored out.
(They appear in both ID and XID)
Do we really want this, or should we assume that ij and ij should be
equivalent? If so, then we need to enforce this somehow.
To me,
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> > I hate to make a decision by majority rule, but I
> > think there is the argument that you need to weigh
> the
> > population of ascii-literate people vs.
> > ascii-illiterate people.
>
> That's a very poor criteria, as not everyone in the
> w
--- Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steve Howell wrote:
> > the one word that I wasn't able to
> > translate, even with the help of Babelfish, was
> the
> > German word for "insert." It turns out the thing
> that
> > threw me off was that I omitted the umlaut.
>
> Although that probably
Steve Howell wrote:
> the one word that I wasn't able to
> translate, even with the help of Babelfish, was the
> German word for "insert." It turns out the thing that
> threw me off was that I omitted the umlaut.
Although that probably wouldn't be such a big problem
for a native German speaker, w
Steve Howell wrote:
> einfugen = in joints ()
Maybe "join in" (as a verb)?
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/pyth
--- Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Here is some code borrowed right from the Python
> standard library. I've
> gone ahead and mangled names in a consistant fashion
> using the tokenize
> module. Can you guess what it does?
>
>
> class RTrCOlOrB :
>
> nBBjIUrB =0
>
> def
Martin v. Löwis wrote:
>> Can somebody post a few examples of what Python code
>> would look like under PEP 3131? Maybe 10-to-15 line
>> programs that illustrate the following use cases.
>
> class Liste:
> def __init__(self):
> self.erstes_element = None
>
> def einfügen(self, objekt):
>
>> Say you have a Latin-1-encoded source code. Is that in NFC or not?
>
> Doesn't that depend on whether they happened to ever write some of the
> combined characters (such as ö) using a two-character form like o¨?
No. Latin-1 does not support that form; the concept does not exist
in that encodin
On 6/4/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > It seems to me the simplest thing to do is to require that Python
> > source files be normalized. Then the ambiguity just goes away.
> > Everyone knows what form their files should be in, and if you really
> > need to construct a non-norm
> It seems to me the simplest thing to do is to require that Python
> source files be normalized. Then the ambiguity just goes away.
> Everyone knows what form their files should be in, and if you really
> need to construct a non-normalized string, you can do that explicitly
> using "\u" notation.
Steve Howell <[EMAIL PROTECTED]> wrote:
> --- Michael Urman <[EMAIL PROTECTED]> wrote:
> >
> > The arguments then feel reduced to "Unicode enhances
> > readability" vs.
> > "Unicode impedes readability" and since clearly it
> > does both, how do
> > we make the value judgement about which it does
Eric V. Smith wrote:
> > Formatter Creation and Initialization
> >
> > The Formatter class takes a single initialization argument, 'flags':
> >
> > Formatter(flags=0)
> >
> > The 'flags' argument is used to control certain subtle behavioral
> > differences in formatting
On 6/3/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
[Most deleted, Stephen Turnbull already answered better than I knew,
let alone could write]
> > The same one-step-at-a-time reasoning applies to unicode identifers.
> > Allowing IDs in your native language (or others that you explicitly
> > ap
--- Michael Urman <[EMAIL PROTECTED]> wrote:
>
> The arguments then feel reduced to "Unicode enhances
> readability" vs.
> "Unicode impedes readability" and since clearly it
> does both, how do
> we make the value judgement about which it does
> more? How do we weigh
> the ability to use native l
On 6/4/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Many of us value a *predictable* identifier character set.
> Whether "predictable" means ASCII only, or user-selectable, or
> restricted by default, I think we all agree in this sentiment:
As someone who would rather see non-ASCII characters gain
Eric V. Smith wrote:
> > Formatter.ALLOW_LEADING_UNDERSCORES
> > Formatter.CHECK_UNUSED_POSITIONAL
> > Formatter.CHECK_UNUSED_NAME
> I'm not sure I'm wild about these flags which would have to be or'd
> together, as opposed to discrete parameters. I realize have a singl
On Sun, 3 Jun 2007, [UTF-8] "Martin v. L??wis" wrote:
> >> All identifiers are converted into the normal form NFC while parsing;
> >
> > Actually, shouldn't the whole file be converted to NFC, instead of
> > only identifiers? If you have decomposable characters in strings and
> > your editor decide
Hi,
Here's a summary of some of the remaining open issues and unaddressed
arguments regarding PEP 3131. These are the ones I'm familiar with,
so I don't claim this to be complete. I hope it helps give some
perspective on this huge thread, though.
A. Should identifiers be allowed to contain any
On Fri, 25 May 2007, Guillaume Proux wrote:
> If you are really paranoid to see evil chars take over your
> python src dir
On Sun, 3 Jun 2007, Stephen J. Turnbull wrote:
> I do not agree with Ka-Ping inter alia that there are bogeymen
> under the bed
Sigh. I have lost count of the number of time
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> # Definition von Element sei gegeben
>
> class Liste:
> def __init__(self):
> self.erstes_element = None
>
> def einfügen(self, objekt):
> if not self.erstes_element:
> self.erstes_element = Element(objekt)
> else:
>
> Formatter Creation and Initialization
>
> The Formatter class takes a single initialization argument, 'flags':
>
> Formatter(flags=0)
>
> The 'flags' argument is used to control certain subtle behavioral
> differences in formatting that would be cumbersome to change vi
27 matches
Mail list logo
