Re: [Python-Dev] [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII

2011-05-10 Thread Victor Stinner 
Le lundi 09 mai 2011 à 22:18 -0500, Michael Urman a écrit :
> On Mon, May 9, 2011 at 20:08, Neil Hodgson  wrote:
> >   Yes, Windows will use UTF-16 as it does for almost everything. From
> > a user's point of view, these should both just be seen as Unicode.
> 
> I'm not convinced this is correct for this case. GetProcAddress takes
> an "ANSI" string, meaning while it could theoretically use UTF-8, in
> practice I doubt it uses anything outside of ASCII safely.

If GetProcAddress() expects a byte string encoded to the ANSI code page,
my patch is correct because the function used the UTF-8 encoding, not
the ANSI code page. We can maybe use GetProcAddressW() to pass a Unicode
string. I don't know which encoding is used by GetProcAddressW()...

I already patched _PyImport_GetDynLoadFunc() for Windows: the path is
now a Unicode object instead of a byte string encoded to the filesystem
encoding. _PyImport_GetDynLoadWindows() uses GetFullPathNameW() and
LoadLibraryExW(). The work to be fully Unicode compliant (for the path
field, not for the name) is not completly done... but I have a pending
patch, see:
http://bugs.python.org/issue11619

But this patch is huge and creates many functions. I am not sure that we
need it, I will work on this later.

Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #12039: Add end_headers() call to avoid BadStatusLine.

2011-05-10 Thread Senthil Kumaran 
On Tue, May 10, 2011 at 10:10:15AM +0200, vinay.sajip wrote:
> diff --git a/Lib/test/test_logging.py b/Lib/test/test_logging.py
> --- a/Lib/test/test_logging.py
> +++ b/Lib/test/test_logging.py
> @@ -1489,6 +1489,7 @@
>  except:
>  self.post_data = None
>  request.send_response(200)
> +request.end_headers()
>  self.handled.set()

This is accurate. It should have resulted from the change made in the
http.server, because the headers are now cached and then written to
the output stream in one-shot when end_headers/flush_headers are
called. 

Thanks,
Senthil

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Commit changelog: issue number and merges

2011-05-10 Thread Aurélien Campéas 

Le 10/05/2011 04:51, Stephen J. Turnbull a écrit :

R. David Murray writes:
  >  On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson 
 wrote:

  >  >  *cough* http://mercurial.selenic.com/wiki/GraphlogExtension
  >
  >  I'm sorry, but I've looked at the output of that and the mental overhead
  >  has so far proven too high for it to be of any use to me.

How about the hgk extension, and "hg view"?

http://mercurial.selenic.com/wiki/HgkExtension



or, FWIW, "hgview" (http://www.logilab.org/project/hgview)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Commit messages: please avoid temporal ambiguity

2011-05-10 Thread Nick Coghlan 
On Tue, May 10, 2011 at 5:36 AM, Eric Smith  wrote:
> Thanks indeed for bringing this up, Terry. It's been on my to-do list
> for a while. I think it comes from just copying the title of a bug
> report. The bug is "X does Y", and that's what's used in the fix.

I believe I've actually seen it in NEWS entries as well (although
thankfully not often and I can't recall any specific instances off the
top of my head).

I'm also a fan of including the word "now" and describing the new
behaviour, although I'll sometimes use "no longer" and describe the
old behaviour for some bugs where that seems more appropriate.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Borrowed and Stolen References in API

2011-05-10 Thread Nick Coghlan 
On Tue, May 10, 2011 at 11:53 AM, Marvin Humphrey
 wrote:
> With regards to "what actually happens to the reference count", I would argue
> that "incremented" and "decremented" are accurate descriptions.
>
>  * When a function returns an "incremented" object, that function has added
>    a refcount to it.

Except that's not quite true in cases like PySet_Pop(). In that case,
the net effect on the refcount is neutral. The significant point is
that the set no longer holds a reference, it has passed that
responsibility back to the caller.

> In my view, it is not desirable to label arguments or return values as
> "borrowed"; it is only necessary to advise the user when they must take action
> to account for a refcount, gained or lost.

Agreed on this part, though. Callers need to know when:

1. The return value is a new reference that must be decremented
(currently indicated in the docs by "Return value: New reference")
2. An input parameter transfers responsibility for the reference to
the callee (the only example I noticed in the docs is PyList_SetItem,
which uses an explicit note rather than any kind of markup or the
refcount data)

I believe the current refcount data covers the first case reasonably
well, but not the latter (and still has the problem of being separated
from the documentation of the functions themselves).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Commit changelog: issue number and merges

2011-05-10 Thread R. David Murray 
On Tue, 10 May 2011 11:51:19 +0900, "Stephen J. Turnbull"  
wrote:
> R. David Murray writes:
>  > On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson 
>  wrote:
> 
>  > > *cough* http://mercurial.selenic.com/wiki/GraphlogExtension
>  > 
>  > I'm sorry, but I've looked at the output of that and the mental overhead
>  > has so far proven too high for it to be of any use to me.
> 
> How about the hgk extension, and "hg view"?

I think the problem is in my brain, not the graphical tools :)  With rare
exceptions I don't use tools that require a mouse to operate, though,
so unless I feel like doing tcl hacking to make good keyboard bindings
that particular tool won't help me anyway.

