Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #104528 > unrolled thread

Re: Encapsulation in Python

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-10 08:27 -0700
    Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-10 16:45 -0800
      Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-11 08:47 -0700
        Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-11 18:39 -0800
          Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-12 09:44 -0700
            Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-12 19:11 -0800
            Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-13 21:11 +1100
              Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 10:32 -0700
                Re: Encapsulation in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-14 15:09 -0600
                Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 21:23 +0000
                  Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-14 22:07 +0000
                    Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 22:20 +0000
                      Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-14 22:40 +0000
                        Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 23:19 +0000
                          Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-14 23:56 +0000
                            Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:12 +1100
                              Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-15 00:54 +0000
                                Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:58 +1100
                                  Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-15 01:22 +0000
                                    Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 13:02 +1100
                            Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 00:28 +0000
                              Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-15 01:10 +0000
                                Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 12:23 +1100
                                Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 04:41 +0000
                          Re: Encapsulation in Python rurpy@yahoo.com - 2016-03-14 17:17 -0700
                            Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:25 +1100
                              Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:06 +1100
                                Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 13:14 +1100
                                  Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:40 +1100
                                    Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 21:08 -0700
                            Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 00:47 +0000
                              Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:46 +1100
                            Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-15 11:56 +1100
                            Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 04:36 +0000
                          Re: Encapsulation in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:01 +1100
                            Re: Encapsulation in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 04:45 +0000
                        Re: Encapsulation in Python Christian Gollwitzer <auriocus@gmx.de> - 2016-03-15 22:02 +0100
                          Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-16 00:39 +0000
                            Re: Encapsulation in Python BartC <bc@freeuk.com> - 2016-03-16 22:58 +0000
          Re: Encapsulation in Python sohcahtoa82@gmail.com - 2016-03-14 11:11 -0700
            Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 23:09 -0700
        Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-11 18:56 -0800
      Re: Encapsulation in Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-12 13:52 +1300
        Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-12 08:49 -0800
          Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-13 08:10 +1100
            Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-12 19:36 -0800
              Re: Encapsulation in Python Chris Angelico <rosuav@gmail.com> - 2016-03-13 15:05 +1100
          Re: Encapsulation in Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-14 12:35 +1300
            Re: Encapsulation in Python Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-14 15:55 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#104884

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 directly supported.  So is the loop.  Anything wrong with the Paul
>> Rubin response?
>
> I tried it. It wasn't bad, but still 1/3 the speed of an if-elif chain
> with discrete range-checking.

I still haven't seen the profile that I asked for, so I've no idea what 
is taking the time.

>
>> And as my earlier link showed you often simply don't
>> need a switch statement in an OO language.  Not much point providing
>> something, much worse optimising it, if it isn't needed in the first
>> place?
>
> 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'..'9' then
>       ++numeric
>   when "()[]<>{}" then
>       ++brackets
>   else
>       ++other
>   end
>
> 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 what I see it adds nothing to the language, so let's 
deprive it from people who clearly don't need it in the first place.

>
>>> Sorry, I'm not going to do that, and I don't expect anyone here to have
>>> to do so either. You will have to take my posts as they are.
>>>
>>
>> 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.  So you're just a chicken.  Where do you buy the
>> paint from for the streaks down your back?
>
> OK, we've got another Rod Speed! He also gets a kick out of being rude
> and insulting to everyone.

I am only rude to people such as yourself who refuse to provide code, in 
fact anything, to support your case.  Your "benchmark" for the switch 
was yet another laughable farce, which only tested the function calls, 
building tuples, running loops, there was nothing to test with respect 
to the actual switch which was meant to be tested.  So just in case you 
missed it above, where is the profile for this test?  Do you even know 
what a profile is?

>
>> on the grounds that speed simply is not
>> the sole criteria for a language.
>
> I agree with you. But once you've got the language right, then there's
> no harm looking at performance. A switch statement like the above can be
> executed in a single byte-code.
>

Really?  Then please show us all just how it can be done via a patch to 
the cPython code on the bug tracker.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104893

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 what I see it adds nothing to the language, so let's
> deprive it from people who clearly don't need it in the first place.

