On Monday, February 11, 2013 11:28:57 PM UTC-6, zipher wrote:
> [...]
> 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.
Indeed!
The current parad
On Mon, Feb 11, 2013 at 8:52 PM, Jean-Michel Pichavant
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...
--
http://mail.python.org/mailman/listinfo/pyt
> Yeah, this is, pardon the french, just batshit crazy.
huh ? :)
JM
-- IMPORTANT NOTICE:
The contents of this email and any attachments are confidential and may also be
privileged. If you are not the intended recipient, please notify the sender
immediately and do not disclose the conten
On Mon, Feb 11, 2013 at 8:55 PM, Rick Johnson
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 unexp
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 /do
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.
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Feb 11, 2013 at 11:53 PM, Rick Johnson
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
> behavi
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:
> >
> > Ret
On Mon, 11 Feb 2013 18:24:05 +1100 Chris Angelico
wrote:
> Is that Unicode string theory or ASCII string theory?
+1 QOTW :-)
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
On 11/02/2013 07:24, Chris Angelico wrote:
On Mon, Feb 11, 2013 at 6:19 PM, Mark Lawrence 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
On Mon, Feb 11, 2013 at 6:19 PM, Mark Lawrence 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 Unico
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 :)
--
Cheers.
Mark Lawrence
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 11, 9:59 am, Rick Johnson wrote:
> We don't add features because of logic, or because of consistency,
> or even because of good sense, we simply add them to appease the masses.
When "logic" or "good sense" are writing programs, maybe then we'll
listen more to what they want in a language.
On 2013-02-11 00:36, Steven D'Aprano wrote:
Rick Johnson wrote:
On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
Rick wrote:
And you have missed my point, which is that reversed(), and sorted(),
were not added to the language on a whim, but because they were
requested, ove
On Feb 9, 2:51 pm, Chris Angelico wrote:
>> Rick Johnson wrote:
>> I really don't like to read docs when learning a language,
>> especially a "so-called" high level language. I prefer to learn
>> the language by interactive sessions and object introspection. Then,
>> when i have exhausted all abi
On Sunday, February 10, 2013 6:12:57 PM UTC-6, Tim Chase wrote:
> What should you get if you flatten
>
> [[[1,2],[3,4]],[[5,6],[7,8]]]
>
> Should the result be
>
> [[1,2],[3,4],[5,6],[7,8]]
>
> or
>
> [1,2,3,4,5,6,7,8]
>
> I've needed both cases, depending on the situation.
Well provid
On Sun, Feb 10, 2013 at 4:10 PM, Steven D'Aprano
wrote:
> Mark Janssen wrote:
>
>> A unified data model as I define it, specifies a canonical atomic unit
>> (like the unit integer) and an abstract grouping construct in which
>> these atomic units can be arranged. By themselves, these two can
>> c
Rick Johnson wrote:
> On Sunday, February 10, 2013 7:30:00 AM UTC-6, Oscar Benjamin wrote:
>> On 10 February 2013 04:53, Mark Janssen wrote:
>> > [...]
>> > I have to agree with Rick, I think requiring the user to explicitly
>> > create a new object, which is already a good and widely-used practic
Rick Johnson wrote:
> On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
>> Rick wrote:
>> And you have missed my point, which is that reversed(), and sorted(),
>> were not added to the language on a whim, but because they were
>> requested, over and over and over again.
>
> We
On Sunday, February 10, 2013 7:30:00 AM UTC-6, Oscar Benjamin wrote:
> On 10 February 2013 04:53, Mark Janssen wrote:
> > [...]
> > I have to agree with Rick, I think requiring the user to explicitly
> > create a new object, which is already a good and widely-used practice,
> > should be the Only O
Rick Johnson wrote:
> we can get the iterator for free. If however you want to control the
> iteration /without/ being locked into a loop, you can explicitly call:
>
> py> iter(seq)
> Or, if python employed /true/ OOP paradigm:
>
> py> Iterator(seq)
Today I learned that the difference between
Dennis Lee Bieber wrote:
> On Mon, 11 Feb 2013 01:29:30 +1100, Steven D'Aprano
> declaimed the following in
> gmane.comp.python.general:
>
>>
>> Oh dear. Chris was being sarcastic. I thought that, even if the sarcasm
>> wasn't obvious, his "Ook. Ook!" at the end should have given it away:
>>
>
Mark Janssen wrote:
> A unified data model as I define it, specifies a canonical atomic unit
> (like the unit integer) and an abstract grouping construct in which
> these atomic units can be arranged. By themselves, these two can
> construct arbitrary levels of data structure complexity. Add the
> > > flatten, flattened
> >
> > flatten is another often requested, hard to implement correctly,
> > function. The only reason that Python doesn't have a flatten is
> > that nobody can agree on precisely what it should do.
>
> Steven, the definition of flatten (as relates to sequences) is
> ver
On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
> Rick wrote:
> And you have missed my point, which is that reversed(), and sorted(), were
> not added to the language on a whim, but because they were requested, over
> and over and over again.
Well, well, this explains everyth
On Sun, Feb 10, 2013 at 1:51 PM, Chris Angelico wrote:
> On Mon, Feb 11, 2013 at 8:28 AM, Mark Janssen
> wrote:
>> Yes, I was aware of his sarcasm. But I was actually wanting to agree
>> with the fundamental idea: that one could reduce all data types to 1
>> atomic unit and 1 grouping construc
Rick Johnson:
Really?
Yes.
>> a = [1,2]
=> [1, 2]
>> a.push(3)
=> [1, 2, 3]
>> a
=> [1, 2, 3]
This could be called "mutation without exclamation".
>> require 'WEBrick'
=> true
>> vowels = "[aeiou]+"
=> "[aeiou]+"
>> vowels.object_id
=> 2234951380
>> WEBrick::HTTPUtils._make_regex!(vow
On Mon, Feb 11, 2013 at 8:28 AM, Mark Janssen wrote:
> Yes, I was aware of his sarcasm. But I was actually wanting to agree
> with the fundamental idea: that one could reduce all data types to 1
> atomic unit and 1 grouping construct, and like set theory in
> mathematics, derive everything else.
On 2/10/2013 1:45 PM, Rick Johnson wrote:
On Sunday, February 10, 2013 2:39:21 AM UTC-6, Terry Reedy wrote:
While it is true that sorted(iterable) is essentially
def sorted(iterable):
tem = list(iterable)
tem.sort
return tem
the body is not an expression and cannot be substituted i
On Sun, Feb 10, 2013 at 6:29 AM, Steven D'Aprano
wrote:
> Mark Janssen wrote:
>> I have to agree with Rick, I think requiring the user to explicitly
>> create a new object, which is already a good and widely-used practice,
>
> Perhaps so, but consider how you creates new objects in Python. Very ra
On Sunday, February 10, 2013 3:53:57 AM UTC-6, Neil Hodgson wrote:
> Ruby does not use '!' to indicate in-place modification:
Really?
rb> a = [1,2,3]
[1, 2, 3]
rb> a.reverse
[3, 2, 1]
rb> a
[1, 2, 3]
rb> a.reverse!
[3, 2, 1]
rb> a
[3, 2, 1]
And now we will verify that a.reverse! has not assigned
On Sunday, February 10, 2013 2:39:21 AM UTC-6, Terry Reedy wrote:
> While it is true that sorted(iterable) is essentially
>
> def sorted(iterable):
>tem = list(iterable)
>tem.sort
>return tem
>
> the body is not an expression and cannot be substituted in an
> expression.
Yes but th
On Sun, Feb 10, 2013 at 5:30 AM, Oscar Benjamin
wrote:
> On 10 February 2013 04:53, Mark Janssen wrote:
>> I have to agree with Rick, I think requiring the user to explicitly
>> create a new object, which is already a good and widely-used practice,
>> should be the Only One Way to Do It.
>
> Why
Steven D'Aprano於 2013年2月9日星期六UTC+8上午11時36分52秒寫道：
> Rick Johnson wrote:
>
>
>
> > The solution is simple. Do not offer the "copy-mutate" methods and force
>
> > all mutation to happen in-place:
>
> >
>
> > py> l = [1,2,3]
>
> > py> l.reverse
>
> > py> l
>
> > [3,2,1]
>
> >
>
> > If the
Mark Janssen wrote:
> On Sat, Feb 9, 2013 at 8:20 PM, Chris Angelico wrote:
>> On Sun, Feb 10, 2013 at 2:54 PM, Rick Johnson
>> wrote:
>>> My point was this: All mutate methods should mutate "in-place", if the
>>> programmer wishes to create a mutated copy of the object, then the
>>> programmer
Chris Angelico wrote:
> On Sun, Feb 10, 2013 at 10:29 PM, Steven D'Aprano
> wrote:
>> "inserted" is called addition, together with list slicing when needed.
>>
>> newlist = [item_to_insert] + oldlist
>> newlist = oldlist[0:5] + [item_to_insert] + oldlist[5:]
>
> Really? Wouldn't it be easier to
On Sun, 10 Feb 2013 22:29:54 +1100, Steven D'Aprano wrote:
> Rick Johnson wrote:
> > map, mapped
> > filter, filtered
> > reduce, reduced
>
> Those are nonsense. None of those are in-place mutator methods.
> Especially reduce, which reduces a list to a single item. You might
> as well have sugg
On 10 February 2013 04:53, Mark Janssen wrote:
> On Sat, Feb 9, 2013 at 8:20 PM, Chris Angelico wrote:
>> On Sun, Feb 10, 2013 at 2:54 PM, Rick Johnson
>> wrote:
>>> My point was this: All mutate methods should mutate "in-place", if the
>>> programmer wishes to create a mutated copy of the obje
On Sun, Feb 10, 2013 at 10:29 PM, Steven D'Aprano
wrote:
> "inserted" is called addition, together with list slicing when needed.
>
> newlist = [item_to_insert] + oldlist
> newlist = oldlist[0:5] + [item_to_insert] + oldlist[5:]
Really? Wouldn't it be easier to use slice assignment on a copy?
ne
Rick Johnson wrote:
> On Friday, February 8, 2013 9:36:52 PM UTC-6, Steven D'Aprano wrote:
>> Rick Johnson wrote:
>>
>> > The solution is simple. Do not offer the "copy-mutate" methods and
>> > force all mutation to happen in-place:
>> >
>> > py> l = [1,2,3]
>> > py> l.reverse
>> > py> l
>> > [3
Neil Hodgson wrote:
> Rick Johnson:
>
>> The Ruby language attempted to save the programmer from the scourge of
>> obtaining a four year degree in linguistics just to create intuitive
>> identifiers "on-the-fly", and they tried to remove this ambiguity by
>> employing "post-fix-punctuation" of th
Rick Johnson:
The Ruby language attempted to save the programmer from the scourge of obtaining a four year degree
in linguistics just to create intuitive identifiers "on-the-fly", and they tried to
remove this ambiguity by employing "post-fix-punctuation" of the exclamation mark as a
visual c
While it is true that sorted(iterable) is essentially
def sorted(iterable):
tem = list(iterable)
tem.sort
return tem
the body is not an expression and cannot be substituted in an
expression. The need for the short form was thought common enough to be
worth, *on balance*, a new builtin na
On Sat, Feb 9, 2013 at 8:20 PM, Chris Angelico wrote:
> On Sun, Feb 10, 2013 at 2:54 PM, Rick Johnson
> wrote:
>> My point was this: All mutate methods should mutate "in-place", if the
>> programmer wishes to create a mutated copy of the object, then the
>> programmer should /explicitly/ create
On Sun, Feb 10, 2013 at 2:54 PM, Rick Johnson
wrote:
> My point was this: All mutate methods should mutate "in-place", if the
> programmer wishes to create a mutated copy of the object, then the programmer
> should /explicitly/ create a copy of the object and then apply the correct
> mutator me
On Friday, February 8, 2013 9:36:52 PM UTC-6, Steven D'Aprano wrote:
> Rick Johnson wrote:
>
> > The solution is simple. Do not offer the "copy-mutate" methods and force
> > all mutation to happen in-place:
> >
> > py> l = [1,2,3]
> > py> l.reverse
> > py> l
> > [3,2,1]
> >
> > If the user wants
On Sat, Feb 9, 2013 at 12:50 PM, Rick Johnson
wrote:
> I really don't like to read docs when learning a language, especially a
> "so-called" high level language. I prefer to learn the language by
> interactive sessions and object introspection. Then, when i have exhausted
> all abilities to int
Rick Johnson wrote:
> The solution is simple. Do not offer the "copy-mutate" methods and force
> all mutation to happen in-place:
>
> py> l = [1,2,3]
> py> l.reverse
> py> l
> [3,2,1]
>
> If the user wants a "mutated copy" he should explicitly create a new
> object and then apply the correct mut
DISCLAIMER:
This post covers a universal programming language design flaw using both Python
and Ruby code examples to showcase the issue.
I really don't like to read docs when learning a language, especially a
"so-called" high level language. I prefer to learn the language by interactive
sess
49 matches
Mail list logo
