Re: Sharing code between different projects?
> On Monday, August 13, 2012 at 7:53:32 PM UTC+3, andrea crotti wrote: >> I am in the situation where I am working on different projects that >> might potentially share a lot of code. >> >> I started to work on project A, then switched completely to project B >> and in the transiction I copied over a lot of code with the >> corresponding tests, and I started to modify it. >> >> Now it's time to work again on project A, but I don't want to copy >> things over again. I use so called "namespace packages" for this. Those are "virtual" packages "containing" a set of related "real" packages - individually manageable on PyPI. The "real" packages describe in their dependencies on which other packages they depend, among them (potentially) "friend" packages. An example is "dm.zope.rpc" and "dm.zope.rpc.wsdl_suds". In this case, "dm.zope.rpc" provides general rpc infrastructure for the web application framework Zope and implementations for some elementary rpc protocols and "dm.zipe.rpc.wsdl_suds" uses this infrastructure for the implementation of a WSDL based rpc protocol by means of "suds". -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
Steve D'Aprano wrote: Similarly for break and continue. I can still see their use causing potential trouble in (really-long) real-world code. How so? Besides, if your code is "really long", you probably should factorise it into smaller, meaningful chunks. I worked in maintenance programming. You got the hand you were dealt! And you weren't allowed to "improve" the code unless the customer contracted you to do so. I maintained for-loops (containing for-loops)... hundreds of lines long. Would you be searching for break or continue? : ) -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
On Wed, 27 Sep 2017 05:50 pm, Bill wrote: [...] > If you are teaching beginning students, do you expect them to try to > follow these sorts of conventions? Yes, but not to the point of being a dick about it. It is better to learn good habits first, rather than to learn bad habits then unlearn them later. The PEP 8 spacing conventions are based on similar English and/or maths conventions. For instance, in English, you should never put a space before the colon. This is wrong : ... any more than you would put a space before a comma , or before the full stop at the end of the sentence . oR capitalise the *second* letter of the first word in a sentence . Yes, the rules are fundamentally arbitrary, but violating them makes your text harder to read, whether that text is English prose, source code, or mathematics. > Is it perfectly fine to let "taste" > guide you (I'm just trying to get a feel for the philosophy here)? To some degree. Consistency with common standards is a valuable thing, but its *your* code and if you want to write in an idiomatic style that gives everyone else a headache, go right ahead. Just don't expect me to contribute to it. One of Raymond Hettinger's videos talks about writing beautiful Python code, and how slavishly obeying PEP 8 is not really productive. I'll try to find a link later and post it. > I > also notice "break" and exception handling is used much more in Python > than in C++, for instance. I was taught "break" and "continue" led to > "unstructured code"--but that was a while back. That's weird. break and continue are perfectly structured. They are no more of an unstructured GOTO than are if...else, for or while. It is the nature of human beings to gravitate to extremes, rather than finding a happy medium. When the idea of structured programming was first introduced into the programming community used to BASIC and other unstructured languages, there was a tendency among many people to slavishly apply the principle that every function, or even block of code, must have exactly one entry point and one exit point. Of course enforcing one entry point is easy: few languages allow you to jump into the middle of a function, because that would be really bad. But having multiple exit points is not just harmless, but actually useful. Nevertheless, because of this overly strict, foolish insistence on a single exit to a block of code, some people prefer to write code like this: done = False result = None for i in range(0, 2**64): if not done: ... code here if condition: result = value done = True return result rather than the simpler code that violates the "one exit" rule: for i in range(0, 2**64): ... code here if condition: return value return None Similarly for break and continue. > I can still see their > use causing potential trouble in (really-long) real-world code. How so? Besides, if your code is "really long", you probably should factorise it into smaller, meaningful chunks. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Wed, 27 Sep 2017 12:41:24 -0400, leam hall wrote: > The question is, what should a person "know" when hiring out as a > programmer? What is 'know" and what should be "known"? Specifically > with Python. The longer I claim to be a programmer, the more I discover how wide a net that is. Web sites, embedded systems, user interfaces (text and graphical), databases, communications protocols, applications programming, systems programming, real time systems, text processing, scientific computing, simulations, security, etc., etc., etc. And I stopped there only because I hope I've made my point and not because that's an exhaustive list. Some of it you'll know up front; it's a pretty boring job on which you learn nothing new. What must be known is how to produce a program that does what the customer says they want (note that they likely don't know what they need, only what they want, but that's a whole other ball of wax). You'll also have to know enough about the problem domain to converse with the customer to turn what will be a vague request into something tangible. I'm sure you already do this when it comes to automating your own tasks. If I'm hiring myself out as a plumber, I should know how to unclog drains; and install, repair, replace toilets, water heaters, and other plumbing fixtures (or whatever else a plumber might be called on to do). Ignore the question of licensing; it doesn't apply to programmers. It's the same whether you use Python, something else, or some combination. Wow, that's a lot more than I intended to write. I don't mean to be discouraging, only enlightening. We all started somewhere, and your background as a sysadmin puts you way ahead of a lot of future programmers. HTH, Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Thu, Sep 28, 2017 at 11:18 AM, Larry Hudson via Python-list
wrote:
>
> It had turned out his company had paid for him to take the course. Since he
> failed, it suddenly came to the attention of his employer that he didn't
> know how to program, and now his job was in jeopardy. As I hung up the
> phone, I mused that his company shouldn't fire him. It was a perfect match:
> a programmer who couldn't program and a company that couldn't figure out
> sooner that he couldn't.
>
I had a coworker like that at my previous job. The boss basically was
paying him to learn to code, and yet (for reasons which to this day I
cannot fathom) let him make a lot of decisions about technology. Thus
we used PHP and MySQL (okay, it could have been worse), with a
multi-threaded daemon in addition to the actual web server (I take
that back, it WAS worse). I had to fight uphill to convince my boss of
the value of git ("why bother, I have daily backups for a week and
then weekly backups for two years"), and even then, this coworker
didn't commit or push until, well, pushed. Eventually he quit the
company (rumour has it he was hoping we'd beg him to stay, since we
were that short-handed), and I had to take over his code... and found
it full of The Daily WTF level abominations. Heard of the "For-Case
paradigm"? Check out this [1] old article if you're not familiar with
it. Well, he gave me this thrilling variant (reconstructed from
memory):
$i=1;
while ($i<3) {
switch($i)
{case 1:
... snip one set of validations
$i=3;
break;
case 3:
... some more validation work
$i=2;
break;
case 2:
... snip another set of validations
$i=4;
break;
}}
I don't remember the exact details, but it was something like this. It
looked like the code just stepped straight through the switch block.
So I stripped out the junk and just did the validations sequentially.
And the code stopped working.
Since I *had* been committing to git frequently, I checked out the
previous version. It worked. I redid the simplification. It broke
again. I stuck in some console output, and found that one of the
blocks of code was actually getting skipped... and due to the
compounding of two or three other bugs, valid input would get rejected
by the validation that wasn't happening.
I have no idea whether he intentionally removed part of the
validation, or if he just never noticed that it wasn't running. It was
a truly impressive piece of work.
ChrisA
[1] https://thedailywtf.com/articles/The_FOR-CASE_paradigm
--
https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On 09/27/2017 09:41 AM, leam hall wrote: On Sat, Sep 23, 2017 at 5:26 PM, Ned Batchelder wrote: [snip] The question is, what should a person "know" when hiring out as a programmer? What is 'know" and what should be "known"? Specifically with Python. Hopefully NOT like this person... (Source: http://rinkworks.com/stupid/cs_misc.shtml There is no direct link to this item, it's about 2/3 the way down in a long web page...) Since I teach nights at a local community college, I get a lot of professional programmers in my classes upgrading their education. One student, who was one such person, attended every lecture and smiled and nodded and took notes. But he only turned in his first assignment. The results of his first test were horrid. Out of curiosity, I asked my wife, who barely knew how to turn a computer on much less program one, to take the test (which was mostly true/false and multiple choice questions). My wife scored higher than this guy. The semester's end came, and he flubbed his final, too. A few weeks later, I got a call from him complaining about his 'F'. I pointed out he hadn't turned in any of his assignments, and those counted 75% of the grade. "Did you hear me say something besides what the other students heard?" I asked. "Well, I thought my test grades would carry me," he replied. It had turned out his company had paid for him to take the course. Since he failed, it suddenly came to the attention of his employer that he didn't know how to program, and now his job was in jeopardy. As I hung up the phone, I mused that his company shouldn't fire him. It was a perfect match: a programmer who couldn't program and a company that couldn't figure out sooner that he couldn't. -- -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: Real Programmers Write Docs
On 9/27/17 6:55 PM, Rob Gaddi wrote: Anyone have any good references on using Sphinx to generate a mix of autogenerated API docs and hand-written "Yeah, but this is what you DO with it" docs? Free is good but I'm happy to drop money on books if they're worthwhile. I can offer you an example: the coverage.py docs are in Sphinx, and use both auto-generated and hand-written pages: https://github.com/nedbat/coveragepy/tree/master/doc I'm not sure what information you are looking for, maybe this will help? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Real Programmers Write Docs
Anyone have any good references on using Sphinx to generate a mix of autogenerated API docs and hand-written "Yeah, but this is what you DO with it" docs? Free is good but I'm happy to drop money on books if they're worthwhile. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: None is None but not working
On 09/27/2017 01:05 PM, Sayth Renshaw wrote:
Hi
I have got a successful script setup to rotate through dates and download json
data from the url.
As the api returns 200 whether successful I want to check if the file returned
is not successful.
when a file doesn't exist the api returns
{'RaceDay': None, 'ErrorInfo': {'SystemId': 200, 'ErrorNo': 55013,
'DisplayMessage': 'File Not Found.', 'ContactSupport': False,
'SupportErrorReference': '200-55013'}, 'Success': False}
When I call data = r.json() it says its type is None if it is not successful so
I thought it easier to check that.
However checking for None does not work the flow in my if else falls straight
to else.
for dates in fullUrl:
r = requests.get(dates)
data = r.json()
if data is None:
print("Nothing here")
else:
print(data["RaceDay"])
Your data is not None, it's a full dictionary.
However, data["RaceDay"] *is* None as shown in your output. Thus your
test should be:
if data["RaceDay"] is None: ...
rather than
if data is None: ...
and I get output of
None
None
{'MeetingDate': '2017-01- ... and so on.
How can I actually get this to check?
If i use type(data) I also get None.
Cheers
Sayth
--
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418
--
https://mail.python.org/mailman/listinfo/python-list
Re: None is None but not working
Sayth Renshaw writes: > When I call data = r.json() it says its type is None if it is not > successful so I thought it easier to check that. Can you show the interactive session where you do that check? >>> data = r.json() >>> data is None True That's what I understand your statement to mean. Is that what you see, exactly? If not, please post the equivalent session. -- \ “Two rules to success in life: 1. Don't tell people everything | `\you know.” —Sassan Tat | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: None is None but not working
Il 27/09/2017 22:05, Sayth Renshaw ha scritto:
Hi
I have got a successful script setup to rotate through dates and download json
data from the url.
As the api returns 200 whether successful I want to check if the file returned
is not successful.
when a file doesn't exist the api returns
{'RaceDay': None, 'ErrorInfo': {'SystemId': 200, 'ErrorNo': 55013,
'DisplayMessage': 'File Not Found.', 'ContactSupport': False,
'SupportErrorReference': '200-55013'}, 'Success': False}
You got None on the member 'RaceDay' of the data, not on all the
data. So you should check for something like:
if data['RaceDay'] is None:
# Missing data
else:
# ok, do what you need
...
When I call data = r.json() it says its type is None if it is not successful so
I thought it easier to check that.
However checking for None does not work the flow in my if else falls straight
to else.
for dates in fullUrl:
r = requests.get(dates)
data = r.json()
if data is None:
print("Nothing here")
else:
print(data["RaceDay"])
and I get output of
None
None
{'MeetingDate': '2017-01- ... and so on.
How can I actually get this to check?
If i use type(data) I also get None.
Cheers
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
None is None but not working
Hi
I have got a successful script setup to rotate through dates and download json
data from the url.
As the api returns 200 whether successful I want to check if the file returned
is not successful.
when a file doesn't exist the api returns
{'RaceDay': None, 'ErrorInfo': {'SystemId': 200, 'ErrorNo': 55013,
'DisplayMessage': 'File Not Found.', 'ContactSupport': False,
'SupportErrorReference': '200-55013'}, 'Success': False}
When I call data = r.json() it says its type is None if it is not successful so
I thought it easier to check that.
However checking for None does not work the flow in my if else falls straight
to else.
for dates in fullUrl:
r = requests.get(dates)
data = r.json()
if data is None:
print("Nothing here")
else:
print(data["RaceDay"])
and I get output of
None
None
{'MeetingDate': '2017-01- ... and so on.
How can I actually get this to check?
If i use type(data) I also get None.
Cheers
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
Thank you for all of the feedback provided! It was just what I was looking for. : ) I'm going to go back and read some of the links more carefully. Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing a Chunk Of Words
On Wed, 27 Sep 2017 at 14:48 Peter Otten <__pete...@web.de> wrote: > > Reproducing the original string exactly the best I've managed is 260: > > That's a bit long, don't you think, as it can be beaten even by plain old > zipping: > ha! tbh yes It's longer than I was expecting to manage. $ cat booltable2.py > from codecs > > import*;print(decode(decode(b'eJzjUgABp/z8nNTEPAX/gtSixJL8omIuXRwArFyBK6SoNFUhMS9FAczILAbTCFG3xJxisDCYwQXh\nIitHF0fTADEpvwiL8UBBuGKwKISHrhYuim6yX34JmitAIqhGcgEAEnJWfA==\n',"base64"),"zip").decode())$ $ wc -c booltable2.py > 210 booltable2.py > Well, ok, but mine is at least parseable by a sufficiently masochistic human, though I suppose that was never given as a requirement :D (You could also shave off 4 more bytes by importing `decode` as `d` rather than your nice `import*` trick, because you call it 3 times) > [snip] > > :) > :D On Wed, 27 Sep 2017 at 17:50 Thomas Jollans wrote: > Touché. > > You're still missing some whitespace, though ;-) (like, I think, > everybody else in this weird international obfuscated Python competition) > I guess you still didn't run it ;D (see the 2nd `for` statement). I diffed my output against the original, which is why I'm confident in the correctness of my solution ;) Actually I managed to shave off another byte by changing `l.insert(i,'')` to `l[i:i]=['']`, so now I'm on 259. I should probably stop now... -- -- Matt Wheeler http://funkyh.at -- https://mail.python.org/mailman/listinfo/python-list
Re: auto installing dependencies with pip to run a python zip application ?
On 09/27/2017 09:50 AM, Paul Moore wrote: >>> What you could do is pip install your binary dependencies into a >>> directory in $TEMP using --target, then add that directory to >>> sys.path. Probably easier than building a full virtualenv. Bundle pip >>> with your app if you can't assume your users will have pip available. >> >> Interesting idea, although like this wouldn't I have to download the >> dependencies every time I launch my game? (unless I re-use the same >> temporary directory every time) > > Ah, I'd assumed that's what you were doing with the virtualenv, I > hadn't realised you were talking about a one-off setup step. Yeah, > re-using a temporary directory doesn't buy you much compared to using > a virtualenv (particularly if you can target versions of Python that > have the built in venv module). Well, I was planning on using a fixed name/location for the virtualenv. That way when you request pip to install the dependencies again at next launch, it will detect them already satisfied and not download/reinstall everything. I could even test for their existence first myself in my application (which is what I'm already doing now, to give the user a clear error message) and only invoke pip when a dependency is missing. -irmen -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing a Chunk Of Words
On 2017-09-27 16:38, Matt Wheeler wrote:
> On Wed, 27 Sep 2017 at 13:58 Thomas Jollans wrote:
>
>>> Reproducing the original string exactly the best I've managed is 260:
>>>
>>> t,f,a,o,n='True','False','and','or','not'
>>
>> The Not is capitalized in the original string.
>>
>
> I guess you didn't try it? (or see `upper()` in the body of the `for` below)
Touché.
You're still missing some whitespace, though ;-) (like, I think,
everybody else in this weird international obfuscated Python competition)
>
>> l=[" Boolean Operators\n"+"-"*24]
>>> for x in [(l,p,r)for p in(a,o)for l in(t,f)for r
>> in(t,f)]+[(n,t),(n,f)]:x='
>>> '.join(x);l+=[x[0].upper()+x[1:]+" is "+str(eval(x))]
>>> for i in 12,9,5,0:l.insert(i,'')
>>> print('\n'.join(l))
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Wed, Sep 27, 2017 at 12:41 PM, leam hall wrote: > The question is, what should a person "know" when hiring out as a > programmer? What is 'know" and what should be "known"? Specifically with > Python. Fake it till you make it! -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginners and experts (Batchelder blog post)
On Sat, Sep 23, 2017 at 5:26 PM, Ned Batchelder wrote: > On 9/23/17 2:52 PM, Leam Hall wrote: > >> On 09/23/2017 02:40 PM, Terry Reedy wrote: >> >>> https://nedbatchelder.com//blog/201709/beginners_and_experts.html >>> >>> Great post. >>> >> >> Yup. Thanks for the link. I often have that "I bet > Fred> doesn't get frustrated." thing going. Nice to know Ned bangs his head >> now and again. :P >> >> > "Ow!" --me Hehe...I've been trying to figure out how to phrase a question. Knowing I'm not the only one who gets frustrated really helps. I'm trying to learn to be a programmer. I can look at a book and read basic code in a few languages but it would be unfair to hire myself out as a programmer. I'm just not yet worth what it costs to pay my bills. To move forward takes a plan and time bound goals. At least for us old folks; we only have so much time left. I want to avoid retirement and just work well until I keel over. I don't come from a CS background but as a Linux sysadmin. My current push is OOP. Grady Booch's book on Analysis and Design is great and I've got the GoF for right after that. I've been doing more testing but need to write more tests. Writing code and starting to work with others on that code as well. The question is, what should a person "know" when hiring out as a programmer? What is 'know" and what should be "known"? Specifically with Python. Thanks! Leam -- https://mail.python.org/mailman/listinfo/python-list
Re: Pyhton
Besides being easy to learn and develop, there is a large number of dev supporters. Which it makes it more compelling. Thank You, Irving Duran On Wed, Sep 27, 2017 at 9:27 AM, wrote: > On Wednesday, September 27, 2017 at 3:10:30 PM UTC+1, darwi...@gmail.com > wrote: > > Whats the reason that python is growing fast? > > It would be growing faster but it is only the second best language in the > world. Please see https://mail.python.org/pipermail/python-list/2002- > November/141486.html > > -- > Kindest regards. > > Mark Lawrence > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing a Chunk Of Words
On Wed, 27 Sep 2017 at 13:58 Thomas Jollans wrote:
> > Reproducing the original string exactly the best I've managed is 260:
> >
> > t,f,a,o,n='True','False','and','or','not'
>
> The Not is capitalized in the original string.
>
I guess you didn't try it? (or see `upper()` in the body of the `for` below)
> l=[" Boolean Operators\n"+"-"*24]
> > for x in [(l,p,r)for p in(a,o)for l in(t,f)for r
> in(t,f)]+[(n,t),(n,f)]:x='
> > '.join(x);l+=[x[0].upper()+x[1:]+" is "+str(eval(x))]
> > for i in 12,9,5,0:l.insert(i,'')
> > print('\n'.join(l))
--
--
Matt Wheeler
http://funkyh.at
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pyhton
On Wednesday, September 27, 2017 at 3:10:30 PM UTC+1, darwi...@gmail.com wrote: > Whats the reason that python is growing fast? It would be growing faster but it is only the second best language in the world. Please see https://mail.python.org/pipermail/python-list/2002-November/141486.html -- Kindest regards. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Pyhton
Whats the reason that python is growing fast? -- https://mail.python.org/mailman/listinfo/python-list
Re: Sharing code between different projects?
On Monday, August 13, 2012 at 7:53:32 PM UTC+3, andrea crotti wrote:
> I am in the situation where I am working on different projects that
> might potentially share a lot of code.
>
> I started to work on project A, then switched completely to project B
> and in the transiction I copied over a lot of code with the
> corresponding tests, and I started to modify it.
>
> Now it's time to work again on project A, but I don't want to copy
> things over again.
>
> I would like to design a simple and nice way to share between projects,
> where the things I want to share are simple but useful things as for
> example:
>
> class TempDirectory:
> """Create a temporary directory and cd to it on enter, cd back to
> the original position and remove it on exit
> """
> def __init__(self):
> self.oldcwd = getcwd()
> self.temp_dir = mkdtemp()
>
> def __enter__(self):
> logger.debug("create and move to temp directory %s" % self.temp_dir)
> return self.temp_dir
>
> def __exit__(self, type, value, traceback):
> # I first have to move out
> chdir(self.oldcwd)
> logger.debug("removing the temporary directory and go back to
> the original position %s" % self.temp_dir)
> rmtree(self.temp_dir)
>
>
> The problem is that there are functions/classes from many domains, so it
> would not make much sense to create a real project, and the only name I
> could give might be "utils or utilities"..
>
> In plus the moment the code is shared I must take care of versioning and
> how to link different pieces together (we use perforce by the way).
>
> If then someone else except me will want to use these functions then of
> course I'll have to be extra careful, designing really good API's and so
> on, so I'm wondering where I should set the trade-off between ability to
> share and burden to maintain..
>
> Anyone has suggestions/real world experiences about this?
I would try bit:
https://github.com/teambit/bit
Hope it helps.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Even Older Man Yells At Whippersnappers
On 20/09/2017 10:54, Chris Angelico wrote: What, you take silicon that someone else created?! ChrisA well I had germanium for flipflops and dekatron tubes with neon for counters never built anything digital with valves though -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing a Chunk Of Words
Matt Wheeler wrote:
> With deepest apologies to all involved...
>
> On Tue, 26 Sep 2017 at 08:42 Gregory Ewing
> wrote:
>
>> Ben Bacarisse wrote:
>> > Think functional! This is 257 characters:
>>
>> 250 chars, 17 shorter than the text it produces:
>>
>> a=[];o=[];n=[];A=list.append
>> for b in range(3,-1,-1):
>> x=bool(b>>1);y=bool(b&1);A(a,"%s and %s is %s"%(x,y,x and y));A(o,"%s
>> or
>> %s is
>> %s"%(x,y,x or y))
>> if x:A(n,"not %s is %s"%(y,not y))
>> print("Boolean Operators\n"+"-"*24+"\n"+"\n".join(a+o+n))
>>
>
> Cutting the same (quite reasonable) corners as you, I've got it down 212
> characters:
>
> t,f,a,o,n='True','False','and','or','not'
> l=[" Boolean Operators\n"+"-"*24]
> for x in [(l,p,r)for p in(a,o)for l in(t,f)for r
> in(t,f)]+[(n,t),(n,f)]:x=' '.join(x);l+=[x[0].upper()+x[1:]+" is
> "+str(eval(x))] for i in 12,9,5,0:l.insert(i,'')
> print('\n'.join(l))
>
> Reproducing the original string exactly the best I've managed is 260:
>
> t,f,a,o,n='True','False','and','or','not'
> l=[" Boolean Operators\n"+"-"*24]
> for x in [(l,p,r)for p in(a,o)for l in(t,f)for r
> in(t,f)]+[(n,t),(n,f)]:x=' '.join(x);l+=[x[0].upper()+x[1:]+" is
> "+str(eval(x))] for i in 12,9,5,0:l.insert(i,'')
> print('\n'.join(l))
>
That's a bit long, don't you think, as it can be beaten even by plain old
zipping:
$ cat booltable2.py
from codecs
import*;print(decode(decode(b'eJzjUgABp/z8nNTEPAX/gtSixJL8omIuXRwArFyBK6SoNFUhMS9FAczILAbTCFG3xJxisDCYwQXh\nIitHF0fTADEpvwiL8UBBuGKwKISHrhYuim6yX34JmitAIqhGcgEAEnJWfA==\n',"base64"),"zip").decode())$
$ wc -c booltable2.py
210 booltable2.py
$ python3 booltable2.py
Boolean Operators
True and True is True
True and False is False
False and True is False
False and False is False
True or True is True
True or False is True
False or True is True
False or False is False
Not True is False
Not False is True
$
:)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Printing a Chunk Of Words
On 2017-09-27 13:51, Matt Wheeler wrote:
> With deepest apologies to all involved...
>
> On Tue, 26 Sep 2017 at 08:42 Gregory Ewing
> wrote:
>
>> Ben Bacarisse wrote:
>>> Think functional! This is 257 characters:
>>
>> 250 chars, 17 shorter than the text it produces:
>>
>> a=[];o=[];n=[];A=list.append
>> for b in range(3,-1,-1):
>> x=bool(b>>1);y=bool(b&1);A(a,"%s and %s is %s"%(x,y,x and y));A(o,"%s or
>> %s is
>> %s"%(x,y,x or y))
>> if x:A(n,"not %s is %s"%(y,not y))
>> print("Boolean Operators\n"+"-"*24+"\n"+"\n".join(a+o+n))
>>
>
> Cutting the same (quite reasonable) corners as you, I've got it down 212
> characters:
>
> t,f,a,o,n='True','False','and','or','not'
> l=[" Boolean Operators\n"+"-"*24]
> for x in [(l,p,r)for p in(a,o)for l in(t,f)for r in(t,f)]+[(n,t),(n,f)]:x='
> '.join(x);l+=[x[0].upper()+x[1:]+" is "+str(eval(x))]
> for i in 12,9,5,0:l.insert(i,'')
> print('\n'.join(l))
>
> Reproducing the original string exactly the best I've managed is 260:
>
> t,f,a,o,n='True','False','and','or','not'
The Not is capitalized in the original string.
> l=[" Boolean Operators\n"+"-"*24]
> for x in [(l,p,r)for p in(a,o)for l in(t,f)for r in(t,f)]+[(n,t),(n,f)]:x='
> '.join(x);l+=[x[0].upper()+x[1:]+" is "+str(eval(x))]
> for i in 12,9,5,0:l.insert(i,'')
> print('\n'.join(l))
--
https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
On Sep 27, 2017, at 12:50 AM, Bill wrote: > > Ever since I download the MyCharm IDE a few days ago, I've been noticing all > sort of "spacing conventions (from PEP) that are suggested. How do folks > regard these in general? > > For instance, the conventions suggest that > > if x>y : > pass > > should be written > if x > y: >pass > > Personally, I like seeing a space before the colon (:). And then in > > my_list = [ i for i in range(0, 10) ] > it complains about my extra space inside of the brackets. > > If you are teaching beginning students, do you expect them to try to follow > these sorts of conventions? Is it perfectly fine to let "taste" guide you > (I'm just trying to get a feel for the philosophy here)? I also notice > "break" and exception handling is used much more in Python than in C++, for > instance. I was taught "break" and "continue" led to "unstructured > code"--but that was a while back. I can still see their use causing > potential trouble in (really-long) real-world code. > > Bill > > > > -- > https://mail.python.org/mailman/listinfo/python-list I came across a Python script on Github that did what I needed except for some trivial modifications to make it Python 3 compatible. I did consider contributing changes to make the script Python 2 and 3 compatible. However, the script was written an idiosyncratic, anti-PEP8 style that was hard to match and the author previously rejected all Python 3 contributions. Forking the script to make it Python 2/3 compatible *and* PEP8 compliant would require too much effort on my part, especially since I needed to use the script only once. Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: Printing a Chunk Of Words
With deepest apologies to all involved...
On Tue, 26 Sep 2017 at 08:42 Gregory Ewing
wrote:
> Ben Bacarisse wrote:
> > Think functional! This is 257 characters:
>
> 250 chars, 17 shorter than the text it produces:
>
> a=[];o=[];n=[];A=list.append
> for b in range(3,-1,-1):
> x=bool(b>>1);y=bool(b&1);A(a,"%s and %s is %s"%(x,y,x and y));A(o,"%s or
> %s is
> %s"%(x,y,x or y))
> if x:A(n,"not %s is %s"%(y,not y))
> print("Boolean Operators\n"+"-"*24+"\n"+"\n".join(a+o+n))
>
Cutting the same (quite reasonable) corners as you, I've got it down 212
characters:
t,f,a,o,n='True','False','and','or','not'
l=[" Boolean Operators\n"+"-"*24]
for x in [(l,p,r)for p in(a,o)for l in(t,f)for r in(t,f)]+[(n,t),(n,f)]:x='
'.join(x);l+=[x[0].upper()+x[1:]+" is "+str(eval(x))]
for i in 12,9,5,0:l.insert(i,'')
print('\n'.join(l))
Reproducing the original string exactly the best I've managed is 260:
t,f,a,o,n='True','False','and','or','not'
l=[" Boolean Operators\n"+"-"*24]
for x in [(l,p,r)for p in(a,o)for l in(t,f)for r in(t,f)]+[(n,t),(n,f)]:x='
'.join(x);l+=[x[0].upper()+x[1:]+" is "+str(eval(x))]
for i in 12,9,5,0:l.insert(i,'')
print('\n'.join(l))
--
--
Matt Wheeler
http://funkyh.at
--
https://mail.python.org/mailman/listinfo/python-list
Re: Aliasing [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 11:00 PM, Steve D'Aprano wrote: > The critical distinction here is whether the names refer to each other: > >a <---> b > >or whether they merely refer to the same value: > >a ---> [ value ] <--- b > > >Python uses the second model. Var parameters in Pascal and references in C++ use >the first. Since the term "aliasing" is well-established for the first, using >it in Python *without making the difference clear* is wrong. > > > Aha! There is the fundamental problem. In your first diagram below, if a is a pointer to b, and b is a pointer to a, then where is the value? If the value of 1 (or 2) is in a, then a cannot point at b; Or are you saying now that all variables in Pascal and C are _both_ values and pointers, simultaneously? Does that mean then that the value 1 (or 2) is in _both_ a and b? So that an assignment to either must change both copies of the value? No, I think it is more likely to be that the second diagram applies in all cases. Simply declaring a variable like A would lead to a --> [ uninitialized ] int& b creates an alias to a leads to a -> [ uninitialized ] <- b and then any assignment to a or b in the non-Python languages under consideration would fill in that box, allowing the change to be visible to both. But in Python, _all_ assignments are aliases. And I'll leave off further discussion by referring back to my previous note about what happens when we do "b = c" in the non-Python languages and in Python. >From the ordering of the notes in this forum, I will just assume you did not get a chance to read it before this post I am responding to. Roger Christman Pennsylvania State University -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
Bill wrote: > Ever since I download the MyCharm IDE a few days ago, I've been noticing > all sort of "spacing conventions (from PEP) that are suggested. How do > folks regard these in general? > > For instance, the conventions suggest that > > if x>y : > pass > > should be written > if x > y: > pass > > Personally, I like seeing a space before the colon (:). And then in > > my_list = [ i for i in range(0, 10) ] > it complains about my extra space inside of the brackets. Of late I've joined the "foolish consistency" camp and made the pep8 tool (now called pycodestyle to make it clear it is non-normative) a check-in hook. I agree with most of its complaints anyway and find it wasteful to fine-tune my code in that regard. > If you are teaching beginning students, do you expect them to try to > follow these sorts of conventions? At least mention the advantages to blend in rather than stand out as far as coding style is concerned. The reader can concentrate on functionality and is not distracted by the writer's ideosyncratic ideas about formatting. > Is it perfectly fine to let "taste" > guide you (I'm just trying to get a feel for the philosophy here)? I > also notice "break" and exception handling is used much more in Python > than in C++, for instance. I was taught "break" and "continue" led to > "unstructured code"--but that was a while back. I can still see their > use causing potential trouble in (really-long) real-world code. What actually causes the trouble is the really-long -- i. e. unstructured -- code. "real-world" is but an excuse here ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: Boolean Expressions
On Wednesday, September 27, 2017 at 1:01:50 PM UTC+8, Cameron Simpson wrote: > On 26Sep2017 20:55, Cai Gengyang wrote: > >On Wednesday, September 27, 2017 at 6:45:00 AM UTC+8, Cameron Simpson wrote: > >> On 26Sep2017 14:43, Cai Gengyang wrote: > >> >C) Set bool_three equal to the result of > >> >19 % 4 != 300 / 10 / 10 and False > >> > > >> 19 % 4 = 3 which is equal to 300 / 10 / 10 = 3, hence the first term is > >> False. Entire expression is then equal to True, because False and False = > >> True > >> > >> Entire expression is False because the left hand side is False. > > > >Am I missing something here ? 19 % 4 = 19 modulo 4 equals to 3 right ? which > >equals the right hand side , hence first term is True > > But the test is for "!=", not "==". So False. > > Cheers, > Cameron Simpson (formerly c...@zip.com.au) Right ... I didn't see the ' =! ' -- https://mail.python.org/mailman/listinfo/python-list
Re: Aliasing [was Re: [Tutor] beginning to code]
Op 27-09-17 om 09:38 schreef Steven D'Aprano:
No, the model that C++ and Pascal use is not different in this aspect.
> that Pascal var parameters and C++ reference variables operate the same
> way as Python variable assignment, the *kindest* thing I can say is that
> you are ignorant.
The kindest thing I can say about you is that you are very confused
at a specific level. A confusion that is illustrated by your
contribution at
https://mail.python.org/pipermail/python-list/2017-September/726513.html
and of which you seem to totally ignore my resonse at
https://mail.python.org/pipermail/python-list/2017-September/726527.html
> Python does not have anything like C++ references and Pascal var
> parameters, which is why you will never be able to write a swap()
> function that operates like the classic Pascal swap procedure used as the
> definitive test for pass-by-reference.
You keep repeating this and you keep ignoring my counter argument.
The fact that you can write a swap procedure in C++ and Pascal
is not because the parameter passing semantics are different but
because the assignment semantics are different.
I already explained that a working swap function depends on two
conditions:
1) Reference paramaters
2) A general way in which the object a name refers to can be
modified/mutated (In a language like Pascal that is the
assignment).
You keep asserting that not being able to write a swap means we
don't have condition (1), while ignoring we know we don't have
condition (2) in Python.
> Twice you have claimed to be able to write such a swap procedure for
> lists. You can't. If you think you can, it is only because you have
> misunderstood the problem and are writing something else that does
> something different from what the Pascal version does.
I already posted code once, here it is again:
ls1 = [1, 3, 5, 7]
ls2 = [2, 4, 6]
def list_swap(lp1, lp2):
tmp = [] # pseudo declaration
tmp[:] = lp1 #
lp1[:] = lp2 # This is more or less how array assignments work in Pascal
lp2[:] = tmp #
print("ls1 =", ls1)
print("ls2 =", ls2)
list_swap(ls1, ls2)
print()
print("ls1 =", ls1)
print("ls2 =", ls2)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Parentheses (as after "print")
On 26/09/17 17:56, Stefan Ram wrote: > What happened? I woke up today in parens mood. So I typed: > > import( operator ) > > Python told me that I should type: > > import operator This is an interesting case: >>> import (os, sys) File "", line 1 import (os, sys) ^ SyntaxError: invalid syntax >>> from os import (listdir, chdir) >>> listdir, chdir (, ) >>> Of course the reasons the second syntax was eventually added to the language don't apply in the first case, but this does look a bit inconsistent... -- Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
On 27/09/17 09:50, Bill wrote: If you are teaching beginning students, do you expect them to try to follow these sorts of conventions? Is it perfectly fine to let "taste" guide you (I'm just trying to get a feel for the philosophy here)? I few years ago I wrote a few short blog posts about my own preferences which contrasted with the PEP8 standard: http://ramblings.timgolden.me.uk/2012/03/27/pep8-or-not/ http://ramblings.timgolden.me.uk/2012/03/29/more-on-pep8/ http://ramblings.timgolden.me.uk/2012/04/09/pep8-it-is-then/ The upshot was that, although I preferred my own style, I recognised the benefit of using a common standard -- although without being slavish to it! FWIW I'd already been programming Python for some years when I wrote those posts: I wasn't just someone who'd discovered the language and had no idea about its conventions. I think with a few more years of experience, both in Python and in other (mostly SQL) coding, a point I'd make is that having a common standard reduces cognitive jarring -- it reduces one small barrier to understanding someone else's code. Of course, within any organisation, you can achieve that without using Python's own convention, but my final decision was that following the more universal Python convention was worthwhile for essentially the same reason. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Aliasing [was Re: [Tutor] beginning to code]
Op 27-09-17 om 10:11 schreef Chris Angelico: > On Wed, Sep 27, 2017 at 5:38 PM, Steven D'Aprano > wrote: >> Twice you have claimed to be able to write such a swap procedure for >> lists. You can't. If you think you can, it is only because you have >> misunderstood the problem and are writing something else that does >> something different from what the Pascal version does. > I suspect what he's thinking of is a swap_contents() function, which > gives the appearance that the lists have been swapped. That's entirely > possible, but doesn't actually achieve what swap() does. If you refer to languages like Pascal or C, for illustrating that you can write a swap function in them, the swapping that happens there is one of content. So claiming that swapping contend doesn't actually achieves whar swap() does, seems wrong. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
On Wed, Sep 27, 2017 at 6:10 PM, Thomas Jollans wrote: > Personally I've found that my preferred tool, the Anaconda plugin for > Sublime Text, sometime gets PEP 8 operator spacing wrong, and complains > operators without spaces even where PEP8 explicitly recommends not using > spaces. Read PEP 8, follow it if possible, but use your best judgement. > Readability is important, blindly following your IDE's advice not so much. And most importantly, read this section: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds This is the single most important recommendation in the document. Next most important is the one immediately before it - the introduction - which specifically states that this is the style guide for *the standard library*. It's not a document which governs YOUR code, unless you specifically choose it to be. That said, though, it does reflect a lot of commonly-held views on what's good style for Python code. And in the original examples, I agree with PEP 8 on all points - no space before colon, no space inside brackets, and generally yes space around the operator. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Aliasing [was Re: [Tutor] beginning to code]
On Wed, Sep 27, 2017 at 5:38 PM, Steven D'Aprano wrote: > Twice you have claimed to be able to write such a swap procedure for > lists. You can't. If you think you can, it is only because you have > misunderstood the problem and are writing something else that does > something different from what the Pascal version does. I suspect what he's thinking of is a swap_contents() function, which gives the appearance that the lists have been swapped. That's entirely possible, but doesn't actually achieve what swap() does. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Spacing conventions
On 27/09/17 09:50, Bill wrote: > Ever since I download the MyCharm IDE a few days ago, I've been > noticing all sort of "spacing conventions (from PEP) that are > suggested. How do folks regard these in general? PEP 8 (https://www.python.org/dev/peps/pep-0008), the officially recommended style guide for Python code, is generally well regarded and widely followed. Having a consistent style, whatever it is, makes your code more readable. You can of course have your own house style, but using the same style as most other Pythonistas for new code helps other people read your code. I recommend following PEP 8 as much as possible. > > For instance, the conventions suggest that > > if x>y : > pass > > should be written > if x > y: > pass > > Personally, I like seeing a space before the colon (:). And then in > > my_list = [ i for i in range(0, 10) ] > it complains about my extra space inside of the brackets. I think you'll find that spaces before colons are exceedingly rare in Python code. Spaces inside brackets, especially in list comprehensions, may be more common. Personally I've found that my preferred tool, the Anaconda plugin for Sublime Text, sometime gets PEP 8 operator spacing wrong, and complains operators without spaces even where PEP8 explicitly recommends not using spaces. Read PEP 8, follow it if possible, but use your best judgement. Readability is important, blindly following your IDE's advice not so much. -- Thomas > > If you are teaching beginning students, do you expect them to try to > follow these sorts of conventions? Is it perfectly fine to let > "taste" guide you (I'm just trying to get a feel for the philosophy > here)? I also notice "break" and exception handling is used much > more in Python than in C++, for instance. I was taught "break" and > "continue" led to "unstructured code"--but that was a while back. I > can still see their use causing potential trouble in (really-long) > real-world code. > > Bill > > > -- https://mail.python.org/mailman/listinfo/python-list
Spacing conventions
Ever since I download the MyCharm IDE a few days ago, I've been noticing all sort of "spacing conventions (from PEP) that are suggested. How do folks regard these in general? For instance, the conventions suggest that if x>y : pass should be written if x > y: pass Personally, I like seeing a space before the colon (:). And then in my_list = [ i for i in range(0, 10) ] it complains about my extra space inside of the brackets. If you are teaching beginning students, do you expect them to try to follow these sorts of conventions? Is it perfectly fine to let "taste" guide you (I'm just trying to get a feel for the philosophy here)? I also notice "break" and exception handling is used much more in Python than in C++, for instance. I was taught "break" and "continue" led to "unstructured code"--but that was a while back. I can still see their use causing potential trouble in (really-long) real-world code. Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: auto installing dependencies with pip to run a python zip application ?
On 26 September 2017 at 23:48, Irmen de Jong wrote: > On 09/26/2017 10:49 PM, Paul Moore wrote: >> On 26 September 2017 at 19:47, Irmen de Jong wrote: >>> Any thoughts on this? Is it a good idea or something horrible? Has >>> someone attempted something like this before perhaps? >> >> When I've done this, I've bundled my dependencies in with my zipapp. >> Of course that's trickier if you have binary dependencies like pillow. > > Yeah I've considered that for a moment but I think sometimes you've also > got to deal with licensing issues. I'd rather avoid this. I'd assume you're simply bundling for convenience, but I agree that avoiding the treacherous waters of licensing is always a good idea ;-) >> What you could do is pip install your binary dependencies into a >> directory in $TEMP using --target, then add that directory to >> sys.path. Probably easier than building a full virtualenv. Bundle pip >> with your app if you can't assume your users will have pip available. > > Interesting idea, although like this wouldn't I have to download the > dependencies every time I launch my game? (unless I re-use the same > temporary directory every time) Ah, I'd assumed that's what you were doing with the virtualenv, I hadn't realised you were talking about a one-off setup step. Yeah, re-using a temporary directory doesn't buy you much compared to using a virtualenv (particularly if you can target versions of Python that have the built in venv module). Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Aliasing [was Re: [Tutor] beginning to code]
On Wed, 27 Sep 2017 08:56:03 +0200, Antoon Pardon wrote: >> But that's not enough for the variable b to be an alias for the >> variable a. > > Yes it is! Since you seem to be intent on inventing your own meanings for well established words, for the confusion and misinformation of all, I can only follow in your footsteps and say: "You are a fine fellow and your arguments make perfect sense." Make if that what you will. Antoon, there is no point in continuing this argument. You're entitled to your own opinions, but not your own facts, so when you insist: > No, the model that C++ and Pascal use is not different in this aspect. that Pascal var parameters and C++ reference variables operate the same way as Python variable assignment, the *kindest* thing I can say is that you are ignorant. Python does not have anything like C++ references and Pascal var parameters, which is why you will never be able to write a swap() function that operates like the classic Pascal swap procedure used as the definitive test for pass-by-reference. Twice you have claimed to be able to write such a swap procedure for lists. You can't. If you think you can, it is only because you have misunderstood the problem and are writing something else that does something different from what the Pascal version does. -- Steven D'Aprano “You are deluded if you think software engineers who can't write operating systems or applications without security holes, can write virtualization layers without security holes.” —Theo de Raadt -- https://mail.python.org/mailman/listinfo/python-list
Re: Aliasing [was Re: [Tutor] beginning to code]
Op 27-09-17 om 04:58 schreef Steve D'Aprano: > A pedantic difference that makes no difference to my argument. > > I see that you ignored the later assignment: > > b = 2; > > which also assigned to a. *That** is the fundamental point: b is certainly an > alias for a, and assigning to b assigns to a. > > That's how aliases work in C++. That's how var parameters in Pascal work, and > out parameters in Ada. That is what it means to say that "b is an alias to a". The main problem is that you keep using assignment as if an assignment in languages like Pascal and C++ has an similar effect like as assignment in Python and thus that if an assignment has an effect in one language it should have that effect in other languages. In C++ and Pascal talking about an assignment means, that we have a name that refers to an object whose value was overwritten. In Python an assignment means that we have name that will now refer to an other object. If two names are aliases they refer to the same object and when the value of that object is modified through one name, it is visible through the other name. How one modified that object is immaterial. It doesn't matter whether the modification/mutation was done through an asignment or an other kind of mutation. It also doesn't matter what the label is, we use for the operation. The label "assignment" is not magic. If in one context an assignment mutates and in an other context it doesn't you can't interfere conclusions about the assignment in the second context based on the effects an assignment has in the first context because we are talking about two differnt operations that just use the same lable. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Parentheses (as after "print")
On Wed, Sep 27, 2017 at 5:25 PM, Peter Otten <__pete...@web.de> wrote:
> If you want that level of -- let's call it consistency -- you should either
> plead for
>
> foo = import("foo")
>
> to spell an import
Yeah no thanks. I work also with JavaScript, and there is no benefit
whatsoever to having lines like:
const express = require("express");
Redundancy is a bad thing. Since importing is so extremely common, it
makes good sense to promote it to syntax and eliminate the redundancy.
That's why we have some things as syntax and others as functions - the
advantages outweigh the costs in some cases, but not in others.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Parentheses (as after "print")
Stefan Ram wrote:
> Why do we newbies write »print 2«? Here's another hint.
> This is an original transcript of what happened to me today:
>
> |>>> import( operator )
> | File "", line 1
> |import( operator )
> | ^
> |SyntaxError: invalid syntax
> |
> |>>> import operator
> |
> |>>> help operator
> | File "", line 1
> |help operator
> |^
> |SyntaxError: invalid syntax
> |
> |>>> help( operator )
> |Help on module operator:
>
> What happened? I woke up today in parens mood. So I typed:
>
> import( operator )
>
> Python told me that I should type:
>
> import operator
>
> . Fine, Python conditioned me to omit the parens.
> So now I was in noparens mood. So I typed:
>
> help operator
>
> . Oops!
>
> "Don't make me think!"
If you want that level of -- let's call it consistency -- you should either
plead for
foo = import("foo")
to spell an import or expect
print foo
to be syntactic sugar for
foo = __print__("foo")
(As for the ":" -- easy to read wins over easy to type.)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Parentheses (as after "print")
On Wed, 27 Sep 2017 02:48:41 +, Stefan Ram wrote: > Steve D'Aprano writes: >>"Do What I Mean" (DWIM) programming is a terrible idea. > > It's an anti-pattern, when one expects the implementation to follow > different and contradicting rules and then somehow guess what was in > the mind of the programmer. > > But it's a pattern when it means to strip the language of useless > boilerplate and still following consistent and simple rules. That was > what made Python great. Python has never followed the DWIM anti-pattern as a philosophy. DWIM goes against the Zen of Python: "In the face of ambiguity, refuse the temptation to guess." You want Python to guess that something which doesn't start with "def" and doesn't end with a colon is a function definition, rather than a class definition, or a messed up `if func(a, b)` statement, or a messed up `while func(a, b)` statement, or a messed up `with func(a, b)` statement. No thanks. -- Steven D'Aprano “You are deluded if you think software engineers who can't write operating systems or applications without security holes, can write virtualization layers without security holes.” —Theo de Raadt -- https://mail.python.org/mailman/listinfo/python-list
Re: Aliasing [was Re: [Tutor] beginning to code]
Op 27-09-17 om 04:58 schreef Steve D'Aprano:
> On Wed, 27 Sep 2017 02:03 am, Stefan Ram wrote:
>
>> Steve D'Aprano writes:
>>> On Tue, 26 Sep 2017 03:26 am, Antoon Pardon wrote:
at that moment, but it still needed correction. If the assignment is
an alias operator then after the statements
>>> Here's some C++ code that demonstrates it. Apologies in advance if it isn't
>>> the most idiomatic C++ code.
>> In C++, assignments and initializations are different
>> concepts.
>>
>>> int& b = a; // reference variable or alias
>> This is an initialization, not an assignment.
> A pedantic difference that makes no difference to my argument.
>
> I see that you ignored the later assignment:
>
> b = 2;
>
> which also assigned to a. *That** is the fundamental point: b is certainly an
> alias for a, and assigning to b assigns to a.
>
> That's how aliases work in C++. That's how var parameters in Pascal work, and
> out parameters in Ada. That is what it means to say that "b is an alias to a".
>
> b is another name for the *variable* a, not just whatever value a happens to
> hold now.
>
> I say that assignment in Python is NOT an aliasing operation. Antoon claims
> I'm
> wrong, and his evidence is:
>
> a = []
> b = a # Antoon says this is an alias operation
> b.append(1)
> assert a == [1]
>
>
> But that's not enough for the variable b to be an alias for the variable a.
Yes it is!
> Antoon is correct that a and b are two different names for the same list, but
> the two variables are not aliases to each other because assignments to b do
> not
> affect a, and vice versa.
You are hitting your blindspot again and ignore that in languages like Pascal
...
an assignment is a copy operation and thus mutates the variable that is assigned
to. Two variables are aliases for each other if they are the same object and so
when one mutates the object seen through one name, the mutation is visible
through
the other.
Since Python in Python an assignent doesn't mutate the object but makes it an
alias of an other object it is wrong to expect in python that an assignment
to one of an alias which would break the alias, would have the same effect
as in a language where an assignemt to one of an alias would mutate the
variable.
> A good test for aliasing is to take the source code and mechanically replace
> every occurrence of the alias (in the same scope of course) with the original,
No it is not. You forget the possibility that two names can be aliases at
one point but no longer are at an other point.
> or vice versa, and see whether the meaning of the code changes.
>
> In C++, apart from the initial binding:
>
> int& b = a;
>
> ("initialisation") you could now randomly swap a for b or b for a and the
> meaning of the code will not change.
That is only true for as long a and b remain aliases. As soon as an operation
is excuted that makes a and b no longer aliases, your test fails. Sure in
a language like C++ such an alias can't be broken, but aliases are broken
in Python all the time because that is what assignment do, break some
aliases and forge new ones.
> But in Python, if we try the same trick, the code *does* change:
>
> a = 1
> b = a
> b = 2
>
> *is not* the same as:
>
> a = 1
> b = a
> a = 2
>
>
> (1) In Pascal, Ada, C++ etc using a reference variable (or var parameter, or
> whatever terminology they use) makes the two names aliases to EACH OTHER, not
> to the value they are bound to.
No using a reference variable makes the two names aliases to the same
object/entity.
So that if you mutate it through one name, the mutation is visible through the
other name. The effect you see in those languages with assignments via one
name are explained by the fact that assignment is a mutating operation.
> (2) In Python, Javascript, Ruby etc assignment can give you two names for the
> same object, but the names do not alias each other.
>
> The critical distinction here is whether the names refer to each other:
>
> a <---> b
In languages like C++, Pascal, ... aliases don't mean the names refer to
each other. Names/Identifiers refering to each other is non sensical in
those languages.
>
> or whether they merely refer to the same value:
>
> a ---> [ value ] <--- b
>
>
> Python uses the second model. Var parameters in Pascal and references in C++
> use
> the first. Since the term "aliasing" is well-established for the first, using
> it in Python *without making the difference clear* is wrong.
No, the model that C++ and Pascal use is not different in this aspect.
--
Antoon Pardon.
--
https://mail.python.org/mailman/listinfo/python-list