Every time you need to test X against more than one other value, then 
you have a potential use for switch.

But yes you can do without switch if you have too. Same for many features.

> I am only rude to people such as yourself who refuse to provide code, in
> fact anything, to support your case.  Your "benchmark" for the switch
> was yet another laughable farce, which only tested the function calls,
> building tuples, running loops, there was nothing to test with respect
> to the actual switch which was meant to be tested.  So just in case you
> missed it above, where is the profile for this test?

I've shown the task. I'm sure you can also do some tests and show us 
some results.

>> I agree with you. But once you've got the language right, then there's
>> no harm looking at performance. A switch statement like the above can be
>> executed in a single byte-code.
>>
>
> Really?  Then please show us all just how it can be done via a patch to
> the cPython code on the bug tracker.

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                The index
SWITCH                   Jump to the right label
....
L5:                      One of multiple labels
  ...                     Deal with the code in this branch
JUMP_ABSOLUTE            Break out of the switch

...                      Provision is needed for the jump-table

But only one is needed for testing and dispatch. Now I've sketched it 
out, perhaps you can fill in the details for yourself... (I'm not 
getting involved in CPython development.)


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#104897

On Tue, Mar 15, 2016 at 12:10 PM, BartC <bc@freeuk.com> 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                The index
> SWITCH                   Jump to the right label
> ....
> L5:                      One of multiple labels
>  ...                     Deal with the code in this branch
> JUMP_ABSOLUTE            Break out of the switch
>
> ...                      Provision is needed for the jump-table
>
> But only one is needed for testing and dispatch. Now I've sketched it out,
> perhaps you can fill in the details for yourself... (I'm not getting
> involved in CPython development.)

Let's be fair here; anyone can make a single byte-code that does
arbitrary amounts of work. (Consider Python's CALL_FUNCTION or the old
PRINT_ITEM opcode.) How much work does SWITCH do here? Does the jump
table require that the possible case values be compact? If they're
not, how does it operate?

In Python, the most obvious way to do the repeated comparisons would
be a hash lookup. The SWITCH opcode could take a dictionary that maps
values to jump targets, with an 'else' target if the lookup fails, and
jump to that. It would actually be possible to implement this entirely
in an optimizer, with code written like this:

if x == 'asdf':
    ...
elif x == 'qwer':
    ...
elif x in ('zxcv', '1234'):
    ...
else:
    ...

Or, of course, it could get its own syntax.

ChrisA

[toc] | [prev] | [next] | [standalone]

#104915

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 rejected via at least
>> one PEP and from what I see it adds nothing to the language, so let's
>> deprive it from people who clearly don't need it in the first place.
>
> Every time you need to test X against more than one other value, then
> you have a potential use for switch.
>
> But yes you can do without switch if you have too. Same for many features.
>
>> I am only rude to people such as yourself who refuse to provide code, in
>> fact anything, to support your case.  Your "benchmark" for the switch
>> was yet another laughable farce, which only tested the function calls,
>> building tuples, running loops, there was nothing to test with respect
>> to the actual switch which was meant to be tested.  So just in case you
>> missed it above, where is the profile for this test?
>
> I've shown the task. I'm sure you can also do some tests and show us
> some results.
>
>>> I agree with you. But once you've got the language right, then there's
>>> no harm looking at performance. A switch statement like the above can be
>>> executed in a single byte-code.
>>>
>>
>> Really?  Then please show us all just how it can be done via a patch to
>> the cPython code on the bug tracker.
>
> 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                The index
> SWITCH                   Jump to the right label
> ....
> L5:                      One of multiple labels
>   ...                     Deal with the code in this branch
> JUMP_ABSOLUTE            Break out of the switch
>
> ...                      Provision is needed for the jump-table
>
> But only one is needed for testing and dispatch. Now I've sketched it
> out, perhaps you can fill in the details for yourself... (I'm not
> getting involved in CPython development.)
>
>

