Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > LangWart: Method congestion from mutate multiplicty

Reply
Thread Tools

LangWart: Method congestion from mutate multiplicty

 
 
Chris Angelico
Guest
Posts: n/a
 
      02-11-2013
On Mon, Feb 11, 2013 at 6:19 PM, Mark Lawrence <(E-Mail Removed)> wrote:
> On 11/02/2013 02:05, alex23 wrote:
>>
>>
>> I highly recommend not reading up on any
>> modern physics as there'll be plenty there that just makes you angry.
>>

>
> Spoil sport. Fancy not wanting rr's views on string theory


Is that Unicode string theory or ASCII string theory?

Can I get a ringside seat at the debate between Rick and jmf on which
kind of string theory was the wronger decision?

ChrisA
(And on whether "wronger" is permitted on this forum. Have at it,trolls!)
 
Reply With Quote
 
 
 
 
Mark Lawrence
Guest
Posts: n/a
 
      02-11-2013
On 11/02/2013 07:24, Chris Angelico wrote:
> On Mon, Feb 11, 2013 at 6:19 PM, Mark Lawrence <(E-Mail Removed)> wrote:
>> On 11/02/2013 02:05, alex23 wrote:
>>>
>>>
>>> I highly recommend not reading up on any
>>> modern physics as there'll be plenty there that just makes you angry.
>>>

>>
>> Spoil sport. Fancy not wanting rr's views on string theory

>
> Is that Unicode string theory or ASCII string theory?
>
> Can I get a ringside seat at the debate between Rick and jmf on which
> kind of string theory was the wronger decision?
>


I guess that the black market would put the price beyond the pocket of
the average Python programmer.

> ChrisA
> (And on whether "wronger" is permitted on this forum. Have at it,trolls!)
>


<incoming, take cover>

And I'll allow wronger as you're the righter.

</incoming, take cover>

--
Cheers.

Mark Lawrence

 
Reply With Quote
 
 
 
 
Tim Chase
Guest
Posts: n/a
 
      02-11-2013
On Mon, 11 Feb 2013 18:24:05 +1100 Chris Angelico <(E-Mail Removed)>
wrote:
> Is that Unicode string theory or ASCII string theory?


+1 QOTW

-tkc


 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-11-2013
On Sunday, February 10, 2013 6:36:20 PM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
> > On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
> >> Rick wrote:

> > [...]
> > Steven, the definition of flatten (as relates to sequences) is very, VERY
> > simple:
> >
> > Return a new sequence that is the result of reducing
> > a nested sequence of sequences into a single depth
> > sequence.

>
> Very, VERY simple until you actually implement this function, and discover
> that it does too much e.g.


I would implement it as a method of sequence types, but i digress!

> flatten([None, 23, [1, 2, 3], Point(x=2, y=3), ["spam", "ham"]])
> => [None, 23, 1, 2, 3, 2, 3, 's', 'p', 'a', 'm', 'h', 'a', 'm']
>
> So people who have *actually programmed*, instead of just talking about
> programming, have discovered that in practice you need to treat some
> sequences as primitives that don't get expanded.


Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten() on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything.

However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable!


I'm not convinced that flattening immutable types is a good idea anyway, because heck, they're designed to be immutable! I suppose if we are not flattening "in-place" it really would not matter though. Creating a new immutable object that is the result of reordering an existing immutable object's values is not mutation.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      02-11-2013
On Mon, Feb 11, 2013 at 11:53 PM, Rick Johnson
<(E-Mail Removed)> wrote:
> Which primitive(s) should NOT have been expanded in your opinion? The "Point" object? I agree, that's why MY implementation would call seq.flatten()on all sub-sequences THEREBY allowing each subtype to define it's own flatten behavior. Of course the default behavior of the SequenceBase#flatten would be to flatten everything.
>
> However, ImmutableSequence Types would not flatten. In your example ["spam", "ham"] would not be expanded to ['s', 'p', 'a', 'm', 'h', 'a', 'm']. psst: strings and tuples are immutable!


So...

flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])

would return

[None, 23, 1, 2, 3, (2, 3), "spam", "ham"]

? I think that's even more unexpected.

ChrisA
 
Reply With Quote
 
Serhiy Storchaka
Guest
Posts: n/a
 
      02-11-2013
On 11.02.13 09:24, Chris Angelico wrote:
> Can I get a ringside seat at the debate between Rick and jmf on which
> kind of string theory was the wronger decision?


I want to see it.

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-12-2013
On Monday, February 11, 2013 7:27:30 AM UTC-6, Chris Angelico wrote:

> So...
> flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])
>
> would return
>
> [None, 23, 1, 2, 3, (2, 3), "spam", "ham"]
>
> I think that's even more unexpected.


Why? Are you over-analyzing? Show me a result that /does/ make you happy.

Do you remember when i was talking about how i attempt to intuit interfacesbefore reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.

The word "flatten" is too ambiguous to intuit the /exact/ "result". The only intuit-able attribute of flatten is that calling list.flatten() will result in a list that probably looks different than the current list. Intuitionis your friend; not your own personal "clairvoyant side-kick"!

To learn the interface you need to initially "intuit", but then you need totest. Run a few example sequences and see what results you get, compare those results to what you /expected/ to get. If it works the way you expect, move on to the next topic, if not, dig deeper.

You can't procrastinate over this method forever because NEWSFLASH you will/never/ find a perfect flatten algorithm that will please /everyone/, so just pick the most logical and consistent, and MOVE ON!

Infinite recursion anyone?

while obj.repeat is True:
obj.lather()
obj.rinse()
obj.repeat = True


 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-12-2013
On Monday, February 11, 2013 7:27:30 AM UTC-6, Chris Angelico wrote:

> So...
> flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])
>
> would return
>
> [None, 23, 1, 2, 3, (2, 3), "spam", "ham"]
>
> I think that's even more unexpected.


Why? Are you over-analyzing? Show me a result that /does/ make you happy.

Do you remember when i was talking about how i attempt to intuit interfacesbefore reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.

The word "flatten" is too ambiguous to intuit the /exact/ "result". The only intuit-able attribute of flatten is that calling list.flatten() will result in a list that probably looks different than the current list. Intuitionis your friend; not your own personal "clairvoyant side-kick"!

To learn the interface you need to initially "intuit", but then you need totest. Run a few example sequences and see what results you get, compare those results to what you /expected/ to get. If it works the way you expect, move on to the next topic, if not, dig deeper.

You can't procrastinate over this method forever because NEWSFLASH you will/never/ find a perfect flatten algorithm that will please /everyone/, so just pick the most logical and consistent, and MOVE ON!

Infinite recursion anyone?

while obj.repeat is True:
obj.lather()
obj.rinse()
obj.repeat = True


 
Reply With Quote
 
Mark Janssen
Guest
Posts: n/a
 
      02-12-2013
On Mon, Feb 11, 2013 at 8:55 PM, Rick Johnson
<(E-Mail Removed)> wrote:
> On Monday, February 11, 2013 7:27:30 AM UTC-6, Chris Angelico wrote:
>
>> So...
>> flatten([None, 23, [1, 2, 3], (2, 3), ["spam", "ham"]])
>>
>> would return
>>
>> [None, 23, 1, 2, 3, (2, 3), "spam", "ham"]
>>
>> I think that's even more unexpected.

>
> Why? Are you over-analyzing? Show me a result that /does/ make you happy.
>
> Do you remember when i was talking about how i attempt to intuit interfaces before reading any docs? Well i have news for you Chris, what you are doing is NOT "intuiting" how flatten will work, what you are doing is "projecting" how flatten will work; these are two completely different concepts Chris.
>
> You can't procrastinate over this method forever because NEWSFLASH you will /never/ find a perfect flatten algorithm that will please /everyone/, sojust pick the most logical and consistent, and MOVE ON!


Yeah, this is where one has to consider the idea of a unified data
model (a sort of OOPv2). Right now, it's all confused because people
are using their own internal, subconscious ideas of data. There are
natural ways of working with data that ***actually map onto the world
we all share*** and there are other ways which are purely abstract and
not-pragmatic however "pure". (Apart from this, there is the
ultra-concrete data model, like C, which only maps onto the machine
architecture). This is where pretty much every computer language is
today.

What I'm suggesting I think is somewhat novel. The first version of
OOP was too concrete in the sense that it was actually trying to make
real-world objects in the machine (class Chevy(Car). This is
ridiculous. There needs to be a refactor of the OOP paradigm. In
practice OOP never was used to represent real-world objects. It came
to model virtual world objects, a very different world with different
relationships. It became the evolution of the data type itself. The
unified object model needs to do for OOP what arithmetic did for
number: defined a very basic and general set of operations on the
concept of "quantificiation". But here were trying to do that not for
quantification but for structures.

My suggestion is to create the "fractal graph" data type to end (and
represent) all data types. (Keep all the special, high-speed matrix
ideas in SciPi/VPython.) But generally, re-arrange the data model
around the fractal graph for efficiency and start watching the magic
happen.

markj
pangaia.sf.net
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      02-12-2013
On Mon, Feb 11, 2013 at 8:52 PM, Jean-Michel Pichavant
<(E-Mail Removed)> wrote:
>
>> Yeah, this is, pardon the french, just batshit crazy.

>
> huh ?


You're French, ergo you are pardoned. Makes good sense to me!



ChrisA
Cheshire was right, we're all mad here...
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: LangWart: Method congestion from mutate multiplicty Jean-Michel Pichavant Python 0 02-11-2013 09:52 AM
Re: mutate dictionary or list Bruno Desthuilliers Python 0 09-07-2010 01:55 PM
mutate an object or create a new one? toton Java 23 11-02-2006 01:37 PM
naming convention for functions that mutate their arguments? mike p. Python 1 02-27-2004 02:18 AM
how to mutate a tuple? Carlo v. Dango Python 10 10-14-2003 03:32 PM



Advertisments