Re: Encapsulation in Python

On 16/03/2016 00:39, BartC wrote: On 15/03/2016 21:02, Christian Gollwitzer wrote: Nevertheless, why don't you setup a repository on an open source server, say github, and post your language implementation there? Actually I would try it out to see how it compares to other dynamic languages,

Re: Encapsulation in Python

On 15/03/2016 21:02, Christian Gollwitzer wrote: Am 14.03.16 um 23:40 schrieb BartC: On 14/03/2016 22:20, Mark Lawrence wrote: > The RUE kept stating that he was an expert in unicode, but never once > provided a single shred of evidence to support his claim. Until I see > substantiated

Re: Encapsulation in Python

Am 14.03.16 um 23:40 schrieb BartC: On 14/03/2016 22:20, Mark Lawrence wrote: > The RUE kept stating that he was an expert in unicode, but never once > provided a single shred of evidence to support his claim. Until I see > substantiated evidence from you I am going to state quite cleary

Re: Encapsulation in Python

On Monday, March 14, 2016 at 1:12:14 PM UTC-5, sohca...@gmail.com wrote: [...a whole lot of my quotes, snipped for bandwidth...] @GROUP: I don't know what the heck happened in this thread, but everyone involved was having a nice respectful conversation about encapsulation, interfaces, and

Re: Encapsulation in Python

On 15/03/2016 02:01, Steven D'Aprano wrote: On Tue, 15 Mar 2016 10:19 am, Mark Lawrence wrote: There is no need to optimise python, it is fast enough. I should of course have said on the end " for (say) 99% of purposes". Somebody should tell the core developers like Brett Cannon and

Re: Encapsulation in Python

On 15/03/2016 01:10, BartC wrote: On 15/03/2016 00:28, Mark Lawrence wrote: On 14/03/2016 23:56, BartC wrote: Anything so terrible about that that Python needs to keep well clear of or that you think its users should be deprived of? Yes, it is not even valid Python. Switch has been

Re: Encapsulation in Python

On 15/03/2016 00:56, Chris Angelico wrote: On Tue, Mar 15, 2016 at 11:47 AM, Mark Lawrence wrote: Same old story. BartC spouts drivel, just like the RUE, or Nick "The Webmaster" Greek, I'm in trouble for pointing it out. When he provides some *EVIDENCE* to back up

Re: Encapsulation in Python

On Monday, March 14, 2016 at 9:41:06 PM UTC-5, Steven D'Aprano wrote: > True. I'm just pointing out that Mark does not speak for the Python > community. In that regard, he is behaving similarly to Ranting Rick in his > claims to be the voice of the silent masses. Now hold on there D'Aprano! Don't

Re: Encapsulation in Python

On Tue, 15 Mar 2016 11:47 am, Mark Lawrence wrote: > Same old story. BartC spouts drivel, just like the RUE, or Nick "The > Webmaster" Greek, I'm in trouble for pointing it out. No, you are in trouble for being aggressive and rude. You're also wrong: Bart is not spouting "drivel". You might

Re: Encapsulation in Python

On Tue, 15 Mar 2016 01:14 pm, Chris Angelico wrote: > On Tue, Mar 15, 2016 at 1:06 PM, Steven D'Aprano > wrote: >> On Tue, 15 Mar 2016 11:25 am, Chris Angelico wrote: >> >>> Mark should be aware that, yes, his >>> actions are not in line with the CoC. >> >> >> Mark's

Re: Encapsulation in Python

On Tue, Mar 15, 2016 at 1:06 PM, Steven D'Aprano wrote: > On Tue, 15 Mar 2016 11:25 am, Chris Angelico wrote: > >> Mark should be aware that, yes, his >> actions are not in line with the CoC. > > > Mark's *technical opinions* are not in line with the Python community or the >

Re: Encapsulation in Python

On Tue, 15 Mar 2016 11:25 am, Chris Angelico wrote: > Mark should be aware that, yes, his > actions are not in line with the CoC. Mark's *technical opinions* are not in line with the Python community or the core developers either. His continual declarations that "python is fast enough" goes

Re: Encapsulation in Python

On Tue, 15 Mar 2016 10:19 am, Mark Lawrence wrote: > There is no need to optimise python, it is fast enough. Somebody should tell the core developers like Brett Cannon and Victor Stinner that they are wasting their time working on Python optimizers. Since Python is fast enough, obviously anyone

Re: Encapsulation in Python

On Tue, Mar 15, 2016 at 12:22 PM, BartC wrote: > The integer-switch is intended for use with jump-tables, which requires not > only that the case expressions are known at compile-time, but that they > don't span too large a range. > Okay, which is what I mean by "compact".

Re: Encapsulation in Python

