Re: For the code to generate `zen of python'.

On 07/08/2019 15.11, Hongyi Zhao wrote: > Hi here, > > I noticed that the `zen of python' is generated by the following code: > > d = {} > for c in (65, 97): > for i in range(26): > d[chr(i+c)] = chr((i+13) % 26 + c) > > print("".join([d.get

Re: For the code to generate `zen of python'.

g encoded characters to their decoded equivalents. Decoding is done by adding 13 to the ASCII value of the letter (wrapping round from 25 back to 0). That's about it, really. Paul On Wed, 7 Aug 2019 at 14:17, Hongyi Zhao wrote: > > Hi here, > > I noticed that the `zen of pytho

For the code to generate `zen of python'.

Hi here, I noticed that the `zen of python' is generated by the following code: d = {} for c in (65, 97): for i in range(26): d[chr(i+c)] = chr((i+13) % 26 + c) print("".join([d.get(c, c) for c in s])) But the above code is not so easy for me to figure out. Could

Re: Zen of Python “obvious way to do it” (was: [TSBOAPOOOWTDI]using names from modules)

On Sun, 5 Nov 2017 12:49 pm, Ben Finney wrote: > Steve D'Aprano writes: > >> On Sun, 5 Nov 2017 06:42 am, Stefan Ram wrote: >> >> > What is the one way to do it? >> >> There is no philosophy of "one way to do it" in Python, that is a >> misunderstanding (possibly deliberate...) spread about by P

Zen of Python “obvious way to do it” (was: [TSBOAPOOOWTDI]using names from modules)

contrast Python from Perl's "more than one way to do it". > > The Zen of Python says: > > There should be one-- and preferably only one --obvious way to do it. > > > The emphasis is on "obvious", not "one". There should be *at least* &g

Re: class-private names and the Zen of Python

On 10/08/2013 06:24 AM, Steven D'Aprano wrote: On Tue, 08 Oct 2013 12:13:48 +0200, Marco Buttu wrote: In the following case: >>> class Foo: ... _Foo__a = 100 ... __a = 33 ... >>> Foo._Foo__a 33 I think this behavior, for a user who does not know the convention, could be a surprise

Re: class-private names and the Zen of Python

On 10/09/2013 01:00 AM, Oscar Benjamin wrote: > On Tue, 08 Oct 2013 12:13:48 +0200, Marco Buttu wrote: > > > Another question is: where is the place in which this transformation > > occurs? Is it at the parser level, before the dictionary attribute is > > gave as argument to the metaclass?

Re: class-private names and the Zen of Python

On Oct 8, 2013 2:26 PM, "Steven D'Aprano" < steve+comp.lang.pyt...@pearwood.info> wrote: > > On Tue, 08 Oct 2013 12:13:48 +0200, Marco Buttu wrote: > > > Another question is: where is the place in which this transformation > > occurs? Is it at the parser level, before the dictionary attribute is >

Re: class-private names and the Zen of Python

On 10/8/13 7:15 AM, Marco Buttu wrote: Also, as Terry mentions, no one has ever assigned the two names you show, Sincerely, I can not now if someone has assigned (or will assegne) in such way... If you explain more about what you are building, and where this crops up as a problem, we can

Re: class-private names and the Zen of Python

On Tue, 08 Oct 2013 12:13:48 +0200, Marco Buttu wrote: > In the following case: > > >>> class Foo: > ... _Foo__a = 100 > ... __a = 33 > ... > >>> Foo._Foo__a > 33 > > I think this behavior, for a user who does not know the convention, > could be a surprise. Yes, you are correct. It s

Re: class-private names and the Zen of Python

On 10/08/2013 01:07 PM, Ned Batchelder wrote: On 10/8/13 6:13 AM, Marco Buttu wrote: >>> class Foo: ... _Foo__a = 100 ... __a = 33 ... >>> Foo._Foo__a 33 ... You also get a "problem" if you do this: >>> class Foo: ... a = 100 ... a = 33 ... >>> Foo.a

Re: class-private names and the Zen of Python

