On Mon, 13 May 2013, Greg Ewing wrote:
Wayne Werner wrote:
On Fri, 10 May 2013, Gregory Ewing wrote:
f = open("myfile.dat")
f.close()
data = f.read()
To clarify - you don't want a class that has functions that need to be
called in a certain order with *valid input* in order to not cr
On 13 May 2013 08:40, "Chris Angelico" wrote:
>
> On Mon, May 13, 2013 at 4:32 PM, Fábio Santos
wrote:
> >
> > On 13 May 2013 00:22, "Greg Ewing" wrote:
> >> The same argument can be applied to:
> >>
> >>foo = Foo()
> >>foo.do_something()
> >>foo.enable() # should have done this firs
On Mon, May 13, 2013 at 4:32 PM, Fábio Santos wrote:
>
> On 13 May 2013 00:22, "Greg Ewing" wrote:
>> The same argument can be applied to:
>>
>>foo = Foo()
>>foo.do_something()
>>foo.enable() # should have done this first
>>
>> You're passing an invalid input to Foo.do_something,
>> n
On 13 May 2013 00:22, "Greg Ewing" wrote:
>
> Wayne Werner wrote:
>>
>> On Fri, 10 May 2013, Gregory Ewing wrote:
>>
>>> f = open("myfile.dat")
>>> f.close()
>>> data = f.read()
>>
>>
>> To clarify - you don't want a class that has functions that need to be
called in a certain order with *va
Wayne Werner wrote:
On Fri, 10 May 2013, Gregory Ewing wrote:
f = open("myfile.dat")
f.close()
data = f.read()
To clarify - you don't want a class that has functions that need to be
called in a certain order with *valid input* in order to not crash.
Exactly what does happen - a Value
On 5/12/2013 12:48 PM, Wayne Werner wrote:
I'll share the anti-pattern that I've seen many times (not actually in
Python)
class CoolPresenter:
def __init__(self):
self.view = None
self.some_property = None
self.other_property = None
On 5/12/2013 1:14 PM, Wayne Werner wrote:
On Fri, 10 May 2013, Gregory Ewing wrote:
Wayne Werner wrote:
You don't ever want a class that has functions that need to be called
in a certain order to *not* crash.
That seems like an overly broad statement. What
do you think the following should d
On Fri, 10 May 2013, Gregory Ewing wrote:
Wayne Werner wrote:
You don't ever want a class that has functions that need to be called in a
certain order to *not* crash.
That seems like an overly broad statement. What
do you think the following should do?
f = open("myfile.dat")
f.close()
On Fri, 10 May 2013, Robert Kern wrote:
On 2013-05-10 12:00, Steven D'Aprano wrote:
But either way, that's fine. You've found an object where it does make
sense to have an explicit "make it go" method: first one entity has
permission to construct the object, but not to open the underlying file
On Sun, May 12, 2013 at 5:55 AM, Robert Kern wrote:
>> Another example of temporal coupling is json_decode in PHP: you must
>> follow it by a call to json_last_error, otherwise you have no way of
>> telling whether the json_decode function succeeded or not.
>>
>> http://php.net/manual/en/function.
On 2013-05-11 08:51, Steven D'Aprano wrote:
On Fri, 10 May 2013 18:20:34 +0100, Robert Kern wrote:
According to Steven's criteria, neither of these are instances of the
anti-pattern because there are good reasons they are this way. He is
reducing the anti-pattern to just those cases where there
On Sun, May 12, 2013 at 1:33 AM, André Malo wrote:
> * Serhiy Storchaka wrote:
>
>> Another example is running a subprocess in Unix-like systems.
>>
>> fork()
>> open/close file descriptors, set limits, etc
>> exec*()
>
> For running a subprocess, only fork() is needed. For starting
* Serhiy Storchaka wrote:
> Another example is running a subprocess in Unix-like systems.
>
> fork()
> open/close file descriptors, set limits, etc
> exec*()
For running a subprocess, only fork() is needed. For starting another
executable, only exec() is needed. For running the ne
In article <518df898$0$29997$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> I never intended to give the impression that *any* use of a separate
> "enable" method call was bad. I certainly didn't intend to be bogged
> down into a long discussion about the minutia of file descrip
> Steven, don't be misled. POSIX is not the model to look to -- it does
> not acknowledge that files are actual objects that reside on a piece
> of hardware. It is not simply an integer.
Please disregard this (my own) flame bait.
--
MarkJ
Tacoma, Washington
--
http://mail.python.org/mailman/li
>> In the old days, it was useful to have fine-grained control over the
>> file object because you didn't know where it might fail, and the OS
>> didn't necessarily give you give good status codes. So being able to
>> step through the entire process was the job of the progammers.
>
> I don't know
On Fri, 10 May 2013 18:20:34 +0100, Robert Kern wrote:
> According to Steven's criteria, neither of these are instances of the
> anti-pattern because there are good reasons they are this way. He is
> reducing the anti-pattern to just those cases where there is no reason
> for doing so.
But isn't
On Fri, 10 May 2013 17:59:26 +0100, Nobody wrote:
> On Thu, 09 May 2013 05:23:59 +, Steven D'Aprano wrote:
>
>> There is no sensible use-case for creating a file without opening it.
>> What would be the point? Any subsequent calls to just about any method
>> will fail. Since you have to open
Am 10.05.2013 15:22 schrieb Roy Smith:
That's correct. But, as described above, the system makes certain
guarantees which allow me to reason about the existence or non-existence
os such entries.
Nevertheless, your 37 is not a FD yet.
Let's take your program:
#include
#include
#include
#
> | No, I've created a file descriptor, which is, by definition, an integer.
> | It has nothing to do with C. This is all defined by the POSIX
> | interface. For example, the getdtablesize(2) man page says:
> |
> | "The entries in the descriptor table are numbered with small integers
> | starting
>> There is no sensible use-case for creating a file OBJECT unless it
>> initially wraps an open file pointer.
>>
>>> So far the only counter-examples given aren't counter-examples ...
>>
>> Well, sure, if you discount operations like "create this file" and
>> queries like "could I delete t
On 10May2013 09:22, Roy Smith wrote:
| In article <518cc239$0$29997$c3e8da3$54964...@news.astraweb.com>,
| Steven D'Aprano wrote:
| > > int fd = 37;
| > >
| > > I've just created a file descriptor. There is not enough information
| > > given to know if it corresponds to an open file or not.
|
In article ,
Nobody wrote:
> However: there are situations where it is useful to be able to separate
> the simple task of creating an object from more invasive actions such as
> system calls. Particularly in multi-threaded or real-time code (although
> the latter is a non-starter in Python for m
family of
functions.
"""
It's deprecated because it's so fragile (and because regular fork()
isn't that much less efficient now; AIUI, vfork was meant to be a
lightweight fork). I would say that the deprecation of vfork in favour
of fork is a strong indication that the object.enable() anti-pattern
can come up in kernel APIs too, and isn't liked there either.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On 2013-05-10 16:44, Serhiy Storchaka wrote:
10.05.13 15:19, Robert Kern написав(ла):
I'd be curious to see in-the-wild instances of the anti-pattern that you
are talking about, then.
Many (if not most) GUI frameworks use this pattern.
button = Button("text")
button.setForegroundCol
10.05.13 15:19, Robert Kern написав(ла):
I'd be curious to see in-the-wild instances of the anti-pattern that you
are talking about, then.
Many (if not most) GUI frameworks use this pattern.
button = Button("text")
button.setForegroundColor(...)
button.setBackgoundColor(...)
bu
On Thu, 09 May 2013 05:23:59 +, Steven D'Aprano wrote:
> There is no sensible use-case for creating a file without opening it.
> What would be the point? Any subsequent calls to just about any method
> will fail. Since you have to open the file after creating the file object
> anyway, why m
On Sat, May 11, 2013 at 1:21 AM, Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>>
>> Agreed, in generality. But what is actually gained by hiding data from
>> yourself?
>
> You're not hiding it from yourself. You're hiding it from the other
> people who are using your code and may not
On 2013-05-10 15:01, Roy Smith wrote:
In article ,
Robert Kern wrote:
I'd be curious to see in-the-wild instances of the anti-pattern that
you are talking about, then. I think everyone agrees that entirely
unmotivated "enable" methods should be avoided, but I have my doubts
that they come up
In article ,
Chris Angelico wrote:
> > Each language has its own set of best practices. Trying to write C++
> > code using Python patterns is as bad as trying to write Python code
> > using C++ patterns.
>
> Agreed, in generality. But what is actually gained by hiding data from
> yourself?
Y
On Sat, May 11, 2013 at 12:54 AM, Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> On Sat, May 11, 2013 at 12:37 AM, Roy Smith wrote:
>> > I suppose, if I had a class like this, I would write a factory function
>> > which called the constructor and post-construction initializer. An
In article ,
Chris Angelico wrote:
> On Sat, May 11, 2013 at 12:37 AM, Roy Smith wrote:
> > I suppose, if I had a class like this, I would write a factory function
> > which called the constructor and post-construction initializer. And
> > then I would make the constructor protected.
>
> That
On Sat, May 11, 2013 at 12:37 AM, Roy Smith wrote:
> I suppose, if I had a class like this, I would write a factory function
> which called the constructor and post-construction initializer. And
> then I would make the constructor protected.
That sounds like a reasonable plan, with the possible
In article ,
Oscar Benjamin wrote:
> It's not just because of exceptions. In C++ virtual method calls in a
> constructor for a class A will always call the methods of class A even
> if the object being constructed is actually of a subclass B because
> the B part of the object isn't initialised w
On 10 May 2013 15:01, Roy Smith wrote:
> In article ,
> Robert Kern wrote:
>
>> I'd be curious to see in-the-wild instances of the anti-pattern that
>> you are talking about, then. I think everyone agrees that entirely
>> unmotivated "enable" methods should be avoided, but I have my doubts
>> th
In article ,
Robert Kern wrote:
> I'd be curious to see in-the-wild instances of the anti-pattern that
> you are talking about, then. I think everyone agrees that entirely
> unmotivated "enable" methods should be avoided, but I have my doubts
> that they come up very often.
As I mentioned e
In article <518cc239$0$29997$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> > int fd = 37;
> >
> > I've just created a file descriptor. There is not enough information
> > given to know if it corresponds to an open file or not.
>
> No, you haven't created a file descriptor. You
On 2013-05-10 12:00, Steven D'Aprano wrote:
But either way, that's fine. You've found an object where it does make
sense to have an explicit "make it go" method: first one entity has
permission to construct the object, but not to open the underlying file.
Another entity has permission to open th
On Fri, 10 May 2013 06:22:31 +, Dan Sommers wrote:
> On Fri, 10 May 2013 05:03:10 +, Steven D'Aprano wrote:
>
> There is no sensible use-case for creating a file OBJECT unless it
> initially wraps an open file pointer.
>
>> So far the only counter-examples given aren't counter-ex
On Fri, 10 May 2013 01:50:09 -0400, Roy Smith wrote:
> In article <518c7f05$0$29997$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> there is no way to create a C file descriptor in a closed state. Such a
>> thing does not exist. If you have a file descriptor, the file is open
On Fri, 10 May 2013 05:03:10 +, Steven D'Aprano wrote:
There is no sensible use-case for creating a file OBJECT unless it
initially wraps an open file pointer.
> So far the only counter-examples given aren't counter-examples ...
Well, sure, if you discount operations like "create t
In article <518c7f05$0$29997$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> there is no way to create a C file descriptor in a closed state. Such
> a thing does not exist. If you have a file descriptor, the file is
> open. Once you close it, the file descriptor is no longer vali
On Fri, 10 May 2013 09:36:43 +1000, Cameron Simpson wrote:
> On 09May2013 11:30, Steven D'Aprano
> wrote:
> | On Thu, 09 May 2013 18:23:31 +1000, Cameron Simpson wrote:
> |
> | > On 09May2013 19:54, Greg Ewing wrote:
> | > | Steven D'Aprano wrote:
> | > | > There is no sensible use-case for cr
On Thu, 09 May 2013 23:09:55 -0400, Roy Smith wrote:
> In article <518c5bbc$0$29997$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> I must admit I am astonished at how controversial the opinion "if your
>> object is useless until you call 'start', you should automatically cal
On Fri, May 10, 2013 at 1:19 PM, Mark Janssen wrote:
>> I think where things went pear shaped is when you made the statement:
>>
There is no sensible use-case for creating a file OBJECT unless it
initially wraps an open file pointer.
>>
>> That's a pretty absolute point of view. Life is
> I think where things went pear shaped is when you made the statement:
>
>>> There is no sensible use-case for creating a file OBJECT unless it
>>> initially wraps an open file pointer.
>
> That's a pretty absolute point of view. Life is rarely so absolute.
In the old days, it was useful to have
In article <518c5bbc$0$29997$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> I must admit I am astonished at how controversial the opinion "if your
> object is useless until you call 'start', you should automatically call
> 'start' when the object is created" has turned out to be
On Fri, May 10, 2013 at 12:30 PM, Steven D'Aprano
wrote:
> I must admit I am astonished at how controversial the opinion "if your
> object is useless until you call 'start', you should automatically call
> 'start' when the object is created" has turned out to be.
I share your astonishment. This i
On Thu, 09 May 2013 19:34:25 +0100, MRAB wrote:
>> There is no sensible use-case for creating a file OBJECT unless it
>> initially wraps an open file pointer.
>>
> You might want to do this:
>
> f = File(path)
> if f.exists():
> ...
>
> This would be an alternative to:
>
> if os.path.exist
In article ,
Michael Speer wrote:
> By his reasoning it simply shouldn't exist. Instead you would access the
> information only like this:
>
> with open("myfile.dat") as f:
> data = f.read()
The problem with things like file objects is they model external
real-world entities, which have ext
By his reasoning it simply shouldn't exist. Instead you would access the
information only like this:
with open("myfile.dat") as f:
data = f.read()
Which is my preferred way to work with resources requiring cleanup in
python anyways, as it ensures I have the least chance of messing things up,
an
On 10May2013 10:56, Greg Ewing wrote:
| Cameron Simpson wrote:
| >You open a file with "0" modes, so
| >that it is _immediately_ not writable. Other attempts to make the
| >lock file thus fail because of the lack of write,
|
| I don't think that's quite right. You open it with
| O_CREAT+O_EXCL, w
Wayne Werner wrote:
You don't ever want a class that has functions that need to be called in
a certain order to *not* crash.
That seems like an overly broad statement. What
do you think the following should do?
f = open("myfile.dat")
f.close()
data = f.read()
--
Greg
--
http://mail.p
On 09May2013 11:30, Steven D'Aprano
wrote:
| On Thu, 09 May 2013 18:23:31 +1000, Cameron Simpson wrote:
|
| > On 09May2013 19:54, Greg Ewing wrote:
| > | Steven D'Aprano wrote:
| > | > There is no sensible use-case for creating a file WITHOUT OPENING
| > | > it. What would be the point?
| > |
|
Cameron Simpson wrote:
You open a file with "0" modes, so
that it is _immediately_ not writable. Other attempts to make the
lock file thus fail because of the lack of write,
I don't think that's quite right. You open it with
O_CREAT+O_EXCL, which atomically fails if the file
already exists. The
On Fri, May 10, 2013 at 4:59 AM, Roy Smith wrote:
> It's not hard to imagine a
> file class which could be used like:
>
> f = file("/path/to/my/file")
> f.delete()
>
> That would be a totally different model from the current python file
> object. And then there would be plenty of things you might
In article <518be931$0$29997$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> There is no sensible use-case for creating a file OBJECT unless it
> initially wraps an open file pointer.
OK, I guess that's a fair statement. But mostly because a python file
object only exposes those
On 09/05/2013 19:21, Steven D'Aprano wrote:
On Thu, 09 May 2013 09:07:42 -0400, Roy Smith wrote:
In article <518b32ef$0$11120$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
There is no sensible use-case for creating a file without opening it.
Sure there is. Sometimes just creating th
On Thu, 09 May 2013 09:07:42 -0400, Roy Smith wrote:
> In article <518b32ef$0$11120$c3e8...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> There is no sensible use-case for creating a file without opening it.
>
> Sure there is. Sometimes just creating the name in the file system is
> all
On 9 May 2013 14:07, Roy Smith wrote:
> In article <518b32ef$0$11120$c3e8...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> There is no sensible use-case for creating a file without opening it.
>
> Sure there is. Sometimes just creating the name in the file system is
> all you want to do. T
In article <518b32ef$0$11120$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
> There is no sensible use-case for creating a file without opening it.
Sure there is. Sometimes just creating the name in the file system is
all you want to do. That's why, for example, the unix "touch" command
On Thu, 09 May 2013 06:08:25 -0500, Wayne Werner wrote:
> Ah, that's it - the problem is that it introduces /Temporal Coupling/ to
> one's code: http://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling/
Good catch!
That's not the blog post I read, but that's the same concept. "Temporal
Coupl
On Thu, 09 May 2013 18:23:31 +1000, Cameron Simpson wrote:
> On 09May2013 19:54, Greg Ewing wrote:
> | Steven D'Aprano wrote:
> | > There is no sensible use-case for creating a file WITHOUT OPENING
> | > it. What would be the point?
> |
> | Early unix systems often used this as a form of locking.
On Wed, 8 May 2013, Steven D'Aprano wrote:
I'm looking for some help in finding a term, it's not Python-specific but
does apply to some Python code.
This is an anti-pattern to avoid. The idea is that creating a resource
ought to be the same as "turning it on", or enabling it, or similar. For
On 09May2013 19:54, Greg Ewing wrote:
| Steven D'Aprano wrote:
| >There is no sensible use-case for creating a file without opening
| >it. What would be the point?
|
| Early unix systems often used this as a form of locking.
Not just early systems: it's a nice lightweight method of making a
lock
Steven D'Aprano wrote:
There is no sensible use-case for creating a file without opening it.
What would be the point?
Early unix systems often used this as a form of locking.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
On 5/9/2013 1:23 AM, Steven D'Aprano wrote:
Besides, this is not to denigrate the idea of a read() function that
takes a filename and returns its contents. But that is not an object
constructor. It may construct a file object internally, but it doesn't
return the file object, so it is completely
On Thu, May 9, 2013 at 3:37 PM, Steven D'Aprano
wrote:
> I can see use-cases for separating "make it go" from initialisation. It
> all depends on what you might want to do to the object before making it
> go. If the answer is "Nothing", then there is no reason not to have the
> constructor make it
On Thu, 09 May 2013 02:38:36 +, Dan Sommers wrote:
> Think of spinning off a thread: initialize it synchronously, and then
> let it execute asynchronously. We tend towards that pattern even when
> we know that execution will be synchronous, because we also that it
> could be asynchronous one
On Thu, 09 May 2013 02:42:01 +, Dan Sommers wrote:
> On Wed, 08 May 2013 08:52:12 +, Steven D'Aprano wrote:
>
>> This is an anti-pattern to avoid. The idea is that creating a resource
>> ought to be the same as "turning it on", or enabling it, or similar.
>> For example, we don't do this
On Wed, 08 May 2013 14:27:53 +, Duncan Booth wrote:
> Steven D'Aprano wrote:
>
>> I'm looking for some help in finding a term, it's not Python-specific
>> but does apply to some Python code.
>>
>> This is an anti-pattern to avoid. The idea is that creating a resource
>> ought to be the same
>> This is an anti-pattern to avoid. The idea is that creating a resource
>> ought to be the same as "turning it on", or enabling it, or similar. For
>> example, we don't do this in Python:
>
> I would call it "user-mediated resource allocation" as distinct from
> "object-mediated" resource allocat
> I'm looking for some help in finding a term, it's not Python-specific but
> does apply to some Python code.
>
> This is an anti-pattern to avoid. The idea is that creating a resource
> ought to be the same as "turning it on", or enabling it, or similar. For
> example, we don't do this in Python:
On Wed, 08 May 2013 08:52:12 +, Steven D'Aprano wrote:
> This is an anti-pattern to avoid. The idea is that creating a resource
> ought to be the same as "turning it on", or enabling it, or similar. For
> example, we don't do this in Python:
>
> f = file("some_file.txt")
> f.open()
> data =
On Wed, 08 May 2013 14:27:53 +, Duncan Booth wrote:
> Steven D'Aprano wrote:
>> I'm looking for some help in finding a term, it's not Python-specific
>> but does apply to some Python code.
>>
>> This is an anti-pattern to avoid. The idea is that creating a
>> resource ought to be the same a
Steven D'Aprano wrote:
> I'm looking for some help in finding a term, it's not Python-specific
> but does apply to some Python code.
>
> This is an anti-pattern to avoid. The idea is that creating a resource
> ought to be the same as "turning it on", or enabling it, or similar
I've come across
In article <518a123c$0$11094$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
> I'm looking for some help in finding a term, it's not Python-specific but
> does apply to some Python code.
>
> This is an anti-pattern to avoid. The idea is that creating a resource
> ought to be the same as "t
On Wed, 08 May 2013 11:13:33 +0100, Robert Kern wrote:
> On 2013-05-08 09:52, Steven D'Aprano wrote:
>> I'm looking for some help in finding a term, it's not Python-specific
>> but does apply to some Python code.
>>
>> This is an anti-pattern to avoid. The idea is that creating a resource
>> ought
On 2013-05-08 09:52, Steven D'Aprano wrote:
I'm looking for some help in finding a term, it's not Python-specific but
does apply to some Python code.
This is an anti-pattern to avoid. The idea is that creating a resource
ought to be the same as "turning it on", or enabling it, or similar.
I do
Am 08.05.2013 10:52, schrieb Steven D'Aprano:
> Basically, any time you have two steps required for using an object, e.g.
> like this:
>
> obj = someobject(arg1, arg2)
> obj.enable()
>
> you should move the make-it-work functionality out of the enable method
> and into __init__ so that creating
I'm looking for some help in finding a term, it's not Python-specific but
does apply to some Python code.
This is an anti-pattern to avoid. The idea is that creating a resource
ought to be the same as "turning it on", or enabling it, or similar. For
example, we don't do this in Python:
f = fi
81 matches
Mail list logo
