Re: web frameworks that support Python 3
On Aug 24, 6:34 am, Sebastian Wiesner basti.wies...@gmx.net wrote: At Sunday 23 August 2009 22:13:16 you wrote: I use Chinese and therefore Unicode very heavily, and so Python 3 is an unavoidable choice for me. Python 2.x supports Unicode just as well as Python 3. Every common web framework works perfectly with unicode. In any case, there is bottle [1], which provides a *very minimal* framework for WSGI web development. Don't expect too much, it is really small, and doesn't do much more than routing and minimal templating. However, it is the only Python-3-compatible web framework I know of. [1]http://bottle.paws.de/page/start There is one big flaw with your claim. That is the there is no WSGI specification for Python 3.0 as yet. Anything that claims to work with WSGI and Python 3.0 is just a big guess as far as how WSGI for Python 3.0 may work. I would therefore be a bit cautious with your claim. Graham -- http://mail.python.org/mailman/listinfo/python-list
Re: elementtree
Hi, elsa wrote: I know how to turn HTML into an ElementTree object I don't. ;) ElementTree doesn't have an HTML parser, so what do you use for parsing? but I don't know how to then view the structure of this object. Is there a method or module that you can give an ElementTree object to, and it returns some kind of graphical or printed representation of the tree? Otherwise, if you can't see you're tree's structure, how do you know what is a sensible way of iterating over the tree to access the info you need? ElementTree has a tostring() method that returns a string. To get a pretty printed representation, you can use the indent() function from this recipe: http://effbot.org/zone/element-lib.htm#prettyprint Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pyxser-1.2r --- Python-Object to XML serialization module
Daniel Molina Wegener wrote: * Added encoded serialization of Unicode strings by using the user defined encoding as is passed to the serialization functions as enc parameter As you see, now Unicode strings are serialized as encoded byte string by using the encoding that the user pass as enc parameter to the serialization function. This means that Unicode strings are serialized in a human readable form, regarding a better interoperability with other platforms. You mean, the whole XML document is serialised with that encoding, right? Stefan -- http://mail.python.org/mailman/listinfo/python-list
Python and JMS
Hi all, I would like to make a JMS client connection from Python to Progress Sonic ESB (JMS message provider similar to WebSphere MQ or Active MQ). What would be the best way to implement that within Python 2.6 ? Any ideas ? Thanks Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: sgmllib.py
elsa wrote: I'm new to both this forum and Python, and I've got a bit stuck trying to learn how to parse HTML... If what you want to do is *parse* the HTML instead of trying to *learn* how to parse it, you might want to give the existing (external) HTML parser libraries a try. There's lxml.html (extremely fast and fixes up broken HTML), html5lib (very slow, but very browser-like parse results) and BeautifulSoup (slow, but good encoding detection if you need that). Here are a couple of (only slightly biased) comparisons: http://blog.ianbicking.org/2008/03/30/python-html-parser-performance/ http://blog.ianbicking.org/2008/12/10/lxml-an-underappreciated-web-scraping-library/ python sgmllib.py path/to/my/file.html example (1) this doesn't work for me. I think I have figured out the problem - the error says /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ Python.app/Contents/MacOS/Python: can't open file 'sgmllib.py': [Errno 2] No such file or directory the problem is that this path is wrong. My sgmllib.py is in: /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/sgmllib.py You can use python -m sgmllib to call a module from the stdlib (or the PYTHONPATH, to be more accurate). But note that sgmllib is a particularly cumbersome way to deal with HTML. Stefan -- http://mail.python.org/mailman/listinfo/python-list
elementtree
I have a question about elementtree: I know how to turn HTML into an ElementTree object, but I don't know how to then view the structure of this object. Is there a method or module that you can give an ElementTree object to, and it returns some kind of graphical or printed representation of the tree? Otherwise, if you can't see you're tree's structure, how do you know what is a sensible way of iterating over the tree to access the info you need? Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Simple IRC library
Hi all, I am new to Python language. I want to capture(either in database or a file) the conversation in IRC. Please suggest me some simple IRC library or code snippet for this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Need cleanup advice for multiline string
Steven D'Aprano wrote: I'm amused and somewhat perplexed that somebody with the non-English name of Stefan, writing from a .de email address, seems to be assuming that (1) everybody is on the Internet, and (2) everybody on the Internet speaks English. Oh, I totally don't. But most people who read c.l.py do at least understand it to a certain extent. I don't commonly read /that/ many non-english-speaking Python forums thoroughly enough to assume that the OP posted the question only in English and only in c.l.py. I don't even assume that he only posted that question to an Internet newsgroup. You know, there's real-life, too. But reading statements like the above really makes me feel that it's best to comment even on simple things like hi guys!. Or you could enter the 21 century and understand that guys has become a generic term for people of any sex. Is that true for everyone who understands and/or writes English? In that case, I'm fine with your above statement. Otherwise, I'd wonder who you meant with the term cultural chauvinism. So far, I only learned that most North-American English native speakers use that term in the way you refer to. That doesn't even get you close to the majority of English speakers. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Need cleanup advice for multiline string
Mensanator wrote: On Aug 23, 2:25�pm, Stefan Behnel wrote: Mensanator wrote: asking how many Jews you can fit into a Volswagen. None, because it's already full. A spelling error does not make it any less offensive. As it stands, I find the joke above perfectly acceptable. Using the word Jew in a joke doesn't make it anti-semitic by default. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
Scott David Daniels scott.dani...@acm.org (SDD) wrote: SDD James Harris wrote:... Another option: 0.(2:1011), 0.(8:7621), 0.(16:c26b) where the three characters 0.( begin the sequence. Comments? Improvements? SDD I did a little interpreter where non-base 10 numbers SDD (up to base 36) were: SDD .7.100 == 64 (octal) SDD .9.100 == 100 (decimal) SDD .F.100 == 256 (hexadecimal) SDD .1.100 == 4 (binary) SDD .3.100 == 9 (trinary) SDD .Z.100 == 46656 (base 36) I wonder how you wrote that interpreter, given that some answers are wrong. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
MRAB wrote: James Harris wrote: On 23 Aug, 00:16, Mel mwil...@the-wire.com wrote: James Harris wrote: I have no idea why Ada which uses the # also apparently uses it to end a number 2#1011#, 8#7621#, 16#c26b# Interesting. They do it because of this example from http://archive.adaic.com/standards/83rat/html/ratl-02-01.html#2.1: Thanks for providing an explanation. 2#1#E8-- an integer literal of value 256 where the E prefixes a power-of-2 exponent, and can't be taken as a digit of the radix. That is to say 16#1#E2 would also equal 256, since it's 1*16**2 . Here's another suggested number literal format. First, keep the familar 0x and 0b of C and others and to add 0t for octal. (T is the third letter of octal as X is the third letter of hex.) The numbers above would be 0b1011, 0t7621, 0xc26b Second, allow an arbitrary number base by putting base and number in quotes after a zero as in 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b It's always a bit impressive how syntax suggestions get more and more involved and, if you'll forgive me for saying, ridiculous as the conversation continues. This is starting to get truly nutty. What I've done in my projects is simply extend the pattern of 0x... for hexadecimal literals in C to 0b... for binary, 0o... for octal, 0d... for decimal (though redundant as that's the default), and so on. (Go crazy and add 0t... for trinary and 0q... for quaternary if you feel like it.) To me this always seemed elegant, simple, and understandable. If arbitrary radix values is what's desirable, then some syntax like radixrvalue (e.g., 8r024222570 for an octal number which represents a very lame joke) would work, but seems to me like huge overkill. A normal string literal coupled with a constructor type function would seem far more appropriate -- and we already have that with `int`. As for large literals, I'd go with having spaces indicate automatic concatenation (though only the first in the series can indicate the radix, whichever method you choose above). It's the same as for strings, and it's the common SI recommendation for thousands separators anyway. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis The little I know, I owe to my ignorance. -- Sacha Guitry -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
J. Cliff Dyer wrote: I had an objection to using spaces in numeric literals last time around and it still stands, and it still stands in the new one. What happens if you use a literal like 0x10f 304? Is 304 treated as decimal or hexadecimal? It's not clear how you would begin to combine it. Well, you can't combine them in any meaningful mathematical or computational sense if they're of different bases, so the answer lies therein: You shouldn't be allowed to do that. The way string concatenation works, it takes two independent string literals, and combines them. If you specify r'\n' 'abc\n', the first half is treated independently as a raw string, and the second half is treated as a normal string. The result is '\\nabc\n'. With numeric literals, this behavior doesn't even make sense. How do you concatenate hex 10f with decimal 304? You can't, and the operation makes no sense, which is what makes the syntax unambiguous. An extended numeric literal continues the radix of wherever it started. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis Do not seek death. Death will find you. -- Dag Hammarskjold -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
On 24 Aug, 02:19, Max Erickson maxerick...@gmail.com wrote:
...
It can be assumed however that .9. isn't in binary?
That's a neat idea. But an even simpler scheme might be:
.octal.100
.decimal.100
.hex.100
.binary.100
.trinary.100
until it gets to this anyway:
.thiryseximal.100
At some point, abandoning direct support for literals and just
having a function that can handle different bases starts to make a
lot of sense to me:
int('100', 8)
64
int('100', 10)
100
int('100', 16)
256
int('100', 2)
4
int('100', 3)
9
int('100', 36)
1296
This is fine typed into the language directly but couldn't be entered
by the user or read-in from or written to a file.
James
--
http://mail.python.org/mailman/listinfo/python-list
Re: Literal concatenation, strings vs. numbers
Ben Finney wrote: Yet, as was pointed out, that behaviour would be inconsistent with the concatenation of string literals:: abc r'def' ughi 'jkl' u'abcdefghijkl' So, different representations of literals are parsed as separate literals, then concatenated. To have the behaviour you describe, the case needs to be made separately that digit concatenation should not be consistent with the established string literal parsing behaviour. Since digit concatenation can't possibly be useful any other way, it makes perfect sense. Why is the operator ** right-to-left associative? The same basic reason: Because it would be dumb for it not to be. Does that make it confusing and inconsistent compared to most of the other binary operators? In some sense, yes, it does. But it also makes it sane. Is anyone so upset by this that it didn't make it into the language, or cause huge confusion on a regular basis that upsets a lot of users? Nope. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis Do not seek death. Death will find you. -- Dag Hammarskjold -- http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
In article 5134d9f1-0e23-4e05-a817-bf0cc9e85...@w6g2000yqw.googlegroups.com, sturlamolden sturlamol...@yahoo.no wrote: On 24 Aug, 02:26, nos...@see.signature (Richard Maine) wrote: You missed the word OOP, which seemed like the whole point. Not that the particular word is used in the Fortran standard, but it isn't hard to guess that he means a derived type that uses some of the OOP features. Inheritance, polymorphism, and type-bound procedure (aka methods in some other languages) come to mind. But C is not OOP. The ISO C bindings in Fortran are not ISO C++ bindings. This is for a reason: C++ does not have a standard ABI like ISO C. Nor does C. Almost everything that most people believe about C is wrong, because C is not well-defined at any level, so there are many twisty little C languages, all different. Richard is perfectly correct that my point was OOP. C interoperability does not apply to any derived type with type-bound procedures, which include finalizers. Note that this ALSO forbids them from being passed as data, even if the other language never uses the OOP features of the type. Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
On Monday 24 August 2009 01:04:37 bartc wrote: That's a neat idea. But an even simpler scheme might be: .octal.100 .decimal.100 .hex.100 .binary.100 .trinary.100 until it gets to this anyway: .thiryseximal.100 Yeah right. So now I first have to type a string, which probably has a strict spelling, before a number. It is only marginally less stupid than this: 1.0 - Unary 11.0101 - Binary 111. 012012 - Trinary .01234567 - Octal 11.0123456789 - Decimal .0123456789abcdef - Hex Any parser that can count will immediately know what to do. I also tried to include an example of a literal with a base of a Googol but I ran out of both ink and symbols. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
On 24 Aug, 09:05, Erik Max Francis m...@alcyone.com wrote: ... Here's another suggested number literal format. First, keep the familar 0x and 0b of C and others and to add 0t for octal. (T is the third letter of octal as X is the third letter of hex.) The numbers above would be 0b1011, 0t7621, 0xc26b Second, allow an arbitrary number base by putting base and number in quotes after a zero as in 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b It's always a bit impressive how syntax suggestions get more and more involved and, if you'll forgive me for saying, ridiculous as the conversation continues. This is starting to get truly nutty. Why do you say that here? MRAB's suggestion is one of the clearest there has been. And it incorporates the other requirements: starts with a digit, allows an appropriate alphabet, has no issues with spacing digit groups, shows clearly where the number ends and could take an exponent suffix. James -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
James Harris wrote: On 24 Aug, 09:05, Erik Max Francis m...@alcyone.com wrote: Here's another suggested number literal format. First, keep the familar 0x and 0b of C and others and to add 0t for octal. (T is the third letter of octal as X is the third letter of hex.) The numbers above would be 0b1011, 0t7621, 0xc26b Second, allow an arbitrary number base by putting base and number in quotes after a zero as in 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b It's always a bit impressive how syntax suggestions get more and more involved and, if you'll forgive me for saying, ridiculous as the conversation continues. This is starting to get truly nutty. Why do you say that here? MRAB's suggestion is one of the clearest there has been. And it incorporates the other requirements: starts with a digit, allows an appropriate alphabet, has no issues with spacing digit groups, shows clearly where the number ends and could take an exponent suffix. In your opinion. Obviously not in others. Which is pretty obviously what I meant, so the rhetorical question is a bit weird here. There's a reason that languages designed by committee end up horrific nightmares. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis Do not seek death. Death will find you. -- Dag Hammarskjold -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
James Harris wrote:
On 24 Aug, 02:19, Max Erickson maxerick...@gmail.com wrote:
It can be assumed however that .9. isn't in binary?
That's a neat idea. But an even simpler scheme might be:
.octal.100
.decimal.100
.hex.100
.binary.100
.trinary.100
until it gets to this anyway:
.thiryseximal.100
At some point, abandoning direct support for literals and just
having a function that can handle different bases starts to make a
lot of sense to me:
int('100', 8)
64
int('100', 10)
100
int('100', 16)
256
int('100', 2)
4
int('100', 3)
9
int('100', 36)
1296
This is fine typed into the language directly but couldn't be entered
by the user or read-in from or written to a file.
Why would a programmer be expecting an arbitrary-radix numeric literal
typed in by a user or read from a file? If you're reading it from a
file, you've already got it in some satisfactory form, binary or
otherwise. If you're taking it as input from a user, they're not going
to know the Python syntax anyway, and would type in the radix and then
the literal (in the unlikely case this would ever be required, which is
still hard to imagine).
Either way, conversion is, as Max showed, one line of code. It's hard
to see the explicit need for truly arbitrary-radix literals in any
language -- and I'm the guy who's put quaternary literals in syntaxes
he's had to develop just for fun. Binary, octal, decimal, hexadecimal,
sure. Beyond that it's a solution begging for problems.
--
Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/
San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis
Do not seek death. Death will find you.
-- Dag Hammarskjold
--
http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
On Monday 24 August 2009 02:14:24 Esben von Buchwald wrote: Hello I'm using Python for S60 1.9.7 on my Nokia phone. I've made a program that gets input from an accelerometer sensor, and then calculates some stuff and displays the result. The sensor framework API does a callback to a function defined by me, every time new data is available. The problem is, that sometimes, the calculations may take longer than others, but if the callback is called before the first calculation is done, it seems like it's queuing up all the callbacks, and execute them sequentially, afterwards. What I need, is to simply ignore the callback, if the previous call hasn't finished it's operations before it's called again. I thought that this code would do the trick, but it obviously doesn't help at all, and i can't understand why... def doCallback(self): if self.process_busy==False: self.process_busy=True self.data_callback() self.process_busy=False see if there is an after method somewhere. What you have to do is to break the link between the callback and the processing. Your code above is all in the callback thread, despite the fact that you call another function to do the processing. So if you replace the data_callback() with an after call, it should work as you expect. HTH - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
Hendrik van Rooyen wrote: I also tried to include an example of a literal with a base of a Googol but I ran out of both ink and symbols. :-) ... or particles in the observable Universe, for that matter. -- Erik Max Francis m...@alcyone.com http://www.alcyone.com/max/ San Jose, CA, USA 37 18 N 121 57 W AIM/Y!M/Skype erikmaxfrancis Do not seek death. Death will find you. -- Dag Hammarskjold -- http://mail.python.org/mailman/listinfo/python-list
Re: basic thread question
Dennis Lee Bieber wlfr...@ix.netcom.com (DLB) wrote: DLB On Sun, 23 Aug 2009 22:14:17 -0700, John Nagle na...@animats.com DLB declaimed the following in gmane.comp.python.general: Multiple Python processes can run concurrently, but each process has a copy of the entire Python system, so the memory and cache footprints are far larger than for multiple threads. DLB One would think a smart enough OS would be able to share the DLB executable (interpreter) code, and only create a new stack/heap DLB allocation for data. Of course they do, but a significant portion of a Python system consists of imported modules and these are data as far as the OS is concerned. Only the modules written in C which are loaded as DLL's (shared libs) and of course the interpreter executable will be shared. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Items inheriting attributes from its container?
Kreso a écrit : I would like to create a list-like container class so that, additionally to usual list methods, I could attach attributes to the container instances. However, I would like it so that the items contained in the particular instance of container somehow 'inherit' those attributes i.e. cont = Container() cont.color = 'blue' cont.append(item) print item.color 'blue' This is named environmental aquisition (or simply aquisition) and is one of the base mechanisms in Zope 2. While an interesting idea, from experience, it can rapidly turn into a total maintainance nightmare if not used with care :-/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
On 24 Aug, 09:30, Erik Max Francis m...@alcyone.com wrote: James Harris wrote: On 24 Aug, 09:05, Erik Max Francis m...@alcyone.com wrote: Here's another suggested number literal format. First, keep the familar 0x and 0b of C and others and to add 0t for octal. (T is the third letter of octal as X is the third letter of hex.) The numbers above would be 0b1011, 0t7621, 0xc26b Second, allow an arbitrary number base by putting base and number in quotes after a zero as in 02:1011, 08:7621, 016:c26b Why not just put the base first, followed by the value in quotes: 21011, 87621, 16c26b It's always a bit impressive how syntax suggestions get more and more involved and, if you'll forgive me for saying, ridiculous as the conversation continues. This is starting to get truly nutty. Why do you say that here? MRAB's suggestion is one of the clearest there has been. And it incorporates the other requirements: starts with a digit, allows an appropriate alphabet, has no issues with spacing digit groups, shows clearly where the number ends and could take an exponent suffix. In your opinion. Obviously not in others. Which is pretty obviously what I meant, so the rhetorical question is a bit weird here. Don't get defensive Yes, in my opinion, if you like, but you can't say obviously not in others as no one else but you has commented on MRAB's suggestion. Also, when you say This is starting to get truly nutty would you accept that that's in your opinion? There's a reason that languages designed by committee end up horrific nightmares. True but I would suggest that mistakes are also made by designers who do not seek the opinions of others. There's a balance to be struck between a committee and an ivory tower. James -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie: list comprehension troubles..
mm a écrit :
Hi, I'm trying to replace this...
# this works but there must be a more pythonic way, right?
tlist = []
for obj in self.objs:
t = obj.intersect(ray)
if (t != None):
hint 1 : this is Python, you don't need parens around conditionals.
hint 2 : None is a singleton, so the usual idiom is to test for identity
('is') instead of equality ('==')
IOW, make this line:
if t is not None:
tlist.append((obj,t))
with a list comprehension- can it be done?
See other answers here. As far as I'm concerned, while being a great fan
of list comps etc, I'd stick with the plain old for loop here - much
more readable if nothing else.
--
http://mail.python.org/mailman/listinfo/python-list
Re: sgmllib.py
elsa wrote: Hi all, I'm new to both this forum and Python, and I've got a bit stuck trying to learn how to parse HTML here is my problem I'm using a textbook that uses sgmllib.py for all its examples. I'm aware that sgmllib is not in the current release, however I want to get it to work, as I have python 2.5, and the text book uses it. So, the first example says to type something like (to test the sgmllib): python sgmllib.py path/to/my/file.html example (1) this doesn't work for me. I think I have figured out the problem - the error says /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ Python.app/Contents/MacOS/Python: can't open file 'sgmllib.py': [Errno 2] No such file or directory the problem is that this path is wrong. My sgmllib.py is in: /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/sgmllib.py if I substitute this path for sgmllib.py in example (1), everything works fine. However, I don't want to do all that typing everytime I want to use sgmllib.py. So, I thought maybe the problem was with PYTHONPATH. I executed the following command: export PYTHONPATH=/System/Library/Frameworks/Python.framework/Versions/ 2.5/li/python2.5:$PYTHONPATH this seemed to work - no errors raised. However, when I retyped example (1), I got the same original error. Any assistance would be much appreciated. I'm working on max os x leopard. Thanks, elsa The path in the error message simply refers to the full path string to your Python interpreter, and reflects %0 in your shell. So I'd assume you've got a script called 'python' on your path, which spells out the full path name. That has nothing to do with your problem. Your problem, as you correctly surmised, is that Python's search path doesn't include the directory containing sgmllib.py Unfortunately, I haven't used Unix for over 15 years, so I don't recall the specifics of the shell 'export' operation. But you should be able to check the workings by inspecting the PYTHONPATH variable after trying to change it. There are a number of places that Python looks for a .py file. My choice, for a standard library like this that you don't plan to modify, would be to put it in the site-packages directory. You can see exactly where that is by doing the following in a simple script, and examining the output. import sys print sys.path -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and JMS
osky wrote: Hi all, I would like to make a JMS client connection from Python to Progress Sonic ESB (JMS message provider similar to WebSphere MQ or Active MQ). What would be the best way to implement that within Python 2.6 ? Any ideas ? I just recently learned about JCC - a Java-wrapper-compiler for python that is used by pylucene to embed (!) the JVM into python. This might be one viable option. I don't know much more, though. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: sgmllib.py
Dave Angel schrieb: elsa wrote: python sgmllib.py path/to/my/file.html example (1) The path in the error message simply refers to the full path string to your Python interpreter, and reflects %0 in your shell. So I'd assume you've got a script called 'python' on your path, which spells out the full path name. No, the problem is that sgmllib.py simply isn't in the directory where the Python interpreter is run. When you say python sgmllib.py you are instructing the Python interpreter to run the script sgmllib.py *in the current directory*. According to the original post, that's clearly not the intention of the OP. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: basic thread question
Dennis Lee Bieber wrote: On Sun, 23 Aug 2009 22:14:17 -0700, John Nagle na...@animats.com declaimed the following in gmane.comp.python.general: Multiple Python processes can run concurrently, but each process has a copy of the entire Python system, so the memory and cache footprints are far larger than for multiple threads. One would think a smart enough OS would be able to share the executable (interpreter) code, and only create a new stack/heap allocation for data. That's what fork is all about. (See os.fork(), available on most Unix/Linux) The two processes start out sharing their state, and only the things subsequently written need separate swap space. In Windows (and probably Unix/Linux), the swapspace taken by the executable and DLLs(shared libraries) is minimal. Each DLL may have a preferred location and if that part of the address space is available, it takes no swapspace at all, except for static variables, which are usually allocated together. I don't know whether the standard build of CPython (python.exe and the pyo libraries) uses such a linker option, but I'd bet they do. It also speeds startup time. On my system, a minimal python program uses about 50k of swapspace. But I'm sure that goes way up with lots of imports. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: elementtree
Stefan Behnel wrote: Hi, elsa wrote: I know how to turn HTML into an ElementTree object I don't. ;) ElementTree doesn't have an HTML parser, so what do you use for parsing? but I don't know how to then view the structure of this object. Is there a method or module that you can give an ElementTree object to, and it returns some kind of graphical or printed representation of the tree? Otherwise, if you can't see you're tree's structure, how do you know what is a sensible way of iterating over the tree to access the info you need? ElementTree has a tostring() method that returns a string. To get a pretty printed representation, you can use the indent() function from this recipe: http://effbot.org/zone/element-lib.htm#prettyprint Stefan Perhaps the OP was referring to XHTML, which should be eligible for ElementTree. But could you tell me whether ElementTree is at all tolerant of malformed XML? Most HTML and XHTML I encounter in the wild is so buggy it's amazing it all works at all. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: elementtree
Dave Angel wrote: Stefan Behnel wrote: elsa wrote: I know how to turn HTML into an ElementTree object I don't. ;) ElementTree doesn't have an HTML parser, so what do you use for parsing? Perhaps the OP was referring to XHTML, which should be eligible for ElementTree. But could you tell me whether ElementTree is at all tolerant of malformed XML? Most HTML and XHTML I encounter in the wild is so buggy it's amazing it all works at all. Well, if the XHTML is buggy, it's not XHTML at all. XHTML is XML, which is defined as being well-formed. Any XHTML parser is required to reject malformed input, and the expat parser that ElementTree uses is (luckily) no exception. Regarding malformed HTML: that's not directly supported by ElementTree, hence my question. You can use ElementSoup to interface with BeautifulSoup, or elementtidy to interface with tidy, or html5lib with ElementTree as backend, or you can use lxml instead, which handles malformed HTML (and is all fast and shiny and ... ;). Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and JMS
osky wrote: I would like to make a JMS client connection from Python to Progress Sonic ESB (JMS message provider similar to WebSphere MQ or Active MQ). Never needed this, but Google gives me this as first hit http://hjb.python-hosting.com/ and this c.l.py thread reference a little further down: http://mail.python.org/pipermail/python-list/2006-July/567400.html Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)
On Aug 23, 7:45 pm, Ben Finney ben+pyt...@benfinney.id.au wrote: greg g...@cosc.canterbury.ac.nz writes: J. Cliff Dyer wrote: What happens if you use a literal like 0x10f 304? To me the obvious thing to do is concatenate them textually and then treat the whole thing as a single numeric literal. Anything else wouldn't be sane, IMO. Yet, as was pointed out, that behaviour would be inconsistent with the concatenation of string literals:: abc r'def' ughi 'jkl' u'abcdefghijkl' Well my take on it is that this would not be the same as string concatenation, the series of digits would be parsed as a single token with spaces automatically removed. That does make a difference to the users (it's not just under the covers). For instance, string concatenation works across lines: abc def but if the numbers were parsed as a single token it wouldn't necessarily be allowed, and would be unwise, so this is out: 100 200 You might want to also enforce rules such as only a single space can separate digits, no tabs, not multiple spaces, so this 100 200 would also be right out. You might even want to enforce that spaces be at regular intervals. I don't think it would matter too much that digit separation can superficially resemble string concatenation if you don't break the strings across lines, it's not too difficult to explain what the difference is, and there's really not much chance anyone would be confused by their meanings. Having said all that, I would favor _ as a digit separator in Python any day of the week, and I don't think it's all that important to have one at all. HOWEVER, I once proposed that if I were designing a new language I'd consider allowing spaces in identifiers. (That didn't stop people from arguing why it would be confusing in Python, but never mind that.) If spaces were allowed in identifiers, then I'd be also in favor of spaces in numeric literals. So, different representations of literals are parsed as separate literals, then concatenated. To have the behaviour you describe, the case needs to be made separately that digit concatenation should not be consistent with the established string literal parsing behaviour. Well, one doesn't really *need* to make that case, they just might not care about consistency. But if they did I think Erik's case is a good one: very little chance of confusion because there's really only one reasonable interpretation. The point of consistency is to help understand things by analogy, but if analogy doesn't help understanding--and it wouldn't in this case--there's no point. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: can python make web applications?
Deep_Feelings wrote: can python make powerfull database web applications that can replace desktop database applications? e.g: entrprise accounting programs,enterprise human resource management programs ...etc As the other replies already mentioned that these already exists, I would like to add that with Pyjamas you can write 'webgui' programs relatively easily: http://pyjs.org/ -- MPH http://blog.dcuktec.com 'If consumed, best digested with added seasoning to own preference.' -- http://mail.python.org/mailman/listinfo/python-list
Re: basic thread question
Dave Angel da...@ieee.org (DA) wrote: DA Dennis Lee Bieber wrote: On Sun, 23 Aug 2009 22:14:17 -0700, John Nagle na...@animats.com declaimed the following in gmane.comp.python.general: Multiple Python processes can run concurrently, but each process has a copy of the entire Python system, so the memory and cache footprints are far larger than for multiple threads. One would think a smart enough OS would be able to share the executable (interpreter) code, and only create a new stack/heap allocation for data. DA That's what fork is all about. (See os.fork(), available on most DA Unix/Linux) The two processes start out sharing their state, and only the DA things subsequently written need separate swap space. But os.fork() is not available on Windows. And I guess refcounts et al. will soon destroy the sharing. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: elementtree
On Aug 24, 12:13 am, Stefan Behnel stefan...@behnel.de wrote: Hi, elsa wrote: I know how to turn HTML into an ElementTree object I don't. ;) ElementTree doesn't have an HTML parser, so what do you use for parsing? The OP could be feeding the HTML through tidy, or it could be XHTML. but I don't know how to then view the structure of this object. Is there a method or module that you can give an ElementTree object to, and it returns some kind of graphical or printed representation of the tree? Otherwise, if you can't see you're tree's structure, how do you know what is a sensible way of iterating over the tree to access the info you need? ElementTree has a tostring() method that returns a string. To get a pretty printed representation, you can use the indent() function from this recipe: http://effbot.org/zone/element-lib.htm#prettyprint Another possibility is to write out the ElementTree object as XML with an .xml extension, and view it in a modern web browser (Firefox, IE, others maybe) that can show XML structure. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: your favorite debugging tool?
Esmail wrote: Hi all, What is your favorite tool to help you debug your code? I've been getting along with 'print' statements but that is getting old and somewhat cumbersome. I'm primarily interested in utilities for Linux (but if you have recommendations for Windows, I'll take them too :) I use emacs as my primary development environment, FWIW. Someone mentioned winpdb .. anyone have experience/comments on this? Others? Thanks, Esmail I execute the program within IPython. run test.py I usually write a CTRL+C except clause that will spawn an Ipython shell so I can inspect the namespace at that time. I'm also using the ipdb to spawn the debugger. import IPython ipdb = IPython.Debugger.Pdb(color_scheme='Linux') ipdb.set_trace() it spawns the IPython debugger, allowing step by step execution, code inspection, changing the namespace. You get all the IPython benefits (espacially the TAB completion, history ...) I used to proceed with print statements, but they are some situations where it won't just make it. Sometimes the code is so complex you can't anticipate all the required prints to catch a bug. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie: list comprehension troubles..
On 24 Ago, 01:27, mm matta...@gmail.com wrote: Hi, I'm trying to replace this... # this works but there must be a more pythonic way, right? tlist = [] for obj in self.objs: t = obj.intersect(ray) if (t != None): tlist.append((obj,t)) with a list comprehension- can it be done? What I need to do is iterate over a list of graphics primitives and call their intersect method. If the returned t value is not None then I want to store the obj refernence and its t value in a list of tuples for further processing. I've tried stuff like ... tlist = [(obj,t) for obj,t in (self.objs, obj.intersect(ray)) if (t != None)] tlist = [(obj,t) for obj in self.objs for t in obj.intersect (ray) ] print ,len(tlist), tlist but they don't work. Any help greatly appreciated. matt What about this: def intersections(objlist, ray): for obj in objlist: yield obj, obj.intersect(ray) tlist = [(obj, t) in intersections(self.objs, ray) if t != None ] It is still quite readable but a bit more compact. More efficient? Maybe. Ciao FB -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python what I need?
Peter Otten wrote: newbie wrote: I'm interested in developing computer based, interactive programs for students in a special school who have an aversion to pen and paper. I've searched the net to find ready made software that will meet my needs but it is either written to a level much higher than these students can cope with or priced beyond our school budget. I came across a blog of someone singing the praises of Python. My question is therefore aimed at those that know what they are talking about (ie users in this group). Is Python the language I need to learn to develop these programs? From the distance it looks like these children need a good teacher rather than a bad (or just starting) programmer. Wow, that is rude. Let's keep this list friendly, won't we ? JM -- http://mail.python.org/mailman/listinfo/python-list
Python for professsional Windows GUI apps?
Hello I was wondering if some people in this ng use Python and some GUI toolkit (PyWin32, wxWidgets, QT, etc.) to build professional applications, and if yes, what it's like, the pros and cons, etc. I'm especially concerned about the lack of controls, the lack of updates (lots of controls in wxWidgets are 1.0 deadware), and problems linked to how to update users' PC remotely when I build a new version using eg. Py2exe. I need controls for business apps like access to databases, good data grid, printing reports (with or without barcodes), etc. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
On Aug 23, 9:42 pm, James Harris james.harri...@googlemail.com
wrote:
The numbers above would be
0b1011, 0t7621, 0xc26b
Algol68 has the type BITS, that is converted to INT with the ABS
operator.
The numbers above would be:
2r1011, 8r7621, 16rc26b
r is for radix: http://en.wikipedia.org/wiki/Radix
The standard supports 2r, 4r, 8r 16r only.
The standard supports LONG BITS, LONG LONG BITS etc, but does not
include UNSIGNED.
Compare gcc's:
bash$ cat num_lit.c
#include stdio.h
main(){
printf(%d %d %d %d\n,0x,0,,0b);
}
bash$ ./num_lit
65535 4095 15
With Algol68's: https://sourceforge.net/projects/algol68/
bash$ cat num_lit.a68
main:(
printf(($g$,ABS 16r,ABS 8r,,ABS 2r,$l$))
)
bash$ algol68g ./num_lit.a68
+65535 +4095 ++15
Enjoy
N
--
http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pyxser-1.2r --- Python-Object to XML serialization module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Stefan Behnel stefan...@behnel.de on Monday 24 August 2009 03:16 wrote in comp.lang.python: Daniel Molina Wegener wrote: * Added encoded serialization of Unicode strings by using the user defined encoding as is passed to the serialization functions as enc parameter As you see, now Unicode strings are serialized as encoded byte string by using the encoding that the user pass as enc parameter to the serialization function. This means that Unicode strings are serialized in a human readable form, regarding a better interoperability with other platforms. You mean, the whole XML document is serialised with that encoding, right? Well, if you call pyxser with: xmldocstr = pyxser.serialize(obj = someobj, enc = utf-8, depth = 3) pyxser will serialize someobj into XML document (xmldocstr) using the utf-8 encoding with a depth of three levels in the object tree. If the object tree has unicode objects, those objects will be encoded into utf-8 too. And yes, it means that unicode objects are encoded into the encoding that the XML document encoding has, and as you say, the whole XML document has one encoding. There is no mixing of byte encoded strings with different encodings in the outout document. When the object is restored, by using pyxser.unserialize: pyobj = pyxser.unserialize(obj = xmldocstr, enc = utf-8) Unicode objects are restored as unicode objects, by decoding the utf-8 strings on the document. Byte string objects are restored as byte string objects. And the other types of objects are restored as their original type. Another issue is the fact that if you have mixed some encodings in byte strings objects in your object tree, such as iso-8859-1 and utf-8, and you try to serialize that object, pyxser will output to stdout the serialization errors by trying to handle those mixed encodings which are not regarding the document encoding. There are some restrictions, if the class of the object is declared on the __main__ module, pyxser can not handle it... This is a bug but I'm expecting to solve it in near future. A depth level of zero (depth = 0) will serialize the complete object tree with a fixed limit of 50 levels, pyxser can handle cross referenced objects and circular references. Sorry if don't answer more questions until we reach the night --- here in Chile --- the night, I must go to my job right now, and there I don't have access to usenet or google groups. Stefan Best regards, - -- .O. | Daniel Molina Wegener | FreeBSD Linux ..O | dmw [at] coder [dot] cl | Open Standards OOO | http://coder.cl/| FOSS Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) iQIcBAEBCgAGBQJKkoe8AAoJEHxqfq6Y4O5Na3gP/R2BTdmZpUPn8PrsPhMPaKLf dmAUAyQ2Ukj1461eiYGAa1zly5bz/rKV8UJXq6zp0cFIIimBHWCYkFlbtCIdCl5k qclT6y3d5N9/VggZi92ICK4xFe4CCOzLeJCaYkBcVgvbpks9oRJwlS9LrTZAMdOw WdnaUdNadj2lRcXHwqV7uk5D5CwBdNujgpp+7vJXZbEnPD9diXEbPDUeHznn7cEa 2zwtGK3+kyPEkLpS5F+zE2iPUQK+HOw4r1s7kow9mSUU0n3p+gJj9J0NtBKDa92d hXGQ6M52jtoyZlv0bWJl8R1YQLnezvNDMu9F/NqB79wmLhJqIZm3Py57rtIaD96J 2a7BN/LcM8fhs+dgTlt6538EKoM5Jj+gv+birSIUwxKFChRpGsj7229cmTzjQc7q mcXlXPa6aknOWxVlhPSpGDSbZ+HpqGH7s9cOHAAuUt+WRcaafeRpy7K3BXJ+AaJ6 Rz69j2nsOgqGufLlBiDf9aRIrX3A47eE0DGZLwVuolValgmBhgedn43T4XH85wrE BfXERoIrIlMS8hmcxs6Ao6TayLHmaZjSVaLmP+qsN9qHCs8hCbQBNBfaU1vrsM2u nppo/+yGepLGZSW35yA8ha7m3RAX1HTyHcKrPcrbTmK5IVjVWjHRbTz4XcqNt1v6 5prWXP8WUIfIr4E2112J =JjU5 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Temat:,Re: IOError: [Errno 22] invalid mode ('wb') or filename: in windows xp while making tarfile
John Machin wrote:
Erik Max Francis max at alcyone.com writes:
I also suspect the pipe symbol. I don't know if it's an invalid
character to Windows, but it's certainly a bad idea. The '|' character
means something special to the shell.
The pipe character is not a valid character in a Windows file.
Despite the OP's message wrapping the filename in pipes,
there are no pipes in the filename in the traceback to
which he posted a link. Wrapping the filename in pipes
and the cryptic reference to the '|\U' literal fault
appear to be side-issue bogglements.
open('boggle|txt', 'wb')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 22] invalid mode ('wb') or filename: 'boggle|txt'
open('|boggle.txt|', 'wb')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 22] invalid mode ('wb') or filename: '|boggle.txt|'
Sorry, but i don't know where those pipes came from : P
The proper path is C:\\Users\\Ryniek's
WinSe7en\\MyNewGGBackup(2009-08-23 14:59:02).tar.bz2
and that string literal is \U, without any pipes :)
The truth is that script works on linux (ubuntu) but not on windows
(neither Win7 nor WinXP).
Maybe it's good idea to use raw string for specifing those paths?
As i mentioned later, some python users had the same problem with this
IOError ( like here: http://www.daniweb.com/forums/thread174552.html or
here:
http://groups.google.com/group/sympy/browse_thread/thread/c42aca3eb532928c
).
--
http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] pyxser-1.2r --- Python-Object to XML serialization module
Daniel Molina Wegener wrote: unicode objects are encoded into the encoding that the XML document encoding has, and as you say, the whole XML document has one encoding. There is no mixing of byte encoded strings with different encodings in the outout document. Ok, that's what I hoped anyway. It just wasn't clear from your description. When the object is restored, by using pyxser.unserialize: pyobj = pyxser.unserialize(obj = xmldocstr, enc = utf-8) But this is XML, right? What do you need to pass the encoding for at this point? Another issue is the fact that if you have mixed some encodings in byte strings objects in your object tree, such as iso-8859-1 and utf-8, and you try to serialize that object, pyxser will output to stdout the serialization errors by trying to handle those mixed encodings which are not regarding the document encoding. There shouldn't be any serialisation errors (unless you try to recode byte strings on the way out, which is a no-no for arbitrary user input). All you have to do is properly escape the byte string so that it passes the XML encoding step. One trick to do that is to decode the byte string as ISO-8859-1 and serialise the result as a normal Unicode string. Then you can re-encode the unicode string on input back to ISO-8859-1. I choose ISO-8859-1 here because it has the well-defined side-effect of mapping byte values directly to Unicode characters with an identical code point value. So you do not risk any failures or data loss. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
James Harris wrote:
On 24 Aug, 02:19, Max Erickson maxerick...@gmail.com wrote:
[ ... ]
int('100', 3)
9
int('100', 36)
1296
This is fine typed into the language directly but couldn't be entered
by the user or read-in from or written to a file.
That's rather beside the point. Literals don't essentially come from files
or user input. Essentially literals are a subset of expressions, just like
function calls are, and they have to be evaluated by Python to yield a
value. I'm not averse to 32'rst', but we already have
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type help, copyright, credits or license for more information.
int ('rst', 32)
28573
Mel.
James
--
http://mail.python.org/mailman/listinfo/python-list
Re: conditional for-statement
seb a écrit : Hi, i was wondering if there is a syntax alike: for i in range(10) if i 5: print i equivalent to for i in (for i in range(10) if i5): print i what about : for i in range(6, 10): print i g More seriously: for i in range(10): if i 5: print i -- http://mail.python.org/mailman/listinfo/python-list
P3 weird sys.stdout.write()
I've stumbled upon the following in Python 3: Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) [GCC 4.3.3] on linux2 Type help, copyright, credits or license for more information. import sys sys.stdout.write() 0 sys.stdout.write(something) something9 write() is appending the length of the string to it's output. That's not how it worked in 2.6. What's the reason for this? Is this intended? I couldn't find a bug report for this. -- http://mail.python.org/mailman/listinfo/python-list
Re: P3 weird sys.stdout.write()
Jerzy Jalocha N wrote: I've stumbled upon the following in Python 3: Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) [GCC 4.3.3] on linux2 Type help, copyright, credits or license for more information. import sys sys.stdout.write() 0 sys.stdout.write(something) something9 write() is appending the length of the string to it's output. That's not how it worked in 2.6. What's the reason for this? Is this intended? I couldn't find a bug report for this. Write returns the number of bytes written. And because you don't capture that output into a variable, the interpreter puts it out as well. If you do n = sys.stdout.write() instead, you won't see the behavior. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: P3 weird sys.stdout.write()
On Aug 24, 10:13 am, Jerzy Jalocha N jjalo...@gmail.com wrote: I've stumbled upon the following in Python 3: Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) [GCC 4.3.3] on linux2 Type help, copyright, credits or license for more information. import sys sys.stdout.write() 0 sys.stdout.write(something) something9 write() is appending the length of the string to it's output. Not quite right, see below. That's not how it worked in 2.6. What's the reason for this? Is this intended? I couldn't find a bug report for this. I don't know what the reason for the change, but try the following: out = sys.stdout.write(test\n) test out 5 What you are seeing is the concatenation of the return value of the write() method with its output. André -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python what I need?
Jean-Michel Pichavant wrote: From the distance it looks like these children need a good teacher rather than a bad (or just starting) programmer. Wow, that is rude. Let's keep this list friendly, won't we ? I may have been too blunt, and if my message has come across as an insult I apologize for that. Let me try again: If you are trying to teach children that are unwilling to use pen and paper putting them in front of a computer doesn't help you and them one bit. As a starting programmer you'll have to spend a lot of time in front of your computer that may be better spent with your students. Better? Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Sun, Aug 23, 2009 at 06:13:31AM +, Steven D'Aprano wrote: On Sat, 22 Aug 2009 22:19:01 -0500, Derek Martin wrote: On Sat, Aug 22, 2009 at 02:55:51AM +, Steven D'Aprano wrote: And the great thing is that now you get to teach yourself to stop writing octal numbers implicitly and be write them explicitly with a leading 0o instead :) Sorry, I don't write them implicitly. A leading zero explicitly states that the numeric constant that follows is octal. That is incorrect. No, it simply isn't. It is a stated specification in most popular programming languages that an integer preceded by a leading zero is an octal number. That makes it explicit, when used by a programmer to write an octal literal. By definition. End of discussion. (Explicitness isn't a binary state Of course it is. Something can be either stated or implied... there are no shades in between. Perhaps you mean obvious and intutitive where you are using the word explicit above (and that would be a matter of subjective opinion). The leading zero, however, is undoubtedly explicit. It is an explicitly written token which, in that context, has the meaning that the digits that follow are an octal number. One simply needs to be aware of that aspect of the specification of the programming language, and one will clearly know that it is octal. My point in mentioning that many other programming languages, by the way, was NOT to suggest that, See, look here, all these other folks do it that way too, so it must be right. It was to refute the notion that the leading zero as octal was in some way unusual. It is, in fact, ubiquitous in computing, taught roughly in the first week of any beginning computing course using nearly any modern popular programming language, and discussed within the first full page of text in the section on numerical literals in _Learning Python_ (and undoubtedly many other books on Python). It may be a surprise the first time you run into it, but you typically won't forget that detail after you run into it the first time. However, octal numbers are defined implicitly: 012 is a legal base 10 number, or base 3, or base 9, or base 16. Not in any programming language I use today, it's not. In all of those, 012 is an octal integer literal, per the language spec. There's nothing about a leading zero that says base 8 apart from familiarity. That is simply untrue. What says base 8 about a leading zero is the formal specification of the programming language. The only way using octal could be implicit in the code is if you wrote something like: x = 12 in your code, and then had to pass a flag to your compiler or interpreter to tell it that you meant to use octal integer literals instead of decimal ones. That, of course, would be insane. But specifying a leading zero to represent an octal number zero is very much explicit, by definition. We can see the difference between leading 0x and leading 0 if you repeat it: repeating an explicit 0x, as in 0x0xFF, is a syntax error, while repeating an implicit 0 silently does nothing different: No, we can't. Just as you can type 0012, you can also type 0x0FF. It's not different AT ALL. In both cases, the marker designated by the programming language as the base indicator can be followed by an arbitrary number of zeros which do not impact the magnitude of the integer so specified. Identical behavior. The key is simply to understand that the first 0 is not a digit -- it's a syntactic marker, an operator if you will (though Python may not technically think of it that way). The definition of '0' is overloaded, just as other language tokens often are. This, too, is hardly unusual. There are a bunch of languages, pretty much all heavily influenced by C, which treat integer literals with leading 0s as oct: C++, Javascript, Python 2.x, Ruby, Perl, Java. As so often is the case, C's design mistakes become common practice. Sigh. That it is a design mistake is a matter of opinion. Obviously the people who designed it didn't think it was a mistake, and neither do I. If you search the web for this topic (I did), you will find no shortage of people who think the recent movement to irradicate the leading zero to be frustrating, annoying, and/or stupid. And by the way, this representation predates C. It was at least present in B. FORTRAN 90 uses a leading O (uppercase o) for octal That clearly IS a design mistake, because O is virtually indistinguishable from 0, especially considering varying fonts and people's variable eye sight quality. Algol uses an explicit base: 8r12 to indicate octal 10. This is far better than 0o01. I maintain that 0o1 is only marginally better than O01 (from your fortran example) or 0O1, allowed by Python. The string 8r12 has the nicety that it can easily be used to represent integers of any radix in a consistent fashion. But I maintain that the leading zero is just fine, and changing it after 20 years
Re: P3 weird sys.stdout.write()
import sys
n = sys.stdout.write('something')
something n
9
Yes, that works as expected, now, similar to 2.6.
Thank you both, Diez and André!
-Jerzy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
On 24 Aug, 10:24, n...@cam.ac.uk wrote: In article 5134d9f1-0e23-4e05-a817-bf0cc9e85...@w6g2000yqw.googlegroups.com, sturlamolden sturlamol...@yahoo.no wrote: On 24 Aug, 02:26, nos...@see.signature (Richard Maine) wrote: You missed the word OOP, which seemed like the whole point. Not that the particular word is used in the Fortran standard, but it isn't hard to guess that he means a derived type that uses some of the OOP features. Inheritance, polymorphism, and type-bound procedure (aka methods in some other languages) come to mind. But C is not OOP. The ISO C bindings in Fortran are not ISO C++ bindings. This is for a reason: C++ does not have a standard ABI like ISO C. Nor does C. Almost everything that most people believe about C is wrong, because C is not well-defined at any level, so there are many twisty little C languages, all different. Richard is perfectly correct that my point was OOP. C interoperability does not apply to any derived type with type-bound procedures, which include finalizers. Note that this ALSO forbids them from being passed as data, even if the other language never uses the OOP features of the type. You also made this claim regarding Fortran's C interop with strings: No, I mean things like 'Kilroy was here'. Currently, Fortran's C interoperability supports only strings of length 1, and you have to kludge them up as arrays. That doesn't work very well, especially for things like function results. This obviosuly proves you wrong: subroutine foobar(fstr) ! this is the Fortran function we want to call from C ! it takes a variable length string as argument and ! print its length character(*) :: fstr write (*,*) len(fstr) end subroutine subroutine wrap_foobar(cstr) bind(c, name='foobar') ! a wrapper for foobar which we expose to C use, intrinsic :: iso_c_binding interface function strlen(cstr) bind(c, name='strlen') use, intrinsic :: iso_c_binding integer(c_int) :: strlen type(c_ptr), value :: cstr end function strlen end interface type(c_ptr), value :: cstr character(2147483647), pointer :: p_fstr integer :: n n = strlen(cstr) call c_f_pointer(cstr, p_fstr) call foobar(p_fstr(1:n)) end subroutine I am not saying you are wrong regarding OOP derives types, but I'm not taking your word for it. However, I am not wasting my time on Fortran 2003 OOP now, as it lacks compiler support. So I'll leave your claim uncontested. By the way, I am more than happy using Python for OOP and Fortran 95 for speed. As for numerical computing, I'd rather see better support for array and matrix types in Cython than OOP in Fortran. Regards, Sturla Molden -- http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
sturlamolden wrote: On 24 Aug, 02:57, nos...@see.signature (Richard Maine) wrote: Does anyone use OOP in Fortran anyway? I do - currently for learning (and eventually training) purposes so I don't distribute any of the code. But, the fact that... Fortran 2003 compilers are not ubiquitous. ...is a major sticking point towards a fully engaged f2003 programme (not program :o) Fortran compilers tend to support a subset for Fortran 2003, usually ISO C bindings but not OOP. Yeah, I'm starting to find it a little bit tiresome that vendors now appear convinced that implementing some of the more note-worthy features of f2008 is of greater importance that wrapping up the f2003 implementations. But, it's their business for their customers so c'est la vie I guess If I ignore parameterised derived types then my f2003 platform/compiler of choice, IBM AIX xlf2003, works well for OOP stuff. cheers, paulv -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Sun, Aug 23, 2009 at 01:13:32PM +, Matthew Woodcraft wrote: Dennis Lee Bieber wlfr...@ix.netcom.com writes: About the only place one commonly sees leading zeros on decimal numbers, in my experience, is zero-filled COBOL data decks (and since classic COBOL stores in BCD anyway... binary (usage is computational/comp-1) was a later add-on to the data specification model as I recall...) A more common case is dates. I suppose this is true, but I can't remember the last time I hard-coded a date in a program, or worked on someone else's code with hard-coded dates. I'm fairly certain I've never done it, and if I had, I obviously would not have used leading zeros. I think hard-coding dates is more uncommon than using octal. ;-) [It unquestionably is, for me personally.] I tend to also discount this example, because when we write dates with leading zeros, usually it's in some variation of the form 08/09/2009, which, containing slashes, is a string, not a number, and can not be used as a date literal in any language I know. We do it for reasons of format, which again implies that it has more the characteristics of a string than of a number. To use such a thing in any programming language I can think of would require translation from a string. I've seen people trip over this writing things like xxx = [ date(2009, 10, 12), date(2009, 12, 26), date(2010, 02, 09), ] I've never seen anyone do this (no doubt because it would be an error), but as I said, I don't think I've ever seen hard-coded dates in any programs I've worked on. I've never encountered anyone having problems with octals who was not a total noob at programming. The changing of this syntax seems like much ado about nothing to me, and as such is annoying, consider that I use it very often. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpJdmZ75Hu7Q.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Reference question
josef a écrit : (snip) I think that something like a = MyClass0(name = 'a', ...) is a bit redundant. Are definitions treated the same way? How would one print or pass function names? In Python, classes and functions are objects too. The class and def statements are mostly syntactic sugar that *both* instanciate the (resp) class of function objet *and* bind it in the local namespace. FWIW, while class and function objects do (usually) have a __name__ attribute (usually the one used in the class or def statement...), this doesn't mean they're still bound to this name, nor that they are not bound to any other name: br...@bruno:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type help, copyright, credits or license for more information. pythonrc start pythonrc done def foo(): print function foo ??? ... foo function foo at 0x8563e9c foo.__name__ 'foo' bar = foo bar.__name__ 'foo' bar() function foo ??? import sys foo = lambda: sys.stdout.write(pick a boo !\n) foo.__name__ 'lambda' foo() pick a boo ! funcs = [foo, bar] del foo funcs[0] function lambda at 0x8563ed4 funcs[0]() pick a boo ! funcs[1] function foo at 0x8563e9c funcs[1]() function foo ??? funcs[1].__name__ 'foo' del bar funcs[1]() function foo ??? funcs[1].__name__ = yadda funcs[1]() function foo ??? funcs[1].__name__ 'yadda' HTH -- http://mail.python.org/mailman/listinfo/python-list
IOError: [Errno 22] invalid mode ('wb') or filename: in windows xp while making tarfile
John Machin wrote:
Erik Max Francis max at alcyone.com writes:
I also suspect the pipe symbol. I don't know if it's an invalid
character to Windows, but it's certainly a bad idea. The '|' character
means something special to the shell.
The pipe character is not a valid character in a Windows file.
Despite the OP's message wrapping the filename in pipes,
there are no pipes in the filename in the traceback to
which he posted a link. Wrapping the filename in pipes
and the cryptic reference to the '|\U' literal fault
appear to be side-issue bogglements.
open('boggle|txt', 'wb')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 22] invalid mode ('wb') or filename: 'boggle|txt'
open('|boggle.txt|', 'wb')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 22] invalid mode ('wb') or filename: '|boggle.txt|'
Sorry, but i don't know where those pipes came from : P
The proper path is C:\\Users\\Ryniek's
WinSe7en\\MyNewGGBackup(2009-08-23 14:59:02).tar.bz2
and that string literal is \U, without any pipes :)
The truth is that script works on linux (ubuntu) but not on windows
(neither Win7 nor WinXP).
Maybe it's good idea to use raw string for specifing those paths?
As i mentioned later, some python users had the same problem with this
IOError ( like here: http://www.daniweb.com/forums/thread174552.html or
here:
http://groups.google.com/group/sympy/browse_thread/thread/c42aca3eb53...
http://groups.google.com/group/sympy/browse_thread/thread/c42aca3eb532928c
).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Mon, Aug 24, 2009 at 08:56:48AM -0500, Derek Martin wrote: On Sun, Aug 23, 2009 at 01:13:32PM +, Matthew Woodcraft wrote: A more common case is dates. I suppose this is true, but [...] I tend to also discount this example, because when we write dates with leading zeros, usually it's in some variation of the form 08/09/2009, which, containing slashes, is a string, not a number In fact, now that I think of it... I just looked at some old school papers I had tucked away in a family album. I'm quite sure that in grammar school, I was tought to use a date format of 8/9/79, without leading zeros. I can't prove it, of course, but feel fairly sure that the prevalence of leading zeros in dates occured only in the mid to late 1980's as computers became more prevalent in our society (no doubt because thousands of cobol programmers writing business apps needed a way to convert dates as strings to numbers that was easy and fit in small memory). Assuming I'm right about that, then the use of a leading 0 to represent octal actually predates the prevalence of using 0 in dates by almost two decades. And while using leading zeros in other contexts is familiar to me, I would certainly not consider it common by any means. Thus I think it's fair to say that when this syntax was selected, it was a rather good choice. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgphWLB493GWi.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying To Catch Invalid User Input
That's nice. Thanks!
V
On Sun, Aug 23, 2009 at 5:02 PM, Dennis Lee Bieber wlfr...@ix.netcom.comwrote:
On Sun, 23 Aug 2009 10:04:57 -0500, Victor Subervi
victorsube...@gmail.com declaimed the following in
gmane.comp.python.general:
Hi;
I have the following:
style = raw_input('What style is this? (1 = short, 2 = long): ')
flag = 0
while flag == 0:
if (style != 1) or (style != 2):
style = raw_input('There was a mistake. What style is this? (1 =
short,
2 = long): ')
else:
flag = 1
Ugh... Unless you are using an archaic version of Python, the
language has support for booleans...
done = False
while not done:
...
done = True
You fail to convert the character input from raw_input into an
integer for comparison... Oh, and you say the input is wrong if it is
NOT 1 OR NOT 2... 1 is not 2, and 2 is not 1, so... even if you did
convert to an integer, it would be rejected.
Consider:
-=-=-=-=-=-=-=-
while True:
charin = raw_input(What style is this? (1: short, 2: long): )
try:
style = int(charin)
except: #I know, should not use naked except clause
print (The input '%s' is not a valid integer value; try again
% charin)
else:
if style in (1, 2): break
print (The input value '%s' is not in the valid range; try
again
% style)
-=-=-=-=-=-=-=-
{Watch out for line wraps}
Works in Python 2.5
E:\UserData\Dennis Lee Bieber\My Documentspython Script1.py
What style is this? (1: short, 2: long): ab1
The input 'ab1' is not a valid integer value; try again
What style is this? (1: short, 2: long): 1a
The input '1a' is not a valid integer value; try again
What style is this? (1: short, 2: long): 12
The input value '12' is not in the valid range; try again
What style is this? (1: short, 2: long): 2
E:\UserData\Dennis Lee Bieber\My Documents
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: basic thread question
On 18 Aug, 22:10, Derek Martin c...@pizzashack.org wrote: I have some simple threaded code... If I run this with an arg of 1 (start one thread), it pegs one cpu, as I would expect. If I run it with an arg of 2 (start 2 threads), it uses both CPUs, but utilization of both is less than 50%. Can anyone explain why? Access to the Python interpreter is serialized by the global interpreter lock (GIL). You created two threads the OS could schedule, but they competed for access to the Python interpreter. If you want to utilize more than one CPU, you have to release the GIL or use multiple processes instead (os.fork since you are using Linux). This is how the GIL can be released: * Many functions in Python's standard library, particularly all blocking i/o functions, release the GIL. This covers the by far most common use of threads. * In C or C++ extensions, use the macros Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. * With ctypes, functions called from a cdll release the GIL, whereas functions called from a pydll do not. * In f2py, declaring a Fortran function threadsafe in a .pyf file or cf2py comment releases the GIL. * In Cython or Pyrex extensions, use a with nogil: block to execute code without holding the GIL. Sturla Molden -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python what I need?
On Mon, Aug 24, 2009 at 9:32 AM, Peter Otten__pete...@web.de wrote: If you are trying to teach children that are unwilling to use pen and paper putting them in front of a computer doesn't help you and them one bit. As a starting programmer you'll have to spend a lot of time in front of your computer that may be better spent with your students. I don't think you were rude at all, but I like your second answer even more than the first. Nevertheless, I'd still like to hear from the Original Poster. What are you trying to accomplish? What software have you found that is too expensive? Given more information, somebody might be able to help. -- http://mail.python.org/mailman/listinfo/python-list
Re: basic thread question
On 24 Aug, 13:21, Piet van Oostrum p...@cs.uu.nl wrote: But os.fork() is not available on Windows. And I guess refcounts et al. will soon destroy the sharing. Well, there is os.fork in Cygwin and SUA (SUA is the Unix subsytem in Windows Vista Professional). Cygwin's fork is a bit sluggish. Multiprocessing works on Windows and Linux alike. Apart from that, how are you going to use threads? The GIL will not be a problem if it can be released. Mostly, the GIL is a hypothetical problem. It is only a problem for compute-bound code written in pure Python. But very few use Python for that. However, if you do and can afford the 200x speed penalty from using Python (instead of C, C++, Fortran, Cython), you can just as well accept that only one CPU is used. Sturla Molden -- http://mail.python.org/mailman/listinfo/python-list
Reading binary files
I need to read a binary file. When I open it up in a text editor it is just junk. Does Python have a class to help with this? -- http://mail.python.org/mailman/listinfo/python-list
Re: Temat:,Re: IOError: [Errno 22] invalid mode ('wb') or filename: in windows xp while making tarfile
Ryniek90 wrote:
div class=moz-text-flowed style=font-family: -moz-fixed
John Machin wrote:
Erik Max Francis max at alcyone.com writes:
I also suspect the pipe symbol. I don't know if it's an invalid
character to Windows, but it's certainly a bad idea. The '|'
character means something special to the shell.
The pipe character is not a valid character in a Windows file.
Despite the OP's message wrapping the filename in pipes,
there are no pipes in the filename in the traceback to
which he posted a link. Wrapping the filename in pipes
and the cryptic reference to the '|\U' literal fault
appear to be side-issue bogglements.
open('boggle|txt', 'wb')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 22] invalid mode ('wb') or filename: 'boggle|txt'
open('|boggle.txt|', 'wb')
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 22] invalid mode ('wb') or filename: '|boggle.txt|'
Sorry, but i don't know where those pipes came from : P
The proper path is C:\\Users\\Ryniek's
WinSe7en\\MyNewGGBackup(2009-08-23 14:59:02).tar.bz2
and that string literal is \U, without any pipes :)
The truth is that script works on linux (ubuntu) but not on windows
(neither Win7 nor WinXP).
Maybe it's good idea to use raw string for specifing those paths?
As i mentioned later, some python users had the same problem with this
IOError ( like here: http://www.daniweb.com/forums/thread174552.html
or here:
http://groups.google.com/group/sympy/browse_thread/thread/c42aca3eb532928c
).
/div
You still haven't gotten rid of those illegal colons in the filename.
They're not legal in Windows, as has been pointed out a couple of times
in this thread.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal?notation
J. Cliff Dyer j...@sdf.lonestar.org wrote: I had an objection to using spaces in numeric literals last time around and it still stands, and it still stands in the new one. Or, we can use U+00A0 NO-BREAK SPACE, once we already have unicode variable names :-) (probably some people would find it difficult to type, though with my keyboard layout it is COMPOSE + SPACE + SPACE, not more difficult than _). Well, reading code listings could be a bit confusing. Thinking about it, U+2005 FOUR-PER-EM SPACE makes more sense. Aesthetically, too :-) -- --- | Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ | | __..--^^^--..__garabik @ kassiopeia.juls.savba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread! -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading binary files
The built-in file type deals with this just fine. You can simply specify when opening the file that it is to be opened as binary: http://docs.python.org/library/functions.html#open On Mon, 24 Aug 2009 07:35:09 -0700, Ronn Ross ronn.r...@gmail.com wrote: I need to read a binary file. When I open it up in a text editor it is just junk. Does Python have a class to help with this? -- Rami Chowdhury Never attribute to malice that which can be attributed to stupidity -- Hanlon's Razor 408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD) -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading binary files
On Mon, 2009-08-24 at 10:35 -0400, Ronn Ross wrote:
I need to read a binary file. When I open it up in a text editor it is
just junk. Does Python have a class to help with this?
Yes, the file class.
myfile = open('/path/to/binary/file', 'rb')
-a
--
http://mail.python.org/mailman/listinfo/python-list
Re: Temat:,Re: IOError: [Errno 22] invalid mode ('wb') or filename: in windows xp while making tarfile
Dave Angel wrote: You still haven't gotten rid of those illegal colons in the filename. They're not legal in Windows, as has been pointed out a couple of times in this thread. Ummm.. Colons are of course legal in Windows filenames as designating the Alternate Data Streams: code with open (c:/temp/test.txt, w) as f: f.write (base text) with open (c:/temp/test.txt:blah, w) as f: f.write (ADS text) print open (c:/temp/test.txt:blah).read () /code On the other hand, though, you can't have more than one of them: code with open (c:/temp/test.txt:blah:blah2, w) as f: f.write (ADS text2) /code should raise an error. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
On 24 Aug, 14:08, Gilles Ganault nos...@nospam.com wrote: I'm especially concerned about the lack of controls, the lack of updates (lots of controls in wxWidgets are 1.0 deadware), and problems linked to how to update users' PC remotely when I build a new version using eg. Py2exe. There is pywin32 if you like to work with MFC and ActiveX. Apart from that, lack of controls is not what I associate with GTK, Qt or wxWidgets. I need controls for business apps like access to databases, good data grid, printing reports (with or without barcodes), etc. Why do you want GUI controls for this? If you think you do, Visual Basic has crippled your mind. Python has packages for database connectivity. There is ReportLab for reports, matplotlib for graphs, pyagg or pycairo for whatever you want to draw, etc. You can find Python packages for anything you can imagine. Sturla -- http://mail.python.org/mailman/listinfo/python-list
Re: P3 weird sys.stdout.write()
Jerzy Jalocha N wrote: I've stumbled upon the following in Python 3: Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) [GCC 4.3.3] on linux2 Type help, copyright, credits or license for more information. import sys sys.stdout.write() 0 sys.stdout.write(something) something9 write() is appending the length of the string to it's output. That's not how it worked in 2.6. What's the reason for this? Is this intended? I couldn't find a bug report for this. (You probably should be using 3.1, but that's not your particular problem here.) The write() function changed in 3.0, but not in the way you're describing. It now (usually) has a return value, the count of the number of characters written. See the 3.1 docs: file.write(/str/) Write a string to the file. Due to buffering, the string may not actually show up in the file until the flush() or close() method is called. The meaning of the return value is not defined for every file-like object. Some (mostly low-level) file-like objects may return the number of bytes actually written, others return None. But because you're running from the interpreter, you're seeing the return value(9), which is suppressed if it's None, which it was in 2.x. This has nothing to do with how the language behaves in normal use. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Temat:, Re: IOError: [Errno 22] invalid mode ('wb') or filename: in windows xp while making tarfile
On Aug 25, 12:46 am, Tim Golden m...@timgolden.me.uk wrote: Dave Angel wrote: You still haven't gotten rid of those illegal colons in the filename. They're not legal in Windows, as has been pointed out a couple of times in this thread. Ummm.. Colons are of course legal in Windows filenames as designating That is the most inappropriate of course I've seen for quite a while. the Alternate Data Streams: OK, so s/illegal/evil/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
On Sun, Aug 23, 2009 at 9:21 AM, Stefan Behnelstefan...@behnel.de wrote: n...@cam.ac.uk wrote: I am interested in surveying people who want to interoperate between Fortran and Python to find out what they would like to be able to do more conveniently, especially with regard to types not supported for C interoperability by the current Fortran standard. Any suggestions as to other ways that I could survey such people (Usenet is no longer as ubiquitous as it used to be) would be welcomed. You might want to ask also on the Cython, NumPy and SciPy mailing lists. NumPy and SciPy have a rather large audience of scientific developers, and Cython has a running sub-project on providing better Fortran integration (which might be of interest to you anyway). Thanks for the mention, Stefan. For those who are interested, here's my blog summarizing the status of 'fwrap,' a Fortran wrapper utility for the C, Cython Python languages. http://fortrancython.wordpress.com/ Linked there are my talk slides presentation at last week's SciPy 2009 conference, which gives a good overview. Kurt -- http://mail.python.org/mailman/listinfo/python-list
problem to write a THREAD enabled python extension
Hi,
the following scenario:
1. using GIL
2. a pthread is created in a library and have to be announced to python
3. the thread is created in a PyObject_CallObject function call from
extension c code using a other extension c-code function called
from python code
python CRASH with invalid thread-state object
http://www.linuxjournal.com/article/3641
has information that GIL is NOT able to keep thread state information
for cross thread operation.
workaround -
..
PyGILState_STATE gilState = PyGILState_Ensure(); // PyEval_RestoreThread
// Call Python/C API...
PyGILState_Release(gilState); // PyEval_SaveThread
..
// Create new thread...
..
PyGILState_STATE gilState = PyGILState_Ensure(); // PyEval_RestoreThread
// Call Python/C API...
PyGILState_Release(gilState); // PyEval_SaveThread
..
the problem is that PyGILState_Release have to be done in the call of
PyObject_CallObject and not in the extension c-code
- for now i call it impossible to provide thread support if thread is
created in extension code
- more info by valgrind
==29105==
==29105== Invalid read of size 4
==29105==at 0x4F099AB: PyEval_EvalFrameEx (ceval.c:3728)
==29105==by 0x4F0B476: PyEval_EvalCodeEx (ceval.c:3180)
==29105==by 0x4E9DE50: function_call (funcobject.c:630)
==29105==by 0x4E7610C: PyObject_Call (abstract.c:2160)
==29105==by 0x4E8BEFB: method_call (classobject.c:323)
==29105==by 0x4E7610C: PyObject_Call (abstract.c:2160)
==29105==by 0x4F04975: PyEval_CallObjectWithKeywords (ceval.c:3624)
==29105==by 0x72132DF: pymsgque_ProcCall (misc_python.c:48)
==29105==by 0x742A23E: pTokenInvoke (token.c:327)
==29105==by 0x742E7E2: sMqEventStart (msgque.c:908)
==29105==by 0x7425365: pEventStart (event.c:360)
==29105==by 0x742ECBF: MqProcessEvent (msgque.c:1081)
==29105==by 0x7215F24: pymsgque_ProcessEvent (context_python.c:176)
==29105==by 0x4F09BFA: PyEval_EvalFrameEx (ceval.c:3961)
==29105==by 0x4F0B476: PyEval_EvalCodeEx (ceval.c:3180)
==29105==by 0x4F0B58A: PyEval_EvalCode (ceval.c:650)
==29105==by 0x4F2EE29: PyRun_FileExFlags (pythonrun.c:1697)
==29105==by 0x4F2F134: PyRun_SimpleFileExFlags (pythonrun.c:1182)
==29105==by 0x4F43CFB: Py_Main (main.c:625)
==29105==by 0x400D11: main (python.c:152)
==29105== Address 0x24 is not stack'd, malloc'd or (recently) free'd
- extension code ... (including some debugging output)
M0
PyGILState_STATE gstate = PyGILState_Ensure();
PyObject *result;
PyObject * const self = (PyObject*) CONTEXT-self;
PyObject * const callable = (PyObject*) dataP;
enum MqErrorE ret = MQ_OK;
// clean Python and libmsgque error
PyErr_Clear();
MqErrorReset(msgque-error);
// call the function
M1
printP(PyThreadState_Get())
if (PyMethod_Check(callable) PyMethod_Self(callable) == self) {
//PyGILState_Release(gstate);
result = PyObject_CallObject(callable, NULL);
//gstate = PyGILState_Ensure();
} else {
//PyGILState_Release(gstate);
result = PyObject_CallFunctionObjArgs(callable, self, NULL);
//gstate = PyGILState_Ensure();
}
M2
printP(PyThreadState_Get())
Py_XDECREF(result);
// no error return OK
if (PyErr_Occurred() != NULL) {
NS(ErrorSet) (self);
ret = MqErrorGetCode(msgque-error);
}
PyGILState_Release(gstate);
return ret;
}
with GIL wrapper 'PyGILState_Release' and 'PyGILState_Ensure' enabled for
'PyObject_CallObject' the following SEG happen
if (PyMethod_Check(callable) PyMethod_Self(callable) == self) {
PyGILState_Release(gstate);
result = PyObject_CallObject(callable, NULL);
gstate = PyGILState_Ensure();
} else {
PyGILState_Release(gstate);
result = PyObject_CallFunctionObjArgs(callable, self, NULL);
gstate = PyGILState_Ensure();
}
pymsgque_ProcCall(misc_python.c:32) - 0
pymsgque_ProcCall(misc_python.c:44) - 1
pymsgque_ProcCall(misc_python.c:45) - PyThreadState_Get()0x68c2ad8
==29223==
==29223== Thread 2:
==29223== Invalid read of size 4
==29223==at 0x4E760EA: PyObject_Call (abstract.c:2158)
==29223==by 0x4F04975: PyEval_CallObjectWithKeywords (ceval.c:3624)
==29223==by 0x72132F7: pymsgque_ProcCall (misc_python.c:48)
==29223==by 0x7430092: MqLinkCreate (msgque.c:644)
==29223==by 0x7430AB0: MqDefaultLinkCreate (msgque.c:681)
==29223==by 0x742F73B: MqLinkCreate (msgque.c:346)
==29223==by 0x7432C3D: sSysServerThreadCreate (sys.c:502)
==29223==by 0x521606F: start_thread (in /lib64/libpthread-2.9.so)
==29223==by 0x5B5B10C: clone (in /lib64/libc-2.9.so)
==29223== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==29223==
==29223== Process terminating with default action of signal 11 (SIGSEGV)
mfg
aotto1968
--
http://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 22] invalid mode ('wb') or filename: in windows xp while making tarfile
The proper path is C:\\Users\\Ryniek's WinSe7en\\MyNewGGBackup(2009-08-23 14:59:02).tar.bz2 and that string literal is \U, without any pipes :) The truth is that script works on linux (ubuntu) but not on windows (neither Win7 nor WinXP). Maybe it's good idea to use raw string for specifing those paths? Colons are not valid in filenames on Windows. You won't get that filename to work. The error may be somewhat cryptic. Depending on the version of Windows and the particulars of your filesystem, *attempting* to read/write a filename with a colon may lead to very surprising results-- 0 sized files with names up to the colon... as you may actually be writing to an alternate named data stream (like a resource fork on the mac). Basically, the error is just cryptic. The problem is your filename isn't a valid windows filename :) --S -- http://mail.python.org/mailman/listinfo/python-list
Fedex + SOAP
Fedex has recently started the process to transition from their XML- based Web Services to the new SOAP-based equivalent. I've been trying unsuccessfully to get an example SOAP transaction working with their new service, but am running into validation problems. I was wondering if anyone has already started tinkering with a Fedex +SOAP module before I potentially re-invent the wheel. If there's nothing in the works yet, would anyone be interested in working with me on such a module? Thanks, Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
On 24 Aug, 14:08, Gilles Ganault nos...@nospam.com wrote: and problems linked to how to update users' PC remotely when I build a new version using eg. Py2exe. Remote update is a problem regardless of language. It typically involves the following steps: 1. Download the update from a server using a background thread. 2. When the program starts, look for downloaded updates. Install updates, then launch the Python app. The problem is that a program's DLLs etc. become write-protected when the program runs. So you nees two programs that cooperate to install updates. But regardless of language you will run into this problem - it is not Python specific. With py2exe, you can solve this using two executables. The first py2exe launch a script that installs updates, then spawns the second py2exe executable. The second py2exe lauch a script that installs updates in the first, then launch the Python app. The Python app then run a background thread that downloads new updates. Sturla Molden -- http://mail.python.org/mailman/listinfo/python-list
Re: problem to write a THREAD enabled python extension
Andreas Otto wrote: Hi, the following scenario: 1. using GIL 2. a pthread is created in a library and have to be announced to python 3. the thread is created in a PyObject_CallObject function call from extension c code using a other extension c-code function called from python code python CRASH with invalid thread-state object You forgot to create a thread state for the new thread. See the PyThreadState_New() function. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: P3 weird sys.stdout.write()
On Mon, Aug 24, 2009 at 10:52 AM, Dave Angelda...@ieee.org wrote: The write() function changed in 3.0, but not in the way you're describing. It now (usually) has a return value, the count of the number of characters written. [...] But because you're running from the interpreter, you're seeing the return value(9), which is suppressed if it's None, which it was in 2.x. This has nothing to do with how the language behaves in normal use. This makes it much clearer! You are right, output in a shell script is normal, without the return value. Thank you, Dave. -Jerzy -- http://mail.python.org/mailman/listinfo/python-list
Re: your favorite debugging tool?
Hello, thank you all for your suggestions/comments. While I do believe in a minimalist approach (part of the reason I find Python so appealing), using print statements sometimes only goes so far (for me). I probably should look into using iPython in the context of debugging (I already use this shell). For now I ended up giving winpdb a whirl and it did help me find the bug that had been elusive to my print statement approach :-) Thanks again .. and if there are additional postings, I'll be reading them too with great interest. Esmail -- http://mail.python.org/mailman/listinfo/python-list
print() and unicode strings (python 3.1)
==python 2.6 == import sys print sys.getdefaultencoding() s = u\u20ac print s.encode(utf-8) $ python2.6 1test.py ascii € =python 3.1 === import sys print(sys.getdefaultencoding()) s = € print(s.encode(utf-8)) print(s) $ python3.1 1test.py utf-8 b'\xe2\x82\xac' Traceback (most recent call last): File 1test.py, line 7, in module print(s) UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 0: ordinal not in range(12 I don't understand why I'm getting an encode error in python 3.1. -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Aug 24, 6:56 am, Derek Martin c...@pizzashack.org wrote: I think hard-coding dates is more uncommon than using octal. ;-) [It unquestionably is, for me personally.] You just don't get it, do you? Do you really think this is a contest over what's more common and the winner gets to choose the syntax? You really think that's the issue? It is not. The issue is that C's arcane octal notation is MIND- BOGGLINGLY RETARDED. So, even if Unix file permissions were a hundred times more common than padding integer constants with zero, it still wouldn't be a good idea to have it in Python because the notation is retarded. Even if 99.999% of other languages use the notation, it still wouldn't be a good idea to have it in Python because the notation is retarded. The vast majority of people reading this will understand intuitively why the arcane octal notation is retarded. I was going to explain it, but I decided it's not worth a serious argument. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
Hendrik van Rooyen wrote: see if there is an after method somewhere. What you have to do is to break the link between the callback and the processing. Your code above is all in the callback thread, despite the fact that you call another function to do the processing. So if you replace the data_callback() with an after call, it should work as you expect. HTH - Hendrik Thanks I'm new to python, what is an after function and an after call? Couldn't find excact answer on google...? Do you have a link to some docs? -- http://mail.python.org/mailman/listinfo/python-list
Re: Literal concatenation, strings vs. numbers (was: Numeric literals in other than base 10 - was Annoying octal notation)
On Mon, 24 Aug 2009 12:45:25 +1000, Ben Finney wrote: greg g...@cosc.canterbury.ac.nz writes: J. Cliff Dyer wrote: What happens if you use a literal like 0x10f 304? To me the obvious thing to do is concatenate them textually and then treat the whole thing as a single numeric literal. Anything else wouldn't be sane, IMO. Agreed. It's the only sane way to deal with concatenating numeric literals. It makes it simple and easy to understand: remove the whitespace from inside the literal, and parse as normal. 123 4567 = 1234567 # legal 0xff 123 = 0xff123 # legal 123 0xff = 1230xff # illegal The first two examples would be legal, the last would raise a syntax error, for obvious reasons. This would also work for floats: 1.23 4e5 = 1.234e5 # legal 1.23 4.5 = 1.234.5 # illegal 1e23 4e5 = 1e234e5 # illegal Yet, as was pointed out, that behaviour would be inconsistent with the concatenation of string literals:: abc r'def' ughi 'jkl' u'abcdefghijkl' Unicode/byte conversion is obviously a special case, and arguably should have been prohibited, although practicality beats purity suggests that a single unicode string in the sequence should make the lot unicode. (What else could it mean?) In any case, numeric concatenation and string concatenation are very different beasts. With strings, you have to interpret each piece as either bytes or characters, you have to treat escapes specially, you have to deal with matching delimiters. For numeric concatenation, none of those complications is relevant: there is no equivalent to the byte/ character dichotomy, there are no escape sequences, there are no delimiters. Numeric literals are much simpler than string literals, consequently the concatenation rule can be correspondingly simpler too. There's no need to complicate it by *adding* complexity: you can't have mixed bases in a single numeric literal without spaces, why would you expect to have mixed bases in one with spaces? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Need cleanup advice for multiline string
On Mon, 24 Aug 2009 09:40:03 +0200, Stefan Behnel wrote: Or you could enter the 21 century and understand that guys has become a generic term for people of any sex. Is that true for everyone who understands and/or writes English? In that case, I'm fine with your above statement. Otherwise, I'd wonder who you meant with the term cultural chauvinism. So far, I only learned that most North-American English native speakers use that term in the way you refer to. That doesn't even get you close to the majority of English speakers. If you read the entire thread, you'd see that we've already discussed the issue of guys for mixed sex groups and females. In fact, as I'd already said, I'm one of those old fashioned guys who still gets surprised when women refer to themselves as guys, but I'm learning to keep up with the times. I'm Australian, not North American, and the British author Michael Quinion, one of the researchers for the Oxford Dictionary, also states that guys now refers to both men and women: http://www.worldwidewords.org/weirdwords/ww-guy1.htm When guys can refer to either sex in English, American, Canadian and Australian English, I think it should be pretty uncontroversial to treat it as standard now. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
I was wondering if some people in this ng use Python and some GUI toolkit (PyWin32, wxWidgets, QT, etc.) to build professional applications, and if yes, what it's like, the pros and cons, etc. My company does. A few years ago we decided to re-write our entire aging product line in Python using wxPython as the GUI layer (PyWin32 was out because we wanted Mac compatibility, and at that time between QT's commercial license and my own familiarity with wx meant we just used that by default.) It took some time to get solid; there's a learning curve involved in doing things the pythonic way, and wxPython is -- not really pythonic(and no powerful GUI library is, though there are some simpler libraries out there which are), so you're learning in two directions at once. It's been a pretty interesting experience, and I'd consider it a complete success, honestly. It took some time to get the full suite going from functional to mature, mostly because of certain complexities to our system which have nothing to do with Python. But, Python and wxPython as the foundation for the system has allowed some pretty remarkable flexibility in getting something usable to the customer quickly, getting early feedback and rapidly responding to their needs and growing the application as we did so. It's been a very iterative process, but I don't know if you want to create a long-term project or get something out that works Just Fine, Right Now. For us we started out with a basic re-implementation of the legacy system which just 'worked', and have over the last few years probably rewritten most of the original code at least twice (a piece at a time)-- re-factoring and redesigning both the insides and UI as new controls and technologies (and our own knowledge!) improve over time. For us that's good, because we like maintenance contracts :) But we've had a continually evolving product line-- getting faster with every new release, slicker, with new features and evolving continually. Sure, every program /should/ do that -- but using Python+wxPython IMHO has been invaluable to the process of evolving /efficiently/. It takes very little effort to /maintain/ the system, very little effort going back to some deep dark place in the codebase and figuring out what the heck was done by someone else three years ago... and very little effort to pull the whole thing apart and piece it back together with a new heart when it's discovered the original didn't quite do things as well as it should. I'm especially concerned about the lack of controls, the lack of updates (lots of controls in wxWidgets are 1.0 deadware), I find this comment -- frankly bizarre. There's a plethora if controls in wxWidgets, and it's not terribly hard once you learn the system how to make your own. Check out Andrea Gavana's excellent suite of custom widgets (which continually get migrated into the core wxPython) and the AUI, and the sublime ObjectListView for Python. Now, if you're talking about lack of the latest Microsoft-specialized controls, that's true. wxWidgets is cross-platform so doesn't readily adopt the latest and newest way that Microsoft does things with each new iteration of Office and Windows pumping out a new UI paradigm. But you can still create very native and impressively functional looking apps. With wxWidgets at least (I have no idea about QT), you also don't have a series of data-aware controls that you may be used to, but it's *really* not that hard to write that layer yourself. You may also want to look into Dabo, which builds on top of wxPython and I believe solves some of its limitations with regards to data-integration if you do things in a way that are Dabo-esque. I'm only vaguely familiar with it, though. Depending on your needs, you can use various dialog builders to create XRC/XML descriptions of your interface and load them up-- but personally I hand-code all the controls and interfaces, and doing so once you learn the system is really quite rapid. I can dummy up a very functional interface for testing/dummying much faster in Python/wxPython then I can in Visual Studio. It doesn't have as many bells and whistles, but I really can't imagine why anyone would find themselves control-starved. and problems linked to how to update users' PC remotely when I build a new version using eg. Py2exe. What problems? Yes, you have to learn py2exe, but once you have your program packaged together, it's no different then any other program on windows. Build a MSI, and have the IT guy push that MSI out via an active directory group policy. Isn't that the standard way you install and update /any/ group of users' software on a windows network? Regardless of in what language you write it in? I need controls for business apps like access to databases, good data grid, printing reports (with or without barcodes), etc. Data access is easy and well supported to a wide-variety of databases, depending on just how you want to do it. I've
Re: Annoying octal notation
On Mon, Aug 24, 2009 at 05:22:39PM +0200, Hendrik van Rooyen wrote: Assuming I'm right about that, then the use of a leading 0 to represent octal actually predates the prevalence of using 0 in dates by almost two decades. Not quite - at the time I started, punch cards and data entry forms were already well established practice, and at least on the English machines, (ICL 1500/1900 series) octal was prevalent, but I don't know when the leading zero octal notation started, and where. I said prevalence. The key is that the average person did not start using leading zeros in dates until (I think) much, much later, and that's what's relevant to this discussion. If it were not commonplace for people to use decimal numbers with leading zeros, this whole thread would be a moot point, the python devs likely never would have considered changing the syntax, and we would not be having this discussion. Most people did not work as data entry clerks on ICL computers... :) Those participating in this thread have pretty much all seem to agree that the only places where decimal numbers with leading zeros really are common are either in rather specialized applications, such as computer-oriented data or serial numbers (which typically behave more like strings, from a computer science perspective), or the rather common one of dates. The latter case is perhaps what's significant, if any of those cases are. I tend to think that within the computer science arena, the history and prevalence of the leading 0 indicating octal far outweighs all of those cases combined. I think you give it credence for far more depth of design thinking than what actually happened in those days - some team working on a compiler made a decision (based on gut feel or experience, or precedent, or whim ) and that was that - lo! - a standard is born! Rather, I think you give the folks at Bell Labs way too little credit. They designed a programming language and an operating system that, while certainly not exactly the same as their original incarnations, even then contained a lot of features and design principles that remain state-of-the-art (though perhaps their specific implementation details have since been improved) and in many ways superior to a lot of what has come since (e.g. virtually anything that came out of Microsoft). [That's just my opinion, of course... but shared by many. :)] I don't think that happened by mere accident. That's not to say they were perfect, but those guys had their proverbial $#!t together. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpTSmevmuY7i.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: print() and unicode strings (python 3.1)
I don't understand why I'm getting an encode error in python 3.1. The default encoding is not relevant here at all. Look at sys.stdout.encoding. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 still not giving memory back to the OS...
Martin v. Löwis wrote: Today, there are two cases when malloc returns memory on a typical Unix system (in particular, in Linux malloc): a) if the malloc block block is small (below page size), it is allocated from the brk heap, where it can only be returned if the last page of that heap is completely free, and b) if the block is large (multiple pages), it gets returned to the system right away. Case b) can only happen if the C malloc uses mmap to allocate large blocks. I believe (and John will correct me if I'm wrong) that xlrd uses mmap, so why am I not seeing the memory being returned? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
Piet van Oostrum wrote: Scott David Daniels scott.dani...@acm.org (SDD) wrote: SDD James Harris wrote:... Another option: 0.(2:1011), 0.(8:7621), 0.(16:c26b) where the three characters 0.( begin the sequence. Comments? Improvements? SDD I did a little interpreter where non-base 10 numbers SDD (up to base 36) were: SDD .7.100 == 64 (octal) SDD .9.100 == 100 (decimal) SDD .F.100 == 256 (hexadecimal) SDD .1.100 == 4 (binary) SDD .3.100 == 9 (trinary) SDD .Z.100 == 46656 (base 36) I wonder how you wrote that interpreter, given that some answers are wrong. Obviously I started with a different set of examples and edited after starting to make a table that could be interpretted in each base. After doing that, I forgot to double check, and lo and behold .F.1000 = 46656, while .F.100 = 1296. Since it has been decades since I've had access to that interpreter, this is all from memory. --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Barcodes
Ronn Ross wrote: I found this library, but no documentation(https://cybernetics.hudora.biz/projects/wiki/huBarcode). Has anyone used this or know of a similar library with better documentation? Yup, reportlab has really good barcode generation stuff. I use it to generate labels with barcodes on for asset tracking :-) http://the-gay-bar.com/index.php?/archives/221-Howto-generate-barcodes-in-Python-with-reportlab/ Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Need cleanup advice for multiline string
Steven D'Aprano wrote: On Mon, 24 Aug 2009 09:40:03 +0200, Stefan Behnel wrote: Or you could enter the 21 century and understand that guys has become a generic term for people of any sex. Is that true for everyone who understands and/or writes English? In that case, I'm fine with your above statement. Otherwise, I'd wonder who you meant with the term cultural chauvinism. So far, I only learned that most North-American English native speakers use that term in the way you refer to. That doesn't even get you close to the majority of English speakers. If you read the entire thread, you'd see that we've already discussed the issue of guys for mixed sex groups and females. In fact, as I'd already said, I'm one of those old fashioned guys who still gets surprised when women refer to themselves as guys, but I'm learning to keep up with the times. I'm Australian, not North American, and the British author Michael Quinion, one of the researchers for the Oxford Dictionary, also states that guys now refers to both men and women: http://www.worldwidewords.org/weirdwords/ww-guy1.htm When guys can refer to either sex in English, American, Canadian and Australian English, I think it should be pretty uncontroversial to treat it as standard now. Ok, then I guess I just misread after being adopted in the USA it started to change meaning in one of the cited articles as it changed meaning in the USA. I didn't expect Australians (and Oxford dictionary writers, and potentially others) to be /that/ influenced by shifts in US juvenile word semantics... I for one wouldn't start calling my leg foot, even though the Austrians kept insisting for ages now. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Mon, Aug 24, 2009 at 08:31:13AM -0700, Carl Banks wrote: On Aug 24, 6:56 am, Derek Martin c...@pizzashack.org wrote: I think hard-coding dates is more uncommon than using octal. ;-) [It unquestionably is, for me personally.] You just don't get it, do you? I think I get it just fine, thanks. Do you really think this is a contest over what's more common and the winner gets to choose the syntax? You really think that's the issue? No, I think it's about egos. Someone got the idea that 0o1 was better than 01, and had to be Right. And had the power to make it happen, or at least (sadly) convince the people with the power. I'm simply presenting an argument that the need for the change is not so clear. You say the old syntax is retarded. I say the new syntax, and the very act of making the change itself is retarded. I think my argument is very solid and persuasive; but of course some minds are invulnerable to persuasion. I might not even disagree that the old syntax could be improved upon, except that it already is what it is, and the new syntax is NOT better; I personally believe it's not only not better, but that it's actually worse. Others have agreed. It is not. The issue is that C's arcane octal notation is MIND- BOGGLINGLY RETARDED. As I said, I searched the web on this topic before I bothered to post. I did a bit of research. One of the things that my search turned up: A lot of smart people disagree with you. If the use of the leading zero boggles your mind, then perhaps your mind is too easily boggled, and perhaps you should seek a different way to occupy your time. This is yet another case where some Pythonista has gotten it in his head that There is One Truth, and the Old Way be Damned, my way is The Way, and Thus Shall It Be Evermore. And worse yet, managed to convince others. Well, there's no such thing as One Truth, and there are different perspectives that are just as valid as yours. I'm expressing one now. This change sucks. I already know that my rant won't change the syntax. The only reason I bothered to post is because I do actually quite like Python -- something I can say of only one other programming language -- and I think the powers that be are (in some cases) making it worse, not better. I hoped to open a few minds with a different perspective, but of course I should have known better. 0o1 is not better than 01. On my terminal it's hard to see the difference between 0 and o. YMMV. But since YMMV, and since the old syntax is prevalent both within and without the Python community, making the change is, was, and always will be a bad idea. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpP7sETirZLX.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Mon, 24 Aug 2009 09:14:25 -0500, Derek Martin wrote: Assuming I'm right about that, then the use of a leading 0 to represent octal actually predates the prevalence of using 0 in dates by almost two decades. And while using leading zeros in other contexts is familiar to me, I would certainly not consider it common by any means. Thus I think it's fair to say that when this syntax was selected, it was a rather good choice. Except of course to anyone familiar with mathematics in the last, oh, five hundred years or so. Mathematics has used a positional system for numbers for centuries now: leading zeroes have been insignificant, just like trailing zeroes after the decimal point: 9 = 09 = 009 = 9.0 = 9.00 = 0009.000 etc. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading binary files
On Mon, Aug 24, 2009 at 11:18 AM, Ronn Ross ronn.r...@gmail.com wrote:
On Mon, Aug 24, 2009 at 10:43 AM, Albert Hopkins
mar...@letterboxes.orgwrote:
On Mon, 2009-08-24 at 10:35 -0400, Ronn Ross wrote:
I need to read a binary file. When I open it up in a text editor it is
just junk. Does Python have a class to help with this?
Yes, the file class.
myfile = open('/path/to/binary/file', 'rb')
-a
This works for a simple binary file, but the actual file I'm trying to read
is give throwing an error that the file cannot be found. Here is the name of
the my file:
2009.08.02_06.52.00_WA-1_0001_00_0662_0.jstars
Should python have trouble reading this file name or extension?
I'm having trouble with the filename:
2009.08.02_06.52.00_WA-1_0001_00_0662_0.jstars
It throws an error with that file name, When I change it to something like
sample.txt it runs, but the data is still garbled. Is there any reason why I
can't use the above file name? If I'm using 'rb' to read the binary file why
is it still garbled?
--
http://mail.python.org/mailman/listinfo/python-list
Re: print() and unicode strings (python 3.1)
On Aug 24, 9:56 am, Martin v. Löwis mar...@v.loewis.de wrote: I don't understand why I'm getting an encode error in python 3.1. The default encoding is not relevant here at all. Look at sys.stdout.encoding. Regards, Martin Hi, Thanks for the response. I get US-ASCII for both 2.6 and 3.1: ===python 3.1== import sys print(sys.stdout.encoding) $ python3.1 1test.py US-ASCII I can't figure out a way to programatically set the encoding for sys.stdout. So where does that leave me? python 3.1 won't let me explicitly encode my unicode string, and python 3.1 implicitly does the encoding with the wrong codec. And why would any programmer rely on python 3.1's implicit encoding of unicode strings anyway? Presumably, different systems will have different encodings for sys.stdout, some encodings might cause encode errors. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
On 08/24/2009 06:08 AM, Gilles Ganault wrote: I was wondering if some people in this ng use Python and some GUI toolkit (PyWin32, wxWidgets, QT, etc.) to build professional applications, and if yes, what it's like, the pros and cons, etc. I'm especially concerned about the lack of controls, the lack of updates (lots of controls in wxWidgets are 1.0 deadware), and problems linked to how to update users' PC remotely when I build a new version using eg. Py2exe. I need controls for business apps like access to databases, good data grid, printing reports (with or without barcodes), etc. I sure you'll get plenty of GUI-x is really great and you'll is just as good as anything commercial out there, so I thought a minority opinion, even if unpopular, might be useful. Won't comment on the control choices or packaging issues, but I am at the moment doing a little database-connected app that presents editable data in a spreadsheet like (grid) form using wxPython. It has been a very painful process. I have not found any simple pre-written code to connect a wxPython grid to a database so that the result is something like a Microsoft Access datasheet.[*1] It is probably taking me 10 times as long to develop this app in WxPython/Postgresql as it did to develop something similar in MS Access/VBA/SQL Server. I haven't needed for printing yet, but I've read wxpython maillist posts about the difficultly of getting printing to work so you may want to check that out as well before commiting to wxpython. A meta-issue that applies (I think) to both wxPython and PyQt is that both projects seem to be highly dependent on a single person leading one to worry about the bus scenario. I am not a fan of Microsoft (in fact I despise their commercial behavior and many aspects of thier products) but I am reporting the reality as I've experienced it. [*1] There are ORMs like Sqlalchemy but they introduce a additional problems like inefficient database operations, dependency on a large external package, etc. It is hard to tell for sure since the Sqlalchemy docs are lousy, which of course means even more development time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Mon, Aug 24, 2009 at 04:47:43PM +, Steven D'Aprano wrote: Except of course to anyone familiar with mathematics in the last, oh, five hundred years or so. Mathematics has used a positional system for numbers for centuries now: leading zeroes have been insignificant, just like trailing zeroes after the decimal point: 9 = 09 = 009 = 9.0 = 9.00 = 0009.000 etc. Dude, seriously. No one ever *uses* leading zeros in the context of mathematics except in 2nd grade math class. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpCgRpbc7UrM.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Mon, 24 Aug 2009 11:21:46 -0500, Derek Martin wrote: since the old syntax is prevalent both within and without the Python community, making the change is, was, and always will be a bad idea. Octal syntax isn't prevalent *at all*, except in a small number of niche areas. You've said that this change is a hardship for you, because on your terminal 0 and o are hard to distinguish. Personally, I'd say that's a good sign that your terminal is crappy and you should use a better one, but putting that aside, let's accept that. To you, for whatever reason, 0o looks just like 00. Okay then. Under the current 2.x syntax, 0012 would be interpreted as octal. Under the new 3.x syntax, 0o12 which looks just like 0012 also would be interpreted as octal. You have argued that it might not be any harder to type the extra 'o' to get an octal literal, but that it will hurt readability. I quote: Writing 0o12 presents no hardship; but I assert, with at least some support from others here, that *reading* it does. But according to you, reading 0o12 is just like reading 0012. 0o12 under the new syntax gives decimal ten, and it looks just like 0012 in the old syntax, which also gives ten. So there's no difference in reading, and you've already accepted that the extra effort in writing it presents no hardship. A whole lot of noise over a change which is more or less invisible. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python what I need?
On 2009-08-24 08:32 AM, Peter Otten wrote: Jean-Michel Pichavant wrote: From the distance it looks like these children need a good teacher rather than a bad (or just starting) programmer. Wow, that is rude. Let's keep this list friendly, won't we ? I may have been too blunt, and if my message has come across as an insult I apologize for that. Let me try again: If you are trying to teach children that are unwilling to use pen and paper putting them in front of a computer doesn't help you and them one bit. As a starting programmer you'll have to spend a lot of time in front of your computer that may be better spent with your students. I suspect everyone is reading too much into the word aversion. There may be physical or mental handicaps involved, not the personal preference of the students. In such a case, the OP's word choice is not ideal, but the readers here should give a little more thought before assuming the most ludicrous interpretation. -- 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: Annoying octal notation
On Mon, 24 Aug 2009 Derek Martin wrote: Those participating in this thread have pretty much all seem to agree that the only places where decimal numbers with leading zeros really are common are either in rather specialized applications, such as computer-oriented data or serial numbers (which typically behave more like strings, from a computer science perspective), or the rather common one of dates. The latter case is perhaps what's significant, if any of those cases are. I don't like the 'leading 0 is octal'-syntax. I typically think of numbers as decimal and bytes as hexadecimal. I would even write something like this: # iterate over bits 3 to 5 for i in range(0x00, 0x40, 0x08): ... print 0x%02x\n % i 0x00 0x08 0x10 0x18 0x20 0x28 0x30 0x38 For me it is easier to see where the bits are in the hex notation. And it is very common to use numbers with leading zeroes that are hexadecimal. Like this: # print address and data for i in range(0x1): print %04x: %d\n % i, data[i] : ... 0001: ... ... 000f: ... 0010: ... ... When you are looking for examples of numbers where leading zeroes do not mean octal then consider decimal AND hexadecimal. I tend to think that within the computer science arena, the history and prevalence of the leading 0 indicating octal far outweighs all of those cases combined. I disagree. Harald -- http://mail.python.org/mailman/listinfo/python-list