On 10/8/13 6:13 AM, Marco Buttu wrote: In the following case: >>> class Foo: ... _Foo__a = 100 ... __a = 33 ... >>> Foo._Foo__a 33 I think this behavior, for a user who does not know the convention, could be a surprise. Should be raising an exception (in order to inform the user the t

Re: class-private names and the Zen of Python

On 10/08/2013 12:36 PM, Terry Reedy wrote: On 10/8/2013 6:13 AM, Marco Buttu wrote: In the following case: >>> class Foo: ... _Foo__a = 100 ... __a = 33 ... >>> Foo._Foo__a 33 I think this behavior, for a user who does not know the convention, could be a surprise. No one qualified

Re: class-private names and the Zen of Python

On 10/8/2013 6:13 AM, Marco Buttu wrote: In the following case: >>> class Foo: ... _Foo__a = 100 ... __a = 33 ... >>> Foo._Foo__a 33 I think this behavior, for a user who does not know the convention, could be a surprise. No one qualified to use such names would do such a thing , so

class-private names and the Zen of Python

In the following case: >>> class Foo: ... _Foo__a = 100 ... __a = 33 ... >>> Foo._Foo__a 33 I think this behavior, for a user who does not know the convention, could be a surprise. Should be raising an exception (in order to inform the user the transformation of the name __a have been

Re: Zen of Python

In article <[EMAIL PROTECTED]>, Tim Peters <[EMAIL PROTECTED]> wrote: >[Paul Rubin] >> >> And you can break out of a containing loop from a nested loop >> with try/raise. > >Heh heh. Yes, you can. I've never seen a real Python program that >did, but there's nothing to stop you. What did you th

Re: Zen of Python

[Tim Peters] >> But at that time, Python didn't have lexical scoping, and it wasn't >> clear that it ever would. So what's the bigger wart? Making >> listcomps exactly equivalent to an easily-explained Python for-loop >> nest, or introducing a notion of lexical scope unique to listcomps, >> hard

Re: Zen of Python

"Andrew Koenig" <[EMAIL PROTECTED]> writes: > Actually, I don't think so. If you intend for it to be impossible for "z = > x" to refer to the x in the list comprehension, you shouldn't mind putting > in "from __future__ import lexical_comprehensions." If you don't intend for > it to be impossi

Re: Zen of Python

"Paul Rubin" wrote in message news:[EMAIL PROTECTED] > It's not obvious to me how the compiler can tell. Consider: > >x = 3 >if frob(): > frobbed = True > squares = [x*x for x in range(9)] >if blob(): > z = x > > Should the compiler issue

Re: Zen of Python

"Andrew Koenig" <[EMAIL PROTECTED]> writes: > In this case, I think the right solution to the problem is two-fold: > > 1) from __future__ import lexical_comprehensions > > 2) If you don't import the feature, and you write a program that depends > on a list-comprehension variable rema

Re: Zen of Python

"Paul Rubin" wrote in message news:[EMAIL PROTECTED] > It's really irrelevant whether anyone is using a feature or not. If > the feature is documented as being available, it means that removing > it is an incompatible change that can break existing code which > current

Re: Zen of Python

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > in some early C++ compilers, the scope for "x" was limited to the scope > containing the for loop, not the for loop itself. some commercial > compilers > still default to that behaviour. Indeed--and the standards com

Re: Zen of Python

On 21 Jan 2005 20:32:46 -0800, Paul Rubin wrote: >Of course in that case, since the absence of lexical scope was a wart >in its own right, fixing it had to have been on the radar. So turning >the persistent listcomp loop var into a documented feature, instead of >descri

Re: Zen of Python

Alex Martelli wrote: >> I do remember seeing some cute tricks (i.e. capable of becoming >> idioms) that depend on the leakage. > > Sure, ``if [mo for mo in [myre.search(line)] if mo]: use(mo)`` and the > like, used to simulate assign-and-test. here's an old favourite: lambda x: ([d for d in

Re: Zen of Python

Paul Rubin wrote: >> > Some languages let you say things like: >> > for (var x = 0; x < 10; x++) >> > do_something(x); >> > and that limits the scope of x to the for loop. >> >> depending on the compiler version, compiler switches, IDE settings, etc. > > Huh? I'm not sure what you're talki

