Re: [Tutor] Why does using "window.addchr()" to place a character at the lower right corner raise an exception?

yes - usually that was the prompt for the terminal to insert a new line ... on some terminals this is a behaviour you can't control as it's implemented in hardware, so curses fakes things by moving the cursor back to where it "should" be afterward. If you try and to something when the cursor is

Re: [Tutor] Why does using "window.addchr()" to place a character at the lower right corner raise an exception?

On Wed, Feb 27, 2019 at 8:09 PM Alex Kleider wrote: > > On 2019-02-27 17:48, boB Stepp wrote: > > Under https://docs.python.org/3/library/curses.html#window-objects in > > the curses docs, it states: > > > > > > window.addch(ch[, attr]) > > window.addch(y, x, ch[, attr]) > > [...] > > > > Note >

Re: [Tutor] Why does using "window.addchr()" to place a character at the lower right corner raise an exception?

On 2019-02-27 17:48, boB Stepp wrote: Under https://docs.python.org/3/library/curses.html#window-objects in the curses docs, it states: window.addch(ch[, attr]) window.addch(y, x, ch[, attr]) [...] Note Writing outside the window, subwindow, or pad raises a curses.error. Attempting to write t

[Tutor] Why does using "window.addchr()" to place a character at the lower right corner raise an exception?

Under https://docs.python.org/3/library/curses.html#window-objects in the curses docs, it states: window.addch(ch[, attr]) window.addch(y, x, ch[, attr]) [...] Note Writing outside the window, subwindow, or pad raises a curses.error. Attempting to write to the lower right corner of a window, su

Re: [Tutor] why can use a widget assigned to a variable or just use it on it's own?

On Mon, Jul 02, 2018 at 11:54:08AM +1000, Chris Roy-Smith wrote: > Hi, > > I'm trying to understand working with objects. > > If I have grasped things correctly a widget is an object. In Python, all values are objects. (That's not the case in all languages.) > So why can I > assign the widge

Re: [Tutor] why can use a widget assigned to a variable or just use it on it's own?

