I did find a couple of patterns in Effective Python: 59 Specific Ways to Write
Better Python (Effective Software Development).
Registering classes and a field example.
Thanks
N.
--
https://mail.python.org/mailman/listinfo/python-list
Thanks Joel,
A quick look on Amazon shows it is probably relevant.
N.
--
https://mail.python.org/mailman/listinfo/python-list
s on setting up a similar system.
>
> ie. Declare classes and fields, query the meta data. Fields restricted to
> certain types.
>
> N.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
Joel Goldstick
http://joelgoldstick.com/ <http://joelg
Django has the idea of specifying models using typed Fields.
The same exists within SQLAlchemy
Are there any tutorials on setting up a similar system.
ie. Declare classes and fields, query the meta data. Fields restricted to
certain types.
N.
--
https://mail.python.org/mailman/listinfo
tring
> >> substitution fit with your inherited objects?
>
> > Since Str(str) inherits all methods of str, those methods that return
> > other strings (always new objects since str is immutable) like e.g.
> > replace() will return str and not Str(str), and don't have
ic case, act like strings
>> but in others, I'm sure, not. How does a concept like string
>> substitution fit with your inherited objects?
>
> Since Str(str) inherits all methods of str, those methods that return
> other strings (always new objects since str is immutable
thods that return
other strings (always new objects since str is immutable) like e.g.
replace() will return str and not Str(str), and don't have the meta
data copied. Which may be a bug or a feature ...:-)
I think the subtle difference here lies between the definition of
inheritance and duck-typing,
those on your own for a reason.
>
> Who says that that's the intended abstraction of inheriting from str?
> I thought that one purpose of inheritance was the reuse of behavior
> (i.e. methods) (and maybe state) of the superclass. So, my class
> Str(str): pass behaves like a stri
> > [...]In fact, now that I think of it, get_key
> > is probably a bad name for it, get_other_object_with_this_same_key is
> > probably more apt :)
>
> Or more precise:
> get_key_that_was_used_when_value_was_inserted_into_dictionary :-)
Or even more precisely:
get_key_obj
iting from str?
I thought that one purpose of inheritance was the reuse of behavior
(i.e. methods) (and maybe state) of the superclass. So, my class
Str(str): pass behaves like a string in all aspects, except that you
can attach some meta data that won't affect that behavior. In fact,
On Oct 10, 2007, at 6:40 PM, Andreas Kraemer wrote:
> On Oct 9, 9:18 pm, Erik Jones <[EMAIL PROTECTED]> wrote:
>> So, do you not keep references to your nodes anywhere but the actual
>> graph dict? I kind of agree with Chris here in that two dicts will
>> work. One for the nodes, indexed by thei
On Oct 9, 9:18 pm, Erik Jones <[EMAIL PROTECTED]> wrote:
> So, do you not keep references to your nodes anywhere but the actual
> graph dict? I kind of agree with Chris here in that two dicts will
> work. One for the nodes, indexed by their strings.
Yes, I guess that's exactly what I want. To kee
g here is conflating 2 mappings
> into
> > one: string value->person and person->values. Use 2 explicit
> dicts to
> > make it clear what you're going, or use one dict and store a
> tuple of
> > values: person, friends = d["John"].
>
> N
t;values. Use 2 explicit dicts to
> make it clear what you're going, or use one dict and store a tuple of
> values: person, friends = d["John"].
No, that was not the point.
I don't want the meta data to be used in the dictionary look-up, and in fact I
want to be able t
On 10/9/07, Andreas Kraemer <[EMAIL PROTECTED]> wrote:
>
> I sometimes find it useful to store meta data on dictionary keys, like in
> the following example:
>
> class Dict(dict):
> def __init__(self,*args,**kw):
> self.key_dict = {}
> super(Dict,self
I sometimes find it useful to store meta data on dictionary keys, like in the
following example:
class Dict(dict):
def __init__(self,*args,**kw):
self.key_dict = {}
super(Dict,self).__init__(*args,**kw)
def __setitem__(self,k,v):
self.key_dict[k] = k
super(Dict,self
In message <[EMAIL PROTECTED]>, BerndWill wrote:
> The only solution from me and my colleagues view (as poor at it sounds)
> is to setup a little python script "pinging" an amount of about 2.000
> servers in daily intervals checking for the validity of those SSL
> certificates.
There's no need t
formation out of the
>>> certificates itself (who signed it and what is the validation period,
>>> i.e. meta data).
>>>
>>> Can someone please help me out here !?
>>
>> This is very cheesy but I sometimes I've just run the openssl command
>>
Jan Dries <[EMAIL PROTECTED]> writes:
> C:\> curl -v https://www.paypal.com
>
> I'm sure that by using the cURL API directly, you can obtain the
> certificate information in a more direct way without having to rely on
> parsing the above output with regexps. Doing so might also be more
> complex t
Paul Rubin wrote:
> "BerndWill" <[EMAIL PROTECTED]> writes:
>> I would love to read programmatically some information out of the
>> certificates itself (who signed it and what is the validation period, i.e.
>> meta data).
>>
>> Can someone please
"BerndWill" <[EMAIL PROTECTED]> writes:
> I would love to read programmatically some information out of the
> certificates itself (who signed it and what is the validation period, i.e.
> meta data).
>
> Can someone please help me out here !?
This is very chees
tion out of the
certificates itself (who signed it and what is the validation period, i.e.
meta data).
Can someone please help me out here !?
(I know we should better setup a database with validation dates, but believe
me, we didn't succeed in it)
Thanks in advance for any help or tip
Regar
certificates itself (who signed it and what is the
validation period, i.e. meta data).
Can someone please help me out here !?
(I know we should better setup a database with
validation dates, but believe me, we didn’t succeed in it)
Thanks in advance for any help or tip
Regards
Bernd
23 matches
Mail list logo
