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.
>
> Modify
On Thu, Jun 13, 2013 at 11:08 AM, Steven D'Aprano
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 __builtins__ with an "s"
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
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 necessa
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
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",
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 Thu, Jun 13, 2013 at 10:18 AM, Skip Montanaro wrote:
> Magic. :-)
>
int = "five"
int("a")
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'str' object is not callable
from __builtin__ import int as _int
_int("5")
> 5
>
> Not sure of the magic neces
> 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
>>> 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 "", line 1, in
TypeError: 'str' object is not callable
>>> from __buil
On Thu, Jun 13, 2013 at 10:26 AM, Mark Janssen
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. They contribute h
On Thu, Jun 13, 2013 at 10:04 AM, Mark Janssen
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:
>>> int="five
> Okay, now I'm a bit confused. "print" is both a 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
T
>> 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
s
On Thu, Jun 13, 2013 at 9:07 AM, Mark Janssen wrote:
>>> You're right. I was being sloppy.
> Okay, now I'm a bit confused. "print" is both a and a
> member of the builtins. What happens then?
Ah! I see where we are getting confused. When you said keyword, did
you mean keyword, a person who ha
>> You're right. I was being sloppy.
>
> ['ArithmeticError', 'AssertionError', 'AttributeError',
> 'BaseException', 'BlockingIOError', 'BrokenPipeError', 'BufferError',
> 'BytesWarning', 'ChildProcessError', 'ConnectionAbortedError',
> 'ConnectionError', 'ConnectionRefusedError', 'ConnectionResetE
On Thu, Jun 13, 2013 at 5:40 AM, Mark Janssen wrote:
> On Wed, Jun 12, 2013 at 7:24 AM, Grant Edwards
> wrote:
>> On 2013-06-11, Mark Janssen wrote:
list = []
Reading further, one sees that the function works with two lists, a list of
file names, unfortunately called 'lis
On Wed, Jun 12, 2013 at 7:24 AM, Grant Edwards wrote:
> On 2013-06-11, 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
On 2013-06-11, 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.
You can't choose a vriable
On Tue, Jun 11, 2013 at 1:30 PM, rusi 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 reason for it
> 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
--
http://mail.python.org/mailman/listinf
On Wed, Jun 12, 2013 at 1:22 AM, Rick Johnson
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
--
http://mail.python.org/mailman/listinfo/python-list
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
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.
L
On 2013-06-11, 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 i
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 look
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 tra
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 i
On 11 June 2013 01:14, Terry Jan Reedy 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 patched) f
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
rusi wrote:
> On Jun 11, 12:09 pm, Peter Otten <[email protected]> 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:
>
On Jun 11, 12:09 pm, Peter Otten <[email protected]> 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 ar
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
> cod
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 clearer
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 us
On Tue, Jun 11, 2013 at 1:02 PM, Steven D'Aprano
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 PITA, and defeat
> the purpose of ha
On Jun 11, 8:02 am, Steven D'Aprano 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 has caused more trouble than it
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
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' c
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.
On Jun 11, 5:14 am, Terry Jan Reedy 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 parameters. The poi
On Jun 11, 5:53 am, Mark Janssen 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
> Tacoma, Washington
Don
> 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 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,
>> 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 le
45 matches
Mail list logo