Re: Zen of Python

Paul Rubin wrote: > Dave Benjamin <[EMAIL PROTECTED]> writes: > > Can we get a show of hands for all of those who have written or are > > currently maintaining code that uses the leaky listcomp "feature"? > > It's really irrelevant whether anyone is using a feature or n

Re: Zen of Python

Paul Rubin wrote: > [EMAIL PROTECTED] (Alex Martelli) writes: > > If it changed the semantics of for-loops in general, that would be quite > > inconvenient to me -- once in a while I do rely on Python's semantics > > (maintaining the loop control variable after a break;

Re: Zen of Python

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > > Some languages let you say things like: > > for (var x = 0; x < 10; x++) > > do_something(x); > > and that limits the scope of x to the for loop. > > depending on the compiler version, compiler switches, IDE settings, etc. Huh? I'm not sure

Re: Zen of Python

Paul Rubin wrote: > Some languages let you say things like: > for (var x = 0; x < 10; x++) > do_something(x); > and that limits the scope of x to the for loop. depending on the compiler version, compiler switches, IDE settings, etc. -- http://mail.python.org/mailman/listinfo/python-

Re: Zen of Python

[EMAIL PROTECTED] (Alex Martelli) writes: > If it changed the semantics of for-loops in general, that would be quite > inconvenient to me -- once in a while I do rely on Python's semantics > (maintaining the loop control variable after a break; I don't recall if > I ever used the fact that the vari

Re: Zen of Python

Dave Benjamin <[EMAIL PROTECTED]> writes: > Can we get a show of hands for all of those who have written or are > currently maintaining code that uses the leaky listcomp "feature"? It's really irrelevant whether anyone is using a feature or not. If the feature is documented as being available, it

Re: Zen of Python

Dave Benjamin <[EMAIL PROTECTED]> wrote: > Can we get a show of hands for all of those who have written or are > currently maintaining code that uses the leaky listcomp "feature"? "Have written": guilty -- basically to show how NOT to do things. "Currently maintaining": you _gotta_ be kidding!-)

Re: Zen of Python

Paul Rubin wrote: Tim Peters <[EMAIL PROTECTED]> writes: But at that time, Python didn't have lexical scoping, and it wasn't clear that it ever would. So what's the bigger wart? Making listcomps exactly equivalent to an easily-explained Python for-loop nest, or introducing a notion of lexical sco

Re: Zen of Python

Tim Peters <[EMAIL PROTECTED]> writes: > But at that time, Python didn't have lexical scoping, and it wasn't > clear that it ever would. So what's the bigger wart? Making > listcomps exactly equivalent to an easily-explained Python for-loop > nest, or introducing a notion of lexical scope unique

Re: Zen of Python

Timothy Fitz <[EMAIL PROTECTED]> wrote: ... > Perhaps Tim Peters is far too > concise for my feeble mind It's Zen, it's beyond Mind. Let it speak to your True Self! Alex -- http://mail.python.org/mailman/listinfo/python-list

Re: Zen of Python

[Paul Rubin] >> You snipped out the examples I gave, like [x*x for x in range(5)] >> leaving unnecessary residue in the name space. Was it not >> obvious from the beginning that that was a kludge? If it was >> obviously a kludge, was it not obvious that there would be >> reason to want to fix it

Re: Zen of Python

Skip Montanaro wrote: Steve> The fact that a bright bunch like the Python developers didn't Steve> realize that it would be sensible to have a local scope for the Steve> list comprehension variable is a perfect demonstration of that Steve> point. Actually, I seem to recall that the

Re: Zen of Python

Steve> The fact that a bright bunch like the Python developers didn't Steve> realize that it would be sensible to have a local scope for the Steve> list comprehension variable is a perfect demonstration of that Steve> point. Actually, I seem to recall that the topic came up, but a

Re: Zen of Python

Paul Rubin wrote: You snipped out the examples I gave, like [x*x for x in range(5)] leaving unnecessary residue in the name space. Was it not obvious from the beginning that that was a kludge? If it was obviously a kludge, was it not obvious that there would be reason to want to fix it someday?