On 02/07/18 02:54, Chris Roy-Smith wrote: > If I have grasped things correctly a widget is an object. Every value in Python is an object. numbers, strings, lists, functions, instances of classes. All are objects. You can see that by using the dir() function on them: >>> dir(5) ['__abs__', '__a

Re: [Tutor] why can use a widget assigned to a variable or just use it on it's own?

Op 02-07-18 om 03:54 schreef Chris Roy-Smith: Hi, I'm trying to understand working with objects. If I have grasped things correctly a widget is an object. So why can I assign the widget, or use it stand alone? See sample code below = #!/usr/bin/python3 from tkinter impor

[Tutor] why can use a widget assigned to a variable or just use it on it's own?

Hi, I'm trying to understand working with objects. If I have grasped things correctly a widget is an object. So why can I assign the widget, or use it stand alone? See sample code below = #!/usr/bin/python3 from tkinter import * main=Tk() # as I understand it this will c

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On 10/01/18 20:20, eryk sun wrote: > ... And working with COM via ctypes is also complex, which is why > comtypes exists. Or easier still Pythonwin (aka PyWin32). I far prefer pythonwin over ctypes for any kind of COM work. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Wed, Jan 10, 2018 at 12:59 PM, Albert-Jan Roskam wrote: > > I tried: from os.path import _getfullpathname _getfullpathname(r"H:") > 'h:\\path\\to\\folder' import os os.getcwd() > 'h:\\path\\to\\folder' > > I expected h:\ to be \\server\share\foo. You called _getfullpathname

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

From: eryk sun Sent: Wednesday, January 10, 2018 3:56 AM To: tutor@python.org Cc: Albert-Jan Roskam Subject: Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?   On Tue, Jan 9, 2018 at 2:48 PM, Albert-

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Tue, Jan 9, 2018 at 2:48 PM, Albert-Jan Roskam wrote: > > I think that it would be a great enhancement if os.realpath would return the > UNC path if > given a mapped drive in Windows, if needed as extended path (prefixed with > "\\?\UNC\"). > That's something I use all the time, unlike symlin

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

From: Tutor on behalf of Steven D'Aprano Sent: Tuesday, January 9, 2018 8:47 AM To: tutor@python.org Subject: Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?   > The Python 3

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Mon, Jan 08, 2018 at 05:08:49PM -0600, boB Stepp wrote: > Hi Steve, > > On Mon, Jan 8, 2018 at 12:47 AM, Steven D'Aprano wrote: > > > As I actually explained in my previous email, the one which has > > disappeared into the aether, ... > > Do you still have the email you sent? I would like t

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Sun, Jan 07, 2018 at 03:07:26AM -0600, boB Stepp wrote: > After some searching I have yet to locate a definition of "canonical > path" that makes sense to me. The dictionary definition of canonical > does not seem to be very helpful in understanding this. Probably the best definition would be

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Sun, Jan 7, 2018 at 10:51 AM, Albert-Jan Roskam wrote: > > On Jan 7, 2018 09:08, Steven D'Aprano wrote: >> >> realpath() returns the canonical path of the given filename. It doesn't >> try to locate some actual existing file. > > I always thought that os.path.realpath is the Python equivalent

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Mon, Jan 08, 2018 at 12:39:07AM +, Alan Gauld via Tutor wrote: > To be fair realpath() does do a tiny bit of magic in that it > checks if the file (or any part of the path) is a link (aka > shortcut) and tries to give you the actual path to the > original file - ie it follows the link. As

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On 08/01/18 00:17, boB Stepp wrote: >> The os.path module is mostly a string manipulation toolkit. > > This is the critical piece that was eluding me. I assumed that the > actual file system was being queried, checked and expanded as needed. To be fair realpath() does do a tiny bit of magic in

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Sun, Jan 7, 2018 at 8:32 AM, Alan Gauld via Tutor wrote: > On 07/01/18 09:07, boB Stepp wrote: >> clarify this? What is the methodology that os.path.realpath(path) is >> actually following to yield a particular path name? And why does it >> not care if path refers to a real file or not? > > T

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Sun, Jan 7, 2018 at 4:51 AM, Albert-Jan Roskam wrote: > > On Jan 7, 2018 09:08, Steven D'Aprano wrote: >> realpath() returns the canonical path of the given filename. It doesn't >> try to locate some actual existing file. > > I always thought that os.path.realpath is the Python equivalent of

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On 07/01/18 09:07, boB Stepp wrote: > clarify this? What is the methodology that os.path.realpath(path) is > actually following to yield a particular path name? And why does it > not care if path refers to a real file or not? The os.path module is mostly a string manipulation toolkit. It checks

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Jan 7, 2018 09:08, Steven D'Aprano wrote: > > On Sun, Jan 07, 2018 at 12:49:59AM -0600, boB Stepp wrote: > > > Win7, Python 3.6.2 > > > > If I run a unit test with the following embedded: > > > > print('realpath =', os.path.realpath('test_main.py')) > > > > I get the following in my test outpu

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Sun, Jan 7, 2018 at 2:05 AM, Steven D'Aprano wrote: > On Sun, Jan 07, 2018 at 12:49:59AM -0600, boB Stepp wrote: > >> Win7, Python 3.6.2 >> >> If I run a unit test with the following embedded: >> >> print('realpath =', os.path.realpath('test_main.py')) >> >> I get the following in my test outpu

Re: [Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

On Sun, Jan 07, 2018 at 12:49:59AM -0600, boB Stepp wrote: > Win7, Python 3.6.2 > > If I run a unit test with the following embedded: > > print('realpath =', os.path.realpath('test_main.py')) > > I get the following in my test output (Only relevant line is shown): > > Ensure expected list of s

[Tutor] Why does os.path.realpath('test_main.py') give different results for unittest than for testing statement in interpreter?

Win7, Python 3.6.2 If I run a unit test with the following embedded: print('realpath =', os.path.realpath('test_main.py')) I get the following in my test output (Only relevant line is shown): Ensure expected list of string integers is returned. ... realpath = c:\Projects\solitaire_scorekeeper\t

Re: [Tutor] Why use main() ?

In most cases, my scripts tend to be pretty self-contained and written for my own purposes, so that would rarely be an issue. How would you hide main() if you _were_ concerned about it? The "main" option would be to move the body of main() to a separate file, which imports the original file as

Re: [Tutor] Why use main() ?

* Mats Wichmann [2017-07-05 16:47]: > > > > As a vaguely contradictory position to a part of this (which I in the > main agree with): if your objective is to make a module, and also have > some code (perhaps including test code) which is run in the non-module > (aka not-imported) case, then stuf

Re: [Tutor] Why use main() ?

On 07/05/2017 09:45 AM, Zachary Ware wrote: > On Wed, Jul 5, 2017 at 10:37 AM, David Rock wrote: >> I personally find using main() cumbersome, but many examples I come >> across use main(). Is there some fundamental benefit to using main() >> that I'm missing? > > In no particular order: testin

Re: [Tutor] Why use main() ?

* Alan Gauld via Tutor [2017-07-05 20:36]: > On 05/07/17 16:37, David Rock wrote: > > > This is a question about the benefits of using a main() function vs not. > > > Others have answered for the pros, but I confess that I don't > always use a main(), but only if all I'm doing is, say, > instan

Re: [Tutor] Why use main() ?

On 05/07/17 16:37, David Rock wrote: > This is a question about the benefits of using a main() function vs not. Others have answered for the pros, but I confess that I don't always use a main(), but only if all I'm doing is, say, instantiating a class and running a method. For anything more comp

Re: [Tutor] Why use main() ?

>> I personally find using main() cumbersome, but many examples I come >> across use main(). Is there some fundamental benefit to using main() >> that I'm missing? > > In no particular order: testing, encapsulation, and reusability. With > a "main()" function (which, recall, can be named whatever

Re: [Tutor] Why use main() ?

On Wed, Jul 5, 2017 at 10:37 AM, David Rock wrote: > This is not a question about using if __name__ == '__main__':. I know > what the difference is between running the script or importing it and > using the value of __name__ to determine behavior. > > This is a question about the benefits of usin

[Tutor] Why use main() ?

This is not a question about using if __name__ == '__main__':. I know what the difference is between running the script or importing it and using the value of __name__ to determine behavior. This is a question about the benefits of using a main() function vs not. ie, if __name__ == '__main__

Re: [Tutor] why it is showing attribute error in line7

Hello, and welcome! Please always post the FULL traceback. Python gives you lots of information to debug problems, so you don't have to guess, but when you throw that information away, we have to guess. My guess follows below: On Fri, Oct 28, 2016 at 09:42:35PM -0700, SONU KUMAR wrote: > fname

Re: [Tutor] why it is showing attribute error in line7

Please always post the full error text in future. Meanwhile I'll guess: On 29/10/16 05:42, SONU KUMAR wrote: > fname = raw_input("Enter file name: ") > if len(fname) < 1 : fname = "mbox-short.txt" > fh = open(fname) > count = 0 > for line in fh: >line=line.rstrip missing parens means you re

[Tutor] why it is showing attribute error in line7

fname = raw_input("Enter file name: ") if len(fname) < 1 : fname = "mbox-short.txt" fh = open(fname) count = 0 for line in fh: line=line.rstrip if not line.startswith("From"):continue lst=line.split() print lst[1] count=count+1 print "There were", count, "lines in the file with Fro

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

On Sat, Jun 18, 2016 at 09:04:10PM -0700, Danny Yoo wrote: > > You know Steve, as I was typing the beginning of a reply responding to > > a similar question you asked earlier in your response, I suddenly > > realized how ridiculous having a parameter of 'col/2' is! I'll just > > have either eat cr

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

On Sun, Jun 19, 2016 at 4:04 AM, Danny Yoo wrote: > >> def f((x,y), z): > ... print x, y, z > ... >> f([1, 2], 3) > 1 2 3 Note that Python 3 doesn't support tuple parameter unpacking. See PEP 3113: https://www.python.org/dev/peps/pep-3113 ___ Tu

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

One other thing to add: the notion of pattern matching is often used in mathematics. For example, if we want to define a function that does something special to even numbers vs. odd numbers, it's not uncommon to see the following when we want to describe a function `f`: for `n` in the natural num

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

> You know Steve, as I was typing the beginning of a reply responding to > a similar question you asked earlier in your response, I suddenly > realized how ridiculous having a parameter of 'col/2' is! I'll just > have either eat crow or attribute this to a brain fart. You pick! Just to play dev

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

On Sat, Jun 18, 2016 at 9:10 PM, Steven D'Aprano wrote: > On Sat, Jun 18, 2016 at 02:04:46PM -0500, boB Stepp wrote: > Can you explain what you expected > > def d(row, col/2) > > to mean? I have literally no idea. You know Steve, as I was typing the beginning of a reply responding to a similar q

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

On Sat, Jun 18, 2016 at 02:04:46PM -0500, boB Stepp wrote: > I have (Finally!) gotten a bit of time to look at Peter's answer to my > Model-View-Controller question from May 29th, particularly his > CircleImageView class to which he added a "#FIXME" comment. I thought > it would be helpful to abbr

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

On 18/06/16 20:04, boB Stepp wrote: > py3: def d(row, col/2, radius=5): > File "", line 1 > def d(row, col/2, radius=5): > ^ > SyntaxError: invalid syntax > > And this surprised me. It seems that only identifiers are allowed as > parameters in a function definition statem

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

On Sat, Jun 18, 2016 at 3:14 PM, Joel Goldstick wrote: > On Sat, Jun 18, 2016 at 3:04 PM, boB Stepp wrote: >> Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 >> 64 bit (AMD64)] on win32 >> Type "help", "copyright", "credits" or "license" for more information. >> py3: def d(

Re: [Tutor] Why are expressions not allowed as parameters in function definition statements?

On Sat, Jun 18, 2016 at 3:04 PM, boB Stepp wrote: > I have (Finally!) gotten a bit of time to look at Peter's answer to my > Model-View-Controller question from May 29th, particularly his > CircleImageView class to which he added a "#FIXME" comment. I thought > it would be helpful to abbreviate h

[Tutor] Why are expressions not allowed as parameters in function definition statements?

I have (Finally!) gotten a bit of time to look at Peter's answer to my Model-View-Controller question from May 29th, particularly his CircleImageView class to which he added a "#FIXME" comment. I thought it would be helpful to abbreviate his distance function in the interpreter while I played arou

Re: [Tutor] Why does 01 give a syntax error, but 00 (or 00...0) does not?

On Sat, Mar 5, 2016 at 11:32 PM, Steven D'Aprano wrote: > On Sat, Mar 05, 2016 at 05:20:21PM -0600, boB Stepp wrote: > >> Why do zeros not give a syntax error, but other numbers with a leading >> zero do give a syntax error? An online search reveals that in Python >> 2 a leading 0 starts an octal

Re: [Tutor] Why does 01 give a syntax error, but 00 (or 00...0) does not?

On Sat, Mar 05, 2016 at 05:20:21PM -0600, boB Stepp wrote: > Why do zeros not give a syntax error, but other numbers with a leading > zero do give a syntax error? An online search reveals that in Python > 2 a leading 0 starts an octal number, but this was changed in Python > 3. But then why is 0

Re: [Tutor] Why does 01 give a syntax error, but 00 (or 00...0) does not?

Ben Finney writes: > Hmm. That is a confusing inconsistency, I agree. It is deliberate, and > explicitly documented: > > Note that leading zeros in a non-zero decimal number are not > allowed. This is for disambiguation with C-style octal literals, > which Python used before version 3

Re: [Tutor] Why does 01 give a syntax error, but 00 (or 00...0) does not?

On 05/03/16 23:33, Ben Finney wrote: >> But then why is 00...0 valid, that is, does not give a syntax error? > > At one level, the answer is: because the language reference declares > those rules for the syntax. > > At another level, the answer is: I don't know why that decision was > made, and

Re: [Tutor] Why does 01 give a syntax error, but 00 (or 00...0) does not?

boB Stepp writes: > >>> 01 > File "", line 1 > 01 > ^ > SyntaxError: invalid token As you later explain, this is because in Python 3 the obsolete “leading 0 for octal notation” is invalid syntax. (Superseded by “leading ‘0o’ for octal notation”). > >>> 00 > 0 > >>> -00 > 0 > >>> 000

[Tutor] Why does 01 give a syntax error, but 00 (or 00...0) does not?

>>> 01 File "", line 1 01 ^ SyntaxError: invalid token >>> 00 0 >>> -00 0 >>> 000 0 Why do zeros not give a syntax error, but other numbers with a leading zero do give a syntax error? An online search reveals that in Python 2 a leading 0 starts an octal number, but this was changed in

Re: [Tutor] Why define a function inside a function?

Thank you to both you and Ben for taking the time and answering my question! The detailed explanation of the example code I provided really helped and made things clear. As did the explanations about closures and a simplified example. I definitely have a lot to learn, but this was very educational

Re: [Tutor] Why define a function inside a function?

Oops, I screwed up! On Sat, Jan 30, 2016 at 02:31:09PM +1100, Steven D'Aprano wrote: > Complicated? Well, a bit. Here's a simpler demonstration of a closure: > > > def factory(num): > """Factory function that returns a new function that adds > num to whatever it is given.""" > def

Re: [Tutor] Why is the name "self" optional instead of mandatory?

On Fri, Jan 22, 2016 at 11:10:39PM -0600, boB Stepp wrote: > Am I understanding this correctly? It appears to me that you have > successfully added a method to class X from outside of class X! If > this is the case, then this clarifies some things I was wondering > about in my other thread. If

Re: [Tutor] Why define a function inside a function?

On Fri, Jan 29, 2016 at 04:29:14PM -0500, Ryan Smith wrote: > Hi all, > > I am new to programming and python and had a question. I hope I > articulate this well enough so here it goes... I was following along > on a thread on this mailing list discussing how to test file I/O > operations. In one o

Re: [Tutor] Why define a function inside a function?

Ryan Smith writes: > In trying to understand the logic behind the code for my own > edification, I was wondering what is the reasoning of defining a > function in side another function (for lack of a better phrase)? Sometimes a function is so specific to the workings of another function that it

[Tutor] Why define a function inside a function?

Hi all, I am new to programming and python and had a question. I hope I articulate this well enough so here it goes... I was following along on a thread on this mailing list discussing how to test file I/O operations. In one of the suggested solutions the following code was used: def _open_as_st

Re: [Tutor] Why is an OrderedDict not sliceable?

> Date: Wed, 27 Jan 2016 02:24:35 +1100 > From: st...@pearwood.info > To: tutor@python.org > Subject: Re: [Tutor] Why is an OrderedDict not sliceable? > > On Sun, Jan 24, 2016 at 07:47:47PM +, Albert-Jan Roskam wrote: > >>&

Re: [Tutor] Why is an OrderedDict not sliceable?

On Sun, Jan 24, 2016 at 07:47:47PM +, Albert-Jan Roskam wrote: > > You appear to be confusing ordered and sorted. > > You are correct. Is there a difference in the way those terms are > used colloquially vs. in the field of Computer Science (Note: English > is not my mother tongue)? In

Re: [Tutor] Why is an OrderedDict not sliceable?

On 24 January 2016 at 20:29, Albert-Jan Roskam wrote: >> I guess that the authors of OrderedDict just didn't really consider >> this to be very useful. Apart from having ordered iteration >> OrderedDict is not really that deeply thought out. There's a thread on >> python-ideas about the inconsiste

Re: [Tutor] Why is an OrderedDict not sliceable?

On 24 January 2016 at 19:47, Albert-Jan Roskam wrote: >> >> You appear to be confusing ordered and sorted. > You are correct. Is there a difference in the way those terms are used > colloquially vs. in the field of Computer Science (Note: English is not my > mother tongue)? Anyway, this page

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Sat, Jan 23, 2016 at 04:25:01PM -0600, boB Stepp wrote: > I think I now have this nuked out. I am only just now realizing how > powerful .__dict__ is: [...] > self.__dict__[attribute_name] = attribute_value Indeed, but generally speaking you hardly ever need to manually operate w

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Fri, Jan 22, 2016 at 10:14:57PM -0600, boB Stepp wrote: > On Thu, Jan 21, 2016 at 4:57 AM, Steven D'Aprano wrote: > > def spam(x, y): > > ... > > > > spam.extra_info = "whatever" > > A new thing that I did not suspect I could do. This bothers me for two > reasons: > > 1) It does n

Re: [Tutor] Why is the name "self" optional instead of mandatory?

On Fri, Jan 22, 2016 at 11:10:39PM -0600, boB Stepp wrote: > On Thu, Jan 21, 2016 at 5:49 AM, Steven D'Aprano wrote: > > class X: > > pass > > > > def func(this): > > print("instance %r called method" % this) > > > > X.method = func > > Am I understanding this correctly? It appears to m

Re: [Tutor] Why is an OrderedDict not sliceable?

On 24/01/2016 20:23, Albert-Jan Roskam wrote: I appear to have confused the terms "sorted" and "ordered" (see the email I just sent to Mark Lawrence). My OrderedDict was sorted on its keys, because I defined the dict using the result of an SQL query that ended with ORDER BY . So in that case

Re: [Tutor] Why is an OrderedDict not sliceable?

> From: oscar.j.benja...@gmail.com > Date: Thu, 21 Jan 2016 11:02:40 + > To: ben+pyt...@benfinney.id.au > Subject: Re: [Tutor] Why is an OrderedDict not sliceable? > CC: tutor@python.org > > On 21 January 2016 at 09:19, Ben Finney wrote: > > Albert-Jan Roskam

Re: [Tutor] Why is an OrderedDict not sliceable?

> To: tutor@python.org > From: ben+pyt...@benfinney.id.au > Date: Fri, 22 Jan 2016 04:12:08 +1100 > Subject: Re: [Tutor] Why is an OrderedDict not sliceable? > > Ben Finney writes: > > > Oscar Benjamin writes: > > > > > According to a narrow defi

Re: [Tutor] Why is an OrderedDict not sliceable?

> Date: Fri, 22 Jan 2016 11:00:00 +1100 > From: st...@pearwood.info > To: tutor@python.org > Subject: Re: [Tutor] Why is an OrderedDict not sliceable? > > Further thoughts on your question... > > > On Wed, Jan 20, 2016 at 01:33:17PM +, Albert-Jan Roskam wrote

Re: [Tutor] Why is an OrderedDict not sliceable?

> To: tutor@python.org > From: alan.ga...@btinternet.com > Date: Fri, 22 Jan 2016 00:12:18 + > Subject: Re: [Tutor] Why is an OrderedDict not sliceable? > > On 22/01/16 00:00, Steven D'Aprano wrote: > > > Also, you have a problem -- what happens if the inc

Re: [Tutor] Why is an OrderedDict not sliceable?

> To: tutor@python.org > From: breamore...@yahoo.co.uk > Date: Thu, 21 Jan 2016 21:02:03 + > Subject: Re: [Tutor] Why is an OrderedDict not sliceable? > > On 20/01/2016 13:33, Albert-Jan Roskam wrote: > > Hi, > > > > Like the subject says: Why is an

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 24/01/16 03:07, boB Stepp wrote: >> In pure OO objects should only expose methods and the data >> attributes should only be there to support the methods. > > Apparently what OOP knowledge I started out with agrees strongly with > what you say here. But this level of *purity* appears to be > n

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Sat, Jan 23, 2016 at 7:20 PM, Alan Gauld wrote: > On 23/01/16 09:30, Cameron Simpson wrote: > >> Alan will take you up on doing purer OO practices in Python. > > In pure OO objects should only expose methods and the data > attributes should only be there to support the methods. > As such, nobod

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 23/01/16 09:30, Cameron Simpson wrote: > Alan will take you up on doing purer OO practices in Python. In pure OO objects should only expose methods and the data attributes should only be there to support the methods. As such, nobody outside the object has any need to know anything about it. An

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 23/01/16 19:17, boB Stepp wrote: > "_single_leading_underscore : weak "internal use" indicator. E.g. from > M import * does not import objects whose name starts with an > underscore." > > My current understanding is to avoid "from M import *", but it is good > to know that this style of import

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 23Jan2016 16:25, boB Stepp wrote: On Sat, Jan 23, 2016 at 12:55 PM, boB Stepp wrote: I still would like to do this via a method, but I am currently stuck on how to replace ??? with the attribute name I would like to insert: class Dog(object): ... def add_attribute(self, attribute_

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 23Jan2016 12:55, boB Stepp wrote: On Sat, Jan 23, 2016 at 3:30 AM, Cameron Simpson wrote: On 23Jan2016 01:52, boB Stepp wrote: I guess no matter how new one is to OOP, one nevertheless brings one's preconceptions, however malformed, into the learning process. In my case, one of mine was

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Sat, Jan 23, 2016 at 12:55 PM, boB Stepp wrote: > I still would like to do this via a method, but I am currently stuck > on how to replace ??? with the attribute name I would like to insert: > > class Dog(object): > ... > > def add_attribute(self, attribute_name, attribute_value): >

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Sat, Jan 23, 2016 at 12:07 PM, Danny Yoo wrote: > But Python has very little of this as a built-in part of the language. > Guarding who gets to touch something is instead done by convention and > by a very thin mechanism of name-mangling via an uncommonly-seen > character, the underscore "_".

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Sat, Jan 23, 2016 at 3:30 AM, Cameron Simpson wrote: > On 23Jan2016 01:52, boB Stepp wrote: >> I guess no matter how new one is to OOP, one nevertheless brings one's >> preconceptions, however malformed, into the learning process. In my >> case, one of mine was that once a class is coded, a

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

> But if I am understanding everyone's comments correctly, Python allows > me write my classes in such a way, that public access to my object's > internals is controlled, in the sense that Python has coding > conventions that tell all of the quite intelligent, respectful, > consenting adults that m

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 23Jan2016 01:52, boB Stepp wrote: On Fri, Jan 22, 2016 at 11:04 PM, Cameron Simpson wrote: On 22Jan2016 22:14, boB Stepp wrote: All you're missing is realising that setting an attribute is not a special operation. I guess no matter how new one is to OOP, one nevertheless brings one's pre

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 23/01/16 04:14, boB Stepp wrote: > humdrum.sigh_strenght = 'high' > > was accepted and did not generate an error, it seemed to mean to me > that I was violating my object's data encapsulation. In fact you were adding to its encapsulation(*). Encapsulation means putting things in a box. You

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Fri, Jan 22, 2016 at 11:04 PM, Cameron Simpson wrote: > On 22Jan2016 22:14, boB Stepp wrote: [...] > Consider: this is information you want assicated with a specific object. > Therefore it really _is_ an arribute of the object so that it can follow it > around. > >> And what bothered me abou

Re: [Tutor] Why is the name "self" optional instead of mandatory?

On Thu, Jan 21, 2016 at 5:49 AM, Steven D'Aprano wrote: > On Wed, Jan 20, 2016 at 09:42:29PM -0600, boB Stepp wrote: > >> So I really only have one question: Why not make Python's >> *traditional* name, "self", mandatory? Why give the programmer this >> kind of choice? [OK, that was two questio

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On 22Jan2016 22:14, boB Stepp wrote: On Thu, Jan 21, 2016 at 4:57 AM, Steven D'Aprano wrote: Danny is correct. And it is a useful feature too. For instance, we can add attributes to functions: def spam(x, y): ... spam.extra_info = "whatever" A new thing that I did not suspect I could d

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Thu, Jan 21, 2016 at 4:57 AM, Steven D'Aprano wrote: > On Wed, Jan 20, 2016 at 09:54:32PM -0800, Danny Yoo wrote: > >> Just to be explicit: you are pointing out that: >> >> humdrum.sigh_strenght = 'high' >> >> was a typo, and it would have been nice if it could be caught as an error. >> >>

Re: [Tutor] Why is an OrderedDict not sliceable?

On 20/01/2016 13:33, Albert-Jan Roskam wrote: Hi, Like the subject says: Why is an OrderedDict not sliceable? (From the collections library). Was that an intentional omission, or a mistake? [1] Plenty of answers on this all ready, but... Background: I do not use OrderedDict very often, but

Re: [Tutor] Why is an OrderedDict not sliceable?

On 22/01/16 00:00, Steven D'Aprano wrote: > Also, you have a problem -- what happens if the incomplete postcode is > missing the first digit? (I suppose for that case, you just have to do a > slow linear search.) Which is why a different solution may be better suited. What about an in-memory S

Re: [Tutor] Why is an OrderedDict not sliceable?

Further thoughts on your question... On Wed, Jan 20, 2016 at 01:33:17PM +, Albert-Jan Roskam wrote: > Hi, > > Like the subject says: Why is an OrderedDict not sliceable? (From the > collections library). Was that an intentional omission, or a mistake? > [1] > > Background: I do not use Or

Re: [Tutor] Why is an OrderedDict not sliceable?

Ben Finney writes: > Oscar Benjamin writes: > > > According to a narrow definition of indexed access. I would say that > > d[k] is index access even if d is a dict and k a key. The sense of “index” implied is used consistently throughout Python https://docs.python.org/3/glossary.html> to refer

Re: [Tutor] Why is an OrderedDict not sliceable?

Oscar Benjamin writes: > According to a narrow definition of indexed access. I would say that > d[k] is index access even if d is a dict and k a key. An index implies the ordinal position in a sequence. In a mapping, the key is *not* referring to the position in a sequence, so is not a key. So

Re: [Tutor] Why is the name "self" optional instead of mandatory?

On Thu, Jan 21, 2016 at 6:49 AM, Steven D'Aprano wrote: > On Wed, Jan 20, 2016 at 09:42:29PM -0600, boB Stepp wrote: > > > So I really only have one question: Why not make Python's > > *traditional* name, "self", mandatory? Why give the programmer this > > kind of choice? [OK, that was two qu

Re: [Tutor] Why is the name "self" optional instead of mandatory?

On Wed, Jan 20, 2016 at 09:42:29PM -0600, boB Stepp wrote: > So I really only have one question: Why not make Python's > *traditional* name, "self", mandatory? Why give the programmer this > kind of choice? [OK, that was two questions.] Why bother making it mandatory? That just makes more work

Re: [Tutor] Why is an OrderedDict not sliceable?

On 21 January 2016 at 09:19, Ben Finney wrote: > Albert-Jan Roskam writes: > >> Why is an OrderedDict not sliceable? > > Because slicing implies index access. The built-in ‘dict’ and > ‘collections.OrderedDict’ both do not support indexed access:: According to a narrow definition of indexed acce

Re: [Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

On Wed, Jan 20, 2016 at 09:54:32PM -0800, Danny Yoo wrote: > Just to be explicit: you are pointing out that: > > humdrum.sigh_strenght = 'high' > > was a typo, and it would have been nice if it could be caught as an error. > > If that's the case, then yes, I agree. Unfortunately, this isn

Re: [Tutor] Why is the name "self" optional instead of mandatory?

On 21/01/16 03:42, boB Stepp wrote: > So I really only have one question: Why not make Python's > *traditional* name, "self", mandatory? Why give the programmer this > kind of choice? [OK, that was two questions.] Because to do otherwise would introduce all sorts of extra complexity into the s

Re: [Tutor] Why is the name "self" optional instead of mandatory?

The answer to this will be an interesting read... :) This email has been sent from a virus-free computer protected by Avast. www.avast.com

Re: [Tutor] Why is an OrderedDict not sliceable?

Albert-Jan Roskam writes: > Why is an OrderedDict not sliceable? Because slicing implies index access. The built-in ‘dict’ and ‘collections.OrderedDict’ both do not support indexed access:: >>> import collections >>> foo = collections.OrderedDict([ ... ('a', 1), ('b', 2), ('

Re: [Tutor] Why is an OrderedDict not sliceable?

> Date: Thu, 21 Jan 2016 12:00:29 +1100 > From: st...@pearwood.info > To: tutor@python.org > Subject: Re: [Tutor] Why is an OrderedDict not sliceable? > > On Wed, Jan 20, 2016 at 01:33:17PM +, Albert-Jan Roskam wrote: > > Hi, > > > > Like the sub

  1   2   3   4   5   6   7   >