I have no interest at this level.  If I were I might as well have stuck 
with C in the first place.  I do find it rather strange that something 
so simple wasn't approved when the PEP(s) were discussed as it looks so 
easy to implement.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104880

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.  So you're just a chicken.  Where do
> you buy the paint from for the streaks down your back?  Just in case
> you can't guess it is yellow.  I'll state the colour just in case
> your knowledge of colours is the same as your so called knowledge of
> computing, something of which I'm far from persuaded, on the grounds
> that speed simply is not the sole criteria for a language.

How much longer is the community going to ignore this nastiness?
These repeated vitriolic personal attacks are creating a poisonous
and hostile atmosphere that I and I'm sure many others don't want
to be exposed to when reading this group.

If I recall correctly, Mr. Lawrence was ejected from the developers
list a few years ago for the same kind of offensive behavior.

I suggest that both Mr. Lawrence and the list monitors review

  https://www.python.org/psf/codeofconduct/

and ask themselves if that document has any meaning at all.

[toc] | [prev] | [next] | [standalone]

#104881

On Tue, Mar 15, 2016 at 11:17 AM, rurpy--- via Python-list
<python-list@python.org> 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 always publish, unless, like the RUE,
>> they've got something to hide.  So you're just a chicken.  Where do
>> you buy the paint from for the streaks down your back?  Just in case
>> you can't guess it is yellow.  I'll state the colour just in case
>> your knowledge of colours is the same as your so called knowledge of
>> computing, something of which I'm far from persuaded, on the grounds
>> that speed simply is not the sole criteria for a language.
>
> How much longer is the community going to ignore this nastiness?
> These repeated vitriolic personal attacks are creating a poisonous
> and hostile atmosphere that I and I'm sure many others don't want
> to be exposed to when reading this group.

The community has not ignored it; several people (myself included)
have told Mark off in public for what he's been saying lately.

> If I recall correctly, Mr. Lawrence was ejected from the developers
> list a few years ago for the same kind of offensive behavior.

This requires that the list admins do something. Regular members like
ourselves can't ban him. However, Mark should be aware that, yes, his
actions are not in line with the CoC.

ChrisA

[toc] | [prev] | [next] | [standalone]

#104906

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 against the
community and core developers who are always looking for ways of speeding
up Python (without compromising on either functionality or
backwards-compatibility). It astonishes me that he could repeat this
nonsense over and over again in the face of evidence of multiple active
projects to get more speed out of Python code.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104910

On Tue, Mar 15, 2016 at 1:06 PM, Steven D'Aprano <steve@pearwood.info> 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 either.
>
> His continual declarations that "python is fast enough" goes against the
> community and core developers who are always looking for ways of speeding
> up Python (without compromising on either functionality or
> backwards-compatibility). It astonishes me that he could repeat this
> nonsense over and over again in the face of evidence of multiple active
> projects to get more speed out of Python code.

Agreed, but there's nothing in the rules of this forum (or any other
that I frequent) saying that you aren't allowed to have disagreeing or
even factually wrong opinions on technical matters.

ChrisA

[toc] | [prev] | [next] | [standalone]

#104911

On Tue, 15 Mar 2016 01:14 pm, Chris Angelico wrote:

> On Tue, Mar 15, 2016 at 1:06 PM, Steven D'Aprano <steve@pearwood.info>
> 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 either.
>>
>> His continual declarations that "python is fast enough" goes against the
>> community and core developers who are always looking for ways of speeding
>> up Python (without compromising on either functionality or
>> backwards-compatibility). It astonishes me that he could repeat this
>> nonsense over and over again in the face of evidence of multiple active
>> projects to get more speed out of Python code.
> 
> Agreed, but there's nothing in the rules of this forum (or any other
> that I frequent) saying that you aren't allowed to have disagreeing or
> even factually wrong opinions on technical matters.


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.

Mark believes that Python (which Python?) is "fast enough" for everyone.
He's wrong. The Python community might not *prioritise* increased speed to
the level (say) C programmers do, or consider it a deal breaker, but with
the possible exception of Mark, I don't believe that there is a single
Python user ever who would reject a faster interpreter.