Re: Zen of Python

Paul Rubin wrote: Steve Holden <[EMAIL PROTECTED]> writes: [Paul proves his superior Lisp knowledge] Perhaps because we don't all have your psychic powers? You snipped out the examples I gave, like [x*x for x in range(5)] leaving unnecessary residue in the name space. Was it not obvious from the

Re: Zen of Python

Steve Holden <[EMAIL PROTECTED]> writes: > But how, in Lisp, would you transliterate the Python list [1, 2, 3, 4]? With a vector. > Clearly the Python list *is* different, and the tradeoff was to > obtain speed of random access, presumably (I wasn't taking an interest > in Python in its early day

Re: Zen of Python

>> The gist of "Flat is better than nested" is "be as nested as you have >> to be, no more," because being too nested is just a mess. Tim> Which I agree with, and which makes sense. However your "gist" is a Tim> different meaning. Not if you conflate "Flat is better than nested"

Re: Zen of Python

Paul Rubin wrote: Tim Peters <[EMAIL PROTECTED]> writes: Huh? [1,2,[3,4,5],[6,7]],8 is a perfectly valid Python list. You're claiming not to know any relevant difference between Python lists and Lisp lists? Heh. Python doesn't provide syntactic sugar for [1,[2,[3,[4,[] if that's what

Re: Zen of Python

Paul Rubin wrote: > But it's often predictable at the beginning what the final destination is going to be. So once we can see where it's going, why not proceed to the finish line immediately instead of bothering with the intermediate steps? Because getting there incrementally helps to make sure y

Re: Zen of Python

Op 2005-01-19, Steve Holden schreef <[EMAIL PROTECTED]>: > Peter Hansen wrote: > >> Timothy Fitz wrote: >> >>> While I agree that the Zen of Python is an amazingly concise list of >>> truisms, I do not see any meaning in: >>> >>> Fl

Re: Zen of Python

Timothy Fitz wrote: > While I agree that the Zen of Python is an amazingly concise list of > truisms, I do not see any meaning in: > > Flat is better than nested. Python's not Pascal. -- http://mail.python.org/mailman/listinfo/python-list

Re: Zen of Python

Luke Skywalker <[EMAIL PROTECTED]> schreef: > On Wed, 19 Jan 2005 14:13:47 -0500, Timothy Fitz > > While I agree that the Zen of Python is an amazingly concise list > > of truisms, I do not see any meaning in: > > For those interested, here's the list: > http:

Re: Zen of Python

On Wed, 19 Jan 2005 14:13:47 -0500, Timothy Fitz <[EMAIL PROTECTED]> wrote: >While I agree that the Zen of Python is an amazingly concise list of >truisms, I do not see any meaning in: (snip) For those interested, here's the list: http://www.python.org/doc/Humor.html#ze

Re: Zen of Python

Tim Peters <[EMAIL PROTECTED]> writes: > > Huh? [1,2,[3,4,5],[6,7]],8 is a perfectly valid Python list. > > You're claiming not to know any relevant difference between Python > lists and Lisp lists? Heh. Python doesn't provide syntactic sugar for [1,[2,[3,[4,[] if that's what you me

Re: Zen of Python

[Paul Rubin] > Huh? [1,2,[3,4,5],[6,7]],8 is a perfectly valid Python list. You're claiming not to know any relevant difference between Python lists and Lisp lists? Heh. > And you can break out of a containing loop from a nested loop > with try/raise. Heh heh. Yes, you can. I've neve

Re: Zen of Python

Tim Peters <[EMAIL PROTECTED]> writes: > Python's basic list type is a flat vector instead of a > recursively-defined S-expression, and that there's no direct way to > break out of a containing loop from a nested loop. Huh? [1,2,[3,4,5],[6,7]],8 is a perfectly valid Python list. And you c

Re: Zen of Python

[Carl Banks] >> The gist of "Flat is better than nested" is "be as nested as >> you have to be, no more," because being too nested is just a >> mess. [Timothy Fitz] > Which I agree with, and which makes sense. However your > "gist" is a different meaning. It's not that "Flat is better than > neste

Re: Zen of Python

On Wed, Jan 19, 2005 at 09:28:13PM -0500, Peter Hansen wrote: > Jeff Shannon wrote: > >Timothy Fitz wrote: > >>Which I agree with, and which makes sense. However your "gist" is a > >>different meaning. It's not that "Flat is better than nested" it's > >>that "Too flat is bad and too flat is nested

Re: Zen of Python

Jeff Shannon wrote: Timothy Fitz wrote: Which I agree with, and which makes sense. However your "gist" is a different meaning. It's not that "Flat is better than nested" it's that "Too flat is bad and too flat is nested so be as nested (or as flat) as you have to be and no more." Perhaps Tim Peters

Re: Zen of Python

Timothy Fitz wrote: On 19 Jan 2005 15:24:10 -0800, Carl Banks <[EMAIL PROTECTED]> wrote: The gist of "Flat is better than nested" is "be as nested as you have to be, no more," because being too nested is just a mess. Which I agree with, and which makes sense. However your "gist" is a different mean

Re: Zen of Python

Timothy Fitz wrote: > On 19 Jan 2005 15:24:10 -0800, Carl Banks <[EMAIL PROTECTED]> wrote: > > The gist of "Flat is better than nested" is "be as nested as you have > > to be, no more," because being too nested is just a mess. > > Which I agree with, and which makes sense. However your "gist" is a

Re: Zen of Python

Timothy Fitz wrote: On 19 Jan 2005 15:24:10 -0800, Carl Banks <[EMAIL PROTECTED]> wrote: The gist of "Flat is better than nested" is "be as nested as you have to be, no more," because being too nested is just a mess. Which I agree with, and which makes sense. However your "gist" is a different mea

Re: Zen of Python

Timothy Fitz wrote: > While I agree that the Zen of Python is an amazingly concise list of > truisms, I do not see any meaning in: > > Flat is better than nested. > > I strive for balance between flat and nested. Does anyone have a good > example of where this is applied? (s

Re: Zen of Python

On 19 Jan 2005 15:24:10 -0800, Carl Banks <[EMAIL PROTECTED]> wrote: > The gist of "Flat is better than nested" is "be as nested as you have > to be, no more," because being too nested is just a mess. Which I agree with, and which makes sense. However your "gist" is a different meaning. It's not t

Re: Zen of Python

Skip Montanaro wrote: > Bill> The example that occurs to me is that "import smtplib" is better > Bill> than "import stdlib.inet.services.smtp". > > Sure. There is a balance to be achieved however. "import std.smtplib" > might be better than "import smtplib", simply because making the standar

Re: Zen of Python

Peter Hansen wrote: Timothy Fitz wrote: While I agree that the Zen of Python is an amazingly concise list of truisms, I do not see any meaning in: Flat is better than nested. [incrdeibly secret PSU facts blurted out] And with that out of the way, one is left with "there's a balance alon

Re: Zen of Python

Timothy Fitz wrote: While I agree that the Zen of Python is an amazingly concise list of truisms, I do not see any meaning in: Flat is better than nested. I strive for balance between flat and nested. Does anyone have a good example of where this is applied? (specifically to python, or in general

Re: Zen of Python

Bill> The example that occurs to me is that "import smtplib" is better Bill> than "import stdlib.inet.services.smtp". Sure. There is a balance to be achieved however. "import std.smtplib" might be better than "import smtplib", simply because making the standard library a package reduces

Re: Zen of Python

The example that occurs to me is that "import smtplib" is better than "import stdlib.inet.services.smtp". Peace Bill Mill bill.mill at gmail.com On Wed, 19 Jan 2005 14:13:47 -0500, Timothy Fitz <[EMAIL PROTECTED]> wrote: > While I agree that the Zen of Python is

Zen of Python

While I agree that the Zen of Python is an amazingly concise list of truisms, I do not see any meaning in: Flat is better than nested. I strive for balance between flat and nested. Does anyone have a good example of where this is applied? (specifically to python, or in general) -- http