On Thu, 13 Jun 2013 01:23:27 +, Steven D'Aprano wrote:
Python does have a globally-global namespace. It is called builtins, and
you're not supposed to touch it. Of course, being Python, you can if you
want, but if you do, you are responsible for whatever toes you shoot off.
Modifying
list = []
Reading further, one sees that the function works with two lists, a list of
file names, unfortunately called 'list',
That is very good advice in general: never choose a variable name
that is a keyword.
--
MarkJ
Tacoma, Washington
--
On Tue, Jun 11, 2013 at 1:30 PM, rusi rustompm...@gmail.com wrote:
Or by example:
def foo(x)...
def bar(x,y)...
there is no reason to confuse the two xes.
Whereas
x = ...
def foo(x)...
Now there is!
The first should be encouraged, the second discouraged.
Again, there can be good
On 2013-06-11, Mark Janssen dreamingforw...@gmail.com wrote:
list = []
Reading further, one sees that the function works with two lists, a list of
file names, unfortunately called 'list',
That is very good advice in general: never choose a variable name
that is a keyword.
You can't
On Wed, Jun 12, 2013 at 7:24 AM, Grant Edwards invalid@invalid.invalid wrote:
On 2013-06-11, Mark Janssen dreamingforw...@gmail.com wrote:
list = []
Reading further, one sees that the function works with two lists, a list of
file names, unfortunately called 'list',
That is very good
On Thu, Jun 13, 2013 at 5:40 AM, Mark Janssen dreamingforw...@gmail.com wrote:
On Wed, Jun 12, 2013 at 7:24 AM, Grant Edwards invalid@invalid.invalid
wrote:
On 2013-06-11, Mark Janssen dreamingforw...@gmail.com wrote:
list = []
Reading further, one sees that the function works with
You're right. I was being sloppy.
['ArithmeticError', 'AssertionError', 'AttributeError',
'BaseException', 'BlockingIOError', 'BrokenPipeError', 'BufferError',
'BytesWarning', 'ChildProcessError', 'ConnectionAbortedError',
'ConnectionError', 'ConnectionRefusedError', 'ConnectionResetError',
On Thu, Jun 13, 2013 at 9:07 AM, Mark Janssen dreamingforw...@gmail.com wrote:
You're right. I was being sloppy.
Okay, now I'm a bit confused. print is both a keyword and a
member of the builtins. What happens then?
Ah! I see where we are getting confused. When you said keyword, did
you
This has caused more trouble than it has solved.
I take it you have never programmed in a programming language with a
single, flat, global namespace? :-)
Hey, the purpose a programming language (i.e. a language which has a
consistent lexical specification), is to provide some modicum of
Okay, now I'm a bit confused. print is both a keyword and a
member of the builtins. What happens then?
It's a keyword in Python 3, a built-in function in Python = 3:
~% python3
Python 3.4.0a0 (default:96f08a22f562, Feb 24 2013, 23:37:53)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
On Thu, Jun 13, 2013 at 10:04 AM, Mark Janssen
dreamingforw...@gmail.com wrote:
Really?
int=five
[int(i) for i in [1,2,3]]
TypeError: str is not callable
Now how are you going to get the original int type back?
Either del it from your module namespace, or use the qualified name:
On Thu, Jun 13, 2013 at 10:26 AM, Mark Janssen
dreamingforw...@gmail.com wrote:
There's no point forcing them to be looked up in a two-step process.
If you want that, you can simply reference them as
__builtins__.whatever, but you can instead just reference them as the
unadorned name whatever.
int=five
[int(i) for i in [1,2,3]]
TypeError: str is not callable
Now how are you going to get the original int type back?
Magic. :-)
int = five
int(a)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'str' object is not callable
from __builtin__ import int
The builtins don't need to be imported, but they're identifiers like
anything else. They're a namespace that gets searched after
module-globals.
Yes, I understand, though for clarity and separability, it seems that
having them in a namespace that gets explicitly pulled into the global
space is
On Thu, Jun 13, 2013 at 10:18 AM, Skip Montanaro s...@pobox.com wrote:
Magic. :-)
int = five
int(a)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'str' object is not callable
from __builtin__ import int as _int
_int(5)
5
Not sure of the magic necessary
On Thu, 13 Jun 2013 09:53:26 +1000, Chris Angelico wrote:
In Python 2.x, 'print' is actually a keyword. It has its own special
syntax (eg printing to something other than stdout), and absolutely
cannot be overridden:
Except that you can:
from __future__ import print_function
Just to make
On 06/12/2013 05:04 PM, Mark Janssen wrote:
Steven D'Aprono wrote:
Apart from Erlang, got any other examples? Because it seems to me that in
languages with nested scopes or namespaces, shadowing higher levels is
exactly the right thing to do.
Really?
-- int=five
-- [int(i) for i in [1,2,3]]
On Wed, 12 Jun 2013 17:04:48 -0700, Mark Janssen wrote:
Apart from Erlang, got any other examples? Because it seems to me that
in languages with nested scopes or namespaces, shadowing higher levels
is exactly the right thing to do.
Really?
int=five
[int(i) for i in [1,2,3]]
TypeError:
On Thu, 13 Jun 2013 10:08:14 +1000, Chris Angelico wrote:
int=five
[__builtins__.int(i) for i in [1,2,3]]
Don't use __builtins__, it's an implementation detail.
In Python 2.x, there is __builtins__ with an s in the global namespace
if you are running CPython, but not necessarily other
On Wed, 12 Jun 2013 17:26:43 -0700, Mark Janssen wrote:
The builtins don't need to be imported, but they're identifiers like
anything else. They're a namespace that gets searched after
module-globals.
Yes, I understand, though for clarity and separability, it seems that
having them in a
On Thu, Jun 13, 2013 at 11:08 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Thu, 13 Jun 2013 10:08:14 +1000, Chris Angelico wrote:
int=five
[__builtins__.int(i) for i in [1,2,3]]
Don't use __builtins__, it's an implementation detail.
In Python 2.x, there is
On 6/10/2013 10:56 PM, Steven D'Aprano wrote:
I was initially confused
and reading the code still takes a small bit of extra mental energy.
Idle stays confused and will wrongly color the list instance name until
it is changed. Calling the file list 'fnames' or 'filenames' would have
been
Terry Jan Reedy wrote:
Many long-time posters have advised Don't rebind built-in names*.
I'm in that camp, but I think this old post by Guido van Rossum is worth
reading to put the matter into perspective:
That was probably a checkin I made. I would have left it alone except the
code was
On Jun 11, 12:09 pm, Peter Otten __pete...@web.de wrote:
Terry Jan Reedy wrote:
Many long-time posters have advised Don't rebind built-in names*.
I'm in that camp, but I think this old post by Guido van Rossum is worth
reading to put the matter into perspective:
Not sure what you are saying
rusi wrote:
On Jun 11, 12:09 pm, Peter Otten __pete...@web.de wrote:
Terry Jan Reedy wrote:
Many long-time posters have advised Don't rebind built-in names*.
I'm in that camp, but I think this old post by Guido van Rossum is worth
reading to put the matter into perspective:
Not sure
On Tue, 11 Jun 2013 04:12:38 -0700, rusi wrote:
[...]
then what the message of the Guido-quote is, is not clear (at least to
me).
The relevant part is in the bit that you deleted. Let me quote it for you
again:
locals hiding built-ins is okay
-- Guido van Rossum, inventor and BDFL of
On 11 June 2013 01:14, Terry Jan Reedy tjre...@udel.edu wrote:
Many long-time posters have advised Don't rebind built-in names*.
For instance, open Lib/idlelib/GrepDialog.py in an editor that colorizes
Python syntax, such as Idle's editor, jump down to the bottom and read up,
and (until it is
On Monday, June 10, 2013 9:56:43 PM UTC-5, Steven D'Aprano wrote:
On Mon, 10 Jun 2013 20:14:55 -0400, Terry Jan Reedy wrote:
For instance, open Lib/idlelib/GrepDialog.py in an editor that colorizes
Python syntax, such as Idle's editor, jump down to the bottom and read
up, and (until it is
On Tuesday, June 11, 2013 8:34:55 AM UTC-5, Steven D'Aprano wrote:
GvR is saying that it's okay to use the names of built-in functions or
types as the names of local variables, even if that causes the built-in
to be inaccessible within that function.
Looks like we've finally found the
11.06.13 06:02, Steven D'Aprano написав(ла):
On Mon, 10 Jun 2013 19:36:44 -0700, rusi wrote:
And so languages nowadays tend to 'protect' against this feature.
Apart from Erlang, got any other examples?
C#? At least local variable can't shadow other local variable in outer
scope (and it
On 2013-06-11, Mark Janssen dreamingforw...@gmail.com wrote:
list = []
Reading further, one sees that the function works with two lists, a list of
file names, unfortunately called 'list',
That is very good advice in general: never choose a variable name
that is a keyword.
Btw,
On 11/06/2013 16:43, Rick Johnson wrote:
On Tuesday, June 11, 2013 8:34:55 AM UTC-5, Steven D'Aprano wrote:
GvR is saying that it's okay to use the names of built-in functions or
types as the names of local variables, even if that causes the built-in
to be inaccessible within that function.
On Tue, 11 Jun 2013 08:22:19 -0700, Rick Johnson wrote:
On Monday, June 10, 2013 9:56:43 PM UTC-5, Steven D'Aprano wrote:
On Mon, 10 Jun 2013 20:14:55 -0400, Terry Jan Reedy wrote:
Reading further, one sees that the function works with two lists, a
list of file names, unfortunately called
On Wed, Jun 12, 2013 at 1:22 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
PS: Is that D in last name short for DevilsAdvocate? Steven
DevilsAdvocate Prano.
I don't think so. Somehow it seems unlikely that he'll argue for you.
ChrisA
--
Many long-time posters have advised Don't rebind built-in names*.
* Unless you really mean to mask it, or more likely wrap it, such as
wrapping print to modify some aspect of its operation than one cannot do
with its keyword parameters. The point for this post is that such
wrapping modify or
list = []
Reading further, one sees that the function works with two lists, a list of
file names, unfortunately called 'list',
That is very good advice in general: never choose a variable name
that is a keyword.
Btw, shouldn't it be illegal anyway? Most compilers don't let you do
On 2013-06-10 17:20, Mark Janssen wrote:
list = []
Reading further, one sees that the function works with two
lists, a list of file names, unfortunately called 'list',
That is very good advice in general: never choose a variable name
that is a keyword.
Btw, shouldn't it be
There's a subtle difference between a keyword and a built-in. Good
Python style generally avoids masking built-ins but allows it:
Right, thank you for reminding me. My C-mind put them in the same category.
--
MarkJ
Tacoma, Washington
--
http://mail.python.org/mailman/listinfo/python-list
On Jun 11, 5:53 am, Mark Janssen dreamingforw...@gmail.com wrote:
There's a subtle difference between a keyword and a built-in. Good
Python style generally avoids masking built-ins but allows it:
Right, thank you for reminding me. My C-mind put them in the same category.
--
MarkJ
On Jun 11, 5:14 am, Terry Jan Reedy tjre...@udel.edu wrote:
Many long-time posters have advised Don't rebind built-in names*.
* Unless you really mean to mask it, or more likely wrap it, such as
wrapping print to modify some aspect of its operation than one cannot do
with its keyword
On Mon, 10 Jun 2013 17:20:58 -0700, Mark Janssen wrote:
list = []
Reading further, one sees that the function works with two lists, a
list of file names, unfortunately called 'list',
That is very good advice in general: never choose a variable name that
is a keyword.
Btw,
On Mon, 10 Jun 2013 20:14:55 -0400, Terry Jan Reedy wrote:
For instance, open Lib/idlelib/GrepDialog.py in an editor that colorizes
Python syntax, such as Idle's editor, jump down to the bottom and read
up, and (until it is patched) find
list.append(fn)
with 'list'
On Mon, 10 Jun 2013 19:36:44 -0700, rusi wrote:
Pascal introduced the idea of block structure -- introduce a name at one
level, override it at a lower level. [Ok ALgol introduced, Pascal
popularized].
This has caused more trouble than it has solved.
I take it you have never programmed in a
On Jun 11, 8:02 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 10 Jun 2013 19:36:44 -0700, rusi wrote:
Pascal introduced the idea of block structure -- introduce a name at one
level, override it at a lower level. [Ok ALgol introduced, Pascal
popularized].
This
On Tue, Jun 11, 2013 at 1:02 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Apart from Erlang, got any other examples? Because it seems to me that in
languages with nested scopes or namespaces, shadowing higher levels is
exactly the right thing to do. Certainly it would be a
On Mon, 10 Jun 2013 20:30:41 -0700, rusi wrote:
Certainly it would be a PITA, and defeat the purpose of having nested
scopes, if inner names had to be globally unique. Wouldn't it be
absolutely horrible if adding a global variable foo[1] suddenly meant
that all your functions that used foo as
46 matches
Mail list logo