>  > But as I think about this, frankly I'd rather see atomic commits, even
>  > on merges.  That was something I disliked about svnmerge, the fact that
>  > often an svnmerge commit involved many changesets from the other branch.
>  > That was especially painful in exactly the same situation:  trying to
>  > backtrack a change starting from 'svn blame'.
> 
> I don't understand the issue.  In my experience, hg annotate will
> point to the commit on the branch, not to the merge, unless there was
> a conflict, in which case the merge is the "right" place (although not
> necessarily the most useful place) to point.

That's what I get for reasoning about hg based on my svn experience.
Someone on IRC also pointed this out.  I haven't done this often
enough in HG for the difference to have penetrated my brain.  I have
a feeling I'm still going to get confused occasionally, but then
I'm sure I did with svn too...

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Commit changelog: issue number and merges

2011-05-10 Thread Nick Coghlan 
On Tue, May 10, 2011 at 12:51 PM, Stephen J. Turnbull
 wrote:
> R. David Murray writes:
>  > On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson 
>  wrote:
>
>  > > *cough* http://mercurial.selenic.com/wiki/GraphlogExtension
>  >
>  > I'm sorry, but I've looked at the output of that and the mental overhead
>  > has so far proven too high for it to be of any use to me.
>
> How about the hgk extension, and "hg view"?
>
> http://mercurial.selenic.com/wiki/HgkExtension

I don't think it's really a jump up to the "graphical" level that
we're after. It's more a matter of:

1. Display commit message for current commit
2. Notice that this commit has two parents
3. Ignore any parent commit in the same branch as the current commit
4. For a parent commit in another branch, also display that commit message
5. If the commit in step 4 also has multiple parents, repeat from step
3 (but based off that parent commit)

So a standard 3.1->3.2->default merge could be displayed along the lines of:

Merge from 3.2
  3.2: Merge from 3.1
3.1: Issue #123456: mod.func now works correctly when argument is negative

It won't help if the last commit on the initial branch was something
boring like "Fix whitespace", but it will be adequate for our typical
single-commit bug fix workflow.

(If nobody does anything before then, I'll see what I can do with the
email hook next week)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread R. David Murray 
On Tue, 10 May 2011 08:36:38 +0300, Eli Bendersky  wrote:
> With an unlimited error message length it could make sense to say "Hey, I
> see 'x' may be assigned in this scope, so I mark it local. But this access
> to 'x' happens before assignment - so ERROR". This isn't realistic, of
> course, so I'm wondering:
> 
> 1. Does this error message (although unrealistic) capture all possible
> appearances of UnboundLocalError?
> 2. If the answer to (1) is yes - could it be usefully shortened to be
> clearer than the current "local variable referenced before assignment"?
> 
> This may not be possible, of course, but it doesn't harm trying :-)

How about:

"reference to variable 'y' precedes an assignment that makes it a local
variable"

IMO this still leaves room for confusion, but is better because it
indicates the causation more clearly.  (I don't think it is necessary to
capture the subtlety of conditional assignment in the error message.)

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Commit messages: please avoid temporal ambiguity

