You could use ctime to see it by the time.
MD5 it's a most secure way to a file that CAN'T be modified. If you
just want to see if the file has been modified (like to make a cache),
use ctime.
--
http://mail.python.org/mailman/listinfo/python-list
Can't you limit SSH tunneling access to the IP and/or MAC that you want
to access ? It's simplest than any other solution.
--
http://mail.python.org/mailman/listinfo/python-list
comes into doubt, rather than adopting language that implies that those
> types are somehow related to types from type theory.
While I am quite sympathetic to this point, I have to say that
this horse left the barn quite some time ago.
Marshall
PS. Hi Chris!
--
http://mail.python.org/mailman/listinfo/python-list
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > While I am quite sympathetic to this point, I have to say that
> > this horse left the barn quite some time ago.
>
> I don't think so. Perhaps it's futile to go scouring the world for uses
> of t
Joe Marshall wrote:
>
> They *do* have a related meaning. Consider this code fragment:
> (car "a string")
> [...]
> Both `static typing' and `dynamic typing' (in the colloquial sense) are
> strategies to detect this sort of error.
The thing is though, that
ve dynamic types, but C does not. C++ is
somewhere in the middle.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
re orthogonal. Maybe
we have reached the point where trying to cram everything
in two one of two possible ways of doing things isn't going
to cut it any more.
Could it be that the US two-party system has influenced our
thinking?
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
e for me.
If the language has no possible mechanism to observe the
it-was-only-eliminated-as-an-optimization tag, in what sense
is it "always there?" E.g. The 'C' programming language.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
ping issues associated with this distinction
are falsely labeled as a static-vs-dynamic issues, since so many
statically
type languages are nominally typed.
We need entirely new, finer grained terminology.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
ral or intuitive to me.
Are you referring to the types in the programmers head,
or the ones at runtime, or what?
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
ed value that cannot be updated, it makes
no sense to call it "variable" since it isn't *able* to *vary.*
Let's call it a named constant.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
g, and set theory seems to me to be a good
choice for a foundation. What else would you use?
(Agree with the rest.)
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Dr.Ruud wrote:
> Marshall schreef:
>
> > "dynamic types." I don't have a firm definition for
> > that term, but my working model is runtime type tags. In which
> > case, I would say that among statically typed languages,
> > Java does have dynamic types
Matthias Blume wrote:
> "Marshall" <[EMAIL PROTECTED]> writes:
>
> > Torben Ægidius Mogensen wrote:
> >>
> >> That's not true. ML has variables in the mathematical sense of
> >> variables -- symbols that can be associated with differ
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > I think what this highlights is the fact that our existing terminology
> > is not up to the task of representing all the possible design
> > choices we could make. Some parts of dynamic vs. static
> > a m
Rob Warnock wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> >
> > Can you be more explicit about what "latent types" means?
> > I'm sorry to say it's not at all natural or intuitive to me.
> > Are you referring to the types in the programmers
ich is still mostly unknown.
Oh, and I also want to say that of all the cross-posted mega threads
on static vs. dynamic typing, this is the best one ever. Most info;
least flames. Yay us!
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Andreas Rossberg wrote:
> Marshall wrote:
> >
> > What prohibits us from describing an abstract type as a set of values?
>
> If you identify an abstract type with the set of underlying values then
> it is equivalent to the underlying representation type, i.e. there is no
e, my goal is to illustrate for those
> who are interested in getting a possibly different perspective.
Yes, and thank you for doing so.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Marshall wrote:
>
> In this simple example,
> the static case is better, but this is not free, and the cost
> of the static case is evident elsewhere, but maybe not
> illuminated by this example.
Ugh, please forgive my ham-fisted use of the word "better."
Let me try again
Joe Marshall wrote:
>
> That's the important point: I want to run broken code.
I want to make sure I understand. I can think of several things
you might mean by this. It could be:
1) I want to run my program, even though I know parts of it
are broken, because I think there are parts t
Joachim Durchholz wrote:
> Marshall schrieb:
> > immutable = can't change
> > vary-able = can change
> >
> > Clearly a contradiction in terms.
>
> Not in mathematics.
So stipulated.
However, it *is* a contradiction in English. Now, we often redefine
or narr
lent* thread. The evangelism is at
rock-bottom
and the open exploration of other people's way of thinking is at what
looks to me like an all-time high.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Anton van Straaten wrote:
> Marshall wrote:
> > Can you be more explicit about what "latent types" means?
> > I'm sorry to say it's not at all natural or intuitive to me.
> > Are you referring to the types in the programmers head,
> > or the ones
." Further, anyone
who was interested in actually understanding the issues woudn't
be doing what you describe.
And if you did find someone who was actively doing this I would
say "never attribute to malice what can adequately be explained
by stupidity."
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Andreas Rossberg wrote:
> Marshall wrote:
> >
> > What we generally (in programming) call variables are locals
> > and globals. If the languages supports an update operation
> > on those variables, then calling them variables makes sense.
> > But "variable&quo
Pascal Costanza wrote:
> Marshall wrote:
> > Pascal Costanza wrote:
> >> Consider a simple expression like 'a + b': In a dynamically typed
> >> language, all I need to have in mind is that the program will attempt to
> >> add two numbers. In a sta
sometime
> in the future) another class is proposed which violates those assumptions,
> then
> that second class is rejected.
I have to object to the term "hybrid".
Java has a static type system.
Java has runtime tags and tag checks.
The two are distinct, and neither one is less
ime
checks can do anything with these properties, at least not without
a formal framework. An example is deadlock freedom. There
exist type systems that can prove code free of deadlock or
race conditions. How woud you write a runtime check for that?
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
whole line of reasoning that goes
"someone might think term x means something bad, so we
can't use it." It's unfalsifiable. It also optimizes for malicious
use of the terms. Both are bad properties to have as design
principles, at least in this context.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Andreas Rossberg wrote:
>
> ... And the reason is that "type" has a
> well-established use in theory. It is not just my "assumption", it is
> established practice since 80 or so years.
Wouldn't it be fair to say it goes back a least to
Principia Mathematica, 1910?
> So far, this discussion has
>
Joe Marshall wrote:
> Marshall wrote:
> > Joe Marshall wrote:
> > >
> > > That's the important point: I want to run broken code.
> >
> > I want to make sure I understand. I can think of several things
> > you might mean by this. It could be:
&
Joe Marshall wrote:
> Marshall wrote:
> > Timo Stamm wrote:
> > >
> > > This is actually one of the most interesting threads I have read in a
> > > long time. If you ignore the evangelism, there is a lot if high-quality
> > > information and first-hand
uage (at least the core
language; the standard is getting huge) with guaranteed termination,
that is used everywhere and quite useful, is SQL.
I wouldn't want to write an accounting package in it; its abstraction
facilities are too weak. But the language is much more powerful
than it is usual
Darren New wrote:
> Marshall wrote:
> > I can't see how you'd call + on a and b if you think they might
> > not be numbers.
>
> Now substitute "<" for "+" and see if you can make the same argument. :-)
If your point is about overloading, the
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > Ouch; I have a really hard time understanding this.
> >
> > I can't see how you'd call + on a and b if you think they might
> > not be numbers. If they could be something other than numbers,
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > Java has a static type system.
> > Java has runtime tags and tag checks.
>
> Yes.
>
> > The two are distinct, and neither one is less than complete
>
> How is neither one less than complete?
elieve you can do the above in C++, can't you?
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Chris Uppal wrote:
> Marshall wrote:
>
> [me:]
> > > But, as a sort of half-way, semi-formal, example: consider the type
> > > environment in a Java runtime. The JVM does formal type-checking of
> > > classfiles as it loads them. In most ways that checking
Dr.Ruud wrote:
> Marshall schreef:
> > Rob Thorpe:
>
> >> Can I make a type in C that can only have values between 1 and 10?
> >> How about a variable that can only hold odd numbers, or, to make it
> >> more difficult, say fibonacci numbers?
> >
> &g
a programmer experiences, not to the subset of that
> language which is all that we're typically able to formally define.
That is starting to get a bit too mystical for my tastes.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
t, which the reverse does not do.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Gabriel Dos Reis wrote:
> "Marshall" <[EMAIL PROTECTED]> writes:
>
> | David Hopwood wrote:
> | >
> | > A type system that required an annotation on all subprograms that do not
> | > provably terminate, OTOH, would not impact expressivenes
alled "suspected." Even if you
think something which turns out to be true, we could not say
that you "knew" it unless your reasons for your thoughts were
valid.
I flipped a coin to see who would win the election; it came
up "Bush". Therefore I *knew* who was going to w
ithout explicit type annotations
> >> with or without type inference
> >>
> >> Wow. And I don't think that's a complete list, either.
> >
> > Yup.
>
> What else?
> (Genuinely curious.)
I left off a big one: nominal vs. structural
Also: h
Chris F Clark wrote:
> Chris F Clark (I) wrote:
>
> > I'm particularly interested if something unsound (and perhaps
> > ambiguous) could be called a type system. I definitely consider such
> > things type systems.
>
> "Marshall" <[EMAIL PROTECTED]&
David Hopwood wrote:
> Marshall wrote:
> > David Hopwood wrote:
> >
> >>A type system that required an annotation on all subprograms that do not
> >>provably terminate, OTOH, would not impact expressiveness at all, and would
> >>be very useful.
> &g
rgument is zero, but will count on the fact
> that the processor will raise an exception one level deeper.
This is an implementation artifact, and hence not relevant to our
understanding of the issue.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
ssible under the circumstances, and writing a separate function
> for each narrow type is ridiculous and a maintenance nightmare even if
> they can share the bulk of the code.
This is the partial function question again, in a different guise.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
, then some bugs must escape it.
I don't think so. Even with a Turing complete type system, a program's
runtime behavior is still something different from its static behavior.
(This is the other side of the "types are not tags" issue--not only
is it the case that there are
Ketil Malde wrote:
> "Marshall" <[EMAIL PROTECTED]> writes:
>
> > There are also what I call "packaging" issues, such as
> > being able to run partly-wrong programs on purpose so
> > that one would have the opportunity to do runtime analysis
&
David Hopwood wrote:
> Marshall wrote:
> > The real question is, are there some programs that we
> > can't write *at all* in a statically typed language, because
> > they'll *never* be typable?
>
> In a statically typed language that has a "dynamic&q
David Hopwood wrote:
> Marshall wrote:
> > David Hopwood wrote:
> >>Marshall wrote:
> >>
> >>>The real question is, are there some programs that we
> >>>can't write *at all* in a statically typed language, because
> >>>they'
Joe Marshall wrote:
> Marshall wrote:
> >
> > Yes, an important question (IMHO the *more* important question
> > than the terminology) is what *programs* do we give up if we
> > wish to use static typing? I have never been able to pin this
> > one down at all
the data where necessary at the time of
> replacement". Translating the data, i.e., re-establishing the
> invariants expected by the updated/replaced code, seems much harder
> (to me) in the case of self-modifying code. Erlang got this one
> right.
Pardon my ignorance, but what is
Chris Smith wrote:
>
> [...] static typing does ... doesn't imply any constraints on the kind
> of behavioral property that's being checked; but only on the way that
> the check occurs.
Nice post.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
sulation is only
a hack to get around the lack of a decent declarative constraint
language.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
also need to add primitives for type
> checking, and if the language is stateful, you'll also want primitives
> for accessing earlier states (most notably at function entry).
Again I'm not entirely clear what this means. Are you talking
about pre/post conditions, or are you talking about having the
constraint language itself be something other than functional?
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > Chris Smith wrote:
> > >
> > > But this starts to look bad, because we used to have this nice property
> > > called encapsulation. To work around that, we'd need to make one of a
> >
ine down to nothing.
>
> Don't you have a newsreader that can mark whole threads that you don't want
> to read?
Sure, or he could just skip over it. Or he could make a simple
request, such as "please trim comp.lang.whatever because it's
off-topic here." But
Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Chris Smith schrieb:
> >>> For example, I wrote that example using variables of type int. If we
> >>> were to suppose that we were actually working with variables of type
&
TAPL? Or ATTPL? Can you cite it a bit more specifically?
I want to reread that.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Joachim Durchholz wrote:
> Marshall schrieb:
> > Now, I'm not fully up to speed on DBC. The contract specifications,
> > these are specified statically, but checked dynamically, is that
> > right?
>
> That's how it's done in Eiffel, yes.
>
> > In
mal model being an issue, but is the
imperative bit really all that much of an obstacle? How hard
is it really to deal with assignment? Or does the issue have
more to do with pointers, aliasing, etc.?
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Joachim Durchholz wrote:
> Marshall schrieb:
>
> > I can certainly see how DbC would be useful without subtyping.
> > But would there still be a reason to separate preconditions
> > from postconditions? I've never been clear on the point
> > of differentiati
Joachim Durchholz wrote:
> Marshall schrieb:
> > I can see the lack of a formal model being an issue, but is the
> > imperative bit really all that much of an obstacle? How hard
> > is it really to deal with assignment? Or does the issue have
> > more to do w
Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> I can see the lack of a formal model being an issue, but is the
> >>> imperative bit really all that much of an obstacle? How hard
> >>> i
David Hopwood wrote:
> Marshall wrote:
>
> > Wouldn't it be possible to do them at compile time? (Although
> > this raises decidability issues.)
>
> It is certainly possible to prove statically that some assertions cannot fail.
>
> The ESC/Java 2 (http://secure.
Andreas Rossberg wrote:
> Marshall wrote:
> >
> > Okay, sure. But for the problem you describe, both imperativeness
> > and the presence of pointers is each necessary but not sufficient;
> > it is the two together that causes the problem. So it strikes
> >
Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> Joachim Durchholz wrote:
> >>>> Marshall schrieb:
> >>>>> I can see the lack of a formal model being an issue, but is the
>
Joachim Durchholz wrote:
> Marshall schrieb:
> > Mutability by itself does not imply identity.
>
> Well, the implication certainly holds from identity to mutability.
> The only definition of identity that I found to hold up for all kinds of
> references (pointers, shared-mem
Joe Marshall wrote:
> Marshall wrote:
> >
> > Again, I disagree: it is posible to have mutability without
> > pointers/identity/objects.
>
> I think you are wrong, but before I make a complete ass out of myself,
> I have to ask what you mean by `mutability'. (A
Joe Marshall wrote:
> Marshall wrote:
> >
> > Consider the following Java fragment:
> >
> > void foo() {
> > int i = 0;
> > int j = 0;
> >
> > // put any code here you want
> >
> > j = 1;
> > i = 2;
> > // c
of its value.
I'm not sure what you mean by that.
> I also see, though, that the majority (so far, I'd
> say all) of the potential uses for which it's worth introducing mutation
> into an otherwise mutation-free language allow the possibility of
> aliasing, which sorta m
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > Chris Smith wrote:
> > > Darren New <[EMAIL PROTECTED]> wrote:
> > > > Chris Smith wrote:
> > > > > Unless I'm missing your point, I disagree with your disagreement.
> &
George Neuner wrote:
> On 13 Jul 2006 08:45:49 -0700, "Marshall" <[EMAIL PROTECTED]>
> wrote:
> >
> >On the other hand, there is no problem domain for which pointers
> >are a requirement. I agree they are deucedly convenient, though.
> >
>
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > > What you are asking for is some subset of identity, and I've not yet
> > > succeeded in understanding exactly what it is or what its limits are...
> > > except that so far, it seems
Joachim Durchholz wrote:
> Marshall schrieb:
> > What about my example of SQL? Mutation, no pointers, no aliasing.
> > Yet: useful.
>
> Sorry, but SQL does have aliasing.
Well. I suppose we do not have an agreed upon definition
of aliasing, so it is hard to evaluate either
Andreas Rossberg wrote:
> Marshall wrote:
> >
> > After all, what are the alternatives? Purely-functional
> > languages remove themselves from a large class of
> > problems that I consider important: data management.
>
> Maybe, but I have yet to see how secon
Joachim Durchholz wrote:
> Marshall schrieb:
> > void foo() {
> > int i = 0;
> > int j = 0;
> > j = 1;
> > i = 2;
> > // check value of j here. It is still 1, no matter what you filled
> > // in above.
> > // The assi
references to mutable data
> everywhere. All OO languages are a typical example of that.
Now with this, it appears you are agreeing that SQL has an advantage
vis-a-vis aliasing compared to OO languages. Yes? If so, we are
agreeing on the part I care about, and the specifics of just what
we call aliasing are not so important to me.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
Joachim Durchholz wrote:
> Marshall schrieb:
>
> >> In some cases, you need an additional level of conceptual indirection -
> >> instead of *doing* the updates, you write a function that *describes* them.
> >
> > But then what do you do with that functio
Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> As I said elsewhere, the record has an identity even though it isn't
> >> explicit in SQL.
> >
> > H. What can this mean?
> >
> > In general, I feel that &
Joachim Durchholz wrote:
> Marshall schrieb:
>
> > But what you descrbe is certainly *not* possible in the
> > relational algebra; alas that SQL doesn't hew closer
> > to it. Would you agree?
>
> Yup, SQL (particularly its update semantics) aren't relational
Chris F Clark wrote:
> "Marshall" <[EMAIL PROTECTED]> wrote:
> > In general, I feel that "records" are not the right conceptual
> > level to think about.
>
> Unfortunately, they are the right level. Actually,the right level
> might even be lo
Joachim Durchholz wrote:
> Marshall schrieb:
> >
> > Good point. Perhaps I should have said "relational algebra +
> > variables with assignment." It is interesting to consider
> > assignment vs. the more restricted update operators: insert,
> > update,
oes. INSERT/DELETE can
> > create resp. destroy records, which is what new and delete operators
> > would do.
> >
> > I must really be missing the point.
>
> I *think* I understand Marshall here. When you are saying "assignment",
> you mean assignment to valu
Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> Good point. Perhaps I should have said "relational algebra +
> >>> variables with assignment." It is interesting to consider
> >>
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > We seem to have slipped back from the hypothetical relation language
> > with only assignement back to SQL.
>
> [...]
> I don't see how such a language (limited to assignment of entire
> relations) i
Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > > If the relations are to
> > > be considered opaque, then there's clearly no aliasing going on.
> >
> > Not certain I understand, but I think I agree.
>
> My condition, though
Joachim Durchholz wrote:
> Marshall schrieb:
> > Chris Smith wrote:
> >> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
> >> I *think* I understand Marshall here. When you are saying "assignment",
> >> you mean assignment to values of attribu
Hi,
Does anyone see a problem with doing:
data = file("tata").read()
Each time this is done, I see a new file
descriptor allocated (Linux) but not
released.
1) Will there ever be a point where I
will have a problem with file
descriptors because the garbage
collector has _not_ yet co
On Thu, 2004-12-09 at 08:41 -0500, Peter Hansen wrote:
> John Marshall wrote:
> > Hi,
> >
> > Does anyone see a problem with doing:
> > data = file("tata").read()
> >
> > Each time this is done, I see a new file
> > descriptor allocat
On Thu, 2004-12-09 at 10:33 -0500, Peter Hansen wrote:
> John Marshall wrote:
> > It seems to me that a file.__del__() _should_
> > call a file.close() to make sure that the file
> > is closed as a clean up procedure before
> > releasing the object.
>
> I
Jeremy Bowers <[EMAIL PROTECTED]> writes:
> On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote:
>
>> Daniel Silva wrote:
>>
>>> Shriram Krishnamurthi has just announced the following elsewhere; it might
>>> be of interest to c.l.s, c.l.f, and c.l.p:
>>> http://list.cs.brown.edu/pipermail/
> Note, however, that there are more pythonic ways to perform this task.
> You might try:
>
> for index in range(len(fruit)):
>letter = fruit[-index-1]
>print letter
Or, if you're *really* just trying to reverse the string, then the
following might read more easily (although it's probably
> I was wondering how i could parse the contents of a file into an array.
> the file would look something like this:
>
> gif:image/gif
> html:text/html
> jpg:image/jpeg
Try something like this:
d = {}
for line in open("input.txt").readlines():
ext, mime = line.strip().split(":")
d[ext] = mim
Hi,
For strings of > 1 character, what are the chances
that hash(st) and hash(st[::-1]) would return the
same value?
My goal is to uniquely identify multicharacter strings,
all of which begin with "/" and never end with "/".
Therefore, st != st[::-1].
Thanks,
John
--
http://mail.python.org/mail
Scott David Daniels wrote:
> John Marshall wrote:
>
>>For strings of > 1 character, what are the chances
>>that hash(st) and hash(st[::-1]) would return the
>>same value?
>
>
> Why not grab a dictionary and do the stats yourself?
I was actually interested
Tim Peters wrote:
> [John Marshall]
> Second, what are your assumptions about (a) the universe of strings;
> and, (b) the hash function?
My assumptions are:
(a) valid and "reasonable" pathnames (e.g., 1024
characters long)
(b) just the builtin hash().
The goal is to b
1 - 100 of 142 matches
Mail list logo