Python's slowness is a cost we are willing to bear, not in and of itself a
good thing. It's a *value judgement* -- we are willing to bear a
performance in order to get certain features. Others may not, and will make
different value judgements, and end up using different languages.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104913

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 lump me in with Mark's bad
behavior. Hey, when i got out of line the other day, i
"self-policed". And don't forget, I myself have been on the
receiving end of Mark's vitriol *MANY* times.

I will have to agree with the others, that Mark's tone has
taken a more aggressive "turn for the worst" in the last few
months. He seems to have lost his patience, has become
overly repetitive with the "RTFM responses", and a bit too
pedantic with the noobs.

Mark, you've got to calm down man. Listen, if you need to
vent, go curse someone out on alt.flame, or some other low
brow group. That's what i do. And the best part is, nobody
even bats an eyelash over there. ;-). 

We need to try to maintain at least a modicum of dignity
here. Nobody wants this group to become a "flamers
paradise". But if all else fails, them flame me. I can
handle it. But for Pete's sake, don't take it out on the
noobs bro!

[toc] | [prev] | [next] | [standalone]

#104888

On 15/03/2016 00:25, Chris Angelico wrote:
> On Tue, Mar 15, 2016 at 11:17 AM, rurpy--- via Python-list
> <python-list@python.org> 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 always publish, unless, like the RUE,
>>> they've got something to hide.  So you're just a chicken.  Where do
>>> you buy the paint from for the streaks down your back?  Just in case
>>> you can't guess it is yellow.  I'll state the colour just in case
>>> your knowledge of colours is the same as your so called knowledge of
>>> computing, something of which I'm far from persuaded, on the grounds
>>> that speed simply is not the sole criteria for a language.
>>
>> How much longer is the community going to ignore this nastiness?
>> These repeated vitriolic personal attacks are creating a poisonous
>> and hostile atmosphere that I and I'm sure many others don't want
>> to be exposed to when reading this group.
>
> The community has not ignored it; several people (myself included)
> have told Mark off in public for what he's been saying lately.
>
>> If I recall correctly, Mr. Lawrence was ejected from the developers
>> list a few years ago for the same kind of offensive behavior.
>
> This requires that the list admins do something. Regular members like
> ourselves can't ban him. However, Mark should be aware that, yes, his
> actions are not in line with the CoC.
>
> ChrisA
>

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 holding my breath, and I do not intend backing 
off.  The Python community cannot let itself get into a position whereby 
crap is spewed by people and they're allowed to get away with it.  You 
lot might also be gutless cowards like he is, I'm not, and you might 
gather I'm not afraid to say so.

For example asking for benchmarks that back up his claims is exactly 
like asking the RUE for evidence to support his claims regarding the 
FSR, they simply never appear.  Why not?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104912

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 not have the
experience or knowledge to understand him, but that just shows your
ignorance in this area, not that Bart is wrong.


> When he provides 
> some *EVIDENCE* to back up his claims then I'll more than happily back
> off.  I do not intend holding my breath, and I do not intend backing
> off.  The Python community cannot let itself get into a position whereby
> crap is spewed by people and they're allowed to get away with it.  You
> lot might also be gutless cowards like he is, I'm not, and you might
> gather I'm not afraid to say so.

Right, you've crossed the line, again.

If the list owner is paying attention, you'll see that Mark has now
explicitly refused to moderate his tone, and furthermore insulted the
entire community ("You lot might also be gutless cowards").

In the meantime, welcome to my kill file. If you're still around in a month,
I'll see you then.

*plonk*




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104891

On Tue, Mar 15, 2016 at 11:47 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> 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 holding my breath, and I do not intend backing off.  The Python
> community cannot let itself get into a position whereby crap is spewed by
> people and they're allowed to get away with it.  You lot might also be
> gutless cowards like he is, I'm not, and you might gather I'm not afraid to
> say so.
>
> For example asking for benchmarks that back up his claims is exactly like
> asking the RUE for evidence to support his claims regarding the FSR, they
> simply never appear.  Why not?

