Rikard Bosnjakovic wrote:
> Steven Bethard wrote:
>
> > [1]http://www.python.org/dev/summary/2005-09-01_2005-09-15.html#string-formatting-in-python-3-0
>
> Reading this link, I find this:
>
> "Currently, using % for string formatting has a number of inconvenient
> consequences:
>
> * preceden
Bengt Richter wrote:
> On 29 Nov 2005 14:08:12 -0800, [EMAIL PROTECTED] wrote:
>
> >We don't scrape programs from news-groups, if you'd like the program to
> >be shown on the shootout then please attach the source code to a
> >tracker item.
> You asked for something, got a response, and then you h
Bengt Richter wrote:
> >Interestingly, I find this response quite compatible with the
> >personality of this group.
> Which "this"? ;-)
>
I meant his response.
--
http://mail.python.org/mailman/listinfo/python-list
Mike Meyer wrote:
> The thing is, the need for an extra attribute doesn't come from your
> class, it comes from the client of your class. You can't know if the
> client code will need that facility or not, so the only choice you
> know won't be wrong sometime is to always add the mixin. In which
>
Paul Rubin wrote:
> Look at the list.count() example at the start of this thread.
> Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat
> Python by an order of magnitude. A suitably factored implementation
> might handle lists and strings with the exact same code and not incur
> an
viewcharts wrote:
> I am reading two text files comparing the values in one to the other,
> this requires two loops. The problem is that when the inner loop is
> finished, it never goes back into the loop. Any suggestions?
>
>
> for refSymbol in symbols.readlines():
> for lookupSymbol in myfil
Christoph Zwerschke wrote:
> [EMAIL PROTECTED] wrote:
> > Paul Rubin wrote:
> >>Look at the list.count() example at the start of this thread.
> >>Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat
> >>Python by an order of magnitude. A suitably factored implementation
> >>might ha
Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > I am puzzled, and could have read what you want wrong. Are you saying
> > you want something like this :
> >
> > a={}
> > a.something = "I want to hang my stuff here, outside the intended use
> > of dict"
>
> Exactly. For a use case, consider calli
Interesting, I found a reduce one liner(just one step further of
Raymond's) easiest to understand and match my thinking about what the
problem is about.
That once again tell me that different people think and approach the
problem differently. It is possible to talk about one "fastest" way,
but man
ex_ottoyuhr wrote:
> class TreeCommand:
> opcode = 0
> children = []
> def __init__(self, anOpcode) :
> opcode = anOpcode
>
opcode and children in this case is more like "class" variable in C++.
If you want "instance" variable, you need to do it as self.opcode,
self.children, i
Mike Meyer wrote:
> Built-in types don't have a real dictionary. They have a C struct that
> holds the various methods. The entries in the struct are called
> "slots", hence the __slots__ magic attribute. That __slots__ makes it
> impossible to add an attribute is documented as an implementation
Mike Meyer wrote:
> > If the authors go to the length of not allowing it, so be it. They
> > are afterall define it for their use and how someone else will use
> > it don't matter.
>
> I take it you never distribute your code, or otherwise expect other
> people to reuse it?
>
No, distribute when n
Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Well, in this case, would it be simple for the OP that if he wants to
> > disallow this attaching additional things, just use __slot__.
>
> That's *documented* as an implementation-dependent behavior. Using it
> to get that effect is abuse of the f
Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Well, in this case, would it be simple for the OP that if he wants to
> > disallow this attaching additional things, just use __slot__.
>
> That's *documented* as an implementation-dependent behavior. Using it
> to get that effect is abuse of the f
Mike Meyer wrote:
> And again, *what's the use case*? A number of people have asked why we
> shouldn't allow this, but none of them been able to come up with a use
> case better than "I think doing that is bad style."
>
oh, that is the usual argument anyway. It is nothing but style, most of
the ti
Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Mike Meyer wrote:
> >> [EMAIL PROTECTED] writes:
> >> > Well, in this case, would it be simple for the OP that if he wants to
> >> > disallow this attaching additional things, just use __slot__.
> >> That's *documented* as an implementation-depende
Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Quoting the frequently used term "Practicality beats purity". If I have
> > a practical problem/needs now and it solves it, why not use it ?
>
> In other words, you have a use case. Cool. Please tell us what it is -
> at least if it's better than "
Mike Meyer wrote:
> I get all that, I really do. I would phrase it as "a tuple is a set of
> attributes that happen to be named by integers." count doesn't make
> sense on the attributes of an object - so it doesn't make sense on a
> tuple. index doesn't make sense on the attributes of an object -
Niels L Ellegaard wrote:
> I just started learning python and I have been wondering. Is there a
> short pythonic way to find the element, x, of a list, mylist, that
> maximizes an expression f(x).
>
> In other words I am looking for a short version of the following:
>
> pair=[mylist[0],f(mylist[0]
Duncan Booth wrote:
> wrote:
>
> >> In other words I am looking for a short version of the following:
> >>
> >> pair=[mylist[0],f(mylist[0])]
> >> for x in mylist[1:]:
> >> if f(x) > pair[1]:
> >>pair=[x,f(x)]
> >
> > this is already very short, what else you want? May be this :
>
Alex Martelli wrote:
> <[EMAIL PROTECTED]> wrote:
>...
> > thanks. I don't know what max can or cannot compare.
>
> Just the same things that you can compare with, say, < .
>
> I believe in 2.5 max and min will also accept a key= argument (like
> sorted etc) to tweak what to compare, so max(th
Mike Meyer wrote:
> That's not a use case, that's a debugging aid. The same logic applies
> to adding type declarations, private/public/etc. declerations, and
> similar B&D language features. It's generally considered that it's not
> a good enough reason for adding those, so it doesn't really cons
Mike Meyer wrote:
> > By design, this is a "don't use" feature so it would be very hard to
> > find a "use case" ;-)
>
> But I can think of use cases for instances with no mutable attributes,
> which is another "don't use" case. If I can do that, those proposing
> that instances ought to be immuta
Bengt Richter wrote:
> >>
> >> Because the empty list expression '[]' is evaluated when the
> >> expression containing it is executed.
> >
> >Again you are just stating the specific choice python has made.
> >Not why they made this choice.
> Why are you interested in the answer to this question? ;
Martin Miller wrote:
> I'd be interested in seeing the one liner using reduce you mentioned --
> how it might be done that way isn't obvious to me.
>
> Another aspect of Taschuk's solution I like and think is important is
> the fact that it is truly iterative in the sense that calling it
> returns
[EMAIL PROTECTED] wrote:
> hello,
>
> i'm wondering how people from here handle this, as i often encounter
> something like:
>
> acc = []# accumulator ;)
> for line in fileinput.input():
> if condition(line):
> if acc:#1
> doSomething(acc)#1
> acc = []
>
Bengt Richter wrote:
> It looks to me like itertools.groupby could get you close to what you want,
> e.g., (untested)
Ah, groupby. The generic string.split() equivalent. But the doc said
the input needs to be sorted.
--
http://mail.python.org/mailman/listinfo/python-list
Bengt Richter wrote:
> On 2 Dec 2005 18:34:12 -0800, [EMAIL PROTECTED] wrote:
>
> >
> >Bengt Richter wrote:
> >> It looks to me like itertools.groupby could get you close to what you want,
> >> e.g., (untested)
> >Ah, groupby. The generic string.split() equivalent. But the doc said
> >the input ne
[EMAIL PROTECTED] wrote:
> Sure, feel free to point of flaws. Just don't let that be the only way you
> contribute. Over time the value of your criticism (valid or not) will be
> discounted.
>
That is quite interesting, if it is true.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> > and, as you just found out, a rather restrictive one
> > at that.
>
> In part because Python's designers failed to make "print" a function
> or provide an if-then-else expression.
>
Why would one need print in lambda ? I like ternary operator(and there
is ugly work ar
Paul Rubin wrote:
> > Why use temporary variables when all you have to do is make your
> > expressions three lines long to avoid "polluting the namespace"?
>
> Indeed. I'd much rather say
>
> x = a + b + (c * d) + e
>
> than
>
> temp1 = a + b
> temp2 = c * d
> temp3 = temp1 + temp2
> x
ProvoWallis wrote:
> I'm still learning python so this might be a crazy question but I
> thought I would ask anyway. Can anyone tell me if it is possible to
> join two dictionaries together to create a new dictionary using the
> keys from the old dictionaries?
>
> The keys in the new dictionary wo
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> > > > and, as you just found out, a rather restrictive one
> > > > at that.
> > >
> > > In part because Python's designers failed to make "print" a function
> > > or provide an if-then-else expression.
> > >
> > Wh
Antoon Pardon wrote:
> Op 2005-12-06, [EMAIL PROTECTED] schreef <[EMAIL PROTECTED]>:
> >
> > Paul Rubin wrote:
> >> > Why use temporary variables when all you have to do is make your
> >> > expressions three lines long to avoid "polluting the namespace"?
> >>
> >> Indeed. I'd much rather say
> >>
Paul Rubin wrote:
> [EMAIL PROTECTED] writes:
> > I think there is, for python. Not that I agree with it. The language
> > doesn't prevent you from using the short one-liner style but the idioms
> > prefer the line by line(and one single op/action per line) style.
>
> Are you serious?!! You're sa
D H wrote:
> Daniel Schüle wrote:
> > Hello NG,
> >
> > I am wondering if there were proposals or previous disscussions in this
> > NG considering using 'while' in comprehension lists
> >
> > # pseudo code
> > i=2
> > lst=[i**=2 while i<1000]
> >
> > of course this could be easily rewritten into
>
Daniel Schüle wrote:
> D H wrote:
> > [EMAIL PROTECTED] wrote:
> >
> >>> You can use i**=2 for i in range(1000) instead
> >>
> >>
> >>
> >> I don't think one can use assignment in list comprehension or generator
> >> expression. The limitation is very much like lambda.
> >>
> >
> > i**2
>
> lst=[i
Duncan Booth wrote:
> Daniel Schüle wrote:
>
> > hi,
> >
> > [...]
> >
> >>># pseudo code
> >>>i=2
> >>>lst=[i**=2 while i<1000]
> >>>
> >>>of course this could be easily rewritten into
> >>>i=2
> >>>lst=[]
> >>>while i<1000:
> >>> i**=2
> >>> lst.append(i)
> >>>
> >>
> >>
> >> Neither of
Bengt Richter wrote:
> On 6 Dec 2005 07:41:45 -0800, [EMAIL PROTECTED] wrote:
> >
> >If one really wants a very messy one-liner, it is possible
> >
> >import operator
> >x=3D[2]
> >lst=3Dlist(((operator.setitem(x,0,x[0]**2),x[0])[1] for _ in
> >xrange(1000) if x[0] < 1000 or iter([]).next()))
Mike Meyer wrote:
> "ex_ottoyuhr" <[EMAIL PROTECTED]> writes:
> > I'm trying to create a function that can take arguments, say, foo and
> > bar, and modify the original copies of foo and bar as well as its local
> > versions -- the equivalent of C++ funct(&foo, &bar).
>
> C++'s '&' causes an argum
Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Mike Meyer wrote:
> >> "ex_ottoyuhr" <[EMAIL PROTECTED]> writes:
> >> > I'm trying to create a function that can take arguments, say, foo and
> >> > bar, and modify the original copies of foo and bar as well as its local
> >> > versions -- the equi
Mike Meyer wrote:
> Except "trick" is a poor word choice. Nobody is playing a trick on
> them - they just don't understand what is going on.
>
oops, never thought about the negative meaning of it, it is just meant
as "not behave as expected", what would be the word you use then ?
--
http://mail.
[EMAIL PROTECTED] wrote:
> hi
>
> I have a file which is very large eg over 200Mb , and i am going to use
> python to code a "tail"
> command to get the last few lines of the file. What is a good algorithm
> for this type of task in python for very big files?
> Initially, i thought of reading eve
Mike Meyer wrote:
> It would probably be more efficient to read blocks backwards and paste
> them together, but I'm not going to get into that.
>
That actually is a pretty good idea. just reverse the buffer and do a
split, the last line becomes the first line and so on. The logic then
would be no
Thomas Liesner wrote:
> Hi all,
>
> i am having a textfile which contains a single string with names.
> I want to split this string into its records an put them into a list.
> In "normal" cases i would do something like:
>
> > #!/usr/bin/python
> > inp = open("file")
> > data = inp.read()
> > name
Peter Otten wrote:
> Alan aka David Isaac wrote:
>
> >>> #evaluate polynomial (coefs) at x using Horner's rule
> >>> def horner(coefs,x): return reduce(lambda a1,a2: a1*x+a2,coefs)
>
> > It just cannot get simpler or more expressive.
>
> But is it correct?
>
> >>> a0, a1, a2 = 1, 2, 3
> >>> x = 2
Shane Hathaway wrote:
> Mike Meyer wrote:
> > Shane Hathaway <[EMAIL PROTECTED]> writes:
> >>I'd like a way to import modules at the point where I need the
> >>functionality, rather than remember to import ahead of time. This
> >>might eliminate a step in my coding process. Currently, my process
Zeljko Vrba wrote:
> >
> > I'm sorry you find the indentation unnatural and inconvenient, but you
> > may have to accept that for this feature you are actually in a minority.
> >
> I have no problem accepting that I'm in a minority. I have a problem with
> offensive people using my example argumen
Steven D'Aprano wrote:
> Python works well with test-driven development. Test-driven development
> will pick up this sort of error, and many other errors too, with less
> effort and more certainty than compile-time checking. The problem with
> static typed languages is that they make the programme
Steven D'Aprano wrote:
> > And I don't think Haskell make the programmer do a lot of work(just
> > because of its static type checking at compile time).
>
> I could be wrong, but I think Haskell is *strongly* typed (just like
> Python), not *statically* typed. At least the "What Is Haskell?" page
Ernst Noch wrote:
> Matthias Kaeppler wrote:
> > Brian Beck wrote:
> >
> >> def foo(self):
> >> raise NotImplementedError("Subclasses must implement foo")
> >
> >
> > That's actually a good idea, though not as nice as a check at
> > "compile-time" (jesus, I'm probably talking in C++ speech aga
Steven D'Aprano wrote:
> On Sun, 11 Dec 2005 07:10:27 -0800, bonono wrote:
>
> >
> > Steven D'Aprano wrote:
> >> > And I don't think Haskell make the programmer do a lot of work(just
> >> > because of its static type checking at compile
shawn a wrote:
> I havet these 2 files in the same dir. This is code im writing to learn
> pythong
> mkoneurl.py:
> #! /usr/bin/env python
>
> import make_ou_class
>
> run = make_ou_class.makeoneurl()
>
>
> make_ou_class.py:
>
> class makeoneurl:
> def
Steven Bethard wrote:
> Paul Rubin wrote:
> > Chris Mellon <[EMAIL PROTECTED]> writes:
> >
> >>As someone who does a tremendous amount of event-driven GUI
> >>programming, I'd like to take a moment to speak out against people
> >>using us as a testament to the virtues of lamda. Event handlers are
Paul Rubin wrote:
> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> > a temporary factory function should be sufficient:
> >
> > def digit(label, x, y):
> > def callback():
> > # print "BUTTON PRESS", label # debug!
> > user_pressed(int(label))
> > Button(
[EMAIL PROTECTED] wrote:
> That does make sense. So there is no way to modify a variable in an
> outer lexical scope? Is the use of a mutable data type the only way?
>
> I'm trying to think of a case that would create semantic ambiguity when
> being able to modify a variable reference in an outer
[EMAIL PROTECTED] wrote:
> Thanks for the example code. Definately provided a few different ways
> of doing the construction.
>
> Actually, the status variable was the only thing that mattered for the
> inner function. The first code post had a bug b/c I was first just
> trying to use reduce. How
Antoon Pardon wrote:
> Suppose I have a list with 10 000 elements and I want
> the sum of the first 100, the sum of the second 100 ...
>
> One way to do that would be:
>
> for i in xrange(0,1,100):
> sum(itertools.islice(lst, i, i+100))
>
> But itertools.islice would each time start from the
Tom Anderson wrote:
> While we're on the subject of Haskell - if you think python's
> syntactically significant whitespace is icky, have a look at Haskell's
> 'layout' - i almost wet myself in terror when i saw that!
>
Though one doesn't need to use indentation and write everything using
{} in Has
Fredrik Lundh wrote:
> Pierre Quentel wrote:
>
> > In some program I was testing if a variable was a boolean, with this
> > test : if v in [True,False]
> >
> > My script didn't work in some cases and I eventually found that for v =
> > 0 the test returned True
> >
> > So I changed my test for the
Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > > but seriously, unless you're writing an introspection tool, testing for
> > > bool is pretty silly. just use "if v" or "if not v", and leave the rest
> > > to
> > > Python.
> > >
> > The OP's code(and his work around) doesn't look like he i
Antoon Pardon wrote:
> Op 2005-12-12, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> > Pierre Quentel wrote:
> >
> >> In some program I was testing if a variable was a boolean, with this
> >> test : if v in [True,False]
> >>
> >> My script didn't work in some cases and I eventually found that for v
Erik Max Francis wrote:
> Paul Rubin wrote:
>
> > Steve Holden <[EMAIL PROTECTED]> writes:
> >> The really interesting question your post raises, though, is "Why do
> >> you feel it's necessary to test to see whether a variable is a
> >> Boolean?".
> >
> > What's the point of having Booleans, if y
Erik Max Francis wrote:
> [EMAIL PROTECTED] wrote:
>
> > True, but if that is the only reason, Two built-in value of
> > True/False(0/1) serves the need which is what is now(well sort of). Why
> > have seperate types and distinguish them ?
>
> Because of this:
>
> x = True
> y = 1 # bu
Erik Max Francis wrote:
> [EMAIL PROTECTED] wrote:
>
> > True too, and could be the reason(or similar too) why the OP wants to
> > test the type rather than the logical value of it.
>
> The type is for the self-documentation purposes. The value is the same;
> so no, that's not a good reason eithe
Fredrik Lundh wrote:
> Duncan Booth wrote:
>
> > Another reason to have a boolean type is of course to provide a cast:
> >
> >def isNameSet(self):
> > return boolean(self.name)
> >
> > instead of:
> >
> >def isNameSet(self):
> >if self.name:
> > return True
> >
Chris Mellon wrote:
> Granted, of course, it's your code. But I wouldn't accept it in
> anything I was in charge of.
>
That says it all. It is his code, whether you would accept it means
nothing. If you can point out that it is functionally wrong, it may
mean something. Otherise, it is nothing mor
Magnus Lycka wrote:
> The static typing means that you either have to make several
> implementations of many algorithms, or you need to work with
> those convoluted templates that were added to the language as
> an afterthought.
I don't see this in Haskell.
> While feature-by-feature comparisions
Grant Edwards wrote:
> > He seems to be testing "boolean type", not whether it is true
> > or false.
>
> Right. But that's almost always pointless. Knowing whether a
> variable is a boolean or not is very rarely useful. What one
> wants to know is whether a varible is true or not. The code for
I like TurboGears best(haven't used any of those you mentioned, just a
brief browse and don't like any of them) and it has a very helpful
community.
[EMAIL PROTECTED] wrote:
> I'm interested in knowing which Python web framework is most like Ruby
> on Rails.
>
> I've heard of Subway and Django.
>
Steve Holden wrote:
> >>It would be somewhat more self-documenting, but why not just use one
> >>name to indicate the state and another, only meaningful in certain
> >>states, to indicate the callback?
> >
> >
> > Why should I do that? Checking the type of a variable is conceptually
> > no differe
Magnus Lycka wrote:
> I don't really know Haskell, so I can't really compare it
> to Python. A smarter compiler can certainly infer types from
> the code and assemble several implementations of an
> algorithm, but unless I'm confused, this makes it difficult
> to do the kind of dynamic linking / l
Magnus Lycka wrote:
> [EMAIL PROTECTED] wrote:
> > Magnus Lycka wrote:
> >
> >>I don't really know Haskell, so I can't really compare it
> >>to Python. A smarter compiler can certainly infer types from
> >>the code and assemble several implementations of an
> >>algorithm, but unless I'm confused,
Magnus Lycka wrote:
> Assume that you didn't use Python, but rather something with
> static typing. How could you make a module such as my_module.py,
> which is capable of working with any type that supports some
> standard copy functionality and the +-operator?
The following is a very short Hask
Mike Meyer wrote:
> [EMAIL PROTECTED] writes:
> > Steve Holden wrote:
> >> >>It would be somewhat more self-documenting, but why not just use one
> >> >>name to indicate the state and another, only meaningful in certain
> >> >>states, to indicate the callback?
> >> > Why should I do that? Checking
Andy Leszczynski wrote:
> How can do elegantly in Python:
>
> if condition:
> a=1
> else:
> a=2
>
> like in C:
>
> a=condition?1:2
a=(condition and [1] or [2])[0]
For this simple snippet, I don't think it is better than if/else, But
you can use it in map/reduce or list comprehension/gene
Donn Cave wrote:
> Really, this kind of abstraction of data types is not only well
> supported in Haskell, it can be almost a curse, at least for
> someone like myself who has fairly superficial experience with
> this kind of programming. After all the functions have been
> zealously scrubbed cle
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Christopher Subich wrote:
>
> > Chris Mellon wrote:
> >> functions with real names is crucial to maintainable code. The only
> >> reason to ever use a lamdba in Python is because you don't want to
> >> give a function a name, and that is ju
Tuvas wrote:
> I don't know if I can help with this much, I'm still somewhat new to
> python, but it is my understanding that "simple" variable, ei, strings,
> ints, etc, although they don't have such names, behave like variables,
> ei, if you pass them to a function, the function will copy them i
Daniel Crespo wrote:
> Hi, I tried:
>
> import ctypes
> import socket
> import struct
>
> def get_macaddress(host):
> """ Returns the MAC address of a network host, requires >= WIN2K.
> """
>
> # Check for api availability
> try:
> SendARP = ctypes.windll.Iphlpapi.SendARP
>
Alex Martelli wrote:
> <[EMAIL PROTECTED]> wrote:
>
> > > those convoluted templates that were added to the language as
> > > an afterthought.
> > I don't see this in Haskell.
>
> Well, historically templates HAVE been added to Haskell "as an
> afterthought" (well after the rest of the language wa
Alex Martelli wrote:
> <[EMAIL PROTECTED]> wrote:
>
> > Alex Martelli wrote:
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > > > those convoluted templates that were added to the language as
> > > > > an afterthought.
> > > > I don't see this in Haskell.
> > >
> > > Well, historically templates HAVE
Frank Millman wrote:
> [EMAIL PROTECTED] wrote:
> > Sorry that I can't help you in any way but have a question myself. Is
> > there an OS independent way to get this thing(regardless of how to
> > format it) in Python ? I know this may not matter if all you want is
> > Windows but there is just a
Antoon Pardon wrote:
> Op 2005-12-14, Grant Edwards schreef <[EMAIL PROTECTED]>:
> > On 2005-12-14, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> >
> > Well, as you might argue, I'm not tryng to effect a change in
> > your behaviour, I'm simply trying to point out how it could be
> > made
Steve Holden wrote:
> Why should you want to associate a MAC address with a socket? Each
> interface has an IP address, and it's that you should be using.
Say for example I want to find out the MAC if a particular interface in
python.
> It may well be possible to write Python code that will run o
Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
> > Steve Holden wrote:
> >
> >>Why should you want to associate a MAC address with a socket? Each
> >>interface has an IP address, and it's that you should be using.
> >
> > Say for example I want to find out the MAC if a particular interface in
> >
Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
> > Steve Holden wrote:
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>>Steve Holden wrote:
> >>>
> >>>
> Why should you want to associate a MAC address with a socket? Each
> interface has an IP address, and it's that you should be using.
> >>>
> >
Steve Holden wrote:
> Nope, but I can make inferences, whose correctness you can choose to lie
> or tell the truth about. I was merely trying to make the point that your
> response failed to further anybody's understanding of anything. I'm not
> really bothered *why* you do what you do.
That is ni
Steve Holden wrote:
> I'm probably just not reading your responses carefully enough.
That is fine, misunderstanding happens all the time. And why I am
curious that there is no such thing in Python, it is because of this :
http://search.cpan.org/~lds/IO-Interface-0.98/Interface.pm
I am learning p
Steve Holden wrote:
> Mondal wrote:
> > Hi,
> >
> > Thanks to Peter, now I know how to control an *existing* Windows
> > service and how to run a *python script* as a Windows service. Although
> > these were really useful, my point was different.
> >
> > I have developed a script that monitors a s
[EMAIL PROTECTED] wrote:
> Tolga wrote:
> > As far as I know, Perl is known as "there are many ways to do
> > something" and Python is known as "there is only one way". Could you
> > please explain this? How is this possible and is it *really* a good
> > concept?
>
> if you 'import this', you get
Chris Mellon wrote:
> On 15 Dec 2005 04:32:39 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > [EMAIL PROTECTED] wrote:
> > > Tolga wrote:
> > > > As far as I know, Perl is known as "there are many ways to do
> > > > something" and Python is known as "there is only one way". Could you
>
Chris Mellon wrote:
>You seem very, very interested in portraying anyone who
> wants to encourage good style and readability as a language Nazi. I
> don't appreciate that. You'll notice that I haven't taken the easy way
> out and told you to go away and play with Perl, right?
Noop. My stand is tha
Steve Holden wrote:
> This would have the unfortunate side effect of only allowing changes to
> Python that allowed users to do things which are currently impossible.
>
> Since Python is Turing-complete, this would effectively inhibit all
> further changes to the language.
I don't quote understand
Terry Hancock wrote:
> But that is precisely what it does mean -- Python's language
> design tries to be "reasonably minimal": there's usually one
> fairly easy way to do a task. Unintentionally, there may
> well be a half-dozen really hard ways to do it. The point of
> telling this to the potenti
Grant Edwards wrote:
> On 2005-12-15, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Why should you want to associate a MAC address with a socket? Each
> interface has an IP address, and it's that you should be using.
> >>>
> >>> Say for example I want to find out the MAC if a particular
Grant Edwards wrote:
> > you can read my temper from what I write ?
>
> If not, then you should be more careful what you write.
>
such as ?
--
http://mail.python.org/mailman/listinfo/python-list
Steve Holden wrote:
> This would have the unfortunate side effect of only allowing changes to
> Python that allowed users to do things which are currently impossible.
>
> Since Python is Turing-complete, this would effectively inhibit all
> further changes to the language.
I don't quote understand
Steve Holden wrote:
> It says that Python is already adequately expressive to allow it to
> solve all solvable problems: more briefly, "Python can already do
> everything". Hence there is no need to change the language.
>
> Of course I use this as a /reductio ad absurdum/ to try to show you the
>
Carl J. Van Arsdall wrote:
> Although, obvious to whom is a good question. If you don't know the
> language very little will be obvious to you, however one who is familiar
> with python (rtfm) would know which cases should obviously use "while"
> and which cases should obviously use "for"
>
So fa
1 - 100 of 212 matches
Mail list logo
