hitespace
while looking for matches of collapsable space (a '>' followed by a '<').
When found, the parse action is triggered, which in this case, replaces
whatever was matched with the string "><". Finally, the input data (in this
case your HTML table, stor
files, then this
goes up to, um, .7 sec vs 3 msec.
There is no question, regexp's beat the pants off of pyparsing in raw
performance. But this newsgroup has visited the raw performance issue many
times in the past, usually when responding to the "Python can't be very
fast, it'
Nico Grubert <[EMAIL PROTECTED]> writes:
> while 'transfer.lock' in os.listdir( WINDOWS_SHARE ):
> print "Busy, please wait..."
> time.sleep(10)
>
> f = open(WINDOWS_SHARE + '/myfile', 'w')
But there's a race condition, and don't you have to make your own lock
before writing myfile, so
owser module sits comfortably in the standard
library, failing to address general file-opening issues directly and
doing the wrong thing under various modern desktop environments, I
advocate people submitting suggestions, criticism and amendments to the
uploaded attachment until we hav
ftp to access
files, pySerial/t616hack to access messages), but provided your Python
distribution is set up correctly, you should be able to work at the
lowest levels too.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Peter Hansen <[EMAIL PROTECTED]> writes:
> If you focus on IDEs, your research will have pre-selected only
> certain kinds of programmers and teams, and will not necessarily
> include the best ones.
It wouldn't have occurred to me to say that Ken Iverson (APL), Peter
Deutsch (PARC Smalltalk), or D
changing them to python. (I feel perl regex combination is very easy to
> learn and very powerfull)
>
> Any information will be appreciated.
>
> -jiro
>
Here's some sample code that might give you some ideas.
-- Paul
data = """\
GRID 1
ervices. There might
be something similar available for Windows, even if it means going
through a COM-based API.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
hi all,
I noticed that setUp() and tearDown() is run before and after *earch*
test* method in my TestCase subclasses. I'd like to run them *once* for
each TestCase subclass. How do I do that.
thanks
paul
--
http://mail.python.org/mailman/listinfo/python-list
pending time sifting through flame wars amidst large
volumes of relatively uninteresting/irrelevant messages.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Diez B. Roggisch wrote:
> paul kölle wrote:
>
>>hi all,
>>
>>I noticed that setUp() and tearDown() is run before and after *earch*
>>test* method in my TestCase subclasses. I'd like to run them *once* for
>>each TestCase subclass. How do I do that.
>
&
#x27;d surely be
a great experience to be one of many in a community fielding questions
about it in public.
That said, choosing the right forum can give better results: how many
Zope-specific posts do you see on comp.lang.python these days?
Paul
--
http://mail.python.org/mailman/listinfo/python-list
"Roger" <[EMAIL PROTECTED]> writes:
> 1. Fetch phone number from my ASCII data.
> 2. Dial (always a local number) phone (through USRobotics 56K? ).
> 3. Ask @3 questions to called phone number. Y/N Y/N Y/N
> 4. Save answers to ASCII file.
> 5. Say 'Thanks', hang up.
> Repeat till eo
I'm opposed to pretty much every proposal of this sort. If you want
to propose adding a feature to the language, add it in a way that the
compiler can know about it and notice when it's not used correctly.
Mere conventions that are not checked by the compiler are just more
stuff for people to reme
Neil Hodgson <[EMAIL PROTECTED]> writes:
> The PEP system allows for the documentation of a convention as an
> "Informational PEP". Documenting conventions is useful.
Where there are conventions, they should be documented. I'm in favor
of fewer conventions. If the preferred method of doing s
Tony Meyer <[EMAIL PROTECTED]> writes:
> Does this mean that you think that PEP 8 (Python Code Style Guide)
> should be enforced by the compiler? So that (e.g) lines that are too
> long just don't compile?
I'd be ok with compiler warning messages from lines that are too long.
I think it's appropr
[EMAIL PROTECTED] (Bengt Richter) writes:
> 2) In general, I think it might be good to meet Paul Rubin half way
> re convention vs syntax, but I don't think code tagging should be
> part of the language syntax per se. (-*- cookies -*- really are
> defacto source syntax that snu
"x""") can be used to block out huge sections of code during
testing, where you'd have to put a # in front of every line otherwise.
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
--
http://mail.python.org/mailman/listinfo/python-list
Traceback (most recent call last):
File "", line 20, in ?
File "c:\Python24\lib\encodings\zlib_codec.py", line 43, in zlib_decode
output = zlib.decompress(input)
zlib.error: Error -5 while decompressing data
The -5 error appears to be a Z_BUF_ERROR from looking at the manual at
http://www.zlib.ne
Terry Hancock <[EMAIL PROTECTED]> writes:
> But that's precisely why it would be valuable to have a PEP -- a
> central catalog of such conventions makes it possible for checking
> software to be consistent. If PyChecker were going to check for such
> things, it would do so only because a standard
Larry Bates <[EMAIL PROTECTED]> writes:
> Several apps using 4Mb each shouldn't be very much memory (maybe
> 20Mb at most). You didn't say how much memory was in your machine,
> but 256Mb of memory will cost you no more than $50. Not really
> worth a lot of effort.
That is bogus reasoning. I ca
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> > That is bogus reasoning.
>
> not if you're a professional software developer and someone's paying you
> to develop an application that is to be run on a platform that they control.
An awful lot of Python targeted users are not in that situation, so
"MrJean1" <[EMAIL PROTECTED]> writes:
> Ocha O + 54 - o otro
> Nena N + 57 -nk nekto
> MInga MI+ 60 -mk mikto
> Luma L + 63 - l lunto
Please tell me you're making this up.
--
http://mail.python.org/mailman/listinfo/pyt
Tony Meyer <[EMAIL PROTECTED]> writes:
> I'm not sure why I haven't seen this mentioned yet, but a leading
> double-underscore does really make a member private:...
> As you see, it's there in the dict, but it's obfuscated - but that's
> all that other languages do anyway.
No, that's false: in lan
Simon Brunning <[EMAIL PROTECTED]> writes:
> I thought about it, but I didn't mention it in the end because this
> feature ("name mangling") isn't intended as a mechanism for making
> things private - it's intended to prevent namespace clashes when doing
> multiple inheritance. It can be used to ma
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Do you know any language that has real private and protected attributes?
Java?
--
http://mail.python.org/mailman/listinfo/python-list
Simon Brunning <[EMAIL PROTECTED]> writes:
> Oh, there are ways around private and protected, even in Java. CGLIB
> spings to mind. But you'd be wise to follow the rules, especially if
> you work in a team.
I don't see anything on the CGLIB web page (in about 1 minute of
looking) that says it can
ords, expect many more threads about global interpreter locks
in the coming three years than we've seen in the last three or even six
years. ;-)
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Chris Gonnerman <[EMAIL PROTECTED]> writes:
> -- Make it easy to do right.
>
> What you are promoting is the first philosophy: Tie the programmer's
> hands so he can't do wrong. Python for the most part follows the
> second philosophy, making writing good code so easy that the coder
> is rarely t
t;maximum of 5 seconds"! Unfortunately, I only have a
passing familiarity with SMS-related messaging, but I imagine you'd
have to switch on any and all quality-of-service features to get that
kind of guarantee (if it's even possible).
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Gregor Horvath <[EMAIL PROTECTED]> writes:
> > to be able to share private variables with other classes under certain
> > circumstances, it's better to use something like C++'s "friend"
> > declaration, where you can export the variables to a specific other class.
>
> That assumes that you always
Mike Meyer <[EMAIL PROTECTED]> writes:
> Note that the quoted article only applies to *writing* attributes. It
> doesn't say anything about needing accessors to *read* a
> variable. This encourages me that the convention I use - adopted from
> Eiffel, where the compiler enforces it - of freeling re
Gregor Horvath <[EMAIL PROTECTED]> writes:
> If its your code this is possible, but if not and the maintainer is
> not willing or able to change it, then you have a problem.
Perhaps the maintainer has good reason for not wanting to change it.
After all, he's maintaining the code and you're not. I
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> No, but that is precisely why Python's semi-private variables are
> usually better. Names like _X and class.__X are warnings to the developer
> "use these at your own risk", without preventing developers who need them
> from using them. You have most of
Mike Meyer <[EMAIL PROTECTED]> writes:
> > Generally that sounds reasonable. Obviously there are other examples
> > when (e.g. for security) you have to make sure that variables can't be
> > read by other classes, e.g. you have a class that stores a capability
> > (or a password) in an instance va
Gregor Horvath <[EMAIL PROTECTED]> writes:
> No, but the assumption here is that the maintainer / designer of a
> class alaways knows everything and things are static. Unfortunatly
> this is wrong in real live.
I'd say it's pretty far removed from how multi-person software
projects actually work.
Gregor Horvath <[EMAIL PROTECTED]> writes:
> One reason is that it does not restrict the programer to tight und has
> genuine simple solutions, like the one with "private" instance
> variables.
If you don't want the compiler to make sure your private instance
variables stay private, then don't dec
"yoda" <[EMAIL PROTECTED]> writes:
> Currently, the content is generated and a number of SMS per user are
> generated. I'll have to measure this more accurately but a cursory
> glance indicated that we're generting approximately 1000 sms per
> second. (I'm sure this can't be right.. the parser\gene
Dennis Lee Bieber <[EMAIL PROTECTED]> writes:
> Ah, but in the way of your code -- it is not "your car"... It is the
> car you supplied to someone "hundreds of miles away"... And they are
> perfectly free to open the hood... tamper with the engine programming, etc.
I don't understand what yo
Gregor Horvath <[EMAIL PROTECTED]> writes:
> > If you don't want the compiler to make sure your private instance
> > variables stay private, then don't declare them that way. You're the
> > one asking for less flexibility.
>
> I want to declare them as private, but want to give the flexibilty to
Gregor Horvath <[EMAIL PROTECTED]> writes:
> Everything is said on this topic. There are two ligitimate solutions
> to the problem of private instance variables. Its a matter of taste,
> and mine is the pythonic one.
The Pythonic solution is to have both solutions available, and Python
in fact use
Peter Corbett <[EMAIL PROTECTED]> writes:
> http://www.pick.ucam.org/~ptc24/yvfc.html
>
Madness! I love it.
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> If changing the way a class uses its own private variables breaks an
> application
> because another class was using the private variable unexpectedly,
> then that's bad, regardless of whether the other class's author was
> notified or not. It
cess documentation
That's what I feel as well. I hadn't commented on the PEP as I had
simply intended to ignore it totally in my own projects...
Paul.
--
http://mail.python.org/mailman/listinfo/python-list
"ncf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I don't mean this harshly, but have you tried recompressing the data to
> see if you may have had a bad data set?
>
> If it still fails, then I'm really not sure why/how zlib decides that
> there isn't enough room in the output buf
Bill Mill <[EMAIL PROTECTED]> writes:
> Python is for consenting adults.
Python might be for consenting adults, but multi-person software
projects are supposed to be done in the workplace, not the bedroom.
So there are still some software constructs that are simply beyond the
bounds of propriety,
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> from yourcode import Secret
>
> class Secret(Secret):
> def gethidden(self):
> return self.__hidden
Heh, interesting, and it occurs to me that you could do that by
accident (A inherits from B, and then something imports B and makes an
inhe
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> > Looks like you must know every one of the base classes of the NotSoSecret,
> > whether there is some base class named Secret? And, if so, you must also
> > know these classes _implementation_
>
> that information isn't hidden, so there's nothing "you
Gregor Horvath <[EMAIL PROTECTED]> writes:
> Are the numerous working python open source projects not multi-person
> software projects? Even multiple persons that even dont know each
> other and can discuss the latest news at the coffee machine?
There are not that many such projects being done in
Gregor Horvath <[EMAIL PROTECTED]> writes:
> Real open source live example from yesterdays mailinglists:
I don't see any use of name mangling in that example.
--
http://mail.python.org/mailman/listinfo/python-list
Dennis Lee Bieber <[EMAIL PROTECTED]> writes:
> They did? Fine... Add another that Python names beginning with _ or
> __ are not to be accessed from outside the module/class that defined
> them. And if one is not the "owner" of that module/class, they should
> contact the responsible person a
Steve Holden <[EMAIL PROTECTED]> writes:
> Good grief, the ultimate choice is to use Python because you like it,
> or not to use it because you don't. Enough with the picking every
> available nit, please. Consent or stop complaining :-)
Riiight. "If she was walking in that neighborhood she must
Gregor Horvath <[EMAIL PROTECTED]> writes:
> >>Real open source live example from yesterdays mailinglists:
> > I don't see any use of name mangling in that example.
>
> Someone has a problem and tweaks a private variable as a workaround.
They should have patched the source instead.
> No python p
"zooko" <[EMAIL PROTECTED]> writes:
> I haven't benchmarked it against Evan Podromou's heap implementation
> yet, but obviously inserting and removing things from a heapq heap is
> O(N).
Good heavens, I should hope not. The whole point of heaps is that
those operations are O(log(N)).
--
http://m
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Still, [EMAIL PROTECTED]'s point that you must know the base classes
> is correct. It is *easy* to find them out (NotSoSecret.__bases__ should do
> it), but if you don't you are taking a chance that your class name doesn't
> clash with one of the bases.
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> > 2) Allow the client access to these private variables, through
> > a special construct. Maybe instead of "from ... import ..."
> > "from ... spy ...".
>
> What you are suggesting is that you have private variables that are only
> private by conventio
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> > It's not easy if the base classes change after you check your code in.
> > You shouldn't need to know about that if it happens. Modularity, remember?
>
> Yes. And if you are relying on a public method in a class, and somebody
> dynamically modifies
"Iyer, Prasad C" <[EMAIL PROTECTED]> writes:
> But I want to do something like this
>
> class BaseClass:
> def __init__(self):
> # Some code over here
> def __init__(self, a, b):
> # Some code over here
> def __init__(self, a, b, c):
> #
Richie Hindle <[EMAIL PROTECTED]> writes:
> Yes. From Guido's announcement at
> http://mail.python.org/pipermail/python-dev/2005-September/056846.html:
> > The syntax will be
> > A if C else B
Wow, I thought this was a prank at first. Congratulations to Guido.
I think the introduction of lis
Steve Holden <[EMAIL PROTECTED]> writes:
> That would make a good Onion (www.TheOnion.com) headline: "Users
> Discover Computer Security Conflicts with Desire for Convenience"
+1 QOTW
--
http://mail.python.org/mailman/listinfo/python-list
th google.no (where I get sent if I go to google.com) and
google.co.uk (where my browser's search field takes me, probably
because of some locale setting or other).
Paul
--
http://mail.python.org/mailman/listinfo/python-list
Rocco Moretti <[EMAIL PROTECTED]> writes:
> There is little in the way of technical problems that are solved by
> language level enforcement of private variables. The issues in
> question are mostly social ones, and if you're not reading and
> following the documented interface, stopping private va
Mike Meyer <[EMAIL PROTECTED]> writes:
> So, fool._bar is now clobbered. Nuts, the _bar attribute is broken for
> *every* instance of Fools. According to you, the error must be in
> Fools. Care to point it out?
Yes, the error is in the "breaker" function, which leaks the private
variable to other
Reinhold Birkenfeld <[EMAIL PROTECTED]> writes:
> For a conditional, syntax must be found, and the tradition of Python
> design is not to use punctuation for something that can be solved with
> keywords.
Yeah, "if C then A else B" is a ancient tradition stretching from
Algol-60 to OCAML, and who k
Mike Meyer <[EMAIL PROTECTED]> writes:
> Unless your compiler detects and flags passing private variables to
> external functions all you've got is a convention that you don't pass
> private variables to external functions.
Yes, the point is that it's something that you can check for by
examining
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> A cautionary tale of what happens when religious wars enter programming
> debates. For all I know, Paul Rubin is intelligent, gentle, kind to
> animals and small children, generous, charitable and modest.
Don't bet on it.
James Stroud <[EMAIL PROTECTED]> writes:
> I'm very curious about what is going on here. I'm sure my curiosity has
> something to do with ignorance of some fundamental concept of computer
> science (maybe that 8 is just a vertical infinity?):
Python doesn't have a character type. A character is
[EMAIL PROTECTED] (Bengt Richter) writes:
> I decided to read this thread today, and I still don't know exactly
> what your requirements are for "private" whatevers. No one seems to
> have discussed what you could do with properties and __getattribute__
> and metaclasses and decorators, yet there a
"bruce" <[EMAIL PROTECTED]> writes:
> if there's anyone here that i could talk with (phone) who's knowledgable
> about these areas, i'd appreciate it. i'm trying to get a much better
> understanding of the actual underlying app.
There's a #bittorrent irc channel on irc.freenode.net. Try there.
--
Mike Meyer <[EMAIL PROTECTED]> writes:
> > Yes, the point is that it's something that you can check for by
> > examining the class in question without having to examine any other
> > classes.
>
> That's a pretty restrictive convention to follow.
What convention? It just makes it possible to writ
"yoda" <[EMAIL PROTECTED]> writes:
> I realize I'm losing so much time I could spend more productively. I'd
> therefore like to know the different approaches you guys employ to
> deploy builds from your staging servers (or laptops:) to the production
> server in an automated repeatable safe manner.
Mike Meyer <[EMAIL PROTECTED]> writes:
> > What convention? It just makes it possible to write code with some
> > specific invariants if there's a need to do so.
>
> That you don't pass private variables to a function unless it's a builtin.
No, I don't see that as "convention", it's just somethi
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> The philosophy of dynamic languages like Python is that the class designer
> shouldn't be the only one who decides whether or not a particular variable
> should be private or public.
I don't see that as part of the philosophy of dynamic languages. For
Mike Meyer <[EMAIL PROTECTED]> writes:
> Actually, I think that the semantic changes required to make private
> do what you want are deep enough that the resulting language
> wouldn't be Python any longer. It has deep implications from the
> interpeter implementation all the way out to the design o
Mike Meyer <[EMAIL PROTECTED]> writes:
> >> Compile-time restrictions don't matter for squat - you need
> >> serious restrictions on what the program can do at runtime.
> >
> > You need both.
>
> Yup. Any language besides Java even *try* to provide both for a
> production environment?
Yes. Pyth
Mike Meyer <[EMAIL PROTECTED]> writes:
> I'd say CPython was missing the features that you need to guarantee
> that. Missing quite a *lot* of features, in fact. But Python has never
> been about keeping people from writing bad code - it's about helping
> people write good code.
Privilege separatio
Mike Meyer <[EMAIL PROTECTED]> writes:
> > Privilege separation is considered a good coding practice. How does
> > Python help it?
>
> With conventions and name mangling. Which are only slightly less
> effective than the C++/Java technic for doing the same thing.
That's not what privilege separa
"El Pitonero" <[EMAIL PROTECTED]> writes:
> The thing is, there are two sides to every coin. Features surely can
> be viewed as "goodies", or they can be viewed as "handcuffs".
Let's see, say I'm a bank manager, and I want to close my cash vault
at 5pm today and set its time lock so it can't be op
Paul Rubin <http://[EMAIL PROTECTED]> writes:
> def countdown():
> n = 3
> while n > 0:
>yield n
Bah, ommitted a line:
def countdown():
n = 3
while n > 0:
yield n
n -= 1
--
http://mail.python.org/mailman/listinfo/python-list
Mike Meyer <[EMAIL PROTECTED]> writes:
> > That's not what privilege separation means. It means that the
> > privileged objects stay secure even when the unprivileged part of the
> > program is completely controlled by an attacker.
>
> In which case, what's "private" got to do with this? The exam
[EMAIL PROTECTED] (Bengt Richter) writes:
> Would you want to outlaw 'None' as an attribute name?
> Python seems to be straddling the fence at this point:
> >>> c.None = 'c.None'
> SyntaxError: assignment to None
Heehee, I think that's just a compiler artifact, the lexer is treating
None as a ke
Mike Meyer <[EMAIL PROTECTED]> writes:
> > If you have a java class instance with a private member that's (say) a
> > network socket to a special port, access to the port is controlled
> > entirely by that class.
>
> Are you sure? My understanding was that Java's introspection mechanism
> could be
"leo" <[EMAIL PROTECTED]> writes:
> I come from a java background, where Exceptions are a big Avoid Me, but
> are the performance implications the same in Python?
Well, you could measure it experimentally pretty easily, but anyway,
Python exceptions are much less expensive than Java exceptions.
-
"Cigar" <[EMAIL PROTECTED]> writes:
> Now that I'm three months into the development of this program, my
> client tells me she would like to protect her investment by preventing
> her employees from doing the same to her. (Going to the competition
> and using her program.)
Exactly what is the thr
Mike Meyer <[EMAIL PROTECTED]> writes:
> I assumed the Java model was based on the C++ model because it seems
> that everything in Java is based on C++, and they share the same
> vocabulary. If I'm wrong - well, that means you considered another
> language already.
I guess it's similar that way, h
"Cigar" <[EMAIL PROTECTED]> writes:
> I may have to just put password protection in and if she hangs herself
> by 'sharing' the password with underlings she trusts (at the
> present)... again that's outside of my control of protecting her.
You could have the password automatically change once a mo
Antoon Pardon <[EMAIL PROTECTED]> writes:
> > Or you just code without declaring, intending to go
> > back and do it later, and invariably forget.
>
> What's the problem, the compilor will allert you
> to your forgetfullness and you can then correct
> them all at once.
Thiat in fact happens to m
"Cigar" <[EMAIL PROTECTED]> writes:
> I think the BIGGEST threat here is a feeling of vulnerablity. She now
> realizes that she is in a position that her competition was many years
> ago when she came into possesion of program the 'other side' was using
> and that she is now vulnerable. She wants
nd useful enhancements whose absence
would otherwise expose your applications to misuse or obsolescence.
Either path can involve a lot of hard work, but at least you get the
choice with open source software.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
criticism, though, but an
observation. Meanwhile, the temptation to add similar type annotations
to Python should be resisted, in my view, since the book certainly
isn't closed on alternative strategies for compile-time checking and
program optimisation.
Paul
[1] http://boo.codehaus.org/Type+In
Brian Quinlan <[EMAIL PROTECTED]> writes:
> Have those of you who think that the lack of required declarations in
> Python is a huge weakness given any thought to the impact that adding
> them would have on the rest of the language? I can't imagine how any
> language with required declarations coul
"Amir Michail" <[EMAIL PROTECTED]> writes:
> Is there an easy way to execute a python cgi script on a different
> machine from the cgi server?
What exactly do you mean by that? You can set a form target to
another machine, if that's what you mean.
--
http://mail.python.org/mailman/listinfo/pyth
Grant Edwards <[EMAIL PROTECTED]> writes:
> > Hmm...perhaps he is trying to do a transfer thing like many chat
> > programs do. Instead of sending large files across a server, you
> > "Direct Connect" and send the file directly. :shrugs:
>
> So how does that require binding the client end of a TCP
Grant Edwards <[EMAIL PROTECTED]> writes:
> > In the nomenclature of some of these applications, that kind
> > of transfer is called a client to client connection. Both
> > ends are called clients.
>
> IIRC, we were talking about TCP sockets.
Yes, but if the person was talking about using TCPs s
Mohammed Smadi <[EMAIL PROTECTED]> writes:
> #transmission socket
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> s.bind(("",hp_port)) # do some error checking
> ...
> any suggestions for alternative implementation?
In this parti
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Grant Edwards wrote:
> > IIRC, you just call bind() with a port number of zero, and then
> > use some method-or-other on the bound socket to find out what
> > port it's bound to.
>
> >>> s = socket.socket()
> >>> s.bind(("", 0))
> >>> s.getsockaddr()
>
marduk <[EMAIL PROTECTED]> writes:
> def myfunc(MyClass myparam):
>int spam = 6
>str eggs
>
># etc
>
> i.e. typed declarations and type checking. This would annoy the heck
> out of me.
It could be like Lisp, which has optional type declarations. If you
use the type declarations, t
"El Pitonero" <[EMAIL PROTECTED]> writes:
> If so, you would probably be the type of person that also likes static
> typing, type safety and variable declaration, right?
I certainly want type safety, which Python claims to have. I'd like
to have variable declaration, at least like "var x". Perl
Duncan Booth <[EMAIL PROTECTED]> writes:
> If you think variable declarations should be required,
I don't think they should be required. I think there should optional
declarations along with a compiler flag that checks for them if the
user asks for it, like Perl has.
> then you presumably want t
Magnus Lycka <[EMAIL PROTECTED]> writes:
> It seems you've missed the entire point of using a dynamically
> typed language. It's not just about saving typing time and making
> your methods take up fewer lines of code. It's about writing generic
> code. Just look at C++ with all that mess with compl
1001 - 1100 of 9129 matches
Mail list logo
