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, es
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 evide
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 that
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 modules
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 Victor
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 rejecte
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 his claims then I'll more th
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
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 n
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 *technical opinions* are not
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
> core developers eithe
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 aga
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
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". There'd be some lowest
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 switch: one for int
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_FASTThe index
> SWIT
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 wha
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 fast), and the ot
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 back off. I do
> not intend
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?
Yes: the complete
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 community, or any other
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
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
>> community for that matter, will
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. S
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
> ++name
> when '0'..
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 loop
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 CPyt
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 va
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 unders
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 experien
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
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
arbitrary lines?
In that parti
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 particular case, I wouldn't, except pos
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 mult
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 a module namespace will be sma
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 som
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 sometimes, a module namespace will
>>
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
>> there; tracing the chain is
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 modX.py
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 symbols, but sometimes, a module na
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 #
> ###
> from m
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 m
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 symbols.
Thousands, really? What sy
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 no
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 like a mutha". Do you want to
>> retract your statement
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 search the
> archives, and then stu
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 contorti
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 th
(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 Obj
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 strictl
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, and
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 th
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 wou
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 "circular import nightmares" that plag
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 class to
> an instance: i.
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 ac
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 would write getters a
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 attrib
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 o
oo {
> private int bar;
> ...
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 mark it with a
> 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 some
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
http://dirtsimple.org/2004/12/python-is-not-java.htm
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 would write getters and setters to set/get the
at
63 matches
Mail list logo
