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(c, c

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

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 python' is generated by the fo

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 someo

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

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

ad about by Perl users, > to 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 shou

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? I

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.

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: 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

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 to

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

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 33 But

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 surprised me, and

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 Oct 8, 2013 2:26 PM, Steven Dapos;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 gave

[issue3364] An ortographical typo in Zen of Python text

Changes by David Goodger [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10928/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3364 ___ ___

[issue3364] An ortographical typo in Zen of Python text

Benjamin Peterson [EMAIL PROTECTED] added the comment: I'm sorry, but syntax is part of poetry, too. Please stop misusing the tracker. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED]

[issue3364] An ortographical typo in Zen of Python text

Tim Peters [EMAIL PROTECTED] added the comment: I'm afraid you missed the joke ;-) While you believe spaces are required on both sides of an em dash, there is no consensus on this point. For example, most (but not all) American authorities say /no/ spaces should be used. That's the joke. In

[issue1621660] this module (Zen of Python) docs list broken URL

Antoine Pitrou added the comment: I think the original poster alludes to the fact that when doing `import this; help(this)`, the module docs section points to the autogenerated URL `http://www.python.org/doc/current/lib/module-this.html`, which doesn't exist. Probably nothing very annoying

[issue1621660] this module (Zen of Python) docs list broken URL

Georg Brandl added the comment: Where exactly is that broken link? -- nosy: +georg.brandl _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621660 _ ___

[ python-Bugs-1621660 ] this module (Zen of Python) docs list broken URL

(Zen of Python) docs list broken URL Initial Comment: The this module, the Zen of Python, has a broken (404) URL in the docs. They link to http://www.python.org/doc/current/lib/module-this.html, which does not exist. Seems like a good place to keep the text, and any links to other resources

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 think the

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!-) I

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

[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

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. /F --

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 what you're

Re: Zen of Python

Paul Rubin http://[EMAIL PROTECTED] 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; I don't

Re: Zen of Python

Paul Rubin http://[EMAIL PROTECTED] 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 not. If the

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 talking about. guess

Re: Zen of Python

On 21 Jan 2005 20:32:46 -0800, Paul Rubin http://[EMAIL PROTECTED] 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 describing

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 committee

Re: Zen of Python

Paul Rubin http://[EMAIL PROTECTED] 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 currently

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 remaining in

Re: Zen of Python

Paul Rubin http://[EMAIL PROTECTED] 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 a warning

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 impossible, then

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 to

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

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 at

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

[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 someday?

Re: Zen of Python

Timothy Fitz [EMAIL PROTECTED] wrote: ... Perhaps Tim Peters is far too concise for my feeble mind wink 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

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 to

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: Flat is better than nested. [incrdeibly secret PSU facts blurted out

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

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

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 with

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 days)

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

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

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 the

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

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 along the flat

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 standard library a

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 that Flat

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

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 meaning.

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 meaning.

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 is

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 so be as nested

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 nested it's that Too

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 can

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 never

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 mean.

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#zen Luke. -- http

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://www.python.org/doc/Humor.html#zen Or you

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. /F -- http://mail.python.org/mailman/listinfo/python-list