2011-05-10 Thread R. David Murray 
On Tue, 10 May 2011 22:29:58 +1000, Nick Coghlan  wrote:
> On Tue, May 10, 2011 at 5:36 AM, Eric Smith  wrote:
> > Thanks indeed for bringing this up, Terry. It's been on my to-do list
> > for a while. I think it comes from just copying the title of a bug
> > report. The bug is "X does Y", and that's what's used in the fix.
> 
> I believe I've actually seen it in NEWS entries as well (although
> thankfully not often and I can't recall any specific instances off the
> top of my head).
> 
> I'm also a fan of including the word "now" and describing the new
> behaviour, although I'll sometimes use "no longer" and describe the
> old behaviour for some bugs where that seems more appropriate.

I generally don't use the same text for commit and NEWS, because I like
to stick to one-liners for the first line of the commit, possibly with
more detail in the body, while for NEWS items I'm aiming for a one to
three line description.  But in both cases what I'm thinking about is
"what have I *changed*".  In the commit message that will probably focus
more on code changes, while the NEWS item will focus more on behavior
changes, but the results are generally similar.

So for example my most recent two comments look like this:

commit:
11999: sync based on comparing mtimes, not mtime to system clock
NEWS:
Issue 11999: fixed sporadic sync failure mailbox.Maildir due to its
trying to detect mtime changes by comparing to the system clock
instead of to the previous value of the mtime.

commit:
#11873: Improve test regex so random directory names don't cause test to 
fail
NEWS:
Issue #11873: Change regex in test_compileall to fix occasional
failures when when the randomly generated temporary path happened to
match the regex.

You will note the *active* verbs "fixed", "improve", and "change"
figure in there prominently :)