On 15/03/2016 00:58, Chris Angelico wrote: On Tue, Mar 15, 2016 at 11:54 AM, BartC wrote: In Python, there's no reason to restrict 'switch' to integers, so I would expect its semantics to be based on either equality comparisons or inequality comparisons I use two forms of

Re: Encapsulation in Python

On Tue, Mar 15, 2016 at 12:10 PM, BartC wrote: > The one-byte-code switch works when all case expressions are known at > compile-time. It makes use of a jump-table within the byte-code. > > The total sequence will be more than one byte-code, typically: > > LOAD_FAST

Re: Encapsulation in Python

On 15/03/2016 00:28, Mark Lawrence wrote: On 14/03/2016 23:56, BartC wrote: Anything so terrible about that that Python needs to keep well clear of or that you think its users should be deprived of? Yes, it is not even valid Python. Switch has been rejected via at least one PEP and from

Re: Encapsulation in Python

On Tue, Mar 15, 2016 at 11:54 AM, BartC wrote: >> In Python, there's no reason to restrict 'switch' >> to integers, so I would expect its semantics to be based on either >> equality comparisons or inequality comparisons > > > I use two forms of switch: one for integers only (very

Re: Encapsulation in Python

On Tue, Mar 15, 2016 at 11:47 AM, Mark Lawrence wrote: > Same old story. BartC spouts drivel, just like the RUE, or Nick "The > Webmaster" Greek, I'm in trouble for pointing it out. When he provides some > *EVIDENCE* to back up his claims then I'll more than happily

Re: Encapsulation in Python

On 15/03/2016 00:12, Chris Angelico wrote: On Tue, Mar 15, 2016 at 10:56 AM, BartC wrote: switch c when 'A'..'Z','a'..'z','_' then ++name Anything so terrible about that that Python needs to keep well clear of or that you think its users should be deprived of?

Re: Encapsulation in Python

On 15/03/2016 00:25, Chris Angelico wrote: On Tue, Mar 15, 2016 at 11:17 AM, rurpy--- via Python-list wrote: On 03/14/2016 05:19 PM, Mark Lawrence wrote: On 14/03/2016 22:40, BartC wrote: [...a polite and reasonable comment...] Drivel. Any establised member of this

Re: Encapsulation in Python

On 14/03/2016 23:56, BartC wrote: On 14/03/2016 23:19, Mark Lawrence wrote: On 14/03/2016 22:40, BartC wrote: Was that in Python? It was /supposed/ to be dreadful. I was making a case for it to be supported directly. You mean the huge great long list of hard coded function calls. They are

Re: Encapsulation in Python

On Tue, Mar 15, 2016 at 11:17 AM, rurpy--- via Python-list wrote: > On 03/14/2016 05:19 PM, Mark Lawrence wrote: >> On 14/03/2016 22:40, BartC wrote: >> > [...a polite and reasonable comment...] >> >> Drivel. Any establised member of this community, or any other >>

Re: Encapsulation in Python

On 03/14/2016 05:19 PM, Mark Lawrence wrote: > On 14/03/2016 22:40, BartC wrote: > > [...a polite and reasonable comment...] > > Drivel. Any establised member of this community, or any other > community for that matter, will always publish, unless, like the RUE, > they've got something to hide.

Re: Encapsulation in Python

On Tue, Mar 15, 2016 at 10:56 AM, BartC wrote: > I disagree. And presumably so do others as there are so many different > attempts to implement switch, with varying degrees of success. Here's how I > do it outside Python: > > switch c > when 'A'..'Z','a'..'z','_' then >

Re: Encapsulation in Python

On 14/03/2016 23:19, Mark Lawrence wrote: On 14/03/2016 22:40, BartC wrote: Was that in Python? It was /supposed/ to be dreadful. I was making a case for it to be supported directly. You mean the huge great long list of hard coded function calls. They are directly supported. So is the

Re: Encapsulation in Python

On 14/03/2016 22:40, BartC wrote: On 14/03/2016 22:20, Mark Lawrence wrote: On 14/03/2016 22:07, BartC wrote: On 14/03/2016 21:23, Mark Lawrence wrote: Python 2.8, RickedPython, and the latest entry into the race, BartCPython, all vapourware. I'm not creating a new version of Python or

Re: Encapsulation in Python

On Sunday, March 13, 2016 at 6:35:40 PM UTC-5, Gregory Ewing wrote: > Unless the module is doing something obscure, you can > still find [it's source file] by following the chain of > imports. [...] True, it's not *always* that easy, but in > the vast majority of cases it is. I agree you have a

Re: Encapsulation in Python

On 14/03/2016 22:20, Mark Lawrence wrote: On 14/03/2016 22:07, BartC wrote: On 14/03/2016 21:23, Mark Lawrence wrote: Python 2.8, RickedPython, and the latest entry into the race, BartCPython, all vapourware. I'm not creating a new version of Python or CPython (you should have used an

Re: Encapsulation in Python

On 14/03/2016 22:07, BartC wrote: On 14/03/2016 21:23, Mark Lawrence wrote: Python 2.8, RickedPython, and the latest entry into the race, BartCPython, all vapourware. I'm not creating a new version of Python or CPython (you should have used an underscore). But I do have considerable

Re: Encapsulation in Python

On 14/03/2016 21:23, Mark Lawrence wrote: Python 2.8, RickedPython, and the latest entry into the race, BartCPython, all vapourware. I'm not creating a new version of Python or CPython (you should have used an underscore). But I do have considerable experience of creating dynamically-typed

Re: Encapsulation in Python

On 14/03/2016 21:09, Ian Kelly wrote: On Mon, Mar 14, 2016 at 11:32 AM, Rick Johnson wrote: Ignoring Tkinter, which is a gawd awful mess, how would you re-organize the 3,656 symbols in OpenGL.GL into smaller modules, without dividing them up along some random or

Re: Encapsulation in Python

On Mon, Mar 14, 2016 at 11:32 AM, Rick Johnson wrote: > Ignoring Tkinter, which is a gawd awful mess, how would you > re-organize the 3,656 symbols in OpenGL.GL into smaller > modules, without dividing them up along some random or > arbitrary lines? In that

Re: Encapsulation in Python

On Friday, March 11, 2016 at 6:39:53 PM UTC-8, Rick Johnson wrote: > On Friday, March 11, 2016 at 9:48:22 AM UTC-6, Ian wrote: > > On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson > > The honorable Rick Johnson wrote: > > > Many times, i would have preferred to define my module space > > > across

Re: Encapsulation in Python

On Sunday, March 13, 2016 at 5:11:50 AM UTC-5, Steven D'Aprano wrote: > On Sun, 13 Mar 2016 03:44 am, Ian Kelly wrote: > > > On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson > > wrote: > >> At run-time, i don't care how large a "module namespace" may be. > >> Sometimes

Re: Encapsulation in Python

Rick Johnson wrote: Sure, that's reliable in most cases, but your argument assumes that the actual source code for the symbol exists in the module from which it was imported, when it could just as well exist N-levels below that that module, due to chained imports. Unless the module is doing

Re: Encapsulation in Python

On Sun, 13 Mar 2016 03:44 am, Ian Kelly wrote: > On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson > wrote: >> At run-time, i don't care how large a "module namespace" may >> be. Sometimes a module namespace will be small, with only a >> few exposed symbols, but

Re: Encapsulation in Python

On Sun, Mar 13, 2016 at 2:36 PM, Rick Johnson wrote: > On Saturday, March 12, 2016 at 3:10:49 PM UTC-6, Chris Angelico wrote: >> Also, if currentModule.py is pulling foo from modX, then modZ.py is an >> implementation detail. You don't necessarily want to go straight

Re: Encapsulation in Python

On Saturday, March 12, 2016 at 3:10:49 PM UTC-6, Chris Angelico wrote: > Also, if currentModule.py is pulling foo from modX, then modZ.py is an > implementation detail. You don't necessarily want to go straight > there; tracing the chain is more likely to be the correct behaviour. > Suppose

Re: Encapsulation in Python

On Saturday, March 12, 2016 at 10:45:43 AM UTC-6, Ian wrote: > On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson > wrote: > > At run-time, i don't care how large a "module namespace" may > > be. Sometimes a module namespace will be small, with only a > > few exposed

Re: Encapsulation in Python

On Sun, Mar 13, 2016 at 3:49 AM, Rick Johnson wrote: > Imagine this scenario: > > > # currentModule.py # > > from modX import foo > > def bar(): > return foo() > > ### > # modX.py #

Re: Encapsulation in Python

On Friday, March 11, 2016 at 6:52:42 PM UTC-6, Gregory Ewing wrote: > Rick Johnson wrote: > > I have witnessed the mayhem that occurs when a language does > > not mandate module encapsulation (Ruby, i'm looking directly > > at you), and while i agree with the Python designers > > that modules

Re: Encapsulation in Python

On Fri, Mar 11, 2016 at 7:39 PM, Rick Johnson wrote: > At run-time, i don't care how large a "module namespace" may > be. Sometimes a module namespace will be small, with only a > few exposed symbols, but sometimes, a module namespace will > expose thousands of

Re: Encapsulation in Python

On Saturday, March 12, 2016 at 3:43:16 AM UTC-6, dieter wrote: > > archives, and then stuff the link down your big fat mouth? > ^^^ > > What happened that you use language like this? Obviously, > you disagree with Steven - but this should

Re: Encapsulation in Python

On Sat, Mar 12, 2016 at 8:42 PM, dieter wrote: > Rick Johnson writes: >> On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote: >> ... >> Are you sure about that? Heck, i posted code quite a few >> years back that "seg faulted

Re: Encapsulation in Python

Rick Johnson writes: > On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote: > ... > Are you sure about that? Heck, i posted code quite a few > years back that "seg faulted like a mutha". Do you want to > retract your statement, or will i need to

Re: Encapsulation in Python

On Friday, March 11, 2016 at 9:48:22 AM UTC-6, Ian wrote: > On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson wrote: > > Many times, i would have preferred to define my module space > > across multiple files, multiple files that could share state > > without resorting to the yoga-style "import

Re: Encapsulation in Python

On Friday, March 11, 2016 at 9:48:22 AM UTC-6, Ian wrote: > On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson > The honorable Rick Johnson wrote: > > Many times, i would have preferred to define my module space > > across multiple files, multiple files that could share state > > without resorting to

Re: Encapsulation in Python

(NOTE: My apologies to the group if this same message was sent twice. From my end, it appears to have been lost, so i'm sending again. Thanks) On Thursday, March 10, 2016 at 1:36:48 PM UTC-6, Mark Lawrence wrote: > On 10/03/2016 14:57, Dan Strohl via Python-list wrote: > >> I've been studying

Re: Encapsulation in Python

Rick Johnson wrote: I have witnessed the mayhem that occurs when a language does not mandate module encapsulation (Ruby, i'm looking directly at you), and while i agree with the Python designers that modules must *ALWAYS* be mandatory, i am not convinced that module space should be so

Re: Encapsulation in Python

On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote: > That's one theory. Another theory is: no they shouldn't, all attributes > should be public. That most accurately models actual physical objects and > maximizes the usefulness of the attribute. > > People over-use private,

Re: Encapsulation in Python

On Thursday, March 10, 2016 at 1:36:48 PM UTC-6, Mark Lawrence wrote: > On 10/03/2016 14:57, Dan Strohl via Python-list wrote: > >> I've been studying Object Oriented Theory using Java. Theoretically, all > >> attributes should be private, meaning no one except the methods itself can > >> access

Re: Encapsulation in Python

On 03/10/2016 02:41 PM, Ben Mezger wrote: Hi all, I've been studying Object Oriented Theory using Java. Theoretically, all attributes should be private, meaning no one except the methods itself can access the attribute; public class Foo { private int bar; ... Normally in Java, we

Re: Encapsulation in Python

On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson wrote: > Many times, i would have preferred to define my module space > across multiple files, multiple files that could share state > without resorting to the yoga-style "import contortions", > and/or the dreaded

Re: Encapsulation in Python

On Fri, Mar 11, 2016 at 2:29 AM, dieter wrote: > If you are really interested to enforce Java encapsulation policies > (access to attributes via "getter/setter" only), you will need > to use your own "metaclass". > > The "metaclass" has a similar relation to a class as a

Re: Encapsulation in Python

On Fri, 11 Mar 2016 12:41 am, Ben Mezger wrote: > Hi all, > > I've been studying Object Oriented Theory using Java. Theoretically, all > attributes should be private, meaning no one except the methods itself > can access the attribute; (Note: in the following, when I say "encapsulation", I am

Re: Encapsulation in Python

Ben Mezger writes: > I've been studying Object Oriented Theory using Java. Theoretically, all > attributes should be private, meaning no one except the methods itself > can access the attribute; > > public class Foo { > private int bar; > ... > > Normally in Java, we

Re: Encapsulation in Python

On Thursday, March 10, 2016 at 9:28:06 AM UTC-6, Ian wrote: > Encapsulation in Python is based on trust rather than the > authoritarian style of C++ / Java. The maxim in the Python > community is that "we're all consenting adults". If I > don't intend an attribute to be messed with, then I'll >

Re: Encapsulation in Python

On 10/03/2016 14:57, Dan Strohl via Python-list wrote: I've been studying Object Oriented Theory using Java. Theoretically, all attributes should be private, meaning no one except the methods itself can access the attribute; public class Foo { private int bar; ... For the benefit

Re: Encapsulation in Python

On Thu, Mar 10, 2016 at 6:41 AM, Ben Mezger wrote: > Hi all, > > I've been studying Object Oriented Theory using Java. Theoretically, all > attributes should be private, meaning no one except the methods itself > can access the attribute; > > public class Foo { > private

RE: Encapsulation in Python

> I've been studying Object Oriented Theory using Java. Theoretically, all > attributes should be private, meaning no one except the methods itself can > access the attribute; > > public class Foo { > private int bar; > ... Why? I mean sure, lots of them should be, but if I am doing

Re: Encapsulation in Python

On 10/03/2016 13:41, Ben Mezger wrote: Hi all, I've been studying Object Oriented Theory using Java. Theoretically, all attributes should be private, meaning no one except the methods itself can access the attribute; I suggest that you read