hello
i would like to add that even for a french user, it would be good
to have the possibility to use non ascii identifiers.
take the simple problem of the difference between "action to do"
and "action done".
In english, most of the time, adding 'ed' to the verb will do
the difference: change -
> One point that was raised by Alex Martelli is that the full set of
> Unicode 'letter' characters includes many characters which are visually
> indistinguishable in every font in the world. It means that, from now
> on, when I look at the variable named 'a', I can no longer be sure that
> what
> If so, it looks like it might be possible to give
> Python a fork() that works on Windows, at least for
> the time being.
It's quite a challenge. That call just creates a process,
and not thread. You need to invoke many more API calls
to make the process actually run.
For some reason (which I c
On 5/13/07, Talin <[EMAIL PROTECTED]> wrote:
> The fact that programming languages resemble a particular human language
> is a pedagogical convenience, but it need not be so, and wasn't always
> that way.
"Crucial usability feature", not "pedagogical convenience".
Choosing good names for things i
Hi Jason,
Very interesting post. I will just make a little comment.
On 5/13/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Python should allow foreign-language identifiers because (1) it's a
> gesture of good will to people everywhere who don't speak English
> fluently; (2) some students will
> S 3123 Making PyObject_HEAD conform to standard C von Löwis
>
> I like it, but who's going to make the changes? Once those chnges have
> been made, will it still be reasonable to expect to merge C code from
> the (2.6) trunk into the 3.0 branch?
I just created bugs.python.org/1718153, whic
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> - Expect pushback on your assumption that every function or method
> should be fair game for overloading. Requiring explicit tagging the
> base or default implementation makes things a lot more palatable and
> predictable for those of us who are sti
Jason Orendorff 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?
I don't think you're missing anything.
I th
On 5/12/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
[snip]
> In this respect, I strongly believe that support non-ASCII identifiers
> as proposed by PEP3131 would improve a number of things:
> - discussion and uptake of python in "non-ascii" countries
> - ability for children to learn programmin
[Guillaume Proux]
> In this respect, I strongly believe that support non-ASCII identifiers
> as proposed by PEP3131 would improve a number of things:
> - discussion and uptake of python in "non-ascii" countries
> - ability for children to learn programming in their own language (I
> started program
On May 13, 2007, at 11:22 AM, Collin Winter wrote:
> See, that's the thing I have yet to see addressed: there's been lot of
> stress on "being able to write variable/class/method names in
> Arabic/Mandarin/Hindi will make it easier for native speakers to
> understand", but as far as I know, no-on
On Sun, May 13, 2007, "Martin v. L?wis" wrote:
>
> There are other, more serious cases of presentation ambiguity
> (e.g. tabs vs. spaces), yet nobody suggests to ban tabs from the
> language for that reason.
Well, I do. ;-)
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft
At 04:31 PM 5/13/2007 +0200, Christian Tanzer wrote:
>"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> > - Expect pushback on your assumption that every function or method
> > should be fair game for overloading. Requiring explicit tagging the
> > base or default implementation makes things a lot
Hello,
On 5/14/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Says you. So far, all I've seen from PEP 3131's supporters is a lot of
> hollow assertions and idle theorizing: "Python will be easier to use
> for people using non-ASCII character sets", "Python will be easier to
> learn for those rais
Dear Tomer,
> well, i myself am a native hebrew speaker, so i'm quite sensitive
> to text-direction issues with all sorts of editors. to this day, i haven't
> seen a single editor that handles RTL/LTR transitions correctly,
> including microsoft word.
Are you talking about editor bugs? You should
On 5/13/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> [Tomer Filiba]
> > when you start mixing LTR and RTL texts, it's asking for trouble:
> > שם_משפחה = "doe"
> > גיל = 5
> >
> > shem_mishpacha = "doe"
> > 5 = gil # looks reversed, but it's actually correct (!!)
> >
> > so that basically rule
"tomer filiba" <[EMAIL PROTECTED]> wrote:
>
> with the new class decorators of py3k, new use cases emerge.
> for example, now it is easy to have real mixin classes or even
> mixin modules, a la ruby.
[snip]
> does it seem useful? should it be included in some stdlib?
> or at least mentioned as a
On Sunday 13 May 2007, Josiah Carlson wrote:
> About the only thing that I think would be nice is if we could get class
> decorators in 2.6 as well (a future import would work for me).
Since class decorators don't introduce a new keyword, there'd be no need for a
future import. Something that'
On 5/13/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> No no no no no. This isn't a problem with the editor: it's a problem
> with allowing Hebrew identifiers. Tomer can correct me on this, but I
> strongly doubt that it improves readability by forcing the programmer
> to constantly change which d
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 that is really a *presentation* issue. And as such, an editor
specia
> Have there been studies on this kind of thing? Has there been any
> research into whether a mixture of English keywords and, say, Japanese
> and English identifiers makes a given programming language easier to
> learn and use? If so, why aren't they referenced in the PEP or linked
> in any emails
some personnal thoughts on the subject, pro, of course:
1) it's a matter of justice:
everybody should have the right to name his variables
with the exact name he prefers.
2) it's a matter of equity:
why would only english speakers able to write programs?
(and even english uses accents in numero
This occurred to me while reading the PEP 3131 discussion, and while
it's not limited to PEP 3131 concerns, I don't believe I've seen
discussed yet elsewhere. What is the interaction between import or
__import__ and Unicode module names (or at least Unicode strings
describing them). Currently in py
I'm okay with applying to 2.6 and then merging into 3.0. ISTM though
that backporting this to 2.5 would cause the release manager to throw
a fit, so I think that's not worth it. What would be the benefit
anyway?
--Guido
On 5/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > S 3123 Makin
On 5/13/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Have there been studies on this kind of thing? Has there been any
> research into whether a mixture of English keywords and, say, Japanese
> and English identifiers makes a given programming language easier to
> learn and use? If so, why aren't
The answer to all of this is the filesystem encoding, which is already
supported. Doesn't appear particularly difficult to me.
On 5/13/07, Michael Urman <[EMAIL PROTECTED]> wrote:
> This occurred to me while reading the PEP 3131 discussion, and while
> it's not limited to PEP 3131 concerns, I don'
Collin Winter wrote:
>So far, all I've seen from PEP 3131's supporters is a lot of
> hollow assertions and idle theorizing: "Python will be easier to use
> for people using non-ASCII character sets", "Python will be easier to
> learn for those raised with non-Roman-influenced languages", etc, e
Guido van Rossum escreveu:
> In particular, AFAIK Java has allowed all Unicode letters in
> identifiers right from the start. I'd like to hear about descriptions
> of actual user experiences with this feature, in Java or in any other
> language that supports it. (*Are* there any others?) That would
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| That's a red herring.
That is how I felt when you dismissed my effort to make your proposal more
useful and more acceptable to some (by addressing transliteration) with the
little molehill problem that Norwegians
Jason Orendorff a écrit :
>
> Python should allow foreign-language identifiers because (1) it's a
> gesture of good will to people everywhere who don't speak English
> fluently; (2) some students will benefit; (3) some people writing code
> that no one else will ever see will benefit.
>
As I sa
I just did a ``make distclean`` on a clean checkout (r55300) and
test_compiler/test_transformer are failing:
File "/Users/drifty/Dev/python/3.x/pristine/Lib/compiler/transformer.py",
line 715, in atom
return self._atom_dispatch[nodelist[0][0]](nodelist)
KeyError: 322
or
File "/Users/drifty
Dear all,
On 5/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> of actual user experiences with this feature, in Java or in any other
> language that supports it. (*Are* there any others?) That would be far
> more valuable to me than any continued argumentation for or against
> the proposal.
test_compiler and test_transformer have been broken for a couple of
months now I believe.
Unless someone comes to the rescue of the compiler package soon, I'm
tempted to remove it from the p3yk branch -- it doesn't seem to serve
any particularly good purpose, especially now that the AST used by th
On 5/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
test_compiler and test_transformer have been broken for a couple of
months now I believe.
Unless someone comes to the rescue of the compiler package soon, I'm
tempted to remove it from the p3yk branch -- it doesn't seem to serve
any partic
Pierre Hanser wrote:
> In english, most of the time, adding 'ed' to the verb will do
> the difference: change -> changed
>
> in french: change -> changé (ends with 'eacute')
Fine if the reader understands French, but if you
later want to translate this program so that a
non-French speaker ca
On 5/13/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > of actual user experiences with this feature, in Java or in any other
> > language that supports it. (*Are* there any others?) That would be far
> > more valuable to me than any cont
On 5/14/07, Anders J. Munch <[EMAIL PROTECTED]> wrote:
You haven't brought any hard evidence to the table yourself, so in
the absense of that, my anecdotal evidence trumps your pure
speculation ;-)
Fact: Younger brains learn new concepts (and languages) faster than older
ones.
Argument: To be
Martin v. Löwis wrote:
> There are other, more serious cases of presentation ambiguity
> (e.g. tabs vs. spaces), yet nobody suggests to ban tabs from the
> language for that reason.
But we *have* suggested banning mixed tabs and spaces
(rather than just recommending against it), which is
something
Hello,
> > Interestingly, this is *not* a well known fact. I have asked 2
> > friend-of-mine seasoned Java programmers and they were *amazed* that
> > this is supported.
> Well, maybe we should add it to Python as a secret feature. :-) :-) :-)
But they also said that:
1) they wish they would have
I respectfully disagree with the conclusion you draw from the same
data. I don't think either of us can say anything that will satisfy
the other.
--Guido
On 5/13/07, Guillaume Proux <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > > Interestingly, this is *not* a well known fact. I have asked 2
> > > fr
On 5/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The answer to all of this is the filesystem encoding, which is already
> supported. Doesn't appear particularly difficult to me.
Okay, that's fair. It seems reasonable to accept the limitations of
following the filesystem encoding for modul
Guido van Rossum schrieb:
> I'm okay with applying to 2.6 and then merging into 3.0. ISTM though
> that backporting this to 2.5 would cause the release manager to throw
> a fit, so I think that's not worth it. What would be the benefit
> anyway?
I think you misunderstood. If this is applied to 2.
> I don't think this scenario is all that unlikely. A
> program is initially written by a Russian programmer
> who uses his own version of "a" as a variable name.
> Later an English-speaking programmer makes some
> changes, and uses an ascii "a". Now there are two
> subtly different variables calle
Greg Ewing a écrit :
> Pierre Hanser wrote:
>
>> In english, most of the time, adding 'ed' to the verb will do
>> the difference: change -> changed
>>
>> in french: change -> changé (ends with 'eacute')
>
> Fine if the reader understands French, but if you
> later want to translate this progr
PEP: 3133
Title: Introducing Roles
Version: $Revision$
Last-Modified: $Date$
Author: Collin Winter <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Requires: 3115, 3129
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 3.0
Post-History: 13-May-2007
Abstract
Python's ex
On 5/13/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> PEP: 3133
> Title: Introducing Roles
[snip]
> * Roles provide a way of indicating a object's semantics and abstract
> capabilities. A role may define abstract methods, but only as a
> way of delineating an interface through which a particu
46 matches
Mail list logo
