Andrea Crotti writes:
[...]
I left the Timeline as before, but tried to rewrite some more classes.
This is the abstract class for a metric, and below another class for the
metric which involve only counting things.
In the end an example on how to use this.
I need to see synthetic values during
On May 4, 3:39 am, Bruno Desthuilliers wrote:
> Alf P. Steinbach a écrit :
> (snip)
>
> > Re efficiency it seems to be a complete non-issue, but correctness is
> > much more important: is there any way that the config details can be
> > (inadvertently) changed while the build is going on?
>
> +1
Alf P. Steinbach a écrit :
(snip)
Re efficiency it seems to be a complete non-issue, but correctness is
much more important: is there any way that the config details can be
(inadvertently) changed while the build is going on?
+1
--
http://mail.python.org/mailman/listinfo/python-list
* Tim Arnold:
This is a question about system design I guess. I have a django
website that allows users to change/view configuration details for
documentation builds. The database is very small. The reason I'm using
a database in the first place is to make it easy for users to change
the configur
Tim Arnold wrote:
> This is a question about system design I guess. I have a django
> website that allows users to change/view configuration details for
> documentation builds. The database is very small. The reason I'm using
> a database in the first place is to make it easy for users to change
>
In article ,
Steve Holden wrote:
>Julian wrote:
>>
>> But:
>>
>> - none classification: return an exception or None? I think None is
>> better, hence its not an exception that there is no classification but
>> a defined state. What do you think?
>> - many classifications: what to do? retun a se
On 18 Dez., 18:59, Steve Holden wrote:
> Julian wrote:
> > Hello,
>
> > I've got a design problem for a classifier. To make it short: it maps
> > strings on strings.
>
> > Some strings have exactly one classification, some none and some more
> > than one.
>
> > There's a method classify(self, word
Julian wrote:
> Hello,
>
> I've got a design problem for a classifier. To make it short: it maps
> strings on strings.
>
> Some strings have exactly one classification, some none and some more
> than one.
>
> There's a method classify(self, word) wich classifies a word. For the
> first case ther
Lacrima wrote:
On Jul 20, 4:05 pm, Jean-Michel Pichavant
wrote:
Lacrima wrote:
Hello!
I am newbie in python and I have really simple question, but I need
your advice to know how to do best.
I need to store a number of dictionaries in certain place. I've
decided to store them in
On 7/20/2009 9:42 AM, Lacrima wrote:
On Jul 20, 4:05 pm, Jean-Michel Pichavant
wrote:
Lacrima wrote:
Hello!
I am newbie in python and I have really simple question, but I need
your advice to know how to do best.
I need to store a number of dictionaries in certain place. I've
decided to store t
On Jul 20, 4:05 pm, Jean-Michel Pichavant
wrote:
> Lacrima wrote:
> > Hello!
>
> > I am newbie in python and I have really simple question, but I need
> > your advice to know how to do best.
> > I need to store a number of dictionaries in certain place. I've
> > decided to store them in a separate
Lacrima wrote:
Hello!
I am newbie in python and I have really simple question, but I need
your advice to know how to do best.
I need to store a number of dictionaries in certain place. I've
decided to store them in a separate module.
Like this:
dicts.py
---
dict1 = {}
dic
On Jul 20, 3:31 pm, "Diez B. Roggisch" wrote:
> Lacrima wrote:
> > Hello!
>
> > I am newbie in python and I have really simple question, but I need
> > your advice to know how to do best.
> > I need to store a number of dictionaries in certain place. I've
> > decided to store them in a separate mo
Lacrima wrote:
> Hello!
>
> I am newbie in python and I have really simple question, but I need
> your advice to know how to do best.
> I need to store a number of dictionaries in certain place. I've
> decided to store them in a separate module.
> Like this:
> dicts.py
> ---
>
> Darren Dale (DD) wrote:
>DD> On Apr 11, 2:15 pm, Darren Dale wrote:
>>> I am working on a project that provides a high level interface to hdf5
>>> files by implementing a thin wrapper around h5py. I would like to
>>> generalize the project so the same API can be used with other formats,
>>
On Apr 12, 4:53 pm, Darren Dale wrote:
> On Apr 12, 4:50 pm, Kay Schluehr wrote:
>
>
>
> > On 11 Apr., 20:15, Darren Dale wrote:
>
> > > I am working on a project that provides a high level interface to hdf5
> > > files by implementing a thin wrapper around h5py.
> > > I would like to
> > > gene
On Apr 12, 4:50 pm, Kay Schluehr wrote:
> On 11 Apr., 20:15, Darren Dale wrote:
>
> > I am working on a project that provides a high level interface to hdf5
> > files by implementing a thin wrapper around h5py.
> > I would like to
> > generalize the project so the same API can be used with other
On 11 Apr., 20:15, Darren Dale wrote:
> I am working on a project that provides a high level interface to hdf5
> files by implementing a thin wrapper around h5py.
> I would like to
> generalize the project so the same API can be used with other formats,
> like netcdf or ascii files. The format sp
On Apr 12, 3:23 pm, Aaron Brady wrote:
> On Apr 12, 1:30 pm, Darren Dale wrote:
>
>
>
> > On Apr 11, 2:15 pm, Darren Dale wrote:
>
> _
>
> > > format1.Group # implementation of group in format1
> > > format2.Group # ...
> > > Base.DerivedGroup # base implementation of DerivedGroup, not directly
On Apr 12, 1:30 pm, Darren Dale wrote:
> On Apr 11, 2:15 pm, Darren Dale wrote:
>
>
_
>
> > format1.Group # implementation of group in format1
> > format2.Group # ...
> > Base.DerivedGroup # base implementation of DerivedGroup, not directly
> > useful
> > format1.DerivedGroup = Base.DerivedGroup(
On Apr 11, 2:15 pm, Darren Dale wrote:
> I am working on a project that provides a high level interface to hdf5
> files by implementing a thin wrapper around h5py. I would like to
> generalize the project so the same API can be used with other formats,
> like netcdf or ascii files. The format spec
Mike D wrote:
> Steve,
>
> You raise some very good (and obvious) issues I did'nt consider. I'll
> look further into this sort of implementation as I'm quite interested.
>
> I suppose a compromise could be to load the objects from a pickle, that
> may have issues in terms of updating the pickle
Steve,
You raise some very good (and obvious) issues I did'nt consider. I'll look
further into this sort of implementation as I'm quite interested.
I suppose a compromise could be to load the objects from a pickle, that may
have issues in terms of updating the pickle perhaps, though it would be m
Mike D wrote:
> Steve,
>
> Thanks for the response. My question really comes down to, as you
> suggested, premature optimization.
>
> It is more for my own understanding than a current practical use.
>
> If an object is loaded into memory and other threads(or processes) can
> recieve a pointer
Steve,
Thanks for the response. My question really comes down to, as you suggested,
premature optimization.
It is more for my own understanding than a current practical use.
If an object is loaded into memory and other threads(or processes) can
recieve a pointer to this location, would this not
Mike D wrote:
> Hello, I've just picked up the Python language and am really enjoying it.
>
> I've just signed up to this mailing list and I'm looking forward to
> taking part in some discussions.
>
> My first post is a question I've been pondering for the last couple of days:
>
> For relativel
asincero a écrit :
> I have a class called Users that provides a higher level of
> abstraction to an underlying "users" table in a pgsql database. It
> has methods like "addUser()" and "deleteUser()" which, obviously, wrap
> the corresponding SQL statements. My question is would it better to
> le
asincero wrote:
> I have a class called Users that provides a higher level of
> abstraction to an underlying "users" table in a pgsql database. It
> has methods like "addUser()" and "deleteUser()" which, obviously, wrap
> the corresponding SQL statements. My question is would it better to
> let a
En Sun, 13 May 2007 11:40:16 -0300, Bruno Desthuilliers
<[EMAIL PROTECTED]> escribió:
> It's alas pretty common to see OO taught by persons who'd rather do some
> other job - preferably not related to computers.
If I had to name my worst class at university, it was the first one about
OO. The
[EMAIL PROTECTED] a écrit :
> On May 12, 9:34 pm, Bjoern Schliessmann [EMAIL PROTECTED]> wrote:
>
>
>>In principle, this is legal.
>>
>>But OTOH, how could a ShoppingCart "buy" something? In my world,
>>Buyers "buy" when using ShoppingCarts.
>
>
> Yes, I don't know either. I got this assignme
On May 12, 9:34 pm, Bjoern Schliessmann wrote:
> In principle, this is legal.
>
> But OTOH, how could a ShoppingCart "buy" something? In my world,
> Buyers "buy" when using ShoppingCarts.
Yes, I don't know either. I got this assignment for my homework, and
in UML diagram class ShoppingCart has
Alan Isaac <[EMAIL PROTECTED]> wrote:
> Essentially I want a generator that I can query about
> its characteristics. (E.g., a random number generator
> that I want to be able to ask about is distributional
> parameters.)
>
> I am thinking of a class that wraps a generator.
> An object of this cl
Alan Isaac wrote:
> Essentially I want a generator that I can query about
> its characteristics. (E.g., a random number generator
> that I want to be able to ask about is distributional
> parameters.)
>
> I am thinking of a class that wraps a generator.
> An object of this class will have a ``nex
Alan Isaac wrote:
> Essentially I want a generator that I can query about
> its characteristics. (E.g., a random number generator
> that I want to be able to ask about is distributional
> parameters.)
>
> I am thinking of a class that wraps a generator.
> An object of this class will have a ``nex
Hi Alan,
> One last point. While I remain interested in examples of how
> "late" addition ofattributesto class instances is useful,
> I must note that everyone who responded agreed that it
> has been a source of bugs. This seems to argue against a
> general ban on "locking" objects in some way, i
On Feb 26, 9:48 pm, "Alan Isaac" <[EMAIL PROTECTED]> wrote:
> I have a class whose instances should only receive attribute
> assignments for attributes that were created at inititialization.
> If slots are not appropriate, what is the Pythonic design for this?
Hi !
Even though a lot of people hav
>
> One last point. While I remain interested in examples of how
> "late" addition of attributes to class instances is useful,
> I must note that everyone who responded agreed that it
> has been a source of bugs. This seems to argue against a
> general ban on "locking" objects in some way, in som
Alan Isaac a écrit :
> The security application seems to call for roles.
Considering that a role is a set of permissions in a context. The
application doesn't want to say "you need this role", but "you need to
have a role that has this permission" (nb : this is based on Zope's
security model).
The security application seems to call for roles.
I'll have to think about the schema example.
But in any case, my question was poorly stated.
I started out wanting to trap was the dynamic
addition of attributes to class instances after
initialization. While you responded to my later question
as as
Alan Isaac a écrit :
> "Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in
> message news:[EMAIL PROTECTED]
>
>>I don't share your definition of "reasonable". But you should have
>>guessed by now
>
>
> My view may be shaped by a different experience.
> I have found dynamic attribute creation conv
On 28 Feb, 15:39, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> > However I will observe that
> > - entire languages are structured on the premise that dynamic
> > attribute creation can be hazardous
>
> Yup, and you are free to use one of them. And as an additional benefit, they
> will be more p
"greg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> There's a problem with that when you want to subclass:
Agreed. The following addresses that and, I think, some
of the other objections that have been raised.
Alan
class Lockable:
a = 0
def __init__(self, lock=False):
"Bruno Desthuilliers" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
> I don't share your definition of "reasonable". But you should have
> guessed by now
My view may be shaped by a different experience.
I have found dynamic attribute creation convenient
when doing something "quick a
On Feb 26, 10:48 pm, "Alan Isaac" <[EMAIL PROTECTED]> wrote:
> I have a class whose instances should only receive attribute
> assignments for attributes that were created at inititialization.
> If slots are not appropriate, what is the Pythonic design for this?
>
> Thanks,
> Alan Isaac
There is a
Alan Isaac wrote:
> class NothingNew:
> a = 0
> def __init__(self):
> self.b = 1
> self.initialized = True
There's a problem with that when you want to subclass:
class NothingElseNew(NothingNew):
def __init__(self):
NothingNew.__init__(self)
self.c
En Wed, 28 Feb 2007 09:41:47 -0300, Alan Isaac <[EMAIL PROTECTED]>
escribió:
> However I will observe that
> - entire languages are structured on the premise that dynamic
> attribute creation can be hazardous
That's why we have so many languages to choose from. What is highly
important for so
Alan Isaac a écrit :
> Ben Finney writes:
>
>>Really, though, adding attributes to an instance is a normal thing to
>>do in Python, and you've not yet shown why you want that normal
>>functionality to be special-cased here.
>
>
>
> I accept your earlier point that if an interface changes
> one
> However I will observe that
> - entire languages are structured on the premise that dynamic
> attribute creation can be hazardous
Yup, and you are free to use one of them. And as an additional benefit, they
will be more performant because you then can optimize the code further.
But they certain
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The easy, but inelegant, way is to set a flag.
That is the approach I explored here:
http://mail.python.org/pipermail/python-list/2007-February/428562.html
Btw, I add some background comments about "why" here:
http://
Ben Finney writes:
> Really, though, adding attributes to an instance is a normal thing to
> do in Python, and you've not yet shown why you want that normal
> functionality to be special-cased here.
I accept your earlier point that if an interface changes
one can just trap use of the old interfac
On Tue, 27 Feb 2007 20:59:03 +, Alan Isaac wrote:
> "Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> class Difficult(object):
> def __setattr__(self, name, value):
> if self.__dict__.has_key(name):
> print "'%s' exists as an instance att
"Alan Isaac" <[EMAIL PROTECTED]> writes:
> OK, let me approach this from a new direction. Suppose I define a
> class that behaves I think as I stipulated::
>
> class NothingNew:
> a = 0
> def __init__(self):
> self.b = 1
> self.initialized = True
> def __setattr__(self
OK, let me approach this from a new direction.
Suppose I define a class that behaves I think
as I stipulated::
class NothingNew:
a = 0
def __init__(self):
self.b = 1
self.initialized = True
def __setattr__(self, attr, val):
if not hasattr(self,'initialized') or
On 2/27/07, Alan Isaac <[EMAIL PROTECTED]> wrote:
> "Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > def __setattr__(self, attr, val):
> > if hasattr(self, attr):
> > self.__dict__[attr] = val
> > else:
> > # Tell the user off
>
> But then
"Arnaud Delobelle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> def __setattr__(self, attr, val):
> if hasattr(self, attr):
> self.__dict__[attr] = val
> else:
> # Tell the user off
But then you cannot even set attributes during initialization, right?
I wan
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
class Difficult(object):
def __setattr__(self, name, value):
if self.__dict__.has_key(name):
print "'%s' exists as an instance attribute" % name
self.__dict__[name] = value
elif
"Alan Isaac" <[EMAIL PROTECTED]> writes:
> "Ben Finney" <[EMAIL PROTECTED]> wrote:
> > The Pythonic design is: don't expect to have such control over
> > users of your code.
>
> I know this is a popular response, but the fact of the matter
> remains that it can be helpful to know when someone trie
On 27 Feb, 06:40, "Alan Isaac" <[EMAIL PROTECTED]> wrote:
> So my question remains:
> how best to trap any such attempt
> subsequent to object initialization?
> (I am willing to have properties for
> all data attributes, if that helps.)
>
You can define the __setattr__ method in your class as
def
On Tue, 27 Feb 2007 06:40:29 +, Alan Isaac wrote:
> "Ben Finney" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> The Pythonic design is: don't expect to have such control over users
>> of your code.
>
> I know this is a popular response,
It's popular for good reason.
> but
"Ben Finney" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The Pythonic design is: don't expect to have such control over users
> of your code.
I know this is a popular response,
but the fact of the matter remains that
it can be helpful to know when someone
tries to set a value for
"Alan Isaac" <[EMAIL PROTECTED]> writes:
> I have a class whose instances should only receive attribute
> assignments for attributes that were created at inititialization.
> If slots are not appropriate, what is the Pythonic design for this?
The Pythonic design is: don't expect to have such contr
Alan Isaac wrote:
> I have a class whose instances should only receive attribute
> assignments for attributes that were created at inititialization.
> If slots are not appropriate, what is the Pythonic design for this?
>
> Thanks,
> Alan Isaac
>
>
My understanding of "Pythonic design" is not to
StepH wrote:
>>a simple loop could do it
>> - handle user events
>> - collect data
>> - update displays
>> - sleep
>>
>>
>Here i've a prob. (due to the fact that I start both with Python &
>TkInter). In TkInter, you run your app by launching a mainloop()
>routine, right ? So, how, in my fo
Alex Verstraeten a écrit :
> StepH wrote:
>
>> 1./ Is each "display" must responsible to acquire/read the data ?
>> 2./ Or an engine collect the data then send them to each "display" ?
>>
>>
>>
> I'd keep it simple:
>
> - DataCollector class
> asociated with one or more display instances (implem
StepH wrote:
>1./ Is each "display" must responsible to acquire/read the data ?
>2./ Or an engine collect the data then send them to each "display" ?
>
>
>
I'd keep it simple:
- DataCollector class
asociated with one or more display instances (implemented as a list of
display subscribers)
it c
65 matches
Mail list logo