(Eh.  And proofreading this email I see I made a grammar error in
that first NEWS example :(

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII

2011-05-10 Thread Michael Urman 
On Tue, May 10, 2011 at 03:03, Victor Stinner
 wrote:
> If GetProcAddress() expects a byte string encoded to the ANSI code page,
> my patch is correct because the function used the UTF-8 encoding, not
> the ANSI code page. We can maybe use GetProcAddressW() to pass a Unicode
> string. I don't know which encoding is used by GetProcAddressW()...

While I can find references to a GetProcAddressW, most of them seem to
agree it doesn't exist. "My kernel32.dll only exports GetProcAddress."
This suggests to me it accepts a null-terminated bytestring instead of
specifically an ANSI string. What data ends up in the export table is
likely similar to the linux filesystem case, only with less likelihood
of the environment telling you its encoding.

> I already patched _PyImport_GetDynLoadFunc() for Windows: the path is
> now a Unicode object instead of a byte string encoded to the filesystem
> encoding. _PyImport_GetDynLoadWindows() uses GetFullPathNameW() and
> LoadLibraryExW(). The work to be fully Unicode compliant (for the path
> field, not for the name) is not completly done... but I have a pending
> patch, see:
> http://bugs.python.org/issue11619
>
> But this patch is huge and creates many functions. I am not sure that we
> need it, I will work on this later.

I'm comfortable with the idea of requiring UTF-8 encoding for the
initmodule entry points of modules named with non-ASCII identifiers,
especially if there is nothing which works consistently today. I've
only seen pure-ASCII library names in all my C++ work, so I feel it
borders on YAGNI (but I like it in theory).

As an alternate approach, one article I read suggested to use ordinals
instead of names if you wanted to use non-ASCII names. Python could
certainly try to load by ordinal on Windows, and fall back to loading
by name. I don't have a clue what the rate of false positives would
be.

-- 
Michael Urman
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Commit messages: please avoid temporal ambiguity

2011-05-10 Thread Oleg Broytman 
On Tue, May 10, 2011 at 09:33:13AM -0400, R. David Murray wrote:
> commit:
> 11999: sync based on comparing mtimes, not mtime to system clock
> NEWS:
> Issue 11999: fixed sporadic sync failure mailbox.Maildir due to its
> trying to detect mtime changes by comparing to the system clock
> instead of to the previous value of the mtime.
> 
> commit:
> #11873: Improve test regex so random directory names don't cause test to 
> fail
> NEWS:
> Issue #11873: Change regex in test_compileall to fix occasional
> failures when when the randomly generated temporary path happened to
> match the regex.
> 
> You will note the *active* verbs "fixed", "improve", and "change"
> figure in there prominently :)

   Why "fixed" is in the past tense, but "improve", and "change" are in
present tense?

   I use past tense to describe what I did on the code, and present
simple to describe what the new code does when running. For example:

"Fixed a bug in time comparison: compare mtime to mtime, not mtime to system 
clock"

   I.e., "fixed" - that what I did, and "compare" is what the code does.

(I used an excerpt from above only for the example, not to correct
something.)

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread Eli Bendersky 
On Tue, May 10, 2011 at 16:11, R. David Murray wrote:

> On Tue, 10 May 2011 08:36:38 +0300, Eli Bendersky 
> wrote:
> > With an unlimited error message length it could make sense to say "Hey, I
> > see 'x' may be assigned in this scope, so I mark it local. But this
> access
> > to 'x' happens before assignment - so ERROR". This isn't realistic, of
> > course, so I'm wondering:
> >
> > 1. Does this error message (although unrealistic) capture all possible
> > appearances of UnboundLocalError?
> > 2. If the answer to (1) is yes - could it be usefully shortened to be
> > clearer than the current "local variable referenced before assignment"?
> >
> > This may not be possible, of course, but it doesn't harm trying :-)
>
> How about:
>
> "reference to variable 'y' precedes an assignment that makes it a local
> variable"
>  


Yes, this is much better and not too long IMHO
Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Commit messages: please avoid temporal ambiguity

2011-05-10 Thread R. David Murray 
On Tue, 10 May 2011 17:45:44 +0400, Oleg Broytman  wrote:
> On Tue, May 10, 2011 at 09:33:13AM -0400, R. David Murray wrote:
> > commit:
> > 11999: sync based on comparing mtimes, not mtime to system clock
> > NEWS:
> > Issue 11999: fixed sporadic sync failure mailbox.Maildir due to its
> > trying to detect mtime changes by comparing to the system clock
> > instead of to the previous value of the mtime.
> > 
> > commit:
> > #11873: Improve test regex so random directory names don't cause test 
> > to fail
> > NEWS:
> > Issue #11873: Change regex in test_compileall to fix occasional
> > failures when when the randomly generated temporary path happened to
> > match the regex.
> > 
> > You will note the *active* verbs "fixed", "improve", and "change"
> > figure in there prominently :)
> 
>Why "fixed" is in the past tense, but "improve", and "change" are in
> present tense?
> 
>I use past tense to describe what I did on the code, and present
> simple to describe what the new code does when running. For example:
> 
> "Fixed a bug in time comparison: compare mtime to mtime, not mtime to system 
> clock"
> 
>I.e., "fixed" - that what I did, and "compare" is what the code does.
> 
> (I used an excerpt from above only for the example, not to correct
> something.)

Yes, that's a good point.  I'll try to be more consistent about that
in the future.  Change should have been Changed.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread Nick Coghlan 
On Tue, May 10, 2011 at 11:11 PM, R. David Murray  wrote:
> How about:
>
> "reference to variable 'y' precedes an assignment that makes it a local
> variable"

For comparison, the error messages I was able to elicit from 2.7 were
as follows:

# Module level
NameError: name 'bob' is not defined

# Function level reference to implicit global
NameError: global name 'bob' is not defined

# Early reference to local
UnboundLocalError: local variable 'bob' referenced before assignment

# Early reference from closure
NameError: free variable 'bob' referenced before assignment in enclosing scope

Personally, I would just add "in current scope" to the existing error
message for the unbound local case (and potentially collapse the
exception hierarchy a bit by setting UnboundLocalError = NameError).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread R. David Murray 
On Wed, 11 May 2011 00:59:08 +1000, Nick Coghlan  wrote:
> On Tue, May 10, 2011 at 11:11 PM, R. David Murray  w=
> rote:
> > How about:
> >
> > "reference to variable 'y' precedes an assignment that makes it a local
> > variable"
> 
> For comparison, the error messages I was able to elicit from 2.7 were
> as follows:
> 
> # Module level
> NameError: name 'bob' is not defined
> 
> # Function level reference to implicit global
> NameError: global name 'bob' is not defined
> 
> # Early reference to local
> UnboundLocalError: local variable 'bob' referenced before assignment
> 
> # Early reference from closure
> NameError: free variable 'bob' referenced before assignment in enclosing sc=
> ope
> 
> Personally, I would just add "in current scope" to the existing error
> message for the unbound local case (and potentially collapse the
> exception hierarchy a bit by setting UnboundLocalError = NameError).

I don't think adding that phrase would add any clarity, myself.
The mental disconnect comes from the fact that the UnboundLocal error
message is emitted for the reference, but it is not immediately obvious
*why* the variable is considered local.  My rephrasing emphasizes that it
is the assignment statement that led to that classification and therefore
the error.  This disconnect doesn't apply in the global cases.  It applies
less strongly in the free variable case because there is visibly another
scope involved (that is, the triggering assignment isn't in the same
scope as the reference producing the error message).

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread Terry Reedy 

On 5/10/2011 10:59 AM, Nick Coghlan wrote:

On Tue, May 10, 2011 at 11:11 PM, R. David Murray  wrote:

How about:

"reference to variable 'y' precedes an assignment that makes it a local
variable"


For comparison, the error messages I was able to elicit from 2.7 were
as follows:

# Module level
NameError: name 'bob' is not defined

# Function level reference to implicit global
NameError: global name 'bob' is not defined

# Early reference to local
UnboundLocalError: local variable 'bob' referenced before assignment


I would change this to
"local name 'bob' used before the assignment that makes it a local name"

Calling names 'variables' is itself a point of confusion.


# Early reference from closure
NameError: free variable 'bob' referenced before assignment in enclosing scope

Personally, I would just add "in current scope" to the existing error
message for the unbound local case (and potentially collapse the
exception hierarchy a bit by setting UnboundLocalError = NameError).

Cheers,
Nick.




--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread R. David Murray 
On Tue, 10 May 2011 13:56:58 -0400, Terry Reedy  wrote:
> On 5/10/2011 10:59 AM, Nick Coghlan wrote:
> > On Tue, May 10, 2011 at 11:11 PM, R. David Murray  
> > wrote:
> >> How about:
> >>
> >> "reference to variable 'y' precedes an assignment that makes it a local
> >> variable"
> >
> > For comparison, the error messages I was able to elicit from 2.7 were
> > as follows:
> >
> > # Module level
> > NameError: name 'bob' is not defined
> >
> > # Function level reference to implicit global
> > NameError: global name 'bob' is not defined
> >
> > # Early reference to local
> > UnboundLocalError: local variable 'bob' referenced before assignment
> 
> I would change this to
> "local name 'bob' used before the assignment that makes it a local name"
> 
> Calling names 'variables' is itself a point of confusion.

Yes, your phrasing is much better.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread Eli Bendersky 


> > > # Early reference to local
> > > UnboundLocalError: local variable 'bob' referenced before assignment
> >
> > I would change this to
> > "local name 'bob' used before the assignment that makes it a local name"
> >
> > Calling names 'variables' is itself a point of confusion.
>
> Yes, your phrasing is much better.
>

+1
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread Steven D'Aprano 

Nick Coghlan wrote:


Personally, I would just add "in current scope" to the existing error
message for the unbound local case (and potentially collapse the
exception hierarchy a bit by setting UnboundLocalError = NameError).


-0

That was the case prior to Python 2.0. Reverting is potentially a 
semantic change that will break any code that distinguishes between 
(global) NameError and (local) UnboundLocalError. But personally, I 
don't know why it was thought necessary to distinguish between them in 
the first place.





--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] more timely detection of unbound locals

2011-05-10 Thread Fred Drake 
On Tue, May 10, 2011 at 6:38 PM, Steven D'Aprano  wrote:
> I don't know why it was thought necessary to distinguish between them in the
> first place.

New users almost constantly expressed confusion by NameError when the name
was clearly bound at global scope, and a subsequent assignment caused it to be
considered a local in their function.


  -Fred

-- 
Fred L. Drake, Jr.    
"Give me the luxuries of life and I will willingly do without the necessities."
   --Frank Lloyd Wright
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com