On Thursday, May 28, 2015 at 11:59:36 AM UTC-5, Marko Rauhamaa wrote:
> Ian Kelly :
> > I think I would be more inclined to use enums. This has the advantages
> > of not creating a new set of state classes for every connection
> > instance and that each state is a singleton instance, allowing thing
On Wednesday, May 27, 2015 at 8:00:49 AM UTC-5, Todd wrote:
> On Wed, May 27, 2015 at 2:40 PM, zipher wrote:
> On Wednesday, May 27, 2015 at 6:30:16 AM UTC-5, Ben Finney wrote:
>
> > Steven D'Aprano writes:
>
> >
>
> > > On Wedn
On Wednesday, May 27, 2015 at 2:39:21 AM UTC-5, Marko Rauhamaa wrote:
> Chris Angelico :
>
> > Using some other name in place of "self" should definitely remain
> > *possible*, but not commonly done.
>
> You are effectively making the argument that Python has made a mistake
> by not giving "self"
On Wednesday, May 27, 2015 at 12:48:02 AM UTC-5, Steven D'Aprano wrote:
> On Wednesday 27 May 2015 14:39, Ben Finney wrote:
>
> > zipher writes:
> >
> >> Arrgh. Sorry, that was meant privately...
> >
> > I'm glad we saw it publicly, so tha
On Tuesday, May 26, 2015 at 11:40:20 PM UTC-5, Ben Finney wrote:
> zipher writes:
>
> > Arrgh. Sorry, that was meant privately...
>
> I'm glad we saw it publicly, so that we get more of an idea how you
> treat people.
Ben, he asked for it. Stop assuming.
> Th
On Tuesday, May 26, 2015 at 3:53:25 PM UTC-5, Michael Torrie wrote:
> On 05/26/2015 08:57 AM, zipher wrote:
> > Comprende? I'm not trying to be cryptic here. This is a bit of OOP
> > theory to be discussed.
>
> No, sorry. Maybe an actual example (with use case) woul
On Wednesday, May 27, 2015 at 6:30:16 AM UTC-5, Ben Finney wrote:
> Steven D'Aprano writes:
>
> > On Wednesday 27 May 2015 14:39, Ben Finney wrote:
> >
> > > That kind of homophobic slur is inappropriate from anyone in this
> > > community. Kindly cut it out altogether.
> >
> > I look forward to
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote:
> In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes:
> >Would it be prudent to rid the long-standing "argument" (pun unintended)
> >about self and the ulterior spellings of it, by
On Tuesday, May 26, 2015 at 9:48:25 PM UTC-5, zipher wrote:
> On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote:
> > On 26/05/2015 17:37, zipher wrote:
> > > Would it be prudent to rid the long-standing "argument" (pun unintended)
> > > about
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote:
> In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes:
> >Would it be prudent to rid the long-standing "argument" (pun unintended)
> >about self and the ulterior spellings of it, by
On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote:
> On 26/05/2015 17:37, zipher wrote:
> > Would it be prudent to rid the long-standing "argument" (pun unintended)
> > about self and the ulterior spellings of it, by changing it into a symbol
> &g
Would it be prudent to rid the long-standing "argument" (pun unintended) about
self and the ulterior spellings of it, by changing it into a symbol rather than
a name?
Something like:
class MyClass(object):
def __init__(@):
@.dummy = None
OR, even better, getting *rid of it* in t
> Apart from object composition or mix-in style, I want to illustrate something
> regarding the "arrow" of inheritance.
>
> class super_dict(dict):
>
> def __init__(self, init={}, default_value=0, collision_function=None):
>*expands what dict can do*
>
> def get_default(self):
Still considering distinguishing between different types of inheritance.
Apart from object composition or mix-in style, I want to illustrate something
regarding the "arrow" of inheritance.
class super_dict(dict):
def __init__(self, init={}, default_value=0, collision_function=None):
On Friday, May 15, 2015 at 10:36:45 PM UTC-5, Rustom Mody wrote:
> On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote:
> > On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> > > On 14/05/2015 02:40, Steven D'Aprano wrote:
> > > > O
On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote:
> On 14/05/2015 02:40, Steven D'Aprano wrote:
> > On Thu, 14 May 2015 04:07 am, zipher wrote:
> >
> >>
> >> No, you haven't understood, padawan. Lambda *is* the function, not it'
> > No, Common LISP does, but as the website says Common LISP is a
> > "multi-paradigm" langauge. It's trying to be everything to everybody,
> > just like Python tried to do in the other direction, making "everything an
> > object". Python was trying to be too pure, while LISP was trying to be
>
On Wednesday, May 13, 2015 at 4:39:52 PM UTC-5, Ian wrote:
> On Wed, May 13, 2015 at 12:07 PM, zipher wrote:
> > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote:
> >> I don't know why I'm replying to this...
> >
> > Because you're tr
On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote:
> I don't know why I'm replying to this...
Because you're trying to get an answer to a question that even Academia hasn't
answered or understood.
> On Wed, May 13, 2015 at 8:44 AM, zipher wrote:
> > O
[Mr. Lawrence spaketh:]
> Do we really have to feed this guy, he's worse than the RUE?
While it may seem like an impossible goal, is it unworthy? Is there something
*better* for high-level, interpreted languages to be good for?
The truth is, that all the theory is worked out, as well as the hea
On Tuesday, May 12, 2015 at 10:47:48 PM UTC-5, Ian wrote:
> On Tue, May 12, 2015 at 9:11 PM, zipher wrote:
> > I know. That's because most people have fallen off the path
> > (http://c2.com/cgi/wiki?OneTruePath).
>
> You wrote that, didn't you? I recognize
On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote:
> On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote:
> > Why can't a language be designed with a *practical and concrete* need in
> > mind? As far as I know, only one language designed from theoretical first
>
On Tuesday, May 12, 2015 at 10:43:44 AM UTC-5, Chris Angelico wrote:
> On Wed, May 13, 2015 at 1:34 AM, zipher wrote:
> > Name one "significant and important" use case for shadowing built-in types.
> > Functions, I don't have a problem with, but types are more f
On Tuesday, May 12, 2015 at 9:30:50 PM UTC-5, Steven D'Aprano wrote:
> On Wed, 13 May 2015 08:00 am, zipher wrote:
>
> > Everyone gets it wrong and now we have a plethora of languages which all
> > do the same thing, without really knowing what they want as an overarchin
On Tuesday, May 12, 2015 at 5:24:34 PM UTC-5, Marko Rauhamaa wrote:
> zipher :
>
> > That is why you have very high-level languages that allow you to
> > rapidly prototype ideas, test them, and then, depending all the other
> > constraints, move them to lower-level
On Tuesday, May 12, 2015 at 1:22:55 PM UTC-5, Mark Lawrence wrote:
> On 12/05/2015 18:35, Rustom Mody wrote:
> > On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote:
> >>
> >> I/O is an essential part of computing in the West. (I'll leave Symbolics
&g
On Tuesday, May 12, 2015 at 8:15:07 PM UTC-5, Steven D'Aprano wrote:
> On Wed, 13 May 2015 02:05 am, Chris Angelico wrote:
>
> > So if you're writing a library function, it probably shouldn't use
> > print()... but your application is most welcome to. You usually know
> > which one you're writing
On Tuesday, May 12, 2015 at 12:57:48 PM UTC-5, Rustom Mody wrote:
> On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote:
> > Rob Gaddi writes:
> > >Is that a true array or a linked list? "It's a high level language,
> > >that's just an implementation detail." Yes, but it's an imple
On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano wrote:
> The consensus among the core developers is:
> * in general, the harm and inconvenience from accidentally
> shadowing built-ins is not great, and it usually easy to
> spot, debug and prevent;
Where is that the consensus? Pl
On Tuesday, May 12, 2015 at 4:16:31 AM UTC-5, Rustom Mody wrote:
> On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote:
> > On Tue, May 12, 2015 at 4:42 PM, Rustom Mody wrote:
> > > And related to that (and one reason a pure functional language is good for
> > > pedagogy): NO PR
On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote:
> On Tue, 12 May 2015 05:01 am, beliav...@aol.com wrote:
>
> > Yale has taken the unusual step of outsourcing its introductory CS class
> > to Harvard, which uses C as the main language in its CS50 class.
>
> And another generati
On Monday, May 11, 2015 at 7:25:09 PM UTC-5, Dennis Lee Bieber wrote:
> On Mon, 11 May 2015 08:33:56 -0700 (PDT), zipher
> declaimed the following:
> >You are making a error that few in the programming community have caught up
> >to. OOP design for *data abstraction* is a co
On Monday, May 11, 2015 at 11:08:14 AM UTC-5, Chris Angelico wrote:
> On Tue, May 12, 2015 at 2:01 AM, Peter Otten <__pete...@web.de> wrote:
> > Though interestingly, my Py2 doesn't have any help
> >> on exec:
> >>
> > help('exec')
> >> no documentation found for 'exec'
> >>
> >> Not sure why t
On Monday, May 11, 2015 at 10:49:01 AM UTC-5, Skip Montanaro wrote:
> On Mon, May 11, 2015 at 10:11 AM, zipher wrote:
> > I also bought the idea of everything as an object, it has a unbeatable
> > purity to it. But we won't ever get to the point were OOP is like the
> &
On Monday, May 11, 2015 at 10:44:51 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
> > The point is that all too often someone wants to defend a specific choice
> > the developers have made and cites some general rule or principle in
> > support, ignoring t
On Monday, May 11, 2015 at 10:34:24 AM UTC-5, Grant Edwards wrote:
> On 2015-05-11, Skip Montanaro wrote:
> >> Python is in production use in hundreds of thousands of
> >> organisations. It has been heavily used for over twenty years, in
> >> everything from quick and dirty one line scripts to hun
On Friday, May 8, 2015 at 10:40:46 AM UTC-5, Tommy C wrote:
> I'm trying to apply OOP in this bouncing ball code in order to have multiple
> balls bouncing around the screen. The objective of this code is to create a
> method called settings, which controls all the settings for the screen and
>
On Monday, May 11, 2015 at 10:22:15 AM UTC-5, zipher wrote:
> Ah, yeah, I guess that does it. But (shame) it looks like you've gone past
> the BDFL. Try:
> [...]
> Better
Oops, omit word "better". Sent before reading over it again...
m
--
https://mail.python.org/mailman/listinfo/python-list
On Sunday, May 10, 2015 at 10:32:07 PM UTC-5, Ian wrote:
> On Sun, May 10, 2015 at 7:39 PM, zipher wrote:
> > Similarly, you'd want:
> >
> >>>> encode(codestr)
> >
> > to instantiate all objects in the codestr. You can't do this with eval
On Monday, May 11, 2015 at 9:52:16 AM UTC-5, Skip Montanaro wrote:
> Steven> Python is in production use in hundreds of thousands of
> organisations. It
> Steven> has been heavily used for over twenty years, in everything
> from quick and
> Steven> dirty one line scripts to hundred-thousand LOC app
On Monday, May 11, 2015 at 9:03:43 AM UTC-5, Marko Rauhamaa wrote:
> Antoon Pardon :
>
> > The point is that all too often someone wants to defend a specific
> > choice the developers have made and cites some general rule or
> > principle in support, ignoring the fact that python breaks that
> > r
On Monday, May 11, 2015 at 1:11:26 AM UTC-5, Steven D'Aprano wrote:
> On Monday 11 May 2015 10:57, zipher wrote:
> > I guess everyone expects this behavior since Python implemented this idea
> > of "everything is an object", but I think this branch of OOP (on
On Sunday, May 10, 2015 at 9:18:55 PM UTC-5, Chris Angelico wrote:
> On Mon, May 11, 2015 at 12:11 PM, zipher wrote:
> >> Please take care of your quoting. You just quoted two other posts, and
> >> I have no idea who said things without going and digging in the
> >&
> Please take care of your quoting. You just quoted two other posts, and
> I have no idea who said things without going and digging in the
> archive.
I'm sorry. I've been sleeping on the beach, away from civilization, a little
too long, and didn't see that this was a post from 6 years ago.
Feel
> > Okay. I apologize for thinking in C and believing "int" was a keyword. It
> > isn't in Python as you remind me. However, this is where I'm arguing the
> > purity has hammered practicality into the ground.
> >
> > Python is trying to be as elegant as LISP in trying to make everything an
>
> > 3.) true OOP
> > Now before you go and get all "huffy" over this statement, hear me
> > out. Python is the best language in the world. But it damn sure has
> > some warts! "len(this)" instead of "obj.length" max(that) instead of
> > [1,2,3,4,5].max().
>
> As the Zen says: '[P]racticality beats
> I'm thinking how interesting it would be to add code blocks to Python, so
> that arbitrary strings of code can be passed around. It would open up some
> interesting possibilities for self-modifying code and generic programming.
>
> My suggestion would be to use triple double-quoted strings
> > Instead of learning only Scheme or only Python for a one semester intro
> > course, what about learning BOTH? Maybe that could somehow
> > get the benefits of both?
>
> No. LISP-like languages are very different beasts, requiring different
> mind-sets. It's like going from geometry to arit
> Huh? Python has plenty of keywords, and indeed, none of them can be
> redefined or shadowed.But you would gain nothing (and lose a bit or
> dynamic-language freedom) by making int a keyword.
Okay. I apologize for thinking in C and believing "int" was a keyword. It
isn't in Python as y
On Sunday, May 10, 2015 at 3:43:25 PM UTC-5, Chris Seberino wrote:
> Instead of learning only Scheme or only Python for a one semester intro
> course, what about learning BOTH? Maybe that could somehow
> get the benefits of both?
>
> I'm thinking that for the VERY beginning, Scheme is the fastest
On Sunday, May 10, 2015 at 7:20:13 PM UTC-5, Mark Lawrence wrote:
> On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:
> > In case the example given at the start of the thread wasn't
> > interesting enough, it also works in the other direction:
> >
> class str(int): pass
> >
> str('2')
On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote:
> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
> wrote:
> > Here's something that might be wrong in Python (tried on v2.7):
> >
> class int(str): pass
>
> This defines a new class named "int" that is a subclass of str. It
On Saturday, March 6, 1999 12:00:00 AM UTC-8, Tim Peters wrote:
> If you're like me, you've been using Python since '91, and every scheme
> you've come up with for testing basically sucked. Some observations:
>
> + Examples are priceless.
>
> + Examples that don't work are worse than worthless.
You raise a valid point: that by abstracting the file pointer into a position
attribute you risk "de-coupling" the conceptual link between the underlying
file and your abstraction in the python interpreter, but I think the programmer
can take responsibility for maintaining the abstraction.
Th
For some time now, I've wanted to suggest a better abstraction for the
type in Python. It currently uses an antiquated C-style interface for moving
around in a file, with methods like tell() and seek(). But after attributes
were introduced to Python, it seems it should be re-addressed.
Let f
55 matches
Mail list logo
