On Tue, 12 Jun 2007, Stephen J. Turnbull wrote:
> It seems to me that rather than *impose* restrictions on third
> parties, the sensible thing to do is to provide those restrictions to
> those who want them.
Hang on a second. No one is *imposing* new restrictions. Python
uses ASCII-only identifi
On Tue, 12 Jun 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> Also, that all identifiers are ASCII is not sufficient
> for you to be able to debug the program in case of need: it also
> needs to be commented well, and the comments also should be in
> a language you understand. Furthermore, it has be
On Sun, 10 Jun 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > That describes me perfectly. I am self-interested to
> > the extent that my employers just pay me to write
> > working Python code, so I want the simplicity of ASCII
> > only.
>
> What I don't understand is why you can't simply continu
Steve Howell wrote:
> I think this whole debate could be put to rest by
> agreeing to err on the side of ascii in 3.0 beta, and
> if in real world experience, that turns out to be the
> wrong decision, simply fix it in 3.0 production, 3.1,
> or 3.2.
On Sun, 10 Jun 2007, [ISO-8859-1] "Martin v. L?w
> > A. Should identifiers be allowed to contain any Unicode letter?
>
> Not an open issue; the PEP has been accepted.
The items listed under "A." are concerns that I wanted to be noted
in the PEP, so thanks for listing them.
> > B. Should the default behaviour accept only ASCII identifiers, or
>
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
On Tue, 29 May 2007, [UTF-8] Ivan Krsti?^G wrote:
> Guido van Rossum wrote:
> > What would that do?
>
> It would split on all separators in the tuple, so
>
> x.split(("\r", "\n"))
>
> would do the same thing that x.splitlines() does now.
Hmm... would it? Or should two split points with nothin
On Mon, 28 May 2007, Stephen J. Turnbull wrote:
> Now, identifiers are by definition character streams. If an English
> speaker would pronounce the spelling of an English word "A B C", and
> an Arabic speaker an Arabic word as "1 2 3", then *as an identifier*
> the combination English then Arabic
On Sun, 27 May 2007, Ryan Freckleton wrote:
> I've been following the python-dev and python 3000 lists for over a
> year, but this is my first posting.
Hello!
> I think I've found additional abstract base class to add to PEP 3119.
> An ABC for composable data (e.g. list, tuple, set, and perhaps d
On Sat, 26 May 2007, Michael Urman wrote:
> On 5/26/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > But the enabling of UTF-8 by a BOM at the
> > beginning of the file is an invisible override. This invisible
> > override is the source of the danger. If we want to be
On Fri, 25 May 2007, Blake Winton wrote:
> Jim Jewett wrote:
> > Arbitrary Unicode identifier opens up the possibility of code that
> > *looks* like ASCII, but isn't -- so I don't even realize that I missed
> > something.
>
> You already have that problem. Right now. And you've had it for at
>
Ka-Ping Yee wrote:
> Alas, the coding directive is not good enough. Have a look at this:
>
> http://zesty.ca/python/tricky.png
>
> That's an image of a text editor containing some Python code. Can you
> tell whether running it (post-PEP-3131) will delete your .bashrc
On Fri, 25 May 2007, Blake Winton wrote:
> Ka-Ping Yee wrote:
> > Let's see what we can find. I made several attempts to search for
> > non-ASCII identifiers using google.com/codesearch and here's what I got.
>
> I think you've got a selection bias here, since
On Sat, 26 May 2007, Greg Ewing wrote:
> Ka-Ping Yee wrote:
> > NFKC might be a better choice than NFC for normalizing identifiers.
> > Do we really want "find()" (with the fi-ligature) and "find()"
> > (without the fi-ligature) to be two different f
NFKC might be a better choice than NFC for normalizing identifiers.
Do we really want "find()" (with the fi-ligature) and "find()"
(without the fi-ligature) to be two different functions?
Martin, is there a reason to prefer NFC over NFKC?
-- ?!ng
___
P
On Thu, 24 May 2007, Stephen J. Turnbull wrote:
> > You've got this backwards, and I suspect that's part of the root of
> > the disagreement. It's not that "when humans enter the loop they
> > cause problems." The purpose of the language is to *serve humans*.
[...]
> N.B. I take offense at you
On Fri, 25 May 2007, Josiah Carlson wrote:
> Apples and oranges to be sure, but there are no other statistics that
> anyone else is able to offer about use of non-ascii identifiers in Java,
> Javascript, C#, etc.
Let's see what we can find. I made several attempts to search for
non-ASCII identifi
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> People should not have to read long system configuration pages
> just to run the program that they intuitively wrote correctly
> right from the start.
It is not intuitive. One thing I learned from the discussion here
about Unicode ident
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> I don't think there is precedence in Python for such an informational
> error message.
SyntaxError: Non-ASCII character '\xd1' in file foo.py on line 2, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for
details
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > I think there are things that can be done here, even
> > if we make Python's default mode to be ascii-pure.
> > Regional distros can set the environment
> > appropriately. Python error messages about non-ascii
> > characters can sugges
On Fri, 25 May 2007, [UTF-8] "Martin v. L??wis" wrote:
> Ka-Ping Yee schrieb:
> > On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L???wis" wrote:
> > People who want to use the feature can turn it on. I don't see what's
> > so unreasonable about
On Thu, 24 May 2007, Guido van Rossum wrote:
> If there's a security argument to be made for restricting the alphabet
> used by code contributions (even by co-workers at the same company), I
> don't see why ASCII-only projects should have it easier than projects
> in other cultures.
This keeps get
Guillaume Proux wrote:
> It is my understanding that the only remaining objection for unicode
> in identifier is for claimed security issues.
You're missing much of the debate. Please read this message:
http://mail.python.org/pipermail/python-3000/2007-May/007855.html
Steve Howell wrote:
>
On Fri, 25 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> Please *do* consider the needs of the people who want to actively
> use the feature as well. Otherwise, you have no chance of understanding
> what will make everyone happy.
People who want to use the feature can turn it on. I don't see
On Thu, 24 May 2007, Stephen J. Turnbull wrote:
> I'll tell you why Ka-Ping's argument is a strawman. First, one only
> *needs* to be able to distinguish those characters that one can read.
> It's nice to be able to admire the rest, of course, but you don't need
> to see them as a speaker of that
On Thu, 24 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > Much of my concerns could be addressed through the use of commandline,
> > environment variable, or in-source code definitions of what are
> > allowable identifier characters.
[...]
> Not sure (anymore) what problem you are trying to so
On Thu, 24 May 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> > That's not true. In the Unicode BMP fallback font, you can easily
> >> differentiate all Unicode characters (in the BMP):
> >>
> >> http://scripts.sil.org/UnicodeBMPFallbackFont
> >
> > Er... somehow I don't think that's what Martin had
On Thu, 24 May 2007, Jim Jewett wrote:
> So how about
>
> (1) By default, python allows only ASCII.
> (2) Additional characters are permitted if they appear in a table
> named on the command line.
>
> These additional characters should be restricted to code points larger
> than ASCII (so you can'
On Wed, 23 May 2007, Stephen J. Turnbull wrote:
> > It means users could see the usability benefits of PEP3131, but the
> > python internals could still work with ASCII only.
>
> But this reasoning is not coherent. Python internals will have no
> problems with non-ASCII; in fact, they would have
On Wed, 23 May 2007, Ka-Ping Yee wrote:
> So there are three sets of characters that look the same:
>
> U+02BB = U+0312 = U+2018
> U+02BC = U+0313 = U+0315 = U+2019
> U+02EE = U+201D
The Greek combining koronis, U+0343, is an allowed identifier
character and also looks
On Wed, 23 May 2007, Guido van Rossum wrote:
> On 5/23/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Certain cut-and-paste errors (such as cutting from a word document
> > that uses "smart quotes") will change from syntax errors to silently
> > creating new identifiers.
>
> Really? Are those quote
On Wed, 23 May 2007, Ian D. Bollinger wrote:
> Ka-Ping Yee wrote:
> > 2. Python will become vulnerable to a new class of security
> > exploits via the writing of misleading or malicious code
> > that is visually indistinguishable from correct code.
> &
I can see that I don't stand a very high chance of convincing you.
But I'd like to make sure you understand what I'm getting at, anyway.
(And I will get to some specific suggestions at the end of this
message.)
The key thing is that the language definition is about to transition
from something whi
On Tue, 22 May 2007, Leonardo Santagada wrote:
> > Today, if a non-English speaker asks you how to learn Python, you can
> > answer that question. You can explain Python's syntax and semantics,
> > and tell them they need to know the 26 letters of the Roman alphabet.
> Have you ever explained that
On Thu, 17 May 2007, Guido van Rossum wrote:
> I have accepted PEP 3131.
I'm surprised that this happened so quickly. I oppose this proposal
quite strongly.
Currently Python has the property that the character set is a fully
known quantity. There currently exists a choice of keyboard, a choice
I fully support the removal of implicit string concatenation
(explicit is better than implicit; there's only one way to do it).
I also fully support the removal of backslashes for line continuation
of statements (same reasons). (I mean this as distinct from line
continuation within a string; that
On Mon, 12 Mar 2007, Greg Ewing wrote:
> Changing __main__ to match would seem to be a
> good idea.
[...]
> There might be merit in renaming __builtins__
> to something less confusable, at the expense of
> breaking existing code which refers to it.
Cool.
> I don't think it would be such a good
For a long time __builtin__ and __builtins__ have mystified me.
Usually I end up guessing -- in any given namespace, one of the
two will exist, and it will either be a module or a dictionary --
but I never committed to memory which name or type to expect.
A little investigation reveals:
In mo
On Tue, 6 Mar 2007, Collin Winter wrote:
> I'd like to strike the part about making "x.next()" ->
> "next(x)"/"x.__next__()" determined by the presence of a module-level
> "next" binding. I'd rather see the transformation always be "x.next()"
> -> "next(x)" and warn on top-level "next"s. Doing it t
On Wed, 7 Mar 2007, Georg Brandl wrote:
> Ka-Ping Yee schrieb:
> > On Tue, 6 Mar 2007, Guido van Rossum wrote:
> >> Having now read this entire thread I am going to accept Ping's PEP.
> >> Adding the sentinel argument to the next() builtin was what did it for
>
On Tue, 6 Mar 2007, Guido van Rossum wrote:
> Having now read this entire thread I am going to accept Ping's PEP.
> Adding the sentinel argument to the next() builtin was what did it for
> me: it neatly solves the problem if having to catch that StopIteration
> in 99% of the cases.
Okay, this is c
On Mon, 5 Mar 2007, Greg Falcon wrote:
> I agree that file.read() is a different beast than iter.next().
> However, file.write() is a counterexample to your argument here. It
> gets called by Python syntax, and yet doesn't (and shouldn't) have
> double underscores.
>
> >>> print >> object(), "foo"
On Tue, 6 Mar 2007, Neil Schemenauer wrote:
> The argument that all "protocol" methods should have double
> underscore names seems to be pretty weak too. It's only an appeal
> for consistency, I think. We don't suggest that file-like objects
> should implement __read__() instead of read(), for ex
On Mon, 5 Mar 2007, Josiah Carlson wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> However, I have written methods named 'next' which have *nothing* to do
> with the iterator protocol.
This is exactly why the iterator protocol metho
On Mon, 5 Mar 2007 [EMAIL PROTECTED] wrote:
> And, more importantly, it is butt-ugly.
What part exactly? Does this bother you:
def __next__(self):
...
or this:
while whatever:
x = next(i)
...
They look pretty much like the rest of Python to me.
-- ?!ng
__
On Mon, 5 Mar 2007 [EMAIL PROTECTED] wrote:
> Can I suggest that next() and __next__() be dropped entirely
> and that iterators just be made callable.
We went through a long discussion about this when iterators
were being figured out the first time around -- in fact, using
__call__ was the origina
One possibility for making a next() built-in more useful:
Just like getattr, two-argument next(iter, sentinel)
returns sentinel if StopException is caught.
If you've used .next() explicitly, would this be handy?
(Or, what convenience would you want in a next() builtin?)
-- ?!ng
___
At Guido's prompting, I drafted the following PEP. How does it sound?
-- ?!ng
Title: Renaming iterator.next() to iterator.__next__()
==
Abstract
The iterator protocol in Python 2.x consists of two methods:
``__iter__()`` called on
On 3/4/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> FWIW, I would like the feature to be kept. I've found it useful in that it
> documents the function signature more completely when dealing
> with arguments that are already pre-packed into tuples
I just noticed that this has a more noticea
On Fri, 2 Mar 2007, Brett Cannon wrote:
> the removal of the automatic unpacking of sequence
> arguments when a tuple parameter is present in a function's signature
> (e.g., the ``(b, c)`` in ``def fxn(a, (b, c), d): pass``).
As I think most people know by now, it makes me quite sad to see these
g
Hi Guido,
I'm in your keynote and looking at a slide right now that says
* bytes has .encode() method returning a string
* str has a .decode() method returning bytes
Should the names of those two methods be swapped? I think it
makes more sense to say that an encoding is something that
t
On 1/3/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>Or perhaps translate blocks of the form:
>
> except ExcType, e:
> # body
>
>to:
>
> except ExcType, e:
> try:
> # body
> finally:
> del e
That's much nicer! (I feel silly now for n
On Wed, 3 Jan 2007, Adam Olsen wrote:
> That can be solved by moving the weakref to the stack frame -> exc
> part, and only turning it from a strong reference into a weak
> reference when the function exits. When debugging via the raised
> exception, the chain of __context__ references would keep
On Wed, 6 Dec 2006, Jan Grant wrote:
[regarding string interpolation]
> I think it's a terrible idea in almost every form.
[...]
> The reason _why_ I think it's such a bad idea is the above statement
> just doesn't gel with practical experience. Google will find plenty of
> reading material if you
On Mon, 4 Dec 2006, Ben Wing wrote:
> how about something nice like
>
> maybe_errout(i"[title], line [lineno]: [errstr]\n")
See PEP 215.
http://www.python.org/dev/peps/pep-0215/
-- ?!ng
___
Python-3000 mailing list
Python-3000@python.org
http://ma
I've committed PEP 3104 to the SVN repository. It should appear at
http://www.python.org/dev/peps/pep-3104/
shortly. The PEP is updated to add a note on the amount of code
breakage in the standard library that we might expect for some of
the possible keywords we might choose. The updated v
On Sat, 4 Nov 2006, Nick Coghlan wrote:
> Count me as another +1 on disallowing the shorthand version.
>
> Rationale:
> 1. We've lived without it in the case of global
> 2. We can add it later if we decide we really need it, but if we
> start with it and it turns out to be confusing or error-prone,
On Mon, 6 Nov 2006, Andrew McNamara wrote:
> >Python, C/C++, JavaScript, Ruby, and Perl all have this in common:
> >
> >A "global variable" is visible to the entire file and does
> >not belong to any particular function.
>
> I note that you didn't say "a global variable is visible to the en
On Sun, 5 Nov 2006, Ka-Ping Yee wrote:
> nonlocal 0 0
> use 2 2
> using 3 3
> reuse 0 4
> free 8 8
> outer 5 147
> global 126 214
Oops, i forgot to explain
As an aside to the discussion about "nonlocal", here are a couple of
thoughts on backward compatibility.
For some of the proposed keywords, here's the number of occurrences
of the keyword in the current standard library (not including comments
and docstrings):
nonlocal 0 0
use
On Thu, 2 Nov 2006, Andrew McNamara wrote:
> >The global scope is the widest scope in which you can declare a variable.
>
> This is inaccurate at best.
No, my statement is correct. What you are disputing is not what i wrote:
The global scope is the widest scope in which you can declare a variabl
On Fri, 3 Nov 2006, Antoine Pitrou wrote:
> Le vendredi 03 novembre 2006 à 15:19 -0600, Ka-Ping Yee a écrit :
> > I suppose that's fine. Also i guess
> >
> > nonlocal x = y = 0
>
> That's ambiguous.
> Is only "x" nonlocal, or are both "x
On Thu, 2 Nov 2006, Christian Tanzer wrote:
> As you allow
>
> nonlocal x, y, z
>
> and
>
> x, y, z = 1, 2, 3
>
> is legal Python (and does the right thing), why not allow
>
> nonlocal x, y, z = 1, 2, 3
>
> too?
>
> That's one less rule needed to be learned and enforced.
I suppose that
On Fri, 3 Nov 2006, Neil Toronto wrote:
> Is there any particular reason this *must* be a Py3k PEP? (Aside from
> the fact that we're discussing it on the Py3k list, of course.) Some of
> the solutions discussed for historical context would *definitely* be bad
> ideas for a 2.x (as would changing t
On Fri, 3 Nov 2006, Greg Ewing wrote:
> > Before it is reasonable to change the meaning of "global", we would
> > need to have coherent answers to these questions:
> >
> > 1. What is the global namespace?
>
> Under the proposal, there is no such thing as
> "the" global namespace, so the questi
Before it is reasonable to change the meaning of "global", we would
need to have coherent answers to these questions:
1. What is the global namespace?
2. Do global variables belong to the global namespace?
3. When it says "global x" does that mean x is a global variable?
I think
On Thu, 2 Nov 2006, Fredrik Lundh wrote:
> Talin wrote:
>
> > If you change the behavior of 'global' to be the same as 'nonlocal' as
> > has been proposed, then this effectively becomes impossible - you can no
> > longer set any global that hasn't already been pre-declared.
>
> of course you can, a
I wrote:
> I'm convinced that "global variable" means top-level for most
> programmers and so this usage would be confusing -- but i think we're
> all just repeating what we've said before.
Andrew McNamara wrote:
> But it doesn't mean "top-level" - it already comes with the qualifier
> "module".
Ka-Ping Yee wrote:
> Would it help at all to survey some folks to see how many interpret
> "global variable" to mean "top-level" vs. "anything nonlocal"?
Steven Bethard wrote:
> I don't think that'll really be worth it. I'd be amazed if peo
Guido wrote:
> My personal preference is still to abuse 'global' instead of adding a
> new, ugly keyword. That would make the syntax for global and nonlocal
> completely identical. :-) But I seem to be alone in this preference.
Brett wrote:
> Seeing Guido have a sad face is enough to force me to h
Hi again.
I've updated the PEP to incorporate some suggestions i received.
This revision also adds a Ruby example, a quote from 1994, a
security argument, and and an additional error case (attempting
to declare a parameter name nonlocal). Thanks, everyone!
http://zesty.ca/python/pep-3104.txt
I wrote:
> I have finally completed a draft of a PEP on rebinding of names
[...]
> http://zesty.ca/python/pep-3104.txt
I've turned this into HTML also, in case you find that easier to read:
http://zesty.ca/python/pep-3104.html
-- ?!ng
___
Pyth
Hi folks,
I have finally completed a draft of a PEP on rebinding of names
in outer scopes. I've tried to go back and gather all of the
(amazingly numerous) proposals -- if i've forgotten or misattributed
any, let me know and i'll be happy to correct them.
I look forward to your thoughts on it:
On Wed, 18 Oct 2006, Talin wrote:
> Seriously, though - this is actually my way of saying that this thread
> has gone too long...what are we hoping to accomplish here? Are you
> really going to re-name PyPI or cheeseshop or whatever you want to call
> it, or are folks just trying to score points? E
On Mon, 16 Oct 2006, Talin wrote:
> Agreed - I don't have any problems with Cheeseshop as it exists today.
I think a good search feature is essential -- a big code repository
is only as useful to the degree that its contents are accessible.
I don't want to hurt anyone's feelings, but i think the
Nick Coghlan wrote:
> Re-using 'global' wasn't popular because it would actually be
> *wrong* for the new semantics
On Wed, 11 Oct 2006, Greg Ewing wrote:
> I don't agree that it's wrong -- it's perfectly
> legitimate to regard "local" and "global" as
> relative terms, i.e. anything not local to y
On Tue, 10 Oct 2006, Fredrik Lundh wrote:
> Nick Coghlan wrote:
> > Any proposal such as this also needs to addresses all of the *other* name
> > binding statements in Python:
> >
> >try/except
> >for loop
> >with statement
> >def statement
> >class statement
> +import state
On Sun, 16 Jul 2006, Nick Coghlan wrote:
> Taking the "import system" to be the overall interaction between the
> Python module namespace and the file system of the underlying computer,
> I thought I'd start compiling a list of the questions we'll want to
> consider for Py3k.
I'd like to add "relo
On Sat, 8 Jul 2006, Calvin Spealman wrote:
> Just throwing this out there, but I would love to see a complete
> dropping of container literals from Python. That is why I proposed the
> coercion syntax (ex: list from something) because it would allow
> things like list(1, 2, 3) and we can already do
On Wed, 5 Jul 2006, Guido van Rossum wrote:
> So, my proposal is to give up on static, accept PEP 3103 with the
> following options:
> - Syntax alternative 2+B (unindented cases, 'case in ...' for
> multiple cases).
> - Semantics option 3 (def-time freezing)
>
> Do we need any more discussi
82 matches
Mail list logo
