On 13 May 2013 00:22, Greg Ewing greg.ew...@canterbury.ac.nz 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
On Mon, May 13, 2013 at 4:32 PM, Fábio Santos fabiosantos...@gmail.com wrote:
On 13 May 2013 00:22, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
The same argument can be applied to:
foo = Foo()
foo.do_something()
foo.enable() # should have done this first
You're passing an
On 13 May 2013 08:40, Chris Angelico ros...@gmail.com wrote:
On Mon, May 13, 2013 at 4:32 PM, Fábio Santos fabiosantos...@gmail.com
wrote:
On 13 May 2013 00:22, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
The same argument can be applied to:
foo = Foo()
foo.do_something()
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
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 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 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
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
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
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 the
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
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 what you
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
--
In article 518df898$0$29997$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
* 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 new
On Sun, May 12, 2013 at 1:33 AM, André Malo ndpar...@gmail.com 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
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
On Sun, May 12, 2013 at 5:55 AM, Robert Kern robert.k...@gmail.com 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.
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 this file
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 steve+comp.lang.pyt...@pearwood.info 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
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-examples ...
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 the
In article 518cc239$0$29997$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
In article mailman.1527.1368188358.3114.python-l...@python.org,
Robert Kern robert.k...@gmail.com 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
On 10 May 2013 15:01, Roy Smith r...@panix.com wrote:
In article mailman.1527.1368188358.3114.python-l...@python.org,
Robert Kern robert.k...@gmail.com 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
In article mailman.1530.1368196163.3114.python-l...@python.org,
Oscar Benjamin oscar.j.benja...@gmail.com 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
On Sat, May 11, 2013 at 12:37 AM, Roy Smith r...@panix.com 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
In article mailman.1531.1368197225.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Sat, May 11, 2013 at 12:37 AM, Roy Smith r...@panix.com wrote:
I suppose, if I had a class like this, I would write a factory function
which called the constructor and post-construction
On Sat, May 11, 2013 at 12:54 AM, Roy Smith r...@panix.com wrote:
In article mailman.1531.1368197225.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Sat, May 11, 2013 at 12:37 AM, Roy Smith r...@panix.com wrote:
I suppose, if I had a class like this, I would write a
In article mailman.1532.1368198547.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com 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
On 2013-05-10 15:01, Roy Smith wrote:
In article mailman.1527.1368188358.3114.python-l...@python.org,
Robert Kern robert.k...@gmail.com 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
On Sat, May 11, 2013 at 1:21 AM, Roy Smith r...@panix.com wrote:
In article mailman.1532.1368198547.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Agreed, in generality. But what is actually gained by hiding data from
yourself?
You're not hiding it from yourself.
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 make
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(...)
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)
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
In article pan.2013.05.10.16.59.31.512...@nowhere.com,
Nobody nob...@nowhere.com 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
On 10May2013 09:22, Roy Smith r...@panix.com wrote:
| In article 518cc239$0$29997$c3e8da3$54964...@news.astraweb.com,
| Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
| int fd = 37;
|
| I've just created a file descriptor. There is not enough information
| given to know if
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 this file if I wanted to?
| 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 at 0.
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 unistd.h
#include
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
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 09May2013 19:54, Greg Ewing greg.ew...@canterbury.ac.nz 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
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 Thu, 09 May 2013 18:23:31 +1000, Cameron Simpson wrote:
On 09May2013 19:54, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
In article 518b32ef$0$11120$c3e8...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On 9 May 2013 14:07, Roy Smith r...@panix.com wrote:
In article 518b32ef$0$11120$c3e8...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
There is no sensible use-case for creating a file without opening it.
Sure there is. Sometimes just creating the name in
On Thu, 09 May 2013 09:07:42 -0400, Roy Smith wrote:
In article 518b32ef$0$11120$c3e8...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
There is no sensible use-case for creating a file without opening it.
Sure there is. Sometimes just creating the name
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 steve+comp.lang.pyt...@pearwood.info wrote:
There is no sensible use-case for creating a file without opening it.
Sure
In article 518be931$0$29997$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On Fri, May 10, 2013 at 4:59 AM, Roy Smith r...@panix.com 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
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 09May2013 11:30, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info
wrote:
| On Thu, 09 May 2013 18:23:31 +1000, Cameron Simpson wrote:
|
| On 09May2013 19:54, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
| | Steven D'Aprano wrote:
| | There is no sensible use-case for creating a file
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
--
On 10May2013 10:56, Greg Ewing greg.ew...@canterbury.ac.nz 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
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,
and
In article mailman.1514.1368145123.3114.python-l...@python.org,
Michael Speer knome...@gmail.com 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
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.exists(path):
On Fri, May 10, 2013 at 12:30 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
In article 518c5bbc$0$29997$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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
On Fri, May 10, 2013 at 1:19 PM, Mark Janssen dreamingforw...@gmail.com 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
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 steve+comp.lang.pyt...@pearwood.info wrote:
I must admit I am astonished at how controversial the opinion if your
object is useless until you call 'start',
On Fri, 10 May 2013 09:36:43 +1000, Cameron Simpson wrote:
On 09May2013 11:30, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
| On Thu, 09 May 2013 18:23:31 +1000, Cameron Simpson wrote:
|
| On 09May2013 19:54, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
| | Steven
In article 518c7f05$0$29997$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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 =
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 the
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
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 to be the
In article 518a123c$0$11094$c3e8...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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,
On Wed, 08 May 2013 14:27:53 +, Duncan Booth wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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 = f.read()
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:
I
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 allocation.
I should
On Wed, 08 May 2013 14:27:53 +, Duncan Booth wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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 in
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, May 9, 2013 at 3:37 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
81 matches
Mail list logo
