Carl Banks wrote:
> On Mar 26, 10:11 am, "Andy Dingley" <[EMAIL PROTECTED]> wrote:
>
>>On 26 Mar, 14:20, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>>
>>
>>>what are the advantages of using Python for
>>>creating number crunching apps over Fortran??
>>
>>If you have to ask, you've not experien
robert wrote:
> Chris Smith wrote:
>
>>Howdy,
>>
>>I'm a college student and for one of we are writing programs to
>>numerically compute the parameters of antenna arrays. I decided to use
>>Python to code up my programs. Up to now I haven't had a pro
Howdy,
I'm a college student and for one of we are writing programs to
numerically compute the parameters of antenna arrays. I decided to use
Python to code up my programs. Up to now I haven't had a problem,
however we have a problem set where we are creating a large matrix and
finding it's inver
Does anyone know of any python scripts that can help me automatically
navigate through some forms so I can schedule the download the file at the
end of all the questions?
--
http://mail.python.org/mailman/listinfo/python-list
t does, though, have the nice property of hiding the aliasing from the
semantic model. That is interesting and worth considering, but is a
different conversation; and I don't know how to start it.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
exist. The implementation is still going to deal with the aliasing
problem, which will resurface once you pass over to the other side of
the abstraction boundary.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ent;
and if that's not the case, then I would need someone to explain how to
accomplish the same goals in the new relational language; i.e. it would
need some way of expressing transformations of relations, not just
complete replacement of them with new relations that are assumed to
app
ng "assignment", he seems to mean assigning a
completely new *table* value to a relation; i.e., wiping out the entire
contents of the relation and replacing it with a whole new set of
tuples. Your assignment is indeed less powerful than DML, whereas
Marshall's assignment is more p
rch or not believing it important, I
don't know.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
David Hopwood <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
> > If checked by execution, yes. In which case, I am trying to get my head
> > around how it's any more true to say that functional languages are
> > compilable postconditions than to say the same
ricted untyped pointers, if it
doesn't get lucky with the capture analysis, may have to re-evaluate all
invariants in the application on any given assignment. Nevertheless,
the re-evaluation of the invariant still needs to be done.
--
Chris Smith - Lead Software Developer /Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
wouldn't be able to get away with it, for example. That said, it's also
quite possible to consider aliasing on higher levels as well; it's just
not possible to point out the lack of aliasing for higher levels of
abstraction, and thus conclude that no aliasing exists. Aliasing is
< i)
> and
>x &= (1 << j)
>
> are aliased expressions for setting a particular bit in x?
I don't know about Joachim, but yes, I would.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ybe I actually spoke to your boss, or to your nephew's best-
friend's father. If databases are capable of modeling these kinds of
relationships (and of course they are), then they are as susceptible to
"aliasing" -- in a logical sense that avoids mention of pointer -- as
anyo
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.
> > > > Mutability only makes sense beca
nal languages are
compilable postconditions than to say the same of imperative languages.
In both cases, some statement is asserted through a description of a
means of computing it. There may be a distinction worth making here,
but I'm missing it so far.
--
Chris Smith - Lead Software Develop
Darren New <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
> > Unless I'm missing your point, I disagree with your disagreement.
> > Mutability only makes sense because of object identity (in the generic
> > sense; no OO going on here).
>
> Depends wha
ity implies aliasing problems, however.
We might have a terminological issue, then. I'd tend to say that
mutability definitely does imply identity, but identity doesn't imply
aliasing. Same difference.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
l stuff within them (in particular,
> express all algorithms).
Is it really consistent to say that postconditions allow you to express
algorithms?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ones, and affect
> the usability of the language.
There doesn't seem to be a point of disagreement here. Programmers
often need to require certain properties to be checked at compile-time.
Others could go either way. There is no property that a program would
rationally desire to *requir
Marshall <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
> > Going back to my
> > handy copy of Pierce's book again, he claims that range checking is a
> > solved problem in theory, and the only remaining work is in how to
> > integrate it into a progr
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Chris Smith <[EMAIL PROTECTED]> writes:
> >> No what happens if right here you code
> >>b := 16;
> >>
> >> Does that again change the type of "b"? Or is that an
t bother
you that I'm considering George's point?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
; true assertions about the types of expressions.
Ah. I meant complete enough to accomplish the goal in this subthread,
which was to ensure that the compiler knows when a particular int
variable is guaranteed to be greater than 18, and when it is not.
--
Chris Smith - Lead Software Dev
mplete, requiring frequent runtime-checked type ascriptions to
prevent it from becoming impossible to write software. That's not my
idea of a usable language.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Darren New <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
> > // Inside this block, a has type int{17..21} and b has type
> > // int{18..22}
>
> No what happens if right here you code
>b := 16;
>
> Does that again change the type of "
I believe these are amenable
> to the usual approaches. The runtime/compile time question, and
> decidability seem bigger issues to me.
Well, the point of static typing is to do what's possible without
reaching the point of undecidability. Runtime support for checking the
co
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
> > few choices: (a) give up encapsulation,
d to be there in all programming languages, and which make
it harder to take one design principle to its extreme and produce a
usable language as a result. I don't know that it's impossible for this
sort of thing to be done in a usable Java-like language, but in any
case, the way to a
of stuff. However, it is possible, and it is a static type system,
because expressions are assigned typed syntactically, rather than values
being checked for correctness at runtime.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
to (Y (\fa.f)) in lambda calculus,
where \ is lambda, and Y is the fixed point combinator?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
int it will be
> possible (and easy) to write buggy programs. Gödel!
I agree. I never said that the ideal point is achievable... only that
there is a convergence toward it. (In some cases, that convergence may
have stalled at some equilibrium point because of the costs of being
near tha
ing different depending on the kind of data. In that
case, the sufficiently powerful type system would need to have rules so
that an if statemement creates a modified type environment to take that
into account. This is different from a runtime type check, in that you
are writing explicit code tha
erations.
> 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? I think there might be, but I've
> never been able to find a solid example of one.
This seems to depend
quoting here, so I don't know exactly how this is true. Marshall
mentioned template meta-programming in C++, which is definitely Turing-
complete.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
giving much of a definition. (Unless you think that
frogs are perfectly good examples of type systems.)
Incidentally, in the case of static type systems, we define the system
(for example, using the definition given from Pierce many times this
thread), and then infer the definition of types and typ
't be formulated as a type error. And if so, what good does
it do us to talk about type errors when we already have the perfectly
good word "bug" to describe the same concept?
> Now, the example may have seemed arbitrary to you, and it was in some
> sense arbitrary.
Arbitrary i
George Neuner wrote:
> On Sun, 25 Jun 2006 14:28:22 -0600, Chris Smith <[EMAIL PROTECTED]>
> wrote:
>
> >George Neuner wrote:
> >> >Undecidability can always be avoided by adding annotations, but of
> >> >course that would be gross overkill in the
Pascal Costanza <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
> > Of course zero is not appropriate as a second argument to the division
> > operator! I can't possibly see how you could claim that it is. The
> > only reasonable statement worth making is that
pe
check" is a different matter, and highlights the fact that again there's
something fundamentally different about the definition of a "type" in
the static and dynamic sense.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
of problems
which people happen to think of as type problems. If type theorists
fourty years ago had limited themselves to considering what people
thought of as types back then, we'd be in a considerably worse position
today with regard to the expressive power of types in commonly used
programming languages. Hence, your implication that insisting on a
formal rather than intuitive definition is opposed to the real-world
usefulness of the field is actually rather ironic. The danger lies in
assuming that unsolved problems are unsolvable, and therefore defining
them out of the discussion until the very idea that someone would solve
that problem with these techniques starts to seem strange.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
be fixed as soon as possible. Otherwise, the type system doesn't
do much good. It's also true, I suppose, that as soon as a person
realizes that their mental thought process of types is unsound, they
would want to fix it. The difference, though, is that there is then no
formal d
like this may be written without
making giving the development process undue difficulty by requiring ten
times as much type annotations as actual code. There are attempts that
have been made, and they don't look too awfully bad.
--
Chris Smith - Lead Software Developer / Technica
rmal definition of
types in the first place, and make it clear when one or the other
meaning is being used.
Hopefully, that's a fair summary of the thread to date.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ype systems and formal
type theory is to avoid confusing aspects of one field with the other.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
throwing away the
details we don't care about (anything that's irrelevant to the
predicate), and applying stereotypical rules (the theorem or axiom). I
don't quite understand what you mean by substituting classes.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
is isn't perceived as too picky. I've already conceded
that we can use "type" in a way that's incompatible with all existing
research literature. I would, however, like to retain some word with
actually has that meaning. Otherwise, we are just going to be
linguistically prevented from discussing it.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
7;s what I've been trying to do. So far I've had only limited
success, although there is definite potential in one post by Chris Uppal
and another by Chris Clark (or maybe I'm just partial to other people
named Chris).
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ther pesky question; if the language
"catches" it, did the error even occur, or did the expression just gain
a defined result such that domain #3 is indistinguishable from the set
of all possible inputs. I tend to agree with Chris Uppal, I suppose,
that the latter is really the case,
Chris F Clark <[EMAIL PROTECTED]> wrote:
> Chris Smith <[EMAIL PROTECTED]> writes:
> > I thought about this in the context of reading Anton's latest post to
> > me, but I'm just throwing out an idea.
>
> I wrote:
> > I think there is some sense
Marshall <[EMAIL PROTECTED]> wrote:
> I stand corrected: if one is using C and writing self-modifying
> code, then one *can* zip one's pants.
I believe you'd need quite the creative USB-based or similar peripheral
device, as well.
--
Chris Smith - Lead Software Develop
ic types do, loosely speaking, have the "purpose" of
> formalizing the informal properties I'm talking about.
Static types have the property of proving ANY properties of a program
that may be proven. Certainly, research is pragmatically restricted to
specific problems that are (1) useful and (2) solvable. Aside from
that, I can't imagine any competent language designer building a type
system, but rejecting some useful and solvable feature for the sole
reason that he or she doesn't think of it as solving a type error.
> But I hardly see why such an informal characterization should bother
> you. It doesn't affect the definition of static type.
I hope I've explained how it does affect the definition of a static
type.
> This is based on the assumption that all we're talking about is
> "well-defined semantics".
Indeed. My statement there will not apply if we find some formal
definition of a dynamic type system that doesn't reduce to well-defined
semantics once you remove the intuitive bits from it.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
reasoning
> that fits the "type" label, and informal reasoning that doesn't.
So while I disagree in the static case, it seems likely that this is
true of what is meant by dynamic types, at least by most people in this
discussion. I'd previously classified you as not agreeing.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
to think of one as a type error being "solved",
whereas the other is not.
Anyway, you just wrote another message that is far closer to what I feel
we ought to be thinking about than my question here... so I will get to
reading that one, and perhaps we can take up this point later w
Dr.Ruud <[EMAIL PROTECTED]> wrote:
> Chris Smith schreef:
>
> > Static types are not fuzzy
>
> Static types can be fuzzy as well. For example: a language can define
> that extra accuracy and bits may be used for the implementation of
> calculations: d = a *
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?
--
Chris Smith - Lead Software Developer / Technical
Chris Smith <[EMAIL PROTECTED]> wrote:
> Programming languages do this all the time, as well. The most popular
> example is the OO sense of the word polymorphism. That's all about
> being able to write code that works with a range of values regardless of
> (or, at l
the example here.]
Programming languages do this all the time, as well. The most popular
example is the OO sense of the word polymorphism. That's all about
being able to write code that works with a range of values regardless of
(or, at least, a range that less constraining than equlity i
pective of
static types. If you are proposing that it is also orthogonal with
respect to dynamic types, that will be a welcome step toward our goal of
a grand unified type theory, I suppose. I have heard from others in
this thread that they don't believe so. I am also interested in your
informal reasoning by programmers about their programs. That would
agree with my skepticism, but probably not with too many other people.
> An example of a form of informal reasoning that (practically) every
> programmer does daily is termination analysis.
Or perhaps you agree with my skept
s, of course, a very good reason to reject the idea that the
static type system for any Turing-complete language could ever perform
this same kind analysis.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Chris Smith <[EMAIL PROTECTED]> wrote:
> I see it as quite reasonable when there's an effort by several
> participants in this thread to either imply or say outright that static
> type systems and dynamic type systems are variations of something
> generally called a
saying that there is a well-
defined semantics for the language.
I believe that's unacceptable for several reasons, but the most
significant of them is this. It's not reasonable to ask anyone to
accept that static type systems gain their essential "type system-ness"
fro
g post. Why does it matter to
you?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ogramming languages. By doing so, we are able at
least to considerably simplify the grammar of the language, and perhaps
also to increase the "tightness" of the verification without risking
making the language grammar context-sensitive. (I'm unsure about the
second part of that st
erations
on actual values. I suppose, though, that they do eventually happen
with primitives at the leaves of the derivation tree, so the definition
would still apply.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
e execution environment, including
the CPU, virtual memory system, etc." as appropriate. I am aware of no
hardware environment that really accepts all possible values for all
possible operations without the potential of somehow signaling a type
violation.
--
Chris Smith - Lead Software
s).
I suspect you'll see the Smalltalk version of the objections raised in
response to my post earlier. In other words, whatever terminology you
think is consistent, you'll probably have a tough time convincing
Smalltalkers to stop saying "type" if they did before. If
strongly with "dynamically typed".
Nevertheless, the existence of languages that are clearly "both"
suggests that they should be considered separately to at least some
extent.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
l.
Really? I can see that in a strong enough static type system, many
dynamic typing features would become unobservable and therefore would be
pragmatically excluded from any probable implementations... but I don't
see any other kind of mutual exclusion between the two.
--
Chris Smith -
ed).
> Typed ("strongly typed") it is, but is it statically typed or
> dynamically typed?
So my answer is that it's not statically typed in the first case, and is
statically typed in the second case, and it intuitively appears to be
dynamically typed at least in the first
; development in Java, because we have a gigantic
existing software system written in Java and no time to rewrite it. On
the other hand, I do like proving theorems, which means I am interested
in type theory; if that type theory relates to programming, then that's
great! That's probably not the thing to say to ensure that my thoughts
are relevant to the software development "industry", but it's
nevertheless the truth.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
sed OO
languages are subject to similar consideration, as it turns out.
I'm unsure whether to consider explicitly stored array lengths, which
are present in most statically typed languages, to be part of a "type"
in this sense or not.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ck typing," which fits neither of
the two definitions above. We'd probably need to modify the definition
of dynamic type systems, since most source tend to classify it as a
dynamic type system. It's getting rather late, though, and I don't
intend to think about how to do that.
for simplicity's sake, clearly has
both a very well-developed static type system, and a somewhat well-
developed dynamic type system. There are dynamic "type" errors that
pass the compiler and are caught by the runtime; and there are errors
that are caught by the static typ
al reasons, but incorrect statements eventually get
corrected.
> PS. Hi Chris!
Hi! Where are you posting from these days?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Joe Marshall <[EMAIL PROTECTED]> wrote:
>
> Chris Smith wrote:
> >
> > Knowing that it'll cause a lot of strenuous objection, I'll nevertheless
> > interject my plea not to abuse the word "type" with a phrase like
> > "dynamically ty
be able to specifically identify which behaviors they
prevent, and not that there is some universal set.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
ons, I guess you could say that we do solve them with types in
the LISP sense).
> Your problem doesn't exist. Just say "types" when you're amongst your
> own folks, and "static types" when you're amongst a broader audience,
> and everything's fine.
I think I've explained why that's not the case. I don't have a
complaint about anyone speaking of types. It's the confusion from
pretending that the two definitions are comparable that I'm pointing
out.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
of solutions. Languages that solve
problems in ways that don't assign types to variables are not typed
languages, even if those same problems may have been originally solved
by type systems.
> Untyped and type-free mean something else: they mean no type checking
> is done.
H
on in a
few places. The compiler may not need the information, but for
precisely the reason that the information is redundant, the compiler is
then able to check the consistency of the programmer in applying the
type. I won't get into precisely how useful this is, but it is
nevertheless present as an advantage to outweigh the wordiness.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Diez B. Roggisch wrote:
> Paolo Pantaleo wrote:
>
>
>>I am working on this:
>>
>>I have a text file, containig certain section in the form
>>> python code here
>>py?>
>>
>>I parse the text file and substitute the python code with its result
>>[redirecting sys.stdin to a StringIO]. It something
> "Stelios" == Stelios Xanthakis <[EMAIL PROTECTED]> writes:
Stelios> It had to happen :) http://pyvm32.infogami.com/EPL
Stelios> Seriously, this is not so much about the whitespace as
Stelios> for the new features, which might interest people who are
Stelios> thinking about n
http://it.slashdot.org/article.pl?sid=05/08/01/0150222
Customer: Well, then, have you got any Venezuelan Beaver Cheese?
Owner: Sir, this is a self-respecting establishment. I shall thank you
not to imply we should traffic in VB, much less, even mention the foul
product.
Props,
Chris
--
http://ma
> "Rene" == Rene Pijlman <[EMAIL PROTECTED]> writes:
Rene> [EMAIL PROTECTED]:
>> how can i copy text to the linux clipboard?
Rene> Linux is an operating system. It doesn't have a
Rene> clipboard. The clipboard is provided by desktop frameworks,
Rene> such as KDE or Gnome.
> "Rich" == Rich <[EMAIL PROTECTED]> writes:
Rich> Hi,
Rich> (this is a probably a bit OT here, but comp.lang seems
Rich> rather desolated, so I'm not sure I would get an answer
Rich> there. And right now I'm in the middle of learning Python
Rich> anyway so...)
Rich>
> "Sriram" == Sriram Krishnan <[EMAIL PROTECTED]> writes:
>> Mladen Adamovic wrote:
>> Hi! I wonder which editor or IDE you can recommend me for
>> writing Python programs. I tried with jEdit but it isn't
>> perfect.
>>
Check out http://wiki.python.org/moin/PythonEditors
> "mik3" == mik3 <[EMAIL PROTECTED]> writes:
mik3> hi this is a question regarding installing Activestate
mik3> python whenever i try to install the latest Activestate
mik3> Python on WinXP SP2, it gives me error saying "The wizard
mik3> was interrupted before Activestate 2.4.
> "Frank" == Frank Millman <[EMAIL PROTECTED]> writes:
Frank> SELECT @@IDENTITY returns the most recent of all
Frank> inserts. If you have a complex transaction which triggers
Frank> inserts into other tables, it may not return the one you
Frank> want.
Frank> This one allo
One thing that made little sense to me when I was first working on
this is the following variation on the original script:
#--begin test script--
import logging
forest = ["root","trunk","branch","leaf"]
lumber_jack = {forest[0] : logging.DEBUG
,forest[1] : logging.INFO
> "J" == J D Leach <[EMAIL PROTECTED]> writes:
J> OK, I'm stupid. I have been unable to discern (even Googled) a
J> way to set the PYTHONDOCS variable to point to where the HTML
J> files are. What to do? I need to know the process and where
J> theses variables are stored. -- J
>>>>> "Diez" == Diez B Roggisch <[EMAIL PROTECTED]> writes:
Diez> Chris Smith schrieb:
>> Hola, pythonisas: The documentation for the logging module is
>> good, but a bit obscure. In particular, there seems to be a
>> lot of
Hola, pythonisas:
The documentation for the logging module is good, but a bit obscure.
In particular, there seems to be a lot of action at a distance.
The fact that getLogger() can actually be a call to Logger.__init__(),
which is mentioned in para 6.29.1, also bears stressing on 6.29. I
grasp
> "John" == John J Lee <[EMAIL PROTECTED]> writes:
John> Guido may or may not realise it, but he seems to have been
John> managing people (in some sense of 'managing', anyway) quite
John> successfully over the past decade or so.
John> John
Just you shush!
If he hears you, he
Hi,
I've been working on some multi-dimensional lists and I've encountered some
very strange behaviour in what appears to be simple code, I'm using python
2.4.2 and IDLE. If anyone can tell me why it's behaving so strange please
let me know, any improvements to my general coding style are also
ap
> "bonono" == bonono <[EMAIL PROTECTED]> writes:
bonono> What I don't quite understand is, if it is "obvious",
bonono> whether there is a Zen, people would still code it that
bonono> way(unless of course they want to hide it from others or
bonono> make it difficult to understa
> "Gary" == Gary Herron <[EMAIL PROTECTED]> writes:
Gary> Erik Max Francis wrote:
>> Pierre Barbier de Reuille wrote: > > >
>>When you need some symbols in your program, what do you use in
>> Python ?
>>>
>>> For example, an object get a state. This state is more
>>> r
> "Sumit" == Sumit <[EMAIL PROTECTED]> writes:
Sumit> I have scinario like I have to Create resource(in
Sumit> __init__()) Before Running a set of testcases and then In
Sumit> Testcases resources are going to used and then It will
Sumit> cleared off after Running the testcases
> "Gordon" == Gordon Airporte <[EMAIL PROTECTED]> writes:
Gordon> I'm wondering if this is might be bad practice. Sometimes
Gordon> when I need to pass around several pieces of datum I will
Gordon> put them in a tuple, then when I need to use them in a
Gordon> receiving functio
> "Robert" == Robert Hicks <[EMAIL PROTECTED]> writes:
Robert> I need to pull data out of Oracle and stuff it into an
Robert> Excel spreadsheet. What modules have you used to interface
Robert> with Excel and would you recommend it?
Robert> Robert
For simple enough tasks, I th
1 - 100 of 123 matches
Mail list logo
