Re: Nice way to cast a homogeneous tuple
Steven D'Aprano wrote: > Perhaps I have been misinformed, but my understanding of C type-casts is > that (where possible), a cast like `int(var)` merely tells the compiler > to temporarily disregard the type of var and treat it as if it were an > int. In other words, it's a compiler instruction rather than a conversion > function. You are misinformed. The result of a cast in C or C++ behaves as if a temporary was created: int x = 0; unsigned(x)--; // invalid, compiler error Now, where this distinction gets blurred is when you are casting pointers: (*(unsigned*)&x)--; or, in C++, references: reinterpret_cast(x)--; Technically, these are still invalid though, only that they give you undefined behaviour at runtime instead of a compiler error, but those are already very fine details of the according standards. Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is there no platform independent way of clearing a terminal?
Neil Cerutti wrote: > Perhaps emailing the tests to yourself would be a good solution. > Every tme the tests ran, you'd get a new email containing the > results. Nice idea, only that it's even less portable and requires manual setup... ;^) Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance ordered dictionary vs normal dictionary
> > > It depends on the problem. A dictionary is a hash table. An ordered > dictionary is a binary search tree (BST). Those are different data > structures. > > The main things to note is that: > > - Access is best-case O(1) for the hash table and O(log n) for the > BST. > > - Worst case behavior is for access is O(n) for both. The pathologic > conditions are excessive collisions (hash) or an unbalanced tree > (BST). In pathologic cases they both converge towards a linked list. > > - Searches are only meaningful for == and != for a hash table, but BST > searches are also meaningful for >, <, <=, and >=. For this reason, > databases are often implemented as BSTs. > > - A BST can be more friendly to cache than a hash table, particularly > when they are large. (Remember that O(1) can be slower than O(log n). > Big-O only says how run-time scales with n.) > > Thanks, this was really insightful :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance ordered dictionary vs normal dictionary
On Jul 28, 6:47 pm, Navkirat Singh wrote: > I was wondering what would be better to do some medium > to heavy book keeping in memory - Ordered Dictionary > or a plain simple Dictionary object?? The current implementation of OrderedDict is based on regular dictionaries, so it performance cannot be better than a regular dictionary for the usual mapping operations. Some accessor methods like __getitem__(), __len__(), __contains__(), and get() are pass throughs, so their performance is the same. Most of the rest of the methods are order aware and are slower by a constant factor. So, if you don't need the ordering feature, then you're better-off with a regular dictionary. A potential future implementation for OrderedDict written in C would have nearly identical performance as regular dicts for most operations and slightly improved performance for iteration. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Nice way to cast a homogeneous tuple
On Thu, 29 Jul 2010 09:21:37 +0200, Ulrich Eckhardt wrote: > Steven D'Aprano wrote: >> Perhaps I have been misinformed, but my understanding of C type-casts >> is that (where possible), a cast like `int(var)` merely tells the >> compiler to temporarily disregard the type of var and treat it as if it >> were an int. In other words, it's a compiler instruction rather than a >> conversion function. > > You are misinformed. The result of a cast in C or C++ behaves as if a > temporary was created: Fair enough. Thank you. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: loading configuration files that are themselves python
Ben Finney wrote: Lawrence D'Oliveiro writes: In message <7j8w5tylmw@rapun.sel.cam.ac.uk>, Matthew Vernon wrote: Is there a more idiomatic way of loading in a configuration file that's python code ... Is it really a good idea to have a configuration language that’s Turing- complete? I think not. Configuration files should be read as data; they should be declarative only, not executable languages. That way, a different program can read and parse them without having to be a parser for an entire programming language. For local non distributed applications, configuration files written in python are just fine. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Robert Kern wrote: On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote: In message, Robert Kern wrote: There are also utilities for mounting ISOs directly without burning them to a physical disk. You need special utilities to do this?? On at least some versions of Windows, Yes. You need the "mount" utility with Linux. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
Steven D'Aprano wrote:
On Sun, 25 Jul 2010 13:58:00 +1200, Gregory Ewing wrote:
Lacrima wrote:
But what if SuperClass1 is from third party library?
If it hasn't been designed for super(), then you can't use super() with
it.
super() only works when *every* class in the hierarchy has been designed
with it in mind.
That incorrect. You can certainly use super() with classic classes in the
hierarchy, and super() didn't even exist when they were created.
class Parent:
... def method(self, arg):
... return repr(arg)
...
class Classic(Parent):
... def method(self, arg):
... return "argument was %s" % Parent.method(self, arg)
...
class New(object, Classic):
... def method(self, arg):
... return super(New, self).method(arg).upper()
...
x = New()
x.method('spam')
"ARGUMENT WAS 'SPAM'"
The problem isn't super(), and people who give glib advise "don't use
super()" are just compounding the problem. The problem is with multiple
inheritance where methods have different method signatures. If you don't
change the method signatures, super() will work fine.
Advising people not to use super() might make people feel virtuous, but
it doesn't do anything to help the reader write non-buggy MI hierarchies.
It pushes the effort of dealing with multiple inheritance onto them,
forcing them to re-implement the MRO, probably badly. Can you re-
implement the C3 algorithm? Have you even heard of it? If you answer No
to either of those questions, chances are high that trying to deal with
the MRO manually will lead to worse bugs than using super().
Should you use super()?
1. If you're doing multiple inheritance with metaclasses, you MUST use
super().
2. If you're using single inheritance only, and never modify method
signatures, there is no reason not to use super().
3. If you're using mixins, you should use super().
4. If you never modify method signatures, then you should use super().
5. If you do modify method signatures, you shouldn't do that (except
possibly in constructors, and even there only cautiously). But if you do
it anyway, then you should use super() *except* in the methods where you
modify the signature.
6. If you don't use super(), chances are that your class hierarchy is
still buggy, but instead of failing loudly and noisily with an exception,
it's silently giving the wrong results.
7. If you can avoid multiple inheritance in favour of another technique
(such as composition), you should strongly consider that.
I think you're missing the point that super for most of us is a
dangerous guess game. It makes implicit what would *really* need to be
explicit.
class Base1(object):
def foo(self):
print 'Base1'
class Base2(object):
def foo(self):
print 'Base1'
class Sub(Base1, Base2):
def foo(self):
# which base version to call ???
# choice A
# use super an pray that it will do what I need (better
know exactly how the MRO works)
# also pray that further readers know as much as I do
about super
# choice B
# use explicit calls so I can choose which algorithm I
want to use, calling Base1, Base2 or both of them
# If the choice is too difficult, that means one thing
=> my inheritance design is crap => rewrite it properly.
Super is known for being required for diamond inheritance, and this
reputation is well earned. Outside this scope, super's not required.
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: Performance ordered dictionary vs normal dictionary
sturlamolden writes: > On 29 Jul, 03:47, Navkirat Singh wrote: > >> I was wondering what would be better to do some medium to heavy book keeping >> in memory - Ordered Dictionary or a plain simple Dictionary object?? > > It depends on the problem. A dictionary is a hash table. An ordered > dictionary is a binary search tree (BST). The ordered dictionary shipped with Python is also a hash table, with an internal list to keep track of item order. The one thing not mentioned in the thread is that ordered dict's deletion is O(n), which might impact "heavy bookkeeping". As Raymond said, where order doesn't matter, it's best to stick with dict. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Jean-Michel Pichavant wrote: Robert Kern wrote: On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote: In message, Robert Kern wrote: There are also utilities for mounting ISOs directly without burning them to a physical disk. You need special utilities to do this?? On at least some versions of Windows, Yes. You need the "mount" utility with Linux. JM On Windows see Daemon-tools lite. free, easy, no spyware. -- http://mail.python.org/mailman/listinfo/python-list
Re: Performance ordered dictionary vs normal dictionary
On 29-Jul-2010, at 2:50 PM, Hrvoje Niksic wrote: > sturlamolden writes: > >> On 29 Jul, 03:47, Navkirat Singh wrote: >> >>> I was wondering what would be better to do some medium to heavy book >>> keeping in memory - Ordered Dictionary or a plain simple Dictionary object?? >> >> It depends on the problem. A dictionary is a hash table. An ordered >> dictionary is a binary search tree (BST). > > The ordered dictionary shipped with Python is also a hash table, with an > internal list to keep track of item order. > > The one thing not mentioned in the thread is that ordered dict's > deletion is O(n), which might impact "heavy bookkeeping". As Raymond > said, where order doesn't matter, it's best to stick with dict. > -- > http://mail.python.org/mailman/listinfo/python-list Thanks that was an excellent point : ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
Joe Goldthwaite wrote:
> import unicodedata
>
> input = file('ascii.csv', 'rb')
> output = file('unicode.csv','wb')
>
> for line in input.xreadlines():
> unicodestring = unicode(line, 'latin1')
> output.write(unicodestring.encode('utf-8')) # This second encode
> is what I was missing.
Actually, I see two problems here:
1. "ascii.csv" is not an ASCII file but a Latin-1 encoded file, so there
starts the first confusion.
2. "unicode.csv" is not a "Unicode" file, because Unicode is not a file
format. Rather, it is a UTF-8 encoded file, which is one encoding of
Unicode. This is the second confusion.
> A number of you pointed out what I was doing wrong but I couldn't
> understand it until I realized that the write operation didn't work until
> it was using a properly encoded Unicode string.
The write function wants bytes! Encoding a string in your favourite encoding
yields bytes.
> This still seems odd to me. I would have thought that the unicode
> function would return a properly encoded byte stream that could then
> simply be written to disk.
No, unicode() takes a byte stream and decodes it according to the given
encoding. You then get an internal representation of the string, a unicode
object. This representation typically resembles UCS2 or UCS4, which are
more suitable for internal manipulation than UTF-8. This object is a string
btw, so typical stuff like concatenation etc are supported. However, the
internal representation is a sequence of Unicode codepoints but not a
guaranteed sequence of bytes which is what you want in a file.
> Instead it seems like you have to re-encode the byte stream to some
> kind of escaped Ascii before it can be written back out.
As mentioned above, you have a string. For writing, that string needs to be
transformed to bytes again.
Note: You can also configure a file to read one encoding or write another.
You then get unicode objects from the input which you can feed to the
output. The important difference is that you only specify the encoding in
one place and it will probably even be more performant. I'd have to search
to find you the according library calls though, but starting point is
http://docs.python.org.
Good luck!
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
--
http://mail.python.org/mailman/listinfo/python-list
write xml to txt encoding
Hello, I have a Python app that parses XML files and then writes to text files. However, the output text file is "sometimes" encoded in some Asian language. Here is my code: encoding = "iso-8859-1" clean_sent = nltk.clean_html(sent.text) clean_sent = clean_sent.encode(encoding, "ignore"); I also tried "UTF-8" encoding, but received the same results. Any suggestions? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
measuring a function time
Hi, I want to measure a function run time. I read http://docs.python.org/library/time.html but I am confused and don't know which one is suitable. I don't know is daylight timing important or not or is Y2K issue important for my case or not I also don't know how epoch time is related to my work. I just want to do this (pseudocode): start_time = get_current_time; function(); end_time = get_current_time; print (end_time - start_time) the output should be 7600 (s) for example. What is the best and easiest way to do that? Thanks, // Naderan *Mahmood; -- http://mail.python.org/mailman/listinfo/python-list
Re: measuring a function time
This should be enough >>>import time >>>tic = time.time() >>>function() >>>toc = time.time() >>>print toc - tic On Thu, Jul 29, 2010 at 2:34 PM, Mahmood Naderan wrote: > Hi, > I want to measure a function run time. I read > http://docs.python.org/library/time.html but I am confused and don't know > which one is suitable. I don't know is daylight timing important or not > or is Y2K issue important for my case or not I also don't know how epoch > time is related to my work. > > I just want to do this (pseudocode): > start_time = get_current_time; > function(); > end_time = get_current_time; > print (end_time - start_time) > > the output should be 7600 (s) for example. What is the best and easiest way > to do that? > > Thanks, > > // Naderan *Mahmood; > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- Matteo Landi http://www.matteolandi.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: measuring a function time
On Thu, Jul 29, 2010 at 8:34 AM, Mahmood Naderan wrote: > the output should be 7600 (s) for example. What is the best and easiest way > to do that? Take a look at time.clock() http://docs.python.org/library/time.html#time.clock "this is the function to use for benchmarking Python or timing algorithms." -- http://mail.python.org/mailman/listinfo/python-list
Re: measuring a function time
On Thu, 29 Jul 2010 14:42:58 +0200, Matteo Landi wrote: > This should be enough > import time tic = time.time() function() toc = time.time() print toc - tic You're typing that in the interactive interpreter, which means the timer is counting the seconds while you're typing subsequent commands. At the very least, you need to put that code into a function. More importantly, the above technique is acceptable if function() is very long-running (multiple seconds, at least). If it is quick, or a code- snippet, the time you measure will be dominated by random chance. The best way to time small code snippets and fast functions is with the timeit module. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: write xml to txt encoding
William Johnston, 29.07.2010 14:12: I have a Python app that parses XML files and then writes to text files. XML or HTML? However, the output text file is "sometimes" encoded in some Asian language. Here is my code: encoding = "iso-8859-1" clean_sent = nltk.clean_html(sent.text) clean_sent = clean_sent.encode(encoding, "ignore"); I also tried "UTF-8" encoding, but received the same results. What result? Maybe the NLTK cannot determine the encoding of the HTML file (because the file is broken and/or doesn't correctly specify its own encoding) and thus fails to decode it? Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
On Thu, 29 Jul 2010 12:08:54 +0200, Jean-Michel Pichavant wrote: > Steven D'Aprano wrote: >> That incorrect. You can certainly use super() with classic classes in >> the hierarchy, and super() didn't even exist when they were created. >> The problem isn't super(), and people who give glib advise "don't use >> super()" are just compounding the problem. The problem is with multiple >> inheritance where methods have different method signatures. If you >> don't change the method signatures, super() will work fine. [...] > I think you're missing the point that super for most of us is a > dangerous guess game. It makes implicit what would *really* need to be > explicit. No, I'm not missing the point. I'm *disagreeing* with the point. I'm saying that for simple inheritance hierarchies, super() does no harm, and it is *required* for most complex inheritance hierarchies. Given that, why not use it? I suppose that, if you're inheriting from an existing class which doesn't use super(), there may be issues (although I'm not convinced that those issues go away if you avoid super!) but for a new class under your control, there are no negatives to super() that didn't already exist with the nature of multiple inheritance. There is, as far as I can tell, ONE use-case where super() must be avoided, and that is a use-case that is discouraged for other reasons: where you change the method signature. If you're changing the method signature, you're already in dubious territory and better know what you're doing. You're violating the Liskov Substitution Principle, and if so, you better have a good reason. (I'm a bit skeptical about the LSP, but many people much smarter than I think it's virtually gospel, so who knows?) But either way, if you change the method signature, you're going to have problems somewhere unless you've really careful. The problems with super() are merely symptoms of that change. If you don't change the method signature, then I don't believe super() does any harm, regardless of whether you have single inheritance or multiple inheritance, whether it is a diamond diagram or not. The worst that can be said about it is that super()'s signature is hard to understand. I would argue that your argument about "explicit" and "implicit" is incorrect. You shouldn't want to explicitly specify which class you are inheriting from, at least not under normal circumstances. It is enough to say that you are inheriting behaviour. If you have a Widget class, and you find yourself explicitly calling methods by *named* superclasses, you're probably doing something wrong. It should always be possible to insert a class higher up the hierarchy, or rename a grandparent, without effecting your class. (Obviously you can't expect to rename an immediate parent class.) super() is just as explicit as len(), or str.upper(). It says, explicitly, that it will call the method belonging to one or more superclass of the given class. That's no more implicit than mylist[5] is implicit merely because you didn't have to walk the list by hand. > class Base1(object): > def foo(self): >print 'Base1' > > > class Base2(object): > def foo(self): >print 'Base1' > > > class Sub(Base1, Base2): > def foo(self): ># which base version to call ??? ># choice A > # use super an pray that it will do what I need (better > know exactly how the MRO works) But the point is, super() knows exactly how the MRO works, so you don't have to. > # also pray that further readers know as much as I do > about super Now that's just silly. Do you write all your classes for the lowest common denominator? Do you assume all you users are ignorant? If you subclass dict, do you feel the need to "pray" that your users won't try to use mutable objects as keys? If you avoid super(), do you "pray" that your users won't try to use your class in a multiple inheritance situation, and have a buggy class? I bet you don't. If they misuse your class, that's their responsibility. ># choice B > # use explicit calls so I can choose which algorithm I > want to use, calling Base1, Base2 or both of them That's a fair point. super() uses the standard MRO algorithm, it isn't a "Do What I Mean" mind- reading function. If you want an unusual MRO, then you're responsible for managing it yourself. Go right ahead, this is Python and you have all the tools to do so. Nothing forces you to inherit behaviour from the superclasses at all -- super() is designed for overloading (extending) the behaviour of methods, and so the assumption is that you want to call the method in each superclass. But if you're overriding the method instead, or doing something unusual, then you're in charge. > # If the choice is too difficult, that means one thing > => my inheritance design is crap => rewrite it properly. > > Super is known
Re: measuring a function time
Thanks, the first method worked. However clock() doesn't. tic = time.time() time.sleep( 2 ) toc = time.time() print toc - tic Result: 2.00269889832 >Take a look at time.clock() tic = time.clock() time.sleep( 2 ) toc = time.clock() print toc - tic result: 0.0 >More importantly, the above technique is acceptable if function() is very >long-running (multiple seconds, at least). yes, the code is long running. Thanks // Naderan *Mahmood; From: Matteo Landi To: Mahmood Naderan Cc: python mailing list Sent: Thu, July 29, 2010 5:12:58 PM Subject: Re: measuring a function time This should be enough >>>import time >>>tic = time.time() >>>function() >>>toc = time.time() >>>print toc - tic On Thu, Jul 29, 2010 at 2:34 PM, Mahmood Naderan wrote: > Hi, > I want to measure a function run time. I read > http://docs.python.org/library/time.html but I am confused and don't know > which one is suitable. I don't know is daylight timing important or not > or is Y2K issue important for my case or not I also don't know how epoch > time is related to my work. > > I just want to do this (pseudocode): > start_time = get_current_time; > function(); > end_time = get_current_time; > print (end_time - start_time) > > the output should be 7600 (s) for example. What is the best and easiest way > to do that? > > Thanks, > > // Naderan *Mahmood; > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- Matteo Landi http://www.matteolandi.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question regarding SSL and certificate verification
Thank you! This is what I was looking for. A final question -- how widely is M2Crypto used? Since I will have to now pitch to our group that this is preferable the first questions they will ask are about stability, who is using it and how secure is it really, especially since it is at version 0.20.2 (i.e. no major release yet). Thanks again! Jeff - Original Message - From: "John Nagle" To: python-list@python.org Sent: Thursday, July 29, 2010 12:08:57 AM Subject: Re: Newbie question regarding SSL and certificate verification On 7/28/2010 6:26 PM, geremy condra wrote: > On Wed, Jul 28, 2010 at 4:41 PM, Jeffrey > Gaynor wrote: >> Hi, >> >> I am making a first large project in python and am having quite a >> bit of difficulty unscrambling various python versions and what >> they can/cannot do. To wit, I must communicate with certain >> services via https and am required to perform certificate >> verification on them. >> >> The problem is that I also have to do this under CentOS 5.5 which >> only uses python 2.4 as its default -- this is not negotiable. As >> near as I can tell from reading various posts, the https client >> does not do verification and there is no low-level SSL support to >> provide a workaround. Near as I can tell from reading, 2.6 does >> include this. Am I getting this right? Is there a simple way to do >> this? More to the point, I need to know pretty darn quick if this >> is impossible so we can try and plan for it. >> >> So the quick question: Has anyone done certificate verification >> using 2.4 and if so, how? >> >> Thanks! > > M2Crypto is the way to go here. I think there's an example on their > site. M2Crypto does that job quite well. Installing M2Crypto tends to be painful if you have to build it, though. See if you can find a pre- built version. You then need a "cacert.pem" file, with the root certificates you're going to trust. You can get one from http://curl.haxx.se/docs/caextract.html which converts Mozilla's format to a .pem file once a week. The actual Mozilla source file is at http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt but M2Crypto needs it in .pem format. The new Python SSL module in 2.6 and later has a huge built-in security hole - it doesn't verify the domain against the certificate. As someone else put it, this means "you get to talk securely with your attacker." As long as the site or proxy has some valid SSL cert, any valid SSL cert copied from anywhere, the new Python SSL module will tell you everything is just fine. John Nagle -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: measuring a function time
On Thu, 29 Jul 2010 08:45:23 -0400
Joe Riopel wrote:
> On Thu, Jul 29, 2010 at 8:34 AM, Mahmood Naderan wrote:
> > the output should be 7600 (s) for example. What is the best and easiest way
> > to do that?
>
> Take a look at time.clock()
I don't know if that's what he wants. The clock() method returns
processor time, not wall time.
Python 2.6.5 (r265:79063, Jul 8 2010, 16:01:18)
[GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)] on netbsd5
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import time, clock, sleep
>>> t = time()
>>> print time() - t, clock()
0.000596046447754 0.03
>>> sleep(3)
>>> print time() - t, clock()
3.03474903107 0.03
>>> x = open("BIGFILE").read()
>>> print time() - t, clock()
10.2008538246 1.42
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question regarding SSL and certificate verification
On Thu, Jul 29, 2010 at 10:07 AM, Jeffrey Gaynor wrote: > ... > A final question -- how widely is M2Crypto used? Since I will have to now > pitch to our group that this is preferable the first questions they will ask > are about stability, who is using it and how secure is it really, especially > since it is at version 0.20.2 (i.e. no major release yet). I know very little about security, but one thing I think I know. Never use security software version 1.0 or greater. It was written by an author insufficiently paranoid. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question regarding SSL and certificate verification
> I know very little about security, but one thing I think I know. Never > use security software version 1.0 or greater. It was written by an > author insufficiently paranoid. OpenSSL 1.0.0a was released about a month ago. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Nice way to cast a homogeneous tuple
On Jul 28, 7:45 pm, Steven D'Aprano wrote: > On Wed, 28 Jul 2010 08:47:52 -0700, Carl Banks wrote: > > On Jul 28, 7:32 am, Steven D'Aprano > cybersource.com.au> wrote: > >> On Wed, 28 Jul 2010 09:35:52 -0400, wheres pythonmonks wrote: > >> > Thanks ... I thought int was a type-cast (like in C++) so I assumed I > >> > couldn't reference it. > > >> Python doesn't have type-casts in the sense of "tell the compiler to > >> treat object of type A as type B instead". The closest Python has to > >> that is that if you have an instance of class A, you can do this: > > >> a = A() # make an instance of class A a.__class__ = B # tell it that > >> it's now class B > > >> and hope that it won't explode when you try to use it :/ > > > Type casts in C and non-pathlogical C++ don't modify the object they are > > casting. > > > int (and str, float, etc.) is the closest thing to a type cast in > > Python. > > Perhaps I have been misinformed, but my understanding of C type-casts is > that (where possible), a cast like `int(var)` (int)var > merely tells the compiler > to temporarily disregard the type of var and treat it as if it were an > int. In other words, it's a compiler instruction rather than a conversion > function. Even if it did, it would still be temporary. The type of the variable remains unchanged. But it doesn't disregard the original type: type casts try to preserve semantic value. (double)1 returns 1.0, which is not only a different bit pattern but a different size. That's exactly what float() does in Python. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question regarding SSL and certificate verification
On 7/28/2010 10:23 PM, geremy condra wrote: On Wed, Jul 28, 2010 at 10:08 PM, John Nagle wrote: On 7/28/2010 6:26 PM, geremy condra wrote: On Wed, Jul 28, 2010 at 4:41 PM, Jeffrey Gaynorwrote: The new Python SSL module in 2.6 and later has a huge built-in security hole - it doesn't verify the domain against the certificate. As someone else put it, this means "you get to talk securely with your attacker." As long as the site or proxy has some valid SSL cert, any valid SSL cert copied from anywhere, the new Python SSL module will tell you everything is just fine. John Nagle Did anything ever come of the discussion that you and Antoine had? Geremy Condra PS- the quote is due to Justin Samuel I had to write my own domain check. Did anyone re-open the bug report on that issue? John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question regarding SSL and certificate verification
On Wed, 28 Jul 2010 22:23:48 -0700 geremy condra wrote: > > > > The new Python SSL module in 2.6 and later has a huge built-in > > security hole - it doesn't verify the domain against the > > certificate. As someone else put it, this means "you get to > > talk securely with your attacker." As long as the site or proxy > > has some valid SSL cert, any valid SSL cert copied from anywhere, > > the new Python SSL module will tell you everything is just fine. > > > > John Nagle > > Did anything ever come of the discussion that you and Antoine had? As I wrote in http://bugs.python.org/issue1589, I would support adding the necessary function(s) to the SSL module, and have urllib (and other stdlib modules) support them. Someone needs to write a patch, though. Regards Antoine. -- http://mail.python.org/mailman/listinfo/python-list
solving Tix problem in ubuntu jaunty
hi,
recently I switched to ubuntu jaunty and installed python 2.6.I
installed lib-tk so that I can work on my gui apps using Tix and
Tkinter.But ,it seems that the python version in jaunty ships a buggy
tix version which gives a 'TclError:unknown color' error message (this
happens when I try to use FileSelectBox in Tix).
I tried to find if the installation is proper by
>>root=Tix.Tk()
>>root.tk.eval('package require Tix')
This outputs the string '8.4'
How do I correct the problem?I downloaded the source Tix8.4.3-src.tar
from sourceforge site.Can somebody tell me how I can install this so I
can use the bug free Tix from python2.6>
thanks
jim
--
http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
Steven D'Aprano wrote: [snip] super() is just as explicit as len(), or str.upper(). It says, explicitly, that it will call the method belonging to one or more superclass of the given class. Come on Steven, you're better than this :) . Everybody can accurately guess what len and upper are doing without looking at the documentation. No one can guess for super without closely looking at the documention, or even at some good articles on the net which try to clear things up about super. And note there is no such article about len or upper. As someone already said in this list, the main problem with super is that it tends to refer to the superclass method while in fact it calls the next MRO method. "mro" would have been the proper name for "super". JM -- http://mail.python.org/mailman/listinfo/python-list
RE: Ascii to Unicode.
Hi Steven,
I read through the article you referenced. I understand Unicode better now.
I wasn't completely ignorant of the subject. My confusion is more about how
Python is handling Unicode than Unicode itself. I guess I'm fighting my own
misconceptions. I do that a lot. It's hard for me to understand how things
work when they don't function the way I *think* they should.
Here's the main source of my confusion. In my original sample, I had read a
line in from the file and used the unicode function to create a
unicodestring object;
unicodestring = unicode(line, 'latin1')
What I thought this step would do is translate the line to an internal
Unicode representation. The problem character \xe1 would have been
translated into a correct Unicode representation for the accented "a"
character.
Next I tried to write the unicodestring object to a file thusly;
output.write(unicodestring)
I would have expected the write function to request the byte string from the
unicodestring object and simply write that byte string to a file. I thought
that at this point, I should have had a valid Unicode latin1 encoded file.
Instead get an error that the character \xe1 is invalid.
The fact that the \xe1 character is still in the unicodestring object tells
me it wasn't translated into whatever python uses for its internal Unicode
representation. Either that or the unicodestring object returns the
original string when it's asked for a byte stream representation.
Instead of just writing the unicodestring object, I had to do this;
output.write(unicodestring.encode('utf-8'))
This is doing what I thought the other steps were doing. It's translating
the internal unicodestring byte representation to utf-8 and writing it out.
It still seems strange and I'm still not completely clear as to what is
going on at the byte stream level for each of these steps.
--
http://mail.python.org/mailman/listinfo/python-list
stdout of external program.
HELP! :) I am trying to output the following program's output to either a file or variable, how can this be done? # Writing the output to a standard argv argument #1/usr/bin/python import sys for arg in sys.argv: print arg #END Thanks, Paul -- http://mail.python.org/mailman/listinfo/python-list
RE: Ascii to Unicode.
Hi Ulrich,
Ascii.csv isn't really a latin-1 encoded file. It's an ascii file with a
few characters above the 128 range that are causing Postgresql Unicode
errors. Those characters work fine in the Windows world but they're not the
correct byte representation for Unicode. What I'm attempting to do is
translate those upper range characters into the correct Unicode
representations so that they look the same in the Postgresql database as
they did in the CSV file.
I wrote up the source of my confusion to Steven so I won't duplicate it
here. You're comment on defining the encoding of the file directly instead
of using functions to encode and decode the data lead me to the codecs
module. Using it, I can define the encoding a file open time and then just
read and write the lines. I ended up with this;
import codecs
input = codecs.open('ascii.csv', encoding='cp1252')
output = codecs.open('unicode.csv', mode='wb', encoding='utf-8')
output.writelines(input.readlines())
input.close()
output.close()
This is doing exactly the same thing but it's much clearer to me. Readlines
translates the input using the cp1252 codec and writelines encodes it to
utf-8 and writes it out. And as you mentioned, it's probably higher
performance. I haven't tested that but since both programs do the job in
seconds, performance isn't and issue.
Thanks again to everyone who posted. I really do appreciate it.
--
http://mail.python.org/mailman/listinfo/python-list
Multiprocessing taking too much time
Hi All, I have a following situation. ==PSUDO CODE START== class holds_big_array: big_array #has a big array def get_some_element(self, cond) # return some data from the array from the big array ==PSUDO CODE END I wanted to use multiprocessing module to parallelise calling "get_some_element". I used following kind of code ==PSUDO CODE START== pool = Pool(processes=2) holder =holds_big_array() #class instantiation def callback_f(result): do something with result loop many times pool.apply_async(holder.get_some_element,args,callback=callback_f) pool.close() pool.join() ==PSUDO CODE END Note: Had to do something to enable instance method being pickled... I tested this with less than realistic size of big_array . My parallel version works much slower than than the normal serial version (10-20 sec vs 7-8 min). I was wonder what could be the possible reason. Is it something to do that it is a instance method and some locking will make other process wait for the locks. Any idea how to trace where the program is spending time? Let me know if the information give is inadequate. Thanks in advance. Shailendra Vikas -- http://mail.python.org/mailman/listinfo/python-list
default behavior
Why is the default value of an int zero? >>> x = int >>> print x >>> x() 0 >>> How do I build an "int1" type that has a default value of 1? [Hopefully no speed penalty.] I am thinking about applications with collections.defaultdict. What if I want to make a defaultdict of defaultdicts of lists? [I guess my Perl background is showing -- I miss auto-vivification.] W -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
Joe Goldthwaite wrote:
Hi Steven,
I read through the article you referenced. I understand Unicode better now.
I wasn't completely ignorant of the subject. My confusion is more about how
Python is handling Unicode than Unicode itself. I guess I'm fighting my own
misconceptions. I do that a lot. It's hard for me to understand how things
work when they don't function the way I *think* they should.
Here's the main source of my confusion. In my original sample, I had read a
line in from the file and used the unicode function to create a
unicodestring object;
unicodestring = unicode(line, 'latin1')
What I thought this step would do is translate the line to an internal
Unicode representation. The problem character \xe1 would have been
translated into a correct Unicode representation for the accented "a"
character.
Correct. At this point you have unicode string.
Next I tried to write the unicodestring object to a file thusly;
output.write(unicodestring)
I would have expected the write function to request the byte string from the
unicodestring object and simply write that byte string to a file. I thought
that at this point, I should have had a valid Unicode latin1 encoded file.
Instead get an error that the character \xe1 is invalid.
Here's the problem -- there is no byte string representing the unicode
string, they are completely different. There are dozens of different
possible encodings to go from unicode to a byte-string (of which UTF-8
is one such possibility).
The fact that the \xe1 character is still in the unicodestring object tells
me it wasn't translated into whatever python uses for its internal Unicode
representation. Either that or the unicodestring object returns the
original string when it's asked for a byte stream representation.
Wrong. It so happens that some of the unicode points are the same as
some (but not all) of the ascii and upper-ascii values. When you
attempt to write a unicode string without specifying which encoding you
want, python falls back to ascii (not upper-ascii) so any character
outside the 0-127 range is going to raise an error.
Instead of just writing the unicodestring object, I had to do this;
output.write(unicodestring.encode('utf-8'))
This is doing what I thought the other steps were doing. It's translating
the internal unicodestring byte representation to utf-8 and writing it out.
It still seems strange and I'm still not completely clear as to what is
going on at the byte stream level for each of these steps.
Don't think of unicode as a byte stream. It's a bunch of numbers that
map to a bunch of symbols. The byte stream only comes into play when
you want to send unicode somewhere (file, socket, etc) and you then have
to encode the unicode into bytes.
Hope this helps!
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing taking too much time
The first thing that is generically tried when wishing to measure how long certain parts take is to record your own time snapshots in the code yourself. take the current time before an operation, take it after, subract, report it to yourself. Also, try working with an array that is actually big, so that you can see meaningful differences in approaches. Shailendra wrote: Hi All, I have a following situation. ==PSUDO CODE START== class holds_big_array: big_array #has a big array def get_some_element(self, cond) # return some data from the array from the big array ==PSUDO CODE END I wanted to use multiprocessing module to parallelise calling "get_some_element". I used following kind of code ==PSUDO CODE START== pool = Pool(processes=2) holder =holds_big_array() #class instantiation def callback_f(result): do something with result loop many times pool.apply_async(holder.get_some_element,args,callback=callback_f) pool.close() pool.join() ==PSUDO CODE END Note: Had to do something to enable instance method being pickled... I tested this with less than realistic size of big_array . My parallel version works much slower than than the normal serial version (10-20 sec vs 7-8 min). I was wonder what could be the possible reason. Is it something to do that it is a instance method and some locking will make other process wait for the locks. Any idea how to trace where the program is spending time? Let me know if the information give is inadequate. Thanks in advance. Shailendra Vikas -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
On Thu, Jul 29, 2010 at 10:59 AM, Joe Goldthwaite wrote: > Hi Ulrich, > > Ascii.csv isn't really a latin-1 encoded file. It's an ascii file with a > few characters above the 128 range that are causing Postgresql Unicode > errors. Those characters work fine in the Windows world but they're not the > correct byte representation for Unicode. What I'm attempting to do is > translate those upper range characters into the correct Unicode > representations so that they look the same in the Postgresql database as > they did in the CSV file. Having bytes outside of the ASCII range means, by definition, that the file is not ASCII encoded. ASCII only defines bytes 0-127. Bytes outside of that range mean either the file is corrupt, or it's in a different encoding. In this case, you've been able to determine the correct encoding (latin-1) for those errant bytes, so the file itself is thus known to be in that encoding. Carey -- http://mail.python.org/mailman/listinfo/python-list
Re: default behavior
wheres pythonmonks writes: > How do I build an "int1" type that has a default value of 1? > [Hopefully no speed penalty.] > I am thinking about applications with collections.defaultdict. You can supply an arbitary function to collections.defaultdict. It doesn't have to be a class. E.g. d = collections.defaultdict(lambda: 1) will do what you are asking. -- http://mail.python.org/mailman/listinfo/python-list
Re: default behavior
Thanks. I presume this will work for my nested example as well. Thanks again. On Thu, Jul 29, 2010 at 2:18 PM, Paul Rubin wrote: > wheres pythonmonks writes: >> How do I build an "int1" type that has a default value of 1? >> [Hopefully no speed penalty.] >> I am thinking about applications with collections.defaultdict. > > You can supply an arbitary function to collections.defaultdict. > It doesn't have to be a class. E.g. > > d = collections.defaultdict(lambda: 1) > > will do what you are asking. > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
Joe Goldthwaite wrote: Hi Ulrich, Ascii.csv isn't really a latin-1 encoded file. It's an ascii file with a few characters above the 128 range . . . It took me a while to get this point too (if you already have "gotten it", I apologize, but the above comment leads me to believe you haven't). *Every* file is an encoded file... even your UTF-8 file is encoded using the UTF-8 format. Someone correct me if I'm wrong, but I believe lower-ascii (0-127) matches up to the first 128 Unicode code points, so while those first 128 code-points translate easily to ascii, ascii is still an encoding, and if you have characters higher than 127, you don't really have an ascii file -- you have (for example) a cp1252 file (which also, not coincidentally, shares the first 128 characters/code points with ascii). Hopefully I'm not adding to the confusion. ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: default behavior
On 07/29/2010 09:12 PM, wheres pythonmonks wrote: How do I build an "int1" type that has a default value of 1? You mean something like: >>> x = int() >>> x 0 >>> def myint(value=1): ... return int(value) ... >>> myint() 1 >>> That's ugly on so many levels.. Anyway, basic types (and almost everything else) in Python are classes. You can always subclass them to do whatever you like [Hopefully no speed penalty.] I am thinking about applications with collections.defaultdict. What if I want to make a defaultdict of defaultdicts of lists? [I guess my Perl background is showing -- I miss auto-vivification.] Ah, python is no perl. Then again, perl is no python either. - Random pseudo-Confucius quote Have fun, Nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing taking too much time
On 7/29/2010 11:08 AM, Shailendra wrote: Hi All, I have a following situation. ==PSUDO CODE START== class holds_big_array: big_array #has a big array def get_some_element(self, cond) # return some data from the array from the big array ==PSUDO CODE END I wanted to use multiprocessing module to parallelise calling "get_some_element". I used following kind of code ==PSUDO CODE START== pool = Pool(processes=2) holder =holds_big_array() #class instantiation def callback_f(result): do something with result loop many times pool.apply_async(holder.get_some_element,args,callback=callback_f) pool.close() pool.join() ==PSUDO CODE END Note: Had to do something to enable instance method being pickled... I tested this with less than realistic size of big_array . My parallel version works much slower than than the normal serial version (10-20 sec vs 7-8 min). I was wonder what could be the possible reason. It's hard to tell from your "PSUDO CODE", but it looks like each access to the "big array" involves calling another process. Calling a function in another process is done by creating an object to contain the request, running it through "pickle" to convert it to a stream of bytes, sending the stream of bytes through a socket or pipe to the other process, running the byte stream through "unpickle" to create an object like the original one, but in a different process, and calling a function on the newly created object in the receiving process. This entire sequence has to be done again in reverse to get a reply back. This is hundreds of times slower than a call to a local function. The "multiprocessing module" is not a replacement for thread-level parallelism. It looks like it is, but it isn't. It's only useful for big tasks which require large amounts of computation and little interprocess communication. Appropriately-sized tasks to send out to another process are things like "parse large web page" or "compress video file", not "access element of array". John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabular Package: importing file
On 7/28/10 4:57 PM, Robert Faryabi wrote: Hi there; I'm using Tabular Package for manipulating tab-delimited data. There is a small problem that I cannot get my head around it. When I construct my tabarray from file, the black fields are replaced by "nan". Does any one knows how to just keep them as empty string (ie. ' ')? If you want the other values to be actual numbers instead of strings containing numerical values, then no, you cannot keep the blank fields as empty strings. There may be an option to have tabular parse the data into an object array, in which all of the items will be Python objects. Then you could mix and match the types. You will find better luck asking questions about tabular on the numpy-discussion mailing list. tabular is built on numpy, so many of your questions will really be questions about how numpy behaves. Also, the tabular authors hang out there. http://www.scipy.org/Mailing_Lists -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
On 7/28/2010 3:58 PM, Joe Goldthwaite wrote: This still seems odd to me. I would have thought that the unicode function would return a properly encoded byte stream that could then simply be written to disk. Instead it seems like you have to re-encode the byte stream to some kind of escaped Ascii before it can be written back out. Here's what's really going on. Unicode strings within Python have to be indexable. So the internal representation of Unicode has (usually) two bytes for each character, so they work like arrays. UTF-8 is a stream format for Unicode. It's slightly compressed; each character occupies 1 to 4 bytes, and the base ASCII characters (0..127 only, not 128..255) occupy one byte each. The format is described in "http://en.wikipedia.org/wiki/UTF-8";. A UTF-8 file or stream has to be parsed from the beginning to keep track of where each Unicode character begins. So it's not a suitable format for data being actively worked on in memory; it can't be easily indexed. That's why it's necessary to convert to UTF-8 before writing to a file or socket. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: default behavior
On 7/29/2010 11:12 AM, wheres pythonmonks wrote: Why is the default value of an int zero? x = int print x x() 0 How do I build an "int1" type that has a default value of 1? >>> class int1(object) : ...def __init__(self) : ... self.val = 1 ...def __call__(self) : ... return(self.val) ... >>> x = int1() >>> x() 1 This isn't useful; you'd also have to define all the numeric operators for this type. And then there are mixed-type conversion issues. Inheriting from "int" is not too helpful, because you can't assign to the value of the base class. "self=1" won't do what you want. [Hopefully no speed penalty.] In your dreams. Although all numbers in CPython are "boxed", so there's more of a speed penalty with "int" itself than you might expect. There are some C libraries for handling large arrays if you really need to crunch numbers. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: default behavior
> Inheriting from "int" is not too helpful, because you can't assign > to the value of the base class. "self=1" won't do what you want. It's useful if you remember that you can set the default value by overwriting __new__. >>> class int1(int): ... def __new__(cls, value=1): ... return super(int1, cls).__new__(cls, value) ... >>> int1() 1 >>> int1(1) 1 >>> int1(2) 2 >>> int1(0) 0 -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
John Nagle wrote: On 7/28/2010 3:58 PM, Joe Goldthwaite wrote: This still seems odd to me. I would have thought that the unicode function would return a properly encoded byte stream that could then simply be written to disk. Instead it seems like you have to re-encode the byte stream to some kind of escaped Ascii before it can be written back out. Here's what's really going on. Unicode strings within Python have to be indexable. So the internal representation of Unicode has (usually) two bytes for each character, so they work like arrays. UTF-8 is a stream format for Unicode. It's slightly compressed; each character occupies 1 to 4 bytes, and the base ASCII characters (0..127 only, not 128..255) occupy one byte each. The format is described in "http://en.wikipedia.org/wiki/UTF-8";. A UTF-8 file or stream has to be parsed from the beginning to keep track of where each Unicode character begins. So it's not a suitable format for data being actively worked on in memory; it can't be easily indexed. Not entirely correct. The advantage of UTF-8 is that although different codepoints might be encoded into different numbers of bytes it's easy to tell whether a particular byte is the first in its sequence, so you don't have to parse from the start of the file. It is true, however, it can't be easily indexed. That's why it's necessary to convert to UTF-8 before writing to a file or socket. -- http://mail.python.org/mailman/listinfo/python-list
combined functionality of ipython's %whos and pdb's next (without a resource heavy IDE)
I am trying to combine the ability to move line-by-line through the code as is done with pdb's "next" function with ipython's ability to list all variables at once... without the use of a full-fledged IDE. I am not seeing how this might be done. Many thanks for your help... Ben Racine -- http://mail.python.org/mailman/listinfo/python-list
Re: measuring a function time
I just use ipython's functions (that are themselves just calls to the time
module functions) for timing my functions...
Enter:
%timeit?
or
%time
At the Ipython command prompt to get started.
Ben R.
On Jul 29, 2010, at 7:43 AM, D'Arcy J.M. Cain wrote:
> On Thu, 29 Jul 2010 08:45:23 -0400
> Joe Riopel wrote:
>> On Thu, Jul 29, 2010 at 8:34 AM, Mahmood Naderan
>> wrote:
>>> the output should be 7600 (s) for example. What is the best and easiest way
>>> to do that?
>>
>> Take a look at time.clock()
>
> I don't know if that's what he wants. The clock() method returns
> processor time, not wall time.
>
> Python 2.6.5 (r265:79063, Jul 8 2010, 16:01:18)
> [GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)] on netbsd5
> Type "help", "copyright", "credits" or "license" for more information.
from time import time, clock, sleep
t = time()
print time() - t, clock()
> 0.000596046447754 0.03
sleep(3)
print time() - t, clock()
> 3.03474903107 0.03
x = open("BIGFILE").read()
print time() - t, clock()
> 10.2008538246 1.42
>
> --
> D'Arcy J.M. Cain | Democracy is three wolves
> http://www.druid.net/darcy/| and a sheep voting on
> +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question regarding SSL and certificate verification
On Thu, Jul 29, 2010 at 9:13 AM, Antoine Pitrou wrote: > On Wed, 28 Jul 2010 22:23:48 -0700 > geremy condra wrote: >> > >> > The new Python SSL module in 2.6 and later has a huge built-in >> > security hole - it doesn't verify the domain against the >> > certificate. As someone else put it, this means "you get to >> > talk securely with your attacker." As long as the site or proxy >> > has some valid SSL cert, any valid SSL cert copied from anywhere, >> > the new Python SSL module will tell you everything is just fine. >> > >> > John Nagle >> >> Did anything ever come of the discussion that you and Antoine had? > > As I wrote in http://bugs.python.org/issue1589, I would support adding > the necessary function(s) to the SSL module, and have urllib (and other > stdlib modules) support them. Someone needs to write a patch, though. > > Regards > > Antoine. Hmm, my understanding at the time was that there had been a decision to just adapt Heikki Toivonen's M2Crypto code, if that's just looking for someone to turn it into a patch I'll see if I can't find the time next week. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: default behavior
On Thu, 29 Jul 2010 21:43:05 +0300, Nick Raptis wrote: > On 07/29/2010 09:12 PM, wheres pythonmonks wrote: >> How do I build an "int1" type that has a default value of 1? > You mean something like: > >>> x = int() > >>> x > 0 > >>> def myint(value=1): > ... return int(value) > ... > >>> myint() > 1 > >>> > >>> > That's ugly on so many levels.. Why do you think it's ugly? It's a function that returns an int, and it provides a default value which is different from the default value of the int constructor. It's a really simple function, and it has an equally simple implementation, and it's an obvious way to do it. Not the *one* obvious way, because subclassing int is equally obvious, but still obvious. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
ANUSHKA HOT PICTURES FOR BOLLYWOOD FANS
ANUSHKA HOT PICTURES FOR BOLLYWOOD FANS - http://sites.google.com/site/anushkaphotosalert -- http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote: > Steven D'Aprano wrote: >> [snip] >> >> super() is just as explicit as len(), or str.upper(). It says, >> explicitly, that it will call the method belonging to one or more >> superclass of the given class. >> > Come on Steven, you're better than this :) . Everybody can accurately > guess what len and upper are doing without looking at the documentation. > No one can guess for super without closely looking at the documention, > or even at some good articles on the net which try to clear things up > about super. And note there is no such article about len or upper. super() is complex because the problem it is solving is a hard problem. That doesn't make it implicit, any more than (say) itertools.groupby() is implicit just because it's complex, or urllib2.request() is implicit just because some people don't know much about web protocols and have to read articles about it to learn. > As someone already said in this list, the main problem with super is > that it tends to refer to the superclass method while in fact it calls > the next MRO method. Why do you think that is a problem? That's what it is supposed to do, because that's what is needed to correctly implement multiple inheritance. > "mro" would have been the proper name for "super". That's your opinion. In any case, whether super() was called super() or mro() or aardvark() makes no difference to the functionality or whether it is useful. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Possible to include \n chars in doctest code samples or output?
In article <4c3ff6f7$0$11101$c3e8...@news.astraweb.com>, Steven D'Aprano wrote: > >Remember that doctests aren't intended for a comprehensive test suite. WDYM not intended? Disagree with Tim Peters much? ;-) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Normal is what cuts off your sixth finger and your tail..." --Siobhan -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
On Thu, 29 Jul 2010 11:14:24 -0700, Ethan Furman wrote:
> Don't think of unicode as a byte stream. It's a bunch of numbers that
> map to a bunch of symbols.
Not only are Unicode strings a bunch of numbers ("code points", in
Unicode terminology), but the numbers are not necessarily all the same
width.
The full Unicode system allows for 1,114,112 characters, far more than
will fit in a two-byte code point. The Basic Multilingual Plane (BMP)
includes the first 2**16 (65536) of those characters, or code points
U+ through U+; there are a further 16 supplementary planes of
2**16 characters each, or code points U+1 through U+10.
As I understand it (and I welcome corrections), some implementations of
Unicode only support the BMP and use a fixed-width implementation of 16-
bit characters for efficiency reasons. Supporting the entire range of
code points would require either a fixed-width of 21-bits (which would
then probably be padded to four bytes), or a more complex variable-width
implementation.
It looks to me like Python uses a 16-bit implementation internally, which
leads to some rather unintuitive results for code points in the
supplementary place...
>>> c = chr(2**18)
>>> c
'\U0004'
>>> len(c)
2
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: measuring a function time
Someone should port Perl's Benchmark.pm module to python that's such a useful
module to measure a functions execution time and CPU usage.
Sent from my iPhone 4.
On Jul 29, 2010, at 3:43 PM, "Benjamin J. Racine" wrote:
> I just use ipython's functions (that are themselves just calls to the time
> module functions) for timing my functions...
>
> Enter:
> %timeit?
> or
> %time
>
> At the Ipython command prompt to get started.
>
> Ben R.
>
> On Jul 29, 2010, at 7:43 AM, D'Arcy J.M. Cain wrote:
>
>> On Thu, 29 Jul 2010 08:45:23 -0400
>> Joe Riopel wrote:
>>> On Thu, Jul 29, 2010 at 8:34 AM, Mahmood Naderan
>>> wrote:
the output should be 7600 (s) for example. What is the best and easiest way
to do that?
>>>
>>> Take a look at time.clock()
>>
>> I don't know if that's what he wants. The clock() method returns
>> processor time, not wall time.
>>
>> Python 2.6.5 (r265:79063, Jul 8 2010, 16:01:18)
>> [GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)] on netbsd5
>> Type "help", "copyright", "credits" or "license" for more information.
> from time import time, clock, sleep
> t = time()
> print time() - t, clock()
>> 0.000596046447754 0.03
> sleep(3)
> print time() - t, clock()
>> 3.03474903107 0.03
> x = open("BIGFILE").read()
> print time() - t, clock()
>> 10.2008538246 1.42
>>
>> --
>> D'Arcy J.M. Cain | Democracy is three wolves
>> http://www.druid.net/darcy/| and a sheep voting on
>> +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
"Joe Goldthwaite" wrote in message
news:5a04846ed83745a8a99a944793792...@newmbp...
Hi Steven,
I read through the article you referenced. I understand Unicode better
now.
I wasn't completely ignorant of the subject. My confusion is more about
how
Python is handling Unicode than Unicode itself. I guess I'm fighting my
own
misconceptions. I do that a lot. It's hard for me to understand how
things
work when they don't function the way I *think* they should.
Here's the main source of my confusion. In my original sample, I had read
a
line in from the file and used the unicode function to create a
unicodestring object;
unicodestring = unicode(line, 'latin1')
What I thought this step would do is translate the line to an internal
Unicode representation.
Correct.
The problem character \xe1 would have been
translated into a correct Unicode representation for the accented "a"
character.
Which just so happens to be u'\xe1', which probably adds to your confusion
later :^) The first 256 Unicode code points map to latin1.
Next I tried to write the unicodestring object to a file thusly;
output.write(unicodestring)
I would have expected the write function to request the byte string from
the
unicodestring object and simply write that byte string to a file. I
thought
that at this point, I should have had a valid Unicode latin1 encoded file.
Instead get an error that the character \xe1 is invalid.
Incorrect. The unicodestring object doesn't save the original byte string,
so there is nothing to "request".
The fact that the \xe1 character is still in the unicodestring object
tells
me it wasn't translated into whatever python uses for its internal Unicode
representation. Either that or the unicodestring object returns the
original string when it's asked for a byte stream representation.
Both incorrect. As I mentioned earlier, the first Unicode code points map
to latin1. It *was* translated to a Unicode code point whose value (but not
internal representation!) is the same as latin1.
Instead of just writing the unicodestring object, I had to do this;
output.write(unicodestring.encode('utf-8'))
This is exactly what you need to do...explicitly encode the Unicode string
into a byte string.
This is doing what I thought the other steps were doing. It's translating
the internal unicodestring byte representation to utf-8 and writing it
out.
It still seems strange and I'm still not completely clear as to what is
going on at the byte stream level for each of these steps.
I'm surprised that by now no one has mentioned the codecs module. You
original stated you are using Python 2.4.4, which I looked up and does
support the codecs module.
import codecs
infile = codecs.open('ascii.csv,'r','latin1')
outfile = codecs.open('unicode.csv','w','utf-8')
for line in infile:
outfile.write(line)
infile.close()
outfile.close()
As you can see, codecs.open takes a parameter for the encoding of the file.
Lines read are automatically decoded into Unicode; Unicode lines written are
automatically encoded into a byte stream.
-Mark
--
http://mail.python.org/mailman/listinfo/python-list
Enabling/Disabling remote desktop - programmatically
I've already posted this in the Python W32 list, but didn't get what I'm looking for. I want to know how to disable Remote Desktop after logging to into a remote machine, to prevent subsequent logins by other users logging me out. I currently have a Windows XP system configured for coworkers to connect to using VPN & remote desktop, so they can get diagnostic data for test failures. I can disable Remote Desktop manually in Ctrl Panel, but have to navigate through several screens to do this. If I could do this using Python it would be very convenient. Have any of the Windows users on this list done this? Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: combined functionality of ipython's %whos and pdb's next (without a resource heavy IDE)
On Jul 29, 12:39 pm, "Benjamin J. Racine" wrote: > I am trying to combine the ability to move line-by-line through the code as > is done with pdb's "next" function with ipython's ability to list all > variables at once... without the use of a full-fledged IDE. > > I am not seeing how this might be done. Many thanks for your help... > > Ben Racine Ben You can actually use the sys module to do this, with just a few lines of code. This article shows you how http://www.doughellmann.com/PyMOTW/sys/tracing.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Ascii to Unicode.
On Thu, 29 Jul 2010 23:49:40 +, Steven D'Aprano wrote: > It looks to me like Python uses a 16-bit implementation internally, It typically uses the platform's wchar_t, which is 16-bit on Windows and (typically) 32-bit on Unix. IIRC, it's possible to build Python with 32-bit Unicode on Windows, but that will be inefficient (because it has to convert to/from 16-bit when calling Windows API functions) and will break any C modules which pass the pointer to the internal buffer directly to API functions. -- http://mail.python.org/mailman/listinfo/python-list
