On May 16, 2007, at 10:30 PM, Talin wrote:
> While there has been a lot of discussion as to whether to accept PEP
> 3131 as a whole, there has been little discussion as to the specific
> details of the PEP. In particular, is it generally agreed that the
> Unicode character classes listed in the PEP
Ron Adam schrieb:
> Guido van Rossum wrote:
>> That would be great! This will automatically turn \u1234 into 6
>> characters, right?
>
> I'm not exactly clear when the '\u' characters get converted. There
> isn't any conversion done in tokanize.c that I can see. It's primarily
> only conce
Jim Jewett wrote:
> You can use any character in a symbol (~= identifier), including (if
> your implementation supports such characters at all, even in comments)
> Hebrew or Chinese characters.
Lisp is a bit different, because it's always had only a very
few chars that aren't identifier chars, so
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
| While there has been a lot of discussion as to whether to accept PEP
| 3131 as a whole, there has been little discussion as to the specific
| details of the PEP. In particular, is it generally agreed that the
| Unicode character
On May 16, 2007, at 9:06 PM, tomer filiba wrote:
> === RTL/LTR ===
> i pointed out already that no existing editor can handle LTR-RTL
> representation correctly, which essentially renders all RTL languages
> out of the scope of this PEP. that doesn't bother me personally so
> much,
> as i'm not
On 16-May-07, at 6:06 PM, tomer filiba wrote:
>
> === help people who can't type english ===
> since the keywords remain ASCII, along with stdlib and all other major
> third party libs -- how does that help the english-illiterate
> programmer?
>
> import random
> 満は = range(100)
> ra
While there has been a lot of discussion as to whether to accept PEP
3131 as a whole, there has been little discussion as to the specific
details of the PEP. In particular, is it generally agreed that the
Unicode character classes listed in the PEP are the ones we want to
include in identifiers
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> all in all, i'm still -1 on that. i would rather go halfway -- allow unicode
> comments. let people write docs in their native language, that's all
> fine with me (or is that already imposed by the UTF8 PEP?)
I could have sworn that unicode comments and
=== RTL/LTR ===
i pointed out already that no existing editor can handle LTR-RTL
representation correctly, which essentially renders all RTL languages
out of the scope of this PEP. that doesn't bother me personally so much,
as i'm not going to use this feature anyway, but that still leaves us with
Collin Winter wrote:
> So now we've made the jump from "help (some) international users" to
> "I want to use unicode characters just for the hell of it".
Seems to me it's more like "I want to express my algorithm
in a way that other mathematicians can easily follow".
Which isn't all that much di
On 5/14/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> as an english-second-language programmer, i'd really like to be able
> to have unicode identifiers -- but my gut feeling is -- it will open the
> door for a tower of babel.
I don't think this happened in Lisp. I won't pretend there hasn't
been
Guido van Rossum wrote:
> I'm still on the fence about the trailing backslash; I personally
> prefer to write Windows paths using regular strings and doubled
> backslashes.
Maybe we should have a special w"..." string in the Windows
version of Python for pathnames.
It would raise a SyntaxError i
I've updated PEP3141 to remove the algebraic classes and bring the
numeric hierarchy much closer to scheme's design. Let me know what you
think. Feel free to send typographical and formatting problems just to
me. My schedule's a little shaky the next couple weeks, but I'll make
updates as quickly a
On 5/13/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Anders J. Munch <[EMAIL PROTECTED] > wrote:
> This PEP talks about support for *identifiers*. If you need *extensive*
> vocabulary for your *identifiers*, I'd assume that you're coding something
> non-trivial (with ignorable excepti
On 5/13/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> HI Tomer,
> > if בייקון.ביצים:
> > pass
> > which comes first? does it say bacon.eggs or eggs.bacon?
> > and what happens if the editor uses a dot prefixed by LTR
> > marker? the meaning is reversed, but it still looks the same!
> All
As I mentioned before, I don't expect either of these will be much of
a concern. I guess tools like pylint could optionally warn if
non-ascii characters are used.
On 5/16/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/13/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> > I think the gesture alon
On 5/13/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> I think the gesture alone is worth it, even if no one ever used the
> feature productively. But people will. The cost to python-dev is low,
> and the cost to English-speaking users is very likely zero.
> What am I missing?
Additional cost
On 15/05/2007 13.20, Greg Ewing wrote:
>> C++ and Java don't have tuples, do they?
>
> No, but in C++ you could probably do something clever by
> overloading the comma operator if you were feeling perverse
> enough...
Well, there's also tr1::tuple :)
--
Giovanni Bajo
__
Guido van Rossum wrote:
> That would be great! This will automatically turn \u1234 into 6
> characters, right?
>
> Perhaps you could make the patch against the py3k-struni branch
> instead of against the regular p3yk (sic) branch?
Done. Patch number 1720390
https://sourceforge.net/tracker/index
On 5/16/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > That would be great! This will automatically turn \u1234 into 6
> > characters, right?
>
> I'm not exactly clear when the '\u' characters get converted. There
> isn't any conversion done in tokanize.c that I can see.
Guido van Rossum wrote:
> That would be great! This will automatically turn \u1234 into 6
> characters, right?
I'm not exactly clear when the '\u' characters get converted. There
isn't any conversion done in tokanize.c that I can see. It's primarily
only concerned with finding the beginnin
That would be great! This will automatically turn \u1234 into 6
characters, right?
Perhaps you could make the patch against the py3k-struni branch
instead of against the regular p3yk (sic) branch?
On 5/16/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> > I actually wasn't able
Steven Bethard wrote:
> I actually wasn't able to find something I couldn't translate. It
> would be helpful to have another set of eyes if anyone has the time.
I have a patch against (*) 2.6 tokanize.py that ignores '\' characters in
raw strings. This has two effects. A matching quote, """,
Yeah, I've decided for myself that similar-looking characters are a
non-issue. They are a real problem in domain names because spammers
use them to fool users into believing they're going to the real ebay.
But source code just doesn't have that attack model. There are lots of
characters that look t
Jason Orendorff wrote:
> On 5/16/07, Collin Winter <[EMAIL PROTECTED]> wrote:
>>> [Test][ExpectedException(typeof(ArgumentException))]
>>> public void 一年未満はエラーになる()
>>> {
>>>Date date = new Date(0, 1, 1);
>>> }
> The mix of Japanese and English is not as visually
> jarring as I expected. I
On 5/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/16/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > +1 for no escaping of quotes in raw strings. Python provides so many
> > different ways to quote a string, the cases in which you can't just
> > switch to another quoting style are v
On 5/16/07, Benji York <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 5/14/07, Benji York <[EMAIL PROTECTED]> wrote:
> >> Collin Winter wrote:
> >>> PEP: 3133
> >>> Title: Introducing Roles
> >> Everything included here is included in zope.interface. See in-line
> >> comments below fo
Guido van Rossum wrote:
> On 5/14/07, Benji York <[EMAIL PROTECTED]> wrote:
>> Collin Winter wrote:
>>> PEP: 3133
>>> Title: Introducing Roles
>> Everything included here is included in zope.interface. See in-line
>> comments below for the analogs.
>
> Could you look at PEP 3119 and do a similar
Hi Collin,
Sorry did not mean to hurt your feelings.
On 5/17/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> I speak three languages. It's insulting to allege that my opposition
> to this proposal is somehow based in English-language cultural
> imperialism or some other politically-correct nonsens
On 5/16/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Walter Doerwald, in private mail, reminded me of a third use case for
> > raw strings: docstrings containing example code using backslashes.
> > Here it really seems wrong to interpol
On 5/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Walter Doerwald, in private mail, reminded me of a third use case for
> raw strings: docstrings containing example code using backslashes.
> Here it really seems wrong to interpolate \u and \U.
>
> So this is swaying me towards changing this
2007/5/16, Collin Winter <[EMAIL PROTECTED]>:
> On 5/15/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> > Just to let you know that a discussion on japanese python users group
> > is going on regarding this issue.
> >
> > Most people feel like the PEP3131 would be a welcome addition.
> > -> some p
On 5/16/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 5/16/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > -> unittest - very useful to give a better overview of the result of
> > > unit test. People pointed us at a Visual C# MVP tutorial
> > > http://www.atmarkit.co.jp/fdotnet/nagile/na
On 5/16/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > -> unittest - very useful to give a better overview of the result of
> > unit test. People pointed us at a Visual C# MVP tutorial
> > http://www.atmarkit.co.jp/fdotnet/nagile/nagile02/nagile02_03.html
>
> I don't know what "a better overvie
On 5/16/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/15/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> > Just to let you know that a discussion on japanese python users group
> > is going on regarding this issue.
> >
> > Most people feel like the PEP3131 would be a welcome addition.
> > ->
On 5/16/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Hi Collin,
>
> You express the same frustration than people who can't read English.
> You feel the same than Japanese people faced with an impenetrable wall
> of English...
Presumably people who don't speak English aren't provided
English-la
On 5/16/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> > Found some evidence of usage of identifiers in Japanese while doing a
> > quick google search
> >
> > All links below are in Japanese.
>
> I have absolutely no way of evaluating the con
On 5/14/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Found some evidence of usage of identifiers in Japanese while doing a
> quick google search
>
> All links below are in Japanese.
I have absolutely no way of evaluating the content of these links.
Testimonials that I can't read are less than
On 5/15/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Just to let you know that a discussion on japanese python users group
> is going on regarding this issue.
>
> Most people feel like the PEP3131 would be a welcome addition.
> -> some people point out the fact that special characters like the
Walter Doerwald, in private mail, reminded me of a third use case for
raw strings: docstrings containing example code using backslashes.
Here it really seems wrong to interpolate \u and \U.
So this is swaying me towards changing this behavior: r"\u1234" will
be a string of length 6, and r"\U000123
Since no PEP has been submitted about eliminating __del__, __del__
remains, by default, in Python 3000. I am more comfortable with this
anyway.
However, I still welcome an informational PEP describing the "best
practices" for avoiding it by using weak references, including some
support code to be
After the warm user testimonials posted in the last few days I am now
warming up to this proposal. Hearing about how it has been a positive
influence in certain local Java communities was especially useful.
--Guido
On 5/15/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Just to let yo
Collin Winter wrote:
MyABC.register(list)
isinstance([], MyABC)
> True # Good, I can call foo()
[].foo()
> Traceback (most recent call last):
> AttributeError: 'list' object has no attribute 'foo'
>
> Have I missed something? It would seem that when dealing with ABCs
> that provide
Guido van Rossum wrote:
> **Open issues:** Conceivably, instead of using the ABCMeta metaclass,
> these classes could override ``__instancecheck__`` and
> ``__subclasscheck__`` to check for the presence of the applicable
> special method; for example::
>
> class Sized(metaclass=ABCMeta):
>
44 matches
Mail list logo