Asking for evidence is not against the CoC. It's *how* you are asking.
There has been more vitriol and acrimony on this list in the past week
than probably the entire previous year, and much of it has come from
your keyboard.

Perhaps you should take a few steps back, mute a few of these threads,
and don't respond to BartC for the next week. Let matters calm down a
little, particularly in your own head. The list will appreciate it.

ChrisA

[toc] | [prev] | [next] | [standalone]

#104914

On 15/03/2016 00:56, Chris Angelico wrote:
> On Tue, Mar 15, 2016 at 11:47 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> 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 holding my breath, and I do not intend backing off.  The Python
>> community cannot let itself get into a position whereby crap is spewed by
>> people and they're allowed to get away with it.  You lot might also be
>> gutless cowards like he is, I'm not, and you might gather I'm not afraid to
>> say so.
>>
>> For example asking for benchmarks that back up his claims is exactly like
>> asking the RUE for evidence to support his claims regarding the FSR, they
>> simply never appear.  Why not?
>
> Asking for evidence is not against the CoC. It's *how* you are asking.
> There has been more vitriol and acrimony on this list in the past week
> than probably the entire previous year, and much of it has come from
> your keyboard.
>
> Perhaps you should take a few steps back, mute a few of these threads,
> and don't respond to BartC for the next week. Let matters calm down a
> little, particularly in your own head. The list will appreciate it.
>
> ChrisA
>

If everybody else would not respond to him he'd go away.  We had to wait 
something like 18 months to get rid of the RUE, surely we don't have to 
go through that pain again?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104904

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 who thinks differently is
obviously mistaken, and we should just shut down all those projects like
Cython, Theano, Numba, Copperhead, Parakeet, Pyjion and Pyston. Clearly
their developers are just wasting their time.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104916

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
> Stinner that they are wasting their time working on Python optimizers.
>
> Since Python is fast enough, obviously anyone who thinks differently is
> obviously mistaken, and we should just shut down all those projects like
> Cython, Theano, Numba, Copperhead, Parakeet, Pyjion and Pyston. Clearly
> their developers are just wasting their time.
>

No, they are merely joining up with Pinky and the Brain in taking over 
the world.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104958

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
>  > you've no idea, you're just another RUE.
>
> Sorry, I'm not going to do that, and I don't expect anyone here to have
> to do so either. You will have to take my posts as they are.

I don't think that you make things up, your posts are much too detailed 
and plausible to be made up. 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, especially since you do not use JIT 
compilation to native code, but still claim that you get good 
performance. You will also profit (in the form of bug reports) if 
somebody actually tries your code.

	Christian

[toc] | [prev] | [next] | [standalone]

#104976

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 evidence from you I am going to state quite cleary that
>>  > you've no idea, you're just another RUE.
>>
>> Sorry, I'm not going to do that, and I don't expect anyone here to have
>> to do so either. You will have to take my posts as they are.
>
> I don't think that you make things up, your posts are much too detailed
> and plausible to be made up. 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, especially since you do not use JIT
> compilation to native code, but still claim that you get good
> performance. You will also profit (in the form of bug reports) if
> somebody actually tries your code.

OK, I'll see what I can do. In the meantime I've put together some notes 
about how my system works, and you can probably see that it's not so 
easy! (Because I use custom languages with circular dependencies...)

But there's some info there that may or may not be of interest:

http://pastebin.com/MsGLsC23

(And I assume everyone here uses Linux? That's another minor problem...)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105063

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, especially since you do not use JIT
>> compilation to native code, but still claim that you get good
>> performance. You will also profit (in the form of bug reports) if
>> somebody actually tries your code.
>
> OK, I'll see what I can do.

(I've started a github repository:

https://github.com/sal58/pcl

Mostly the same handful of files from before. You'll have to keep an eye 
on it as I add more things, as I can hardly announce updates in a Python 
group...

This doesn't seem so hard actually; I should have done it before.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#104851

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 multiple files, multiple files that could share state
> > > without resorting to the yoga-style "import contortions",
> > > and/or the dreaded "circular import nightmares" that plague
> > > our community today.
> >
> > Sounds to me like you're blaming Python for your own poor design.
> > Possible solutions:
> >
> > 1) Don't do that. If your module is too big for one file, then it's
> > likely poorly organized and doesn't all belong in one module anyway.
> 
> Apparently you've missed the many heated arguments between
> Chris Angelico and myself concerning the size of source
> files. I have *ALWAYS* taken the position that source files
> should be kept as small as possible, but that position is
> more relevant in Python, were modules are defined by a
> single source file. I don't take the Java position that a
> module can only contain one class, but i like to keep the
> number of classes (IN MY SOURCE FILES) small.
> 
> 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. The size of a "run-time module"
> is irrelevant in most languages, but here in Python, were
> module namespace is defined by the contents of *ONE SINGLE
> SOURCE FILE*, the whole ballgame is changed. If i need to
> create a module that contains many exposed symbols in
> Python, i'm forced to do one of the following:
> 
>   (1) Write all my code in a single *GIGANTIC* file...
> 
> or
> 
>   (2) Create one file that will be the "mother-ship module",
>   and N files that will be the "satellite modules", and from
>   inside the mother-ship, import all the symbols from all
>   the satellites. Ha, but in reality, it's not that simple,
>   because state does not "magically" travel between modules!
> 
>     ##########
>     # foo.py #
>     ##########
>     FOO_SHARED_STATE = "foo"
>     import _fooSatilite1
>     _fooSatilite1.FOO_SHARED_STATE = FOO_SHARED_STATE
>     from _fooSatilite1 import *
>     import _fooSatilite2
>     _fooSatilite2.FOO_SHARED_STATE = FOO_SHARED_STATE
>     from _fooSatilite2 import *
>     print 'This is the mother-ship called foo'
>     ...
> 
>     ####################
>     # _fooSatilite1.py #
>     ####################
>     from _fooConstants import *
>     print 'This is foo-fighter1, reporting for duty'
>     print FOO_SHARED_STATE
>     ...
> 
>     ####################
>     # _fooSatilite2.py #
>     ####################
>     from _fooConstants import *
>     print 'This is foo-fighter2, reporting for duty'
>     print FOO_SHARED_STATE
>     ...
> 
> But i find both to be absurd. Writing all code in a single
> file might be fine for a toy module that contains a handful
> of functions or classes or vars, but once we start creating 
> anything in the "professional size range", it will become 
> an "editing nightmare" of epic proportions!
> 
> But option two is no better, because once we cut and paste
> portions of the code into satellite files, we lose the
> ability to "easily share state". Then we're forced to start
> "hacking at the weeds" with import contortions and monkey
> patches, all the while, fearing the dreaded circular import.
> 
> 
> NO, THIS IS INSANITY!  WHAT WE NEED IS AN OPTION 3!
> 
>  (3) Allow a programmer to define module space at will
> 
>     ##########
>     # foo.py #
>     ##########
>     module foo
>     FOO_SHARED_STATE = "foo"
>     print 'This is the mother-ship called foo'
>     ...
> 
>     ####################
>     # _fooSatilite1.py #
>     ####################
>     module foo
>     print 'This is foo-fighter1, reporting for duty'
>     print FOO_SHARED_STATE # NO MP REQUIRED!
>     ...
> 
>     ####################
>     # _fooSatilite2.py #
>     ####################
>     module foo
>     print 'This is foo-fighter2, reporting for duty'
>     print FOO_SHARED_STATE # NO MP REQUIRED!
>     ...
> 
> No need for import contortions, no need for monkey patching,
> but most importantly, no need for professional programmers
> to feel as though they are penchant little children, who
> need their "module diapers" wrapped for them by mommy
> Python, who, after popping one too many "mother's little
> helpers", has a nasty habit of wrapping our diapers too damn
> tight -- what a drag, it is, getting old...
> 
> > 2) Clearly define which module is to be imported first. Then follow
> > it. When module b is imported, it should import module a. When module
> > a is imported, it *shouldn't* import module b until it's defined all
> > of its own members first. If module a depends on anything from module
> > b at import time, then refactor so it doesn't. This doesn't require
> > "contortions".
> 
> That sounds simple in theory, but it breaks down quickly
> when you create "professional sized programs"
> 
> > 3) Just put all your damn shared state in a class. There's nothing
> > stopping you from spreading out your class method definitions over
> > multiple files if you really want to, and it solves your import issue
> > by allowing everything to be imported before you even begin to set up
> > the shared state.
> 
> Your words tell me that you have not written anything substantial.
> 
> > And you're suggesting that public attributes and properties do not
> > expose an interface? Rubbish.
> 
> No, what i'm suggesting, is that, from the POV of a dir
> listing, they *ALL* look the same.
> 
> > I don't care how easy they are to *create*. Code is read much more
> > often than it is written, and excessive boilerplate damages
> > readability.
> 
> I understand the importance of readability, but is usability
> of no concern to you? In fact, i would argue that, when
> *ROCK SOLID* professional interfaces are combined with
> proper documentation and strict adherence to style guides,
> there is no need to read source code.
> 
> The only person who should be reading source, is a
> maintenance programmer. And if the code was designed
> properly, his job would be mostly just adding a feature here
> or there, or repairing a small bug here or there -- any code
> monkey can do that!
> 
> > >   (2) Properties and attributes encourage vague naming
> > >   schemes. When i read code, i find the code more
> > >   comprehensible when the symbols give me clues as to what
> > >   is going on. So if i read code like: `re.groups`,
> > >   befuddlement sets in. What is "groups"? A function
> > >   object? An attribute? "getCapturingGroupCount" would be a
> > >   better name (but that's semantics)
> >
> > Actually, it would be wrong. Match.groups doesn't return a count.
> 
> Who said anything about match objects?
> 
> ############################################################
> # BEGIN INTERACTIVE SESSION
> ############################################################
> py> import re
> py> prog = re.compile(r'(Ian) (\w+)')
> py> prog?
> ['findall', 'finditer', 'flags', 'groupindex', 'groups', 'match', 'pattern', 'scanner', 'search', 'split', 'sub', 'subn']
> py> prog.groups
> 2
> py> prog.groups?type
> <type 'int'>
> ############################################################
> # END INTERACTIVE SESSION
> ############################################################
> 
> Looks like an integer to me. (Well, i'll admit, first you'll
> have to parse my mini-language syntax, but it's highly
> intuitive -- more than a Python dir listing, i'll tell you
> that much!)
> 
> > >   In pure OOP,  methods
> > >   are the only communication meduim, so we're more likely to
> > >   write "getBlah" and "setBlah", and use verbs for
> > >   procedural names -- these naming conventions are more
> > >   comprehensible to the user.
> >
> > Good names for methods are *descriptive* verb phrases. Good names for
> > attributes and properties are *descriptive* nouns or noun phrases. Do
> > you really believe that verbs are somehow inherently easier to
> > understand?
> 
> When i see "get_width" or "set_width", i know that the first is
> returning the width, and the second will set the width. And
> anyone with an IQ over room temperature, can surmise that
> set_width takes at least one argument.
> 
> However, when i see "width", how the hell am i supposed to
> know if it is a read-only attribute, a property, or a method?
> Must i read source code just to find this out? Sure, if the
> author included a useful doc string, i could pull it up, but
> to me, this is a giant waste of time. Self documenting names
> are the *KEY* to short learning curves.

I don't think you'll find anyone that disagrees with you here.

If you're seeing a method "width", then whoever wrote that method is a terrible programmer.  Method names should *always* contain some sort of verb.  As you just said, self-documenting names are the key to short learning curves.

IMO, if you intend an attribute to be read-only, then you should use a getter, even in Python, and of course prefix the actual value with an underscore to show it should not be accessed publicly.  Of course, a programmer still can, but that's fine.  Let them shoot themselves in the foot if that's what they want to do.  It should not be the job of the module author to make sure users of the module behave.

The only time you should see "someObject.width" is if width is both readable and writable.  Of course, Using @property to add some logic to the setting/getting is fine.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web