Python Game Programming Challenge 13 (September 2011) is coming!
The 13th Python Game Programming Challenge (PyWeek) is coming. It'll run from the 11th to the 18th of September. The PyWeek challenge: - Invites entrants to write a game in one week from scratch either as an individual or in a team, - Is intended to be challenging and fun, - Will hopefully increase the public body of game tools, code and expertise, - Will let a lot of people actually finish a game, and - May inspire new projects (with ready made teams!) Richard http://pyweek.org/13/ -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Multi-taper spectral analysis code available
This is the initial release of a module that implements Thomson's multi-taper spectral analysis algorithms. The code is based on a subroutine from Lees and Park and has, of course, a python interface. References are provided in the readme file. It requires that numpy be available. The code has seen substantial usage and should be fairly reliable. Examples are included. It's available at http://code.google.com/p/pymutt/. Martin L. Smith Blindgoat Geophysics -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Convert '165.0' to int
On Jul 21, 10:00 pm, Terry Reedy tjre...@udel.edu wrote:
On 7/21/2011 10:13 AM, Grant Edwards wrote:
On 2011-07-21, Web Dreamerwebdrea...@nospam.fr wrote:
Leo Jay a ?crit ce jeudi 21 juillet 2011 11:47 dans
int(x.split('.')[0])
But, the problem is the same as with int(float(x)), the integer number is
still not as close as possible as the original float value.
Nobody said that close as possible to the original float value was
the goal. Perhaps the OP just wants it truncated.
The OP did not specify the domain of possible inputs nor the desired
output for all possible inputs. Without that, function design is
guessing. The appropriate response to the original post would have been
a request for clarification.
If the domain is strings with and int followed by '.0', then chopping
off two chars is sufficient. This was sort of implied by the original
post, since it was the only example, and assumed by the respondant.
If the domain is int literals followed by '.' and some number of zeroes,
then split works. So does int(float(s)). Split also works for non-digits
following '.' whereas int(float(s)) does not.
If the domain is all float literals, then ??.
--
Terry Jan Reedy
As the OP, I will clarify what *my* requirement is. This discussion
has gone off at various tangents beyond what I was asking for.
As suggested above, I am only talking about a string containing int
literals followed by '.' followed by zero or more zeros.
I think that there is a case for arguing that this is a valid
representation of an integer. It would therefore not be unreasonable
for python to accept int('165.0') and return 165. I would expect it to
raise an exception if there were any non-zero digits after the point.
However, the fact is that python does not accept this, and I am not
asking for a change.
int(float(x)) does the job, and I am happy with that. I was just
asking if there were any alternatives.
Frank
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On Jul 22, 12:05 am, Corey Richardson kb1...@aim.com wrote: from archive import ZipFile, TarFile zf = ZipFile(path, *args) tf = TarFile(path, *args) I have nothing to do this weekend, I might as well either write my own or twist around the existing implementations in the hg repo. My hat is off to you Mr. Richardson. I've even considered creating my own clean versions of these two modules, because heck, it is not that difficult to do! However we must stop fixing these warts on a local level Corey. We MUST clean up this damn python stdlib once and for all. I am willing and you are willing; that's two people. However, can we convince the powers that be to upgrade these modules? Sure, if we get enough people shouting for it to happen they will notice. So come on people make your voices heard. Chime in and let the devs know we are ready to unite and tackle these problems in our stdlib. What this community needs (first and foremost) is some positive attitudes. If you don't want to write the code fine. But at least chime in and say... Hey guys, that's a good idea! I would like to see some of these APIs cleaned up too. good luck! +1 Now, even if we get one hundred people chanting... Yes, Yes, Fix This Mess!... i know Guido and company are going to frown because of backwards incompatibility. But let me tell you something people, the longer we put off these changes the more painful they are going to be. Python 3000 would have been the perfect time to introduce a more intuitive and unified zip/tar archive module however that did not happen. So now we need to think about adding a duplicate module archive.py and deprecating zipfile.py and tarfile.py. We can remove the old modules when Python 4000 rolls out. That's just step one people, we have a long way to go! -- http://mail.python.org/mailman/listinfo/python-list
Question about timeit
Hi all
I mentioned in a recent post that I noticed an inconsistency in timeit, and
then reported that I must have made a mistake.
I have now identified my problem, but I don't understand it.
C:\Python32\Libtimeit.py int(float('165.0'))
10 loops, best of 3: 3.52 usec per loop
C:\Python32\Libtimeit.py int(float('165.0'))
10 loops, best of 3: 3.51 usec per loop
C:\Python32\Libtimeit.py 'int(float(165.0))'
1000 loops, best of 3: 0.0888 usec per loop
C:\Python32\Libtimeit.py 'int(float(165.0))'
1000 loops, best of 3: 0.0887 usec per loop
I ran them both twice just to be sure.
The first two use double-quote marks to surround the statement, and
single-quote marks to surround the literal inside the statement.
The second two swap the quote marks around.
Can someone explain the difference?
I am using python 3.2 on Windows Server 2003.
Thanks
Frank Millman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about timeit
Frank Millman, 22.07.2011 08:06:
I mentioned in a recent post that I noticed an inconsistency in timeit, and
then reported that I must have made a mistake.
I have now identified my problem, but I don't understand it.
C:\Python32\Libtimeit.py int(float('165.0'))
10 loops, best of 3: 3.52 usec per loop
C:\Python32\Libtimeit.py int(float('165.0'))
10 loops, best of 3: 3.51 usec per loop
C:\Python32\Libtimeit.py 'int(float(165.0))'
1000 loops, best of 3: 0.0888 usec per loop
C:\Python32\Libtimeit.py 'int(float(165.0))'
1000 loops, best of 3: 0.0887 usec per loop
I ran them both twice just to be sure.
The first two use double-quote marks to surround the statement, and
single-quote marks to surround the literal inside the statement.
The second two swap the quote marks around.
Can someone explain the difference?
I am using python 3.2 on Windows Server 2003.
As expected, I can't reproduce this (on Linux). Maybe your processor
switched from power save mode to performance mode right after running the
test a second time? Or maybe you need a better console application that
handles quotes in a more obvious way?
Note that it's common to run timeit like this: python -m timeit.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On Jul 22, 12:45 am, Terry Reedy tjre...@udel.edu wrote: On 7/22/2011 12:48 AM, rantingrick wrote: On Jul 21, 11:13 pm, Corey Richardsonkb1...@aim.com wrote: Hmm. Archives are more like directories than files. Windows, at least, seems to partly treat zipfiles as more or less as such. Yes but a zipfile is just a file not a directory. This is not the first time Microsoft has mislead people you know. ;-) Certainly, 7zip present a directory interface. So opening a zipfile/tarfile would be like opening a directory, which we normally do not do. On the other hand, I am not sure I like python's interface to directories that much. I don't think we should make comparisons between applications and API's. It would be more sensible to open files within the archives. Certainly, it would be nice to have the result act like file objects as much as possible. Well you still need to start at the treetop (which is the zip/tar file) because lots of important information is exposed at that level: * compressed file listing * created, modified times * adding / deleting * etc. I'll admit you could think of it as a directory but i would not want to do that. People need to realize that tar and zip files are FILES and NOT folders. Seaching open issues for 'tarfile' or 'zipfile' returns about 40 issues each. So I think some people would care more about fixing bugs than adjusting the interfaces. Of course, some of the issues may be about the interface and increasing consistency where it can be done without compatibility issues. Yes i agree! If we can at least do something as meager as this it would be a step forward. However i still believe the current API is broken beyond repair so we must introduce a new archive module. That's my opinion anyway. However, I do not think there are any active developers focued on those two modules. We need some fresh blood infused into Python-dev. I have been trying to get involved for a long time. We as a community need to realize that this community is NOT a homogeneous block. We need to be a little more accepting of new folks and new ideas. I know this language would evolve much quicker if we did. Unfortunately i know what the powers that be are going to say about fixing this wart. PTB: Sorry we cannot break backwards compatibility Do you propose we break compatibility more than we do? You are not the only Python ranter. People at Google march into Guido's office to complain instead of posting here. Well, i do feel for Guido because i know he's taking holy hell over this whole Python 3000 thing. If you guys don't remember i was a strong opponent of almost all the changes a few years ago (search the archives). However soon after taking a serious look at the changes and considering the benefits i was convinced. I believe we are moving in the correct direction with the language HOWEVER the library is growing stale by the second. I want to breathe new life into this library and i believe many more people like myself exist but they don't know how to get involved. I can tell everyone who is listening the easiest first step is simply to speak up and make a voice for yourself. Don't be afraid to state your opinions. You can start right now by chiming in on this thread. Anybody is welcome to offer opinions no matter what experience level. Rick: But what about Python 3000? PTB: Oh, well, umm, lets see. Well that was then and this is now! The changes made for 3.0 were more than enough for some people to discourage migration to Py3. And we *have* made additional changes since. So the resistance to incompatible feature changes has increased. Yes i do understand these changes have been very painful for some folks (me included). However there is only but one constant in this universe and that constant is change. I believe we can improve many of these API's starting with zip/tar modules. By the time Python 4000 gets here (and it will be much sooner than you guys realize!) we need to have this stdlib in pristine condition. That means: * Removing style guide violations. * Removing inconsistencies in existing API's. * Making sure doc strings and comments are everywhere. * Cleaning up the IDLE library (needs a complete re-write!) * Cleaning up Tkinter. * And more Baby steps are the key to winning this battle. We hit all the easy stuff first (doc-strings and style guide) and save the painful stuff for Python 4000. Meanwhile we introduce new modules and deprecate the old stuff. However we need to start the python 4000 migration now. We cannot keep putting off what should have already been done in Python 3000. Maybe i can offer a solution. A NEW module called archive.py (could even be a package!) which exports both the zip and tar file classes. However, unlike the current situation this archive module will be consistent with it's API. Not a bad idea. Put it on PyPI and see how much support you can get. Thanks, I might just do that! --
Re: Question about timeit
On Jul 22, 8:37 am, Stefan Behnel stefan...@behnel.de wrote:
Frank Millman, 22.07.2011 08:06:
I mentioned in a recent post that I noticed an inconsistency in timeit, and
then reported that I must have made a mistake.
I have now identified my problem, but I don't understand it.
C:\Python32\Libtimeit.py int(float('165.0'))
10 loops, best of 3: 3.52 usec per loop
C:\Python32\Libtimeit.py int(float('165.0'))
10 loops, best of 3: 3.51 usec per loop
C:\Python32\Libtimeit.py 'int(float(165.0))'
1000 loops, best of 3: 0.0888 usec per loop
C:\Python32\Libtimeit.py 'int(float(165.0))'
1000 loops, best of 3: 0.0887 usec per loop
I ran them both twice just to be sure.
The first two use double-quote marks to surround the statement, and
single-quote marks to surround the literal inside the statement.
The second two swap the quote marks around.
Can someone explain the difference?
I am using python 3.2 on Windows Server 2003.
As expected, I can't reproduce this (on Linux). Maybe your processor
switched from power save mode to performance mode right after running the
test a second time? Or maybe you need a better console application that
handles quotes in a more obvious way?
Note that it's common to run timeit like this: python -m timeit.
Stefan- Hide quoted text -
- Show quoted text -
I tried python -m timeit, and got exactly the same result as before.
I am using a desktop, not a laptop, so there is no power-saving mode
going on.
I am using the standard Windows 'Command Prompt' console to run this.
I tried it with python 2.6, and still get the same result.
My guess is that it is something to do with the console, but I don't
know what. If I get time over the weekend I will try to get to the
bottom of it.
Frank
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
Excerpts from rantingrick's message of Fri Jul 22 02:40:51 -0400 2011: On Jul 22, 12:45am, Terry Reedy tjre...@udel.edu wrote: On 7/22/2011 12:48 AM, rantingrick wrote: On Jul 21, 11:13 pm, Corey Richardsonkb1...@aim.com wrote: Hmm. Archives are more like directories than files. Windows, at least, seems to partly treat zipfiles as more or less as such. Yes but a zipfile is just a file not a directory. This is not the first time Microsoft has mislead people you know. ;-) Ehh...yes and no. Physically, it is a file and nothing more. But its actual use and contents could reflect that of a directory. Are files and directories that different, after all? I don't believe so. They are both an expression of the same thing. Both contain data, one just contains others of itself. Of course, treating a zipfile as a directory will certainly have a performance cost. But here in Linux-land (and elsewhere I'm sure) I can mount, for example, a disk image to a mountpoint anywhere. It's a useful thing to do! Certainly, 7zip present a directory interface. So opening a zipfile/tarfile would be like opening a directory, which we normally do not do. On the other hand, I am not sure I like python's interface to directories that much. I don't think we should make comparisons between applications and API's. Ehh...yes and no again. Maybe the applications are on to something? Whether the filesystem is physically on disk or is just a representation of a filesystem on a file in a filesystem on disk, treating them both as a filesystem is a useful abstraction (NOT the only one available?) It would be more sensible to open files within the archives. Certainly, it would be nice to have the result act like file objects as much as possible. Well you still need to start at the treetop (which is the zip/tar file) because lots of important information is exposed at that level: * compressed file listing * created, modified times * adding / deleting * etc. I'll admit you could think of it as a directory but i would not want to do that. People need to realize that tar and zip files are FILES and NOT folders. I think it's a useful abstraction to think if an archive as a directory. They ARE files, yes. But must their physical representation impact their semantics? I think not! It doesn't matter if Python's list object is a linked-list down under or if it isn't. Or any sequence, for that matter! It's a useful abstraction to treat them all as sequences, uniform interface etc, even though one sequence might be a linked list in a C module, or a row from a database, or whatever! Seaching open issues for 'tarfile' or 'zipfile' returns about 40 issues each. So I think some people would care more about fixing bugs than adjusting the interfaces. Of course, some of the issues may be about the interface and increasing consistency where it can be done without compatibility issues. Yes i agree! If we can at least do something as meager as this it would be a step forward. However i still believe the current API is broken beyond repair so we must introduce a new archive module. That's my opinion anyway. Checking if such a thing exists already may be more useful. I saw someone mention a project similar? However, I do not think there are any active developers focued on those two modules. We need some fresh blood infused into Python-dev. I have been trying to get involved for a long time. We as a community need to realize that this community is NOT a homogeneous block. We need to be a little more accepting of new folks and new ideas. I know this language would evolve much quicker if we did. Rick: But what about Python 3000? PTB: Oh, well, umm, lets see. Well that was then and this is now! The changes made for 3.0 were more than enough for some people to discourage migration to Py3. And we *have* made additional changes since. So the resistance to incompatible feature changes has increased. Yes i do understand these changes have been very painful for some folks (me included). However there is only but one constant in this universe and that constant is change. I believe we can improve many of these API's starting with zip/tar modules. By the time Python 4000 gets here (and it will be much sooner than you guys realize!) we need to have this stdlib in pristine condition. That means: * Removing style guide violations. * Removing inconsistencies in existing API's. * Making sure doc strings and comments are everywhere. * Cleaning up the IDLE library (needs a complete re-write!) * Cleaning up Tkinter. * And more All noble goals. I think the fact that everyone* knows that the stdlib is a mess and not the epitome of Good Python is kinda sad... * for some definition of everyone -- Corey Richardson Those who deny freedom to others, deserve it not for themselves -- Abraham Lincoln signature.asc Description: PGP signature --
Re: Can someone help please
Hey! Is Billy a responder, rather than the OP? Sorry then! My previous point is entirely nullified. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can someone help please
Hey Billy. That may not be the important part of the code, but the many people giving up their free time to read it and help you don't know that. It's probably most helpful to give them a working example so as not to waste their time. Just sayin for future, is all. :-) Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about timeit
Am 22.07.2011 08:59 schrieb Frank Millman:
My guess is that it is something to do with the console, but I don't
know what. If I get time over the weekend I will try to get to the
bottom of it.
I would guess that in the first case, python (resp. timeit.py) gets the
intended code for execution: int(float('165.0')). I. e., give the string
to float() and its result to int().
In the second case, however, timeit.py gets the string
'int(float(165.0))' and evaluates it - which is a matter of
sub-microseconds.
The reason for this is that the Windows shell removes the in the
first case, but not the '' in the second case.
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
Writing a MUD Console
I had this idea on an easy way to write a MUD console.
Basically, you start a program written in Python. This will connect to
the MUD of your choice, and otherwise behave like Telnet. In fact, it
will just spawn telnet to do all the hard work for you.
As you type commands, they are piped directly into the telnet process
as MUD input commands. Commands that start with ! or maybe # will be
intercepted, however, and interpreted as special commands
Also, as output comes back, you can put hooks in to react to the data
and execute Python functions, or pipe the data to subprocesses you may
spawn. For instance, you might spawn a subprocess that opens up a
window to show your current map location. When the MUD sends the map,
it is intercepted and directed to this map subprocess. Your status
line could be interpreted and displayed in another window in graphical
format.
I have the feeling that this isn't that hard to do. It's just a matter
of getting the right combination of subprocesses working.
My preliminary experiments with the telnet subprocess have had curious results:
CODE:
import subprocess
import sys
import traceback
host = 'midkemiaonline.com'
port = '23'
conn = subprocess.Popen(
['/usr/bin/telnet', host, port],
stdin=subprocess.PIPE,
stdout=sys.stdout,
stderr=sys.stderr)
def do_command(cmd):
print \n {}.format(cmd)
try:
result = eval(cmd)
except Exception:
traceback.print_exc()
else:
if result is not None:
print repr(result)
while True:
cmd = raw_input()
if cmd[:1] == '!':
do_command(cmd[1:])
else:
conn.stdin.write(cmd)
conn.terminate()
END CODE
It seems all goes well, except certain input sequences are being
intercepted. For instance, CTRL-C throws a KeyboardInterrupt.
Also, I only get to enter one command:
$ ./telnetsubprocess.py
Trying 209.212.147.74...
Connected to midkemiaonline.com.
Escape character is '^]'.
Rapture Runtime Environment v2.1.6 -- (c) 2010 -- Iron Realms Entertainment
Multi-User License: 100-0004-000
*
-- Midkemia Online --
*
[Open Beta]
Based on the novels by Raymond E. Feist
Midkemia Online's IP address is 209.212.147.74
For general questions e-mail supp...@midkemiaonline.com
There are 20 people currently on-line.
1. Enter the game.
2. Create a new character.
3. Quit.
Enter an option or your character's name. 1
Traceback (most recent call last):
File ./telnetsubprocess.py, line 17, in module
cmd = raw_input()
EOFError
Connection closed by foreign host.
Any ideas on what is going on here?
--
Jonathan Gardner
jgard...@jonathangardner.net
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
Am 22.07.2011 00:45 schrieb Terry Reedy: Whether or not they are intended, the rationale is that lining up does not work with proportional fonts. Who on earth would use proportional fonts in programming?! -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about timeit
Thomas Rachel, 22.07.2011 10:08:
Am 22.07.2011 08:59 schrieb Frank Millman:
My guess is that it is something to do with the console, but I don't
know what. If I get time over the weekend I will try to get to the
bottom of it.
I would guess that in the first case, python (resp. timeit.py) gets the
intended code for execution: int(float('165.0')). I. e., give the string to
float() and its result to int().
In the second case, however, timeit.py gets the string
'int(float(165.0))' and evaluates it - which is a matter of
sub-microseconds.
The reason for this is that the Windows shell removes the in the first
case, but not the '' in the second case.
Good call. Or maybe it actually gets the code 'int(float(165.0))' in the
second case, so it doesn't need to parse the string into a float. But given
the huge difference in the timings, I would second your guess that it just
evaluates the plain string itself instead of the code.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs
On Thu, Jul 21, 2011 at 08:46:05PM -0700, rantingrick wrote: I may have found the mother of all inconsitency warts when comparing the zipfile and tarfile modules. Not only are the API's different, but the entry and exits are differnet AND zipfile/tarfile do not behave like proper file objects should. There is a reason why these two APIs are different. When I wrote tarfile zipfile had already been existing for maybe 8 years and I didn't like its interface very much. So, I came up with a different one for tarfile that in my opinion was more general and better suited the format and the kind of things I wanted to do with it. In the meantime the zipfile API got a lot of attention and some portions of tarfile's API were ported to zipfile. *COMMENT* As you can see, the tarfile modules exports an open function and zipfile does not. Actually i would prefer that neither export an open function and instead only expose a class for instantion. So that is your preference. *COMMENT* Since a zipfile object is a file object then asking for the tf object after the object after the file is closed should show a proper message! It is no file object. *COMMENT* Tarfile is missing the attribute fp and instead exposes a boolean closed. This mismatching API is asinine! Both tarfile and zipfile should behave EXACTLY like file objects No, they don't. Because they have not much in common with file objects. I am not sure what you are trying to prove here. And although I must admit that you have a point overall you seem to get the details wrong. If tarfile and zipfile objects behave EXACTLY like file objects, what does the read() method return? What does seek() do? And readline()? What do you prove when you say that tarfile has no fp attribute? You're not supposed to use the tarfile's internal file object, there is nothing productive you could do with it. *COMMENT* As you can see, unlike tarfile zipfile cannot handle a passed path. Hm, I don't know what you mean. zf.namelist() - tf.getnames() zf.getinfo(name) - tf.getmenber(name) zf.infolist() - tf.getmembers() zf.printdir() - tf.list() *COMMENT* Would it have been too difficult to make these names match? Really? As I already stated above, I didn't want to adopt the zipfile API because I found it unsuitable. So I came up with an entirely new one. I thought that being incompatible was better than using an API that did not fit exactly. *COMMENT* Note the inconsistencies in naming conventions of the zipinfo methods. *COMMENT* Not only is modified time named different between zipinfo and tarinfo, they even return completely different values of time. See above. It is very obvious that these modules need some consistency between not only themselves but also collectively. People, when emulating a file type always be sure to emulate the built-in python file type as closely as possible. See above. PS: I will be posting more warts very soon. This stdlib is a gawd awful mess! I do not agree. Although I come across one or two odd things myself from time to time, I think the stdlib as a whole is great, usable and powerful. The stdlib surely needs our attention. Instead of answering your post, I should have been writing code and fixing bugs ... -- Lars Gustäbel l...@gustaebel.de Seek simplicity, and distrust it. (Alfred North Whitehead) -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On Thu, Jul 21, 2011 at 10:58:37PM -0700, rantingrick wrote: My hat is off to you Mr. Richardson. I've even considered creating my own clean versions of these two modules, because heck, it is not that difficult to do! However we must stop fixing these warts on a local level Corey. We MUST clean up this damn python stdlib once and for all. One could get the impression that you are leading a grass-roots movement fighting a big faceless corporation. Instead, what you're dealing with is this warm and friendly Python community you could as well be a part of if you are a reasonable guy and write good code. I am willing and you are willing; that's two people. However, can we convince the powers that be to upgrade these modules? Sure, if we get enough people shouting for it to happen they will notice. So come on people make your voices heard. Chime in and let the devs know we are ready to unite and tackle these problems in our stdlib. Yeah, great. Please write code. Or a PEP. What this community needs (first and foremost) is some positive attitudes. If you don't want to write the code fine. But at least chime in and say... Hey guys, that's a good idea! I would like to see some of these APIs cleaned up too. good luck! +1 +1 Now, even if we get one hundred people chanting... Yes, Yes, Fix This Mess!... i know Guido and company are going to frown because of backwards incompatibility. But let me tell you something people, the longer we put off these changes the more painful they are going to be. And backwards compatibility is bad why? Tell me, what exactly is your view towards this? Should there be none? Python 3000 would have been the perfect time to introduce a more intuitive and unified zip/tar archive module however that did not happen. So now we need to think about adding a duplicate module archive.py and deprecating zipfile.py and tarfile.py. We can remove the old modules when Python 4000 rolls out. That's just step one people, we have a long way to go! archive.py is no new idea. Unfortunately, to this day, nobody had the time to come up with an implementation. Let me say it again: less false pathos, more code. Please. -- Lars Gustäbel l...@gustaebel.de To a man with a hammer, everything looks like a nail. (Mark Twain) -- http://mail.python.org/mailman/listinfo/python-list
Re: Writing a MUD Console
On Fri, Jul 22, 2011 at 6:20 PM, Jonathan Gardner jgard...@jonathangardner.net wrote: I had this idea on an easy way to write a MUD console. Basically, you start a program written in Python. This will connect to the MUD of your choice, and otherwise behave like Telnet. In fact, it will just spawn telnet to do all the hard work for you. The hard work as you call it is simply: Open socket connection (possibly a DNS lookup), and parse some fairly simple TELNET codes (stuff like go into password mode). As you type commands, they are piped directly into the telnet process as MUD input commands. Commands that start with ! or maybe # will be intercepted, however, and interpreted as special commands Also, as output comes back, you can put hooks in to react to the data and execute Python functions, or pipe the data to subprocesses you may spawn. For instance, you might spawn a subprocess that opens up a window to show your current map location. When the MUD sends the map, it is intercepted and directed to this map subprocess. Your status line could be interpreted and displayed in another window in graphical format. Yep, these sorts of ideas are fine. And will work just as easily when you do the socket connection yourself. In the early days of Android, my brother couldn't find a decent MUD client, so I whipped one up for him in Python. The project never went very far, but it's a start. It works on Linux, not Windows; but since you're referring to /usr/bin/telnet I assume that's not going to be a problem for you! Rather than attach it to this post, I've tossed the script onto my MUD's web site. (Yes, I run a MUD. Your subject line grabbed my attention!) Grab it from http://minstrelhall.com/RosMudAndroid.py and give it a whirl! I haven't tested the code lately. I don't remember whether it's for Python 2 or Python 3. Feel free to pester me with questions; I've written several MUD clients (in various languages) and a couple of MUD servers, and would be happy to share oddments of code with you. Chris Angelico aka Rosuav -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On 22/07/11 10:11, Thomas Rachel wrote: Am 22.07.2011 00:45 schrieb Terry Reedy: Whether or not they are intended, the rationale is that lining up does not work with proportional fonts. Who on earth would use proportional fonts in programming?! Why not? I don't (it doesn't work with vim), but it happens to be the default of the excellent programmer's editor SciTE. -- http://mail.python.org/mailman/listinfo/python-list
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs
On 22/07/11 05:46, rantingrick wrote: PS: I will be posting more warts very soon. This stdlib is a gawd awful mess! Please don't. Not here. There's a wonderful bug tracker at python.org. Use that. That's where this kind of thing belongs. And, please, be concise. What's the point of shouting it out here anyway? Just fix what you think needs fixing! Sure, you can come here to ask for comments on your new and improved API. Sure, when you've got something presentable, come here and show us. But nobody needs this kind of rant, rantingrick. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 22 Jul, 02:34, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: I think that's a bit of an exaggeration -- there's only one major dependency on each platform, and it's a very widely used one (currently PyObjC/PyGTK/PyWin32). And I'm thinking about ways to reduce the dependencies further, Pyrex or Cython? -- http://mail.python.org/mailman/listinfo/python-list
Re: WindowsError: exception: access violation
On Fri, Jul 22, 2011 at 7:47 AM, Benjamin Kaplan wrote: Are you using a Cygwin build of Python? Trying to mix Cygwin with normal Windows programs doesn't usually work very well. On 22/07/11 06:41, Sathish S wrote: Benjamin thanks for replying. i'm not using the python that comes with cygwin. Its the regular python 2.7.2 Recompile your DLL with Visual C++ 2008, or use a cygwin build of Python. I see you are using ctypes.cdll - perhaps you just need to use ctypes.windll? I'm not too familiar with the ins and outs of ctypes, cygwin, and windows calling conventions. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On 21 Jul, 16:52, Kevin Walzer k...@codebykevin.com wrote: I bet that other scripting languages would piggyback on top of it (Lua or Ruby bindings for Python's GUI toolkit, anyone?) because doing that is less work than writing your own toolkit from scratch. No doubt about that. Lua has a nice GUI toolkit by the way, which also has a C API. Currently it works on GTK+, Motif and Window. The C API is very small, only about 100 functions. So it makes a good candidate for a new Cython-based toolkit, even without piggybacking on Lua. http://www.tecgraf.puc-rio.br/iup/ -- http://mail.python.org/mailman/listinfo/python-list
Use self.vars in class.method(parameters, self.vars)
I'm very very new with python, and I have some experience with java programming, so probably you guys will notice. Anyway this is my question: I'd like to use class scope vars in method parameter, something like that class foo(object): __init__(self, len = 9): self.__myvar = len def foo2(self, len = self_myvar): while i len: dosomething I want to use optional parameter, so i can use myfoo = foo() or myfoo = foo(20) and also foo.foo2(20) or foo.foo2() but in def foo2(self, len = self_myvar): ^ self is undefined, so: How can I do this stuff? -- http://mail.python.org/mailman/listinfo/python-list
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs
On 07/22/2011 03:26 AM, Lars Gustäbel wrote: On Thu, Jul 21, 2011 at 08:46:05PM -0700, rantingrick wrote: Tarfile is missing the attribute fp and instead exposes a boolean closed. This mismatching API is asinine! Both tarfile and zipfile should behave EXACTLY like file objects What do you prove when you say that tarfile has no fp attribute? You're not supposed to use the tarfile's internal file object, there is nothing productive you could do with it. While I've needed access to such a fp object, it's been limited to cases where I passed a file-like object to the constructor instead of a path-name: tf = tarfile.open(fileobj=foo, ...) so I had access to foo without reaching into the tarfile/zipfile object for the internal fp. Usually this involves using a StringIO object or a temp-file that then gets cleaned up when complete. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
I think you did a typo it is def foo2(self, len = self._myvar): while i len: dosomething You forget '.' dot between self and _myvar By the way in the function header you have only one '_' and in the init you have 2 '_'. Be careful that's not the same variable and behavior in case you want to access it. Regards Karim On 07/22/2011 01:12 PM, caccolangrifata wrote: I'm very very new with python, and I have some experience with java programming, so probably you guys will notice. Anyway this is my question: I'd like to use class scope vars in method parameter, something like that class foo(object): __init__(self, len = 9): self.__myvar = len def foo2(self, len = self_myvar): while i len: dosomething I want to use optional parameter, so i can use myfoo = foo() or myfoo = foo(20) and also foo.foo2(20) or foo.foo2() but in def foo2(self, len = self_myvar): ^ self is undefined, so: How can I do this stuff? -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On 22/07/11 13:12, caccolangrifata wrote: I'm very very new with python, and I have some experience with java programming, so probably you guys will notice. Anyway this is my question: I'd like to use class scope vars in method parameter, something like that class foo(object): __init__(self, len = 9): self.__myvar = len def foo2(self, len = self_myvar): while i len: dosomething I think what you want to do is this: class foo (object): def __init__(self, len=9): self._len = len def foo2(self, len=None): if len is None: len = self._len # ... Default arguments are for when you want to use exactly the same object each time the function/method is called. If you the object you want to use depends on something, you can use this arg=None idiom. -- http://mail.python.org/mailman/listinfo/python-list
Re: What Programing Language are the Largest Website Written In?
You're partially right. As far as I know, Facebook uses HipHop which translates PHP to C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Jul 22, 1:33 pm, Thomas Jollans t...@jollybox.de wrote: On 22/07/11 13:12, caccolangrifata wrote: I'm very very new with python, and I have some experience with java programming, so probably you guys will notice. Anyway this is my question: I'd like to use class scope vars in method parameter, something like that class foo(object): __init__(self, len = 9): self.__myvar = len def foo2(self, len = self_myvar): while i len: dosomething I think what you want to do is this: class foo (object): def __init__(self, len=9): self._len = len def foo2(self, len=None): if len is None: len = self._len # ... Default arguments are for when you want to use exactly the same object each time the function/method is called. If you the object you want to use depends on something, you can use this arg=None idiom. Yep! Leaving aside the typos, that's exactly I want to do. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On 22/07/11 13:32, Karim wrote: I think you did a typo it is def foo2(self, len = self._myvar): while i len: dosomething That, of course, won't work: the default argument (in this case: self._myvar) is looked up when the function is created, and stored with the function. self does not exist at that point. (or, if it does, it's the wrong self) -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about timeit
On Jul 22, 10:34 am, Stefan Behnel stefan...@behnel.de wrote:
Thomas Rachel, 22.07.2011 10:08:
Am 22.07.2011 08:59 schrieb Frank Millman:
My guess is that it is something to do with the console, but I don't
know what. If I get time over the weekend I will try to get to the
bottom of it.
I would guess that in the first case, python (resp. timeit.py) gets the
intended code for execution: int(float('165.0')). I. e., give the string to
float() and its result to int().
In the second case, however, timeit.py gets the string
'int(float(165.0))' and evaluates it - which is a matter of
sub-microseconds.
The reason for this is that the Windows shell removes the in the first
case, but not the '' in the second case.
Good call. Or maybe it actually gets the code 'int(float(165.0))' in the
second case, so it doesn't need to parse the string into a float. But given
the huge difference in the timings, I would second your guess that it just
evaluates the plain string itself instead of the code.
Stefan- Hide quoted text -
- Show quoted text -
This is what I get after modifying timeit.py as follows -
if args is None:
args = sys.argv[1:]
+ print(args)
C:\python -m timeit int(float('165.0'))
[int(float('165.0'))]
10 loops, best of 3: 3.43 usec per loop
C:\python -m timeit int(float(165.0))
['int(float(165.0))']
100 loops, best of 3: 1.97 usec per loop
C:\python -m timeit int(float('165.0'))
[int(float('165.0'))]
10 loops, best of 3: 3.45 usec per loop
It seems that the lesson is -
1. Use double-quotes around the command itself - may not be necessary
if the command does not contain spaces.
2. Use single-quotes for any literals in the command.
Frank
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about timeit
On 22/07/11 14:30, Frank Millman wrote:
This is what I get after modifying timeit.py as follows -
if args is None:
args = sys.argv[1:]
+ print(args)
C:\python -m timeit int(float('165.0'))
[int(float('165.0'))]
10 loops, best of 3: 3.43 usec per loop
C:\python -m timeit int(float(165.0))
['int(float(165.0))']
100 loops, best of 3: 1.97 usec per loop
C:\python -m timeit int(float('165.0'))
[int(float('165.0'))]
10 loops, best of 3: 3.45 usec per loop
It seems that the lesson is -
1. Use double-quotes around the command itself - may not be necessary
if the command does not contain spaces.
2. Use single-quotes for any literals in the command.
What about 'int(float(165.0))' (single quotes around the argument)?
Does that pass the single quotes around the argument to Python? Or does
it eliminate all quotes?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
Frank Millman fr...@chagford.com writes: int(float(x)) does the job, and I am happy with that. I was just asking if there were any alternatives. int(float(s)) will corrupt integers larger than 2**53, should you ever need them. int(decimal.Decimal(s)) works with numbers of arbitrary size. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On 2011-07-22, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de wrote: Am 22.07.2011 00:45 schrieb Terry Reedy: Whether or not they are intended, the rationale is that lining up does not work with proportional fonts. Who on earth would use proportional fonts in programming?! Under the assumption that leading white space is important for code formatting, but that all alignment after that is unimportant. Peek at Stroustrup's writing for examples. It really doesn't take much time at all to get used to it. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
compiling qt app extensions with distutils
I'd like to extend my C++ Qt applicaition using distutils. Looking over the tutorial docs (http://docs.python.org/extending/ building.html#building), it seems fairly intuitive for simple examples, but I'm already using a rather complex qmake/Makefile system to get all my cpp files and libraries included. Is it possible to take advantage of the existing makefile (http://pastebin.com/ Ln3NCkNL)? -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On 2011-07-22, Billy Mays no...@nohow.com wrote:
On 7/21/2011 10:40 PM, Thomas 'PointedEars' Lahn wrote:
Billy Mays wrote:
On 07/21/2011 08:46 AM, Web Dreamer wrote:
If you do not want to use 'float()' try:
int(x.split('.')[0])
This is right.
Assuming that the value of `x' is in the proper format, of course. Else you
might easily cut to the first one to three digits of a string representation
(if `.' is the thousands separator of the locale, e. g.)
The point (which was clear to me) was to convert a properly formatted
string representation of a floating point number to an integer.
While that may be clear to you, that's because you've made some
assumptions. Convert a properly formatted string representation of a
floating point number to an integer is not a rigorous definition.
We might also assume the number could be a hex encoded float or be in
scientific notation. If the input is not properly formatted, it is
unreasonable for us to return a correct value.
What does properly formatted mean? Who says that the character
representing the radix is . rather than ,?
Notice the last digit switched from a 3 to a 2? Floats in python don't
have arbitrary accuracy. You would need to import decimal and use it
for rounding to work properly.
It should be floor() though, for that is what int() does.
Um, what?
The example given by the OP implied that int(float(s)) did what he
wanted. That is _not_ rounding the float. It's the equivalent of
using the floor() function.
--
Grant Edwards grant.b.edwardsYow! Maybe we could paint
at GOLDIE HAWN a rich PRUSSIAN
gmail.comBLUE --
--
http://mail.python.org/mailman/listinfo/python-list
Re: compiling qt app extensions with distutils
On 22/07/11 15:43, strattonbrazil wrote: I'd like to extend my C++ Qt applicaition using distutils. Looking over the tutorial docs (http://docs.python.org/extending/ building.html#building), it seems fairly intuitive for simple examples, but I'm already using a rather complex qmake/Makefile system to get all my cpp files and libraries included. Is it possible to take advantage of the existing makefile (http://pastebin.com/ Ln3NCkNL)? What do you want to do? Distutils is used to build extension modules. Do you want to turn your application into a Python module? It seams more likely that you want to embed Python in your application, in which case you're looking at altogether the wrong documentation and you simply have to link with libpythonX.Y like any other library -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On 07/22/2011 10:21 AM, Grant Edwards wrote: While that may be clear to you, that's because you've made some assumptions. Convert a properly formatted string representation of a floating point number to an integer is not a rigorous definition. What does properly formatted mean? Who says that the character representing the radix is . rather than ,? Properly formatted means that Python would accept the string as an argument to float() without raising an exception. Notice the last digit switched from a 3 to a 2? Floats in python don't have arbitrary accuracy. You would need to import decimal and use it for rounding to work properly. It should be floor() though, for that is what int() does. Um, what? The example given by the OP implied that int(float(s)) did what he wanted. That is _not_ rounding the float. It's the equivalent of using the floor() function. int(float(s)) does the right thing for short strings. However, for longer strings it loses information due to the way floats are implemented in Python. Python uses the IEEE754 double precision datatype(double) to implement floating point numbers. The floats only have 53 bits in the mantissa portion of the number which means python can only accurately represent integers up to 2**53 correctly as floats. Compare this to integers in Python, which are automatically upcast to longs if overflow would occur. The int() call will never lose accuracy when converting a properly formatted integer string. float() will lose accuracy, even if the float string is properly formatted. The is no floor() being called or used, this is simply the behavior of the float datatype. You seem to be worrying about python producing invalid output for invalid input (period separated numbers). You should be worrying if valid input (a very long float string) produces invalid output. -- Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: Writing a MUD Console
On Fri, Jul 22, 2011 at 3:25 AM, Chris Angelico ros...@gmail.com wrote: In the early days of Android, my brother couldn't find a decent MUD client, so I whipped one up for him in Python. The project never went very far, but it's a start. It works on Linux, not Windows; but since you're referring to /usr/bin/telnet I assume that's not going to be a problem for you! Rather than attach it to this post, I've tossed the script onto my MUD's web site. (Yes, I run a MUD. Your subject line grabbed my attention!) Grab it from http://minstrelhall.com/RosMudAndroid.py and give it a whirl! I also have a half-finished (but fully usable) MUD client written in Python. It uses Twisted and wxPython and is cross-platform. I would be willing to share the code if somebody is interested. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On 2011-07-22, Billy Mays 81282ed9a88799d21e77957df2d84bd6514d9...@myhashismyemail.com wrote: On 07/22/2011 10:21 AM, Grant Edwards wrote: While that may be clear to you, that's because you've made some assumptions. Convert a properly formatted string representation of a floating point number to an integer is not a rigorous definition. What does properly formatted mean? Who says that the character representing the radix is . rather than ,? Properly formatted means that Python would accept the string as an argument to float() without raising an exception. Then you can't assume that '.' is the radix character. Notice the last digit switched from a 3 to a 2? Floats in python don't have arbitrary accuracy. You would need to import decimal and use it for rounding to work properly. It should be floor() though, for that is what int() does. Um, what? The example given by the OP implied that int(float(s)) did what he wanted. That is _not_ rounding the float. It's the equivalent of using the floor() function. int(float(s)) does the right thing for short strings. However, for longer strings it loses information due to the way floats are implemented in Python. True but irrelevent to the point that using a rounding conversion is _not_ equivelent to the OP's example using int(float()). Python uses the IEEE754 double precision datatype(double) to implement floating point numbers. The floats only have 53 bits in the mantissa portion of the number which means python can only accurately represent integers up to 2**53 correctly as floats. Compare this to integers in Python, which are automatically upcast to longs if overflow would occur. The int() call will never lose accuracy when converting a properly formatted integer string. float() will lose accuracy, even if the float string is properly formatted. The is no floor() being called or used, this is simply the behavior of the float datatype. You seem to be worrying about python producing invalid output for invalid input (period separated numbers). You should be worrying if valid input (a very long float string) produces invalid output. No, I'm talking about the claim that you should use decmial so that you can use rounding when the OP's example showed that rounding was not what he wanted. -- Grant Edwards grant.b.edwardsYow! Boys, you have ALL at been selected to LEAVE th' gmail.comPLANET in 15 minutes!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On 07/22/2011 10:58 AM, Grant Edwards wrote: On 2011-07-22, Billy Mays81282ed9a88799d21e77957df2d84bd6514d9...@myhashismyemail.com wrote: Properly formatted means that Python would accept the string as an argument to float() without raising an exception. Then you can't assume that '.' is the radix character. When you use radix, I assume you mean the grouping separator for large numbers, not the base correct? I have always heard radix used as the base (ie base 2) of the number, as in radix sort. No, I'm talking about the claim that you should use decmial so that you can use rounding when the OP's example showed that rounding was not what he wanted. Yes, you are right. I mistyped what I was thinking. Let me rephrase: decimal is needed to preserve the accuracy of the string to `number` conversion. -- Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On 2011-07-22, Billy Mays 81282ed9a88799d21e77957df2d84bd6514d9...@myhashismyemail.com wrote: On 07/22/2011 10:58 AM, Grant Edwards wrote: On 2011-07-22, Billy Mays81282ed9a88799d21e77957df2d84bd6514d9...@myhashismyemail.com wrote: Properly formatted means that Python would accept the string as an argument to float() without raising an exception. Then you can't assume that '.' is the radix character. When you use radix, I assume you mean the grouping separator for large numbers, not the base correct? I have always heard radix used as the base (ie base 2) of the number, as in radix sort. http://en.wikipedia.org/wiki/Radix_point No, I'm talking about the claim that you should use decmial so that you can use rounding when the OP's example showed that rounding was not what he wanted. Yes, you are right. I mistyped what I was thinking. Let me rephrase: decimal is needed to preserve the accuracy of the string to `number` conversion. True. You shouldn't try to use a float for values not within the range of a float. -- Grant Edwards grant.b.edwardsYow! NANCY!! Why is at everything RED?! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Jul 22, 1:12 pm, caccolangrifata caccolangrif...@gmail.com wrote:
Totally OT but others already answered the question...
class foo(object):
class names should start with an uppercase letter:
class Foo(object):
__init__(self, len = 9):
1/ you want to add a def statement before __init__
2/ the argument name ('len') will shadow the builtin 'len' function
within this function's scope.
self.__myvar = len
There are very few reasons to invoke the __name_mangling mechanism.
Canonically, implementation attributes (ie: not part of the API) are
written with a *single* leading underscore. Also and FWIW, there's no
need to hide public attributes and add dummy accessors in Python
since you can turn a plain attribute into a computed one latter
without breaking client code, so only use _implementation attributes
if you really mean implementation.
def foo2(self, len = self_myvar):
while i len:
dosomething
Most of the time, this is spelled:
for x in somesquence:
do_something
Note that range() can provide the required sequence.
I want to use optional parameter, so i can use
myfoo = foo() or myfoo = foo(20)
and also
foo.foo2(20) or foo.foo2()
Note that default values for function params are only computed once,
when the def statement is evaluated. This is a famous gotcha,
specially if you use some mutable object as default value...
Also, since neither the class nor - a fortiori - the instance exist
when the def statement is evaluated, there's no way to make reference
to the instance at this time.
--
http://mail.python.org/mailman/listinfo/python-list
Re: compiling qt app extensions with distutils
I have a simple Qt app that renders a scene in OpenGL does some very basic geometry routines. I originally was planning extending my app just by including Python.h and the corresponding lib possibly using pythonqt, but every time I brought it up on the python mailing list, many would say I should be extending it instead usually referencing this article (http://twistedmatrix.com/users/glyph/rant/ extendit.html). The article makes pretty good sense in most cases. I could see the value of extending it as a module if my app ever wanted to be used a library, but then I would have to do the whole business of making a complex setup.py file to match the current Makefile. I can't find any other docs on doing this to a Qt app/library though (especially since Trolltech uses the terms extend and embed interchangeably). The article does seem to glean over the difficulties of extending a complex app and the python docs, at least, seem to present embedding python as just a viable and worthwhile option. Like I said, the article made sense in theory, but at the same time I have limited time to work on my project and don't want to spend too much time trying to figure out out to create a Qt extension-- especially since it looks like few others have actually done it. Is there a way to build a simple python module from my existing makefile? Or should I just stick with embedding for now using the existing makefile? Thanks. On Jul 22, 7:29 am, Thomas Jollans t...@jollybox.de wrote: On 22/07/11 15:43, strattonbrazil wrote: I'd like to extend my C++ Qt applicaition using distutils. Looking over the tutorial docs (http://docs.python.org/extending/ building.html#building), it seems fairly intuitive for simple examples, but I'm already using a rather complex qmake/Makefile system to get all my cpp files and libraries included. Is it possible to take advantage of the existing makefile (http://pastebin.com/ Ln3NCkNL)? What do you want to do? Distutils is used to build extension modules. Do you want to turn your application into a Python module? It seams more likely that you want to embed Python in your application, in which case you're looking at altogether the wrong documentation and you simply have to link with libpythonX.Y like any other library -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
You're right. Sure the method header is evaluated first I usually not fall in this trap when default is a list but a singleton one with the same id. I answered too fast, I did not understand if he forget the dot or what. And the double '_' in init was strange because he uses only one '_' after. Thanks to take time to point that. Regards Karim On 07/22/2011 02:06 PM, Thomas Jollans wrote: On 22/07/11 13:32, Karim wrote: I think you did a typo it is def foo2(self, len = self._myvar): while i len: dosomething That, of course, won't work: the default argument (in this case: self._myvar) is looked up when the function is created, and stored with the function. self does not exist at that point. (or, if it does, it's the wrong self) -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Jul 22, 5:43 pm, bruno.desthuilli...@gmail.com
bruno.desthuilli...@gmail.com wrote:
On Jul 22, 1:12 pm, caccolangrifata caccolangrif...@gmail.com wrote:
Totally OT but others already answered the question...
class foo(object):
class names should start with an uppercase letter:
class Foo(object):
__init__(self, len = 9):
1/ you want to add a def statement before __init__
as just said, Leaving aside the typos ...
2/ the argument name ('len') will shadow the builtin 'len' function
within this function's scope.
self.__myvar = len
I have experience in java programming so using function calling
without () is foolish for me XD, but that a great suggestion
There are very few reasons to invoke the __name_mangling mechanism.
Canonically, implementation attributes (ie: not part of the API) are
written with a *single* leading underscore. Also and FWIW, there's no
need to hide public attributes and add dummy accessors in Python
since you can turn a plain attribute into a computed one latter
without breaking client code, so only use _implementation attributes
if you really mean implementation.
I do not really already understand the mechanism of using private
public vars in python.
def foo2(self, len = self_myvar):
while i len:
dosomething
Most of the time, this is spelled:
for x in somesquence:
do_something
Note that range() can provide the required sequence.
yep..when the range is known is better use for right.
I want to use optional parameter, so i can use
myfoo = foo() or myfoo = foo(20)
and also
foo.foo2(20) or foo.foo2()
Note that default values for function params are only computed once,
when the def statement is evaluated. This is a famous gotcha,
specially if you use some mutable object as default value...
Also, since neither the class nor - a fortiori - the instance exist
when the def statement is evaluated, there's no way to make reference
to the instance at this time.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Jul 22, 6:54 pm, Karim karim.liat...@free.fr wrote: You're right. Sure the method header is evaluated first I usually not fall in this trap when default is a list but a singleton one with the same id. I answered too fast, I did not understand if he forget the dot or what. And the double '_' in init was strange because he uses only one '_' after. Thanks to take time to point that. Regards Karim On 07/22/2011 02:06 PM, Thomas Jollans wrote: On 22/07/11 13:32, Karim wrote: I think you did a typo it is def foo2(self, len = self._myvar): while i len: dosomething That, of course, won't work: the default argument (in this case: self._myvar) is looked up when the function is created, and stored with the function. self does not exist at that point. (or, if it does, it's the wrong self) class foo(object): def __init__(self, len = 9): self.__myvar = len def foo2(self, len = self.__myvar): while i len: do_something that the initial code, . and _ forgot -- http://mail.python.org/mailman/listinfo/python-list
Re: Writing a MUD Console
On Fri, Jul 22, 2011 at 2:25 AM, Chris Angelico ros...@gmail.com wrote: Rather than attach it to this post, I've tossed the script onto my MUD's web site. (Yes, I run a MUD. Your subject line grabbed my attention!) Grab it from http://minstrelhall.com/RosMudAndroid.py and give it a whirl! That code is surprisingly simple. Let me write one that uses asyncore so that the looping can incorporate other async processes as well. -- Jonathan Gardner jgard...@jonathangardner.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On Jul 22, 3:26 am, Lars Gustäbel l...@gustaebel.de wrote:
There is a reason why these two APIs are different. When I wrote tarfile
zipfile had already been existing for maybe 8 years and I didn't like its
interface very much. So, I came up with a different one for tarfile that in my
opinion was more general and better suited the format and the kind of things I
wanted to do with it. In the meantime the zipfile API got a lot of attention
and some portions of tarfile's API were ported to zipfile.
Well i'll admit that i do like like the tarfile's API much better; so
kudos to you kind sir.
*COMMENT*
As you can see, the tarfile modules exports an open function and
zipfile does not. Actually i would prefer that neither export an open
function and instead only expose a class for instantion.
So that is your preference.
WWrong! It is more that just a MERE preference. Tarfile and zipfile
are BOTH archive modules and as such should present a consistent API.
I really don't care so much about the actual details AS LONG AS THE
APIs ARE CONSISTENT!
*COMMENT*
Since a zipfile object is a file object then asking for the tf object
after the object after the file is closed should show a proper
message!
It is no file object.
Then why bother to open and close it like a file object? If we are not
going to treat it as a file object then we should not have API methods
open and close.
*COMMENT*
Tarfile is missing the attribute fp and instead exposes a boolean
closed. This mismatching API is asinine! Both tarfile and zipfile
should behave EXACTLY like file objects
If tarfile and zipfile
objects behave EXACTLY like file objects, what does the read() method
return?
What does seek() do? And readline()?
I am not suggesting that these methods become available. What i was
referring to is the fact that the instance does not return its current
state like a true file object would. But just for academic sake we
could apply these three methods in the following manner:
* read() - extract the entire archive.
* readline() - extract the N'ith archive member.
* seek() - move to the N'ith archive member.
Not that i think we should however.
What do you prove when you say that tarfile has no fp attribute?
My point is that the API's between tarfile and zipfile should be
consistent. fp is another example of inconsistency. If we are going
to have an fp method in one, we should have it in the other.
*COMMENT*
As you can see, unlike tarfile zipfile cannot handle a passed path.
Hm, I don't know what you mean.
Sorry that comment was placed in the wrong position. I also eulogizer
for sending the message three times; it seems my finger was a little
shaky that night. What i was referring to is that tarfile does not
allow a path to be passed to the constructor whereas zipfile does:
import tarfile, zipfile
tf = tarfile.TarFile('c:\\tar.tar')
Traceback (most recent call last):
File pyshell#1, line 1, in module
tf = tarfile.TarFile('c:\\tar.tar')
File C:\Python27\lib\tarfile.py, line 1572, in __init__
self.firstmember = self.next()
File C:\Python27\lib\tarfile.py, line 2335, in next
raise ReadError(str(e))
ReadError: invalid header
zf = zipfile.ZipFile('C:\\zip.zip')
zf
zipfile.ZipFile instance at 0x02C6CE18
zf.namelist() - tf.getnames()
zf.getinfo(name) - tf.getmenber(name)
zf.infolist() - tf.getmembers()
zf.printdir() - tf.list()
*COMMENT*
Would it have been too difficult to make these names match? Really?
As I already stated above, I didn't want to adopt the zipfile API because I
found it unsuitable. So I came up with an entirely new one. I thought that
being incompatible was better than using an API that did not fit exactly.
I agree with you. Now if we can ONLY change the zipfile API to match
then we would be golden!
PS: I will be posting more warts very soon. This stdlib is a gawd
awful mess!
I do not agree. Although I come across one or two odd things myself from time
to time, I think the stdlib as a whole is great, usable and powerful.
And that's why we find ourselves in this current dilemma. This stdlib
IS a mess and yours and everyone else's denials about it is not
helping the situation.
The stdlib surely needs our attention. Instead of answering your post, I
should
have been writing code and fixing bugs ...
Will you be starting with the zipfile API migration?
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On Jul 22, 2011, at 12:23, Thomas Jollans wrote: On 22/07/11 10:11, Thomas Rachel wrote: Am 22.07.2011 00:45 schrieb Terry Reedy: Whether or not they are intended, the rationale is that lining up does not work with proportional fonts. Who on earth would use proportional fonts in programming?! Why not? Indeed. Since Windows95 I always use a proportional font for programming: http://www.michielovertoom.com/incoming/comic-sans-python.jpg It's so elegant and gives aesthetic pleasure to look at. Greetings, -- If you don't know, the thing to do is not to get scared, but to learn. - Ayn Rand -- http://mail.python.org/mailman/listinfo/python-list
Re: Writing a MUD Console
On Sat, Jul 23, 2011 at 3:12 AM, Jonathan Gardner jgard...@jonathangardner.net wrote: On Fri, Jul 22, 2011 at 2:25 AM, Chris Angelico ros...@gmail.com wrote: Rather than attach it to this post, I've tossed the script onto my MUD's web site. (Yes, I run a MUD. Your subject line grabbed my attention!) Grab it from http://minstrelhall.com/RosMudAndroid.py and give it a whirl! That code is surprisingly simple. Let me write one that uses asyncore so that the looping can incorporate other async processes as well. Yes, it is; and you don't necessarily need all of that. I haven't really put any sort of license on that, so I'll hereby formally release it as CC-BY-SA (and have modified the version on my web site to say so). ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On Sat, Jul 23, 2011 at 3:11 AM, rantingrick rantingr...@gmail.com wrote: WWrong! It is more that just a MERE preference. Tarfile and zipfile are BOTH archive modules and as such should present a consistent API. I really don't care so much about the actual details AS LONG AS THE APIs ARE CONSISTENT! Python and C++ are BOTH programming languages and as such should present a consistent API. I really don't care so much about the actual details capsas long as the APIs (standard libraries) are consistent!/caps Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
Oh, and: On Sat, Jul 23, 2011 at 3:11 AM, rantingrick rantingr...@gmail.com wrote: Will you be starting with the zipfile API migration? Will you? Rick, quit ranting and start coding. If you want things to happen, the best way is to do them. If you make a post on the dev list WITH A PATCH, or submit your patch on the bug tracker, then people might start taking you seriously. In other words, put up or shut up. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
Be careful when using double underscore prefix the variable is said to be private but in fact you can modify it. It is a convention to say don't change it. And to discourage to use it python change its name to '_class name__myvar' appending the prefix '_class name' to it. See with your example: karim@Requiem4Dream:~$ python Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2 Type help, copyright, credits or license for more information. a = foo() dir(a) ['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_foo__myvar', 'foo2'] In the instance namespace your attribute was transformed in '_foo__myvar'. This is a veritable mess when you want to access from outside your class this attribute. For maintenance when you inherited you have huge coupling NEVER DO THAT (advice): In case you change the name of your class and reference this attribute in external class you will end up with huge trouble to change the name in all referenced code. With one '_' it says to others well this is my non public variable don't use it (this is a convention because you can still modify it in python. Cheers Karim On 07/22/2011 06:59 PM, caccolangrifata wrote: while i len: -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On Sat, Jul 23, 2011 at 3:05 AM, Michiel Overtoom mot...@xs4all.nl wrote: Indeed. Since Windows95 I always use a proportional font for programming: http://www.michielovertoom.com/incoming/comic-sans-python.jpg It's so elegant and gives aesthetic pleasure to look at. http://xkcd.com/590/ ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On Jul 22, 3:49 am, Lars Gustäbel l...@gustaebel.de wrote: One could get the impression that you are leading a grass-roots movement fighting a big faceless corporation. Instead, what you're dealing with is this warm and friendly Python community you could as well be a part of if you are a reasonable guy and write good code. Sometimes i do feel as if i am fighting against an evil empire. I am a reasonable guy and i do write -good-, no excellent code. Yeah, great. Please write code. Or a PEP. I am not about to just hop through all the hoops of PEP and PEP8 code just to have someone say Sorry, we are not going to include your code. What i want at this point is to get feedback from everyone about this proposed archive.py module. Because unlike other people, i don't want to ram MY preferred API down others throats. Step one is getting feedback on the idea of including a new archive module. Step two is hammering out an acceptable API spec. Step three is is actually writing the code and finally getting it accepted into the stdlib. Not only do i need feedback from everyday Python scripters, i need feedback from Python-dev. I even need feedback from the great GvR himself! (maybe not right away but eventually). What this community needs (first and foremost) is some positive attitudes. If you don't want to write the code fine. But at least chime in and say... Hey guys, that's a good idea! I would like to see some of these APIs cleaned up too. good luck! +1 +1 Thank you! Now, can you convince your comrades at pydev to offer their opinions here also? Even if all they do is say +1. Now, even if we get one hundred people chanting... Yes, Yes, Fix This Mess!... i know Guido and company are going to frown because of backwards incompatibility. But let me tell you something people, the longer we put off these changes the more painful they are going to be. And backwards compatibility is bad why? Tell me, what exactly is your view towards this? Should there be none? First let me be clear that backwards-compatibility (BC) is very important to any community. We should always strive for BC. However there is no doubt we are going to make mistakes along the way and at some point SOME APIs will need to be broken in the name of consistency or some other important reason. As i've said before Py3000 would have been the PERFECT opportunity to fix this broken API within the current zipfile and tarfile modules. Since that did not happen, we must now introduce a new module archive.py and deprecate the zip and tar modules immediately. We shall remove them forever in Python4000. If you guys think we are done breaking BC, you are in for big surprises! Py3000 was just the beginning of clean-ups. Py4000 is going to be a game changer! And when we finally get to Py4000 and remove all these ugly warts python is going to be a better language for it. Mark my words people! archive.py is no new idea. Unfortunately, to this day, nobody had the time to come up with an implementation. It's time to change; Can't stay the same; Rev-o-lu-tion is MY name! We can never become complacent and believe we have reached perfection because we never will. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On Jul 22, 10:05 pm, Michiel Overtoom mot...@xs4all.nl wrote: On Jul 22, 2011, at 12:23, Thomas Jollans wrote: On 22/07/11 10:11, Thomas Rachel wrote: Am 22.07.2011 00:45 schrieb Terry Reedy: Whether or not they are intended, the rationale is that lining up does not work with proportional fonts. Who on earth would use proportional fonts in programming?! Why not? Indeed. Since Windows95 I always use a proportional font for programming: http://www.michielovertoom.com/incoming/comic-sans-python.jpg It's so elegant and gives aesthetic pleasure to look at. Greetings, -- If you don't know, the thing to do is not to get scared, but to learn. - Ayn Rand Also it is more optimized. For the same size -- and therefore readability -- a proportional font packs in more text. I also find it all the more surprising that python programmers argue against proportional fonts, given that python is one of the odd languages that gives semantic significance to white space. I dont use proportional fonts because the tools are broken. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On Fri, Jul 22, 2011 at 6:59 AM, Neil Cerutti ne...@norwich.edu wrote: Under the assumption that leading white space is important for code formatting, but that all alignment after that is unimportant. ...unless you're trying to adhere to a line length limit. 80 characters is a lot easier to do in a fixed-width font, and 10 inches or 400 pixels or however you want to do it in a proportional font effectively limits you to using that specific font, at that specific size. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On Fri, Jul 22, 2011 at 11:43 AM, rusi rustompm...@gmail.com wrote: Also it is more optimized. For the same size -- and therefore readability -- a proportional font packs in more text. More text == less readability. This is one of the reasons I limit my line lengths. -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Jul 22, 10:43 am, bruno.desthuilli...@gmail.com
bruno.desthuilli...@gmail.com wrote:
class names should start with an uppercase letter:
WRONG! Class identifiers should use the capwords convention
* class Foo
* class FooBar
* class FooBarBaz
--
PEP8.Naming_Conventions.Class_Names
--
Almost without exception, class names use the CapWords convention.
Classes for internal use have a leading underscore in addition.
--
Make sure to follow this directive to a T because if you don't, i
can assure you that you will regret it! I would actually change
Almost without exception to WITHOUT EXCEPTION myself. Actually in
RickPy4000 naming conventions are going to be enforced -- follow them
or die of exceptions.
*Case in point:*
Some folks refuse to cap all words because they think some words
are actually a single compound word. And in the real world they are
correct but in the case sensitve world of programming this can bite
you in the arse later.
Consider:
class Messagebox
class Listview
class Combobox
class ScrolledTextbox
Now later on when you are writing some code you cannot remember which
words you capped and which you did NOT cap. Best thing to do is ALWAYS
cap every word. In other words, be consistent!
class MessageBox
class ListView
class ComboBox
class ScrolledTextBox
*school-bell-rings*
PS: Someone needs to create links in the PEP for faster navigation to
topic of interest OR we need to create a new module called
styleguide.py
import styleguide
styleguide.naming_conventions('class')
Almost without exception, class names use the CapWords convention.
Classes for internal use have a leading underscore in addition.
PEP8: http://www.python.org/dev/peps/pep-0008/
--
http://mail.python.org/mailman/listinfo/python-list
Re: compiling qt app extensions with distutils
On 22/07/11 18:22, strattonbrazil wrote: I have a simple Qt app that renders a scene in OpenGL does some very basic geometry routines. I originally was planning extending my app just by including Python.h and the corresponding lib possibly using pythonqt, but every time I brought it up on the python mailing list, many would say I should be extending it instead usually referencing this article (http://twistedmatrix.com/users/glyph/rant/ extendit.html). The article makes pretty good sense in most cases. I could see the value of extending it as a module if my app ever wanted to be used a library, but then I would have to do the whole business of making a complex setup.py file to match the current Makefile. I can't find any other docs on doing this to a Qt app/library though (especially since Trolltech uses the terms extend and embed interchangeably). The article does seem to glean over the difficulties of extending a complex app and the python docs, at least, seem to present embedding python as just a viable and worthwhile option. Okay, your terminology was confused: you want to extend Python, not your application. First of all, you don't technically need distutils: an extension module is simply a shared library that you can build like any other library, and I'm sure your build system can easily handle that. Then, you can probably use bits of distutils to figure out where to install things to. It may also be possible to subclass the distutils Extension class and let it invoke your existing build system. You could also turn your application into a library independent of Python with your existing build infrastructure, and create a separate Python module, with distutils, that links in turn to that library. This would make building your project a two-part process, of course. Lastly, depending on what your goals are, you might want to consider not integrating Python with your application at all, but exposing what functionality you want to expose to Python via dbus. You could write a skeleton module that exposes dbus proxy objects to Python scripts / modules to make life easier. Like I said, the article made sense in theory, but at the same time I have limited time to work on my project and don't want to spend too much time trying to figure out out to create a Qt extension-- especially since it looks like few others have actually done it. Is there a way to build a simple python module from my existing makefile? Or should I just stick with embedding for now using the existing makefile? Thanks. On Jul 22, 7:29 am, Thomas Jollans t...@jollybox.de wrote: On 22/07/11 15:43, strattonbrazil wrote: I'd like to extend my C++ Qt applicaition using distutils. Looking over the tutorial docs (http://docs.python.org/extending/ building.html#building), it seems fairly intuitive for simple examples, but I'm already using a rather complex qmake/Makefile system to get all my cpp files and libraries included. Is it possible to take advantage of the existing makefile (http://pastebin.com/ Ln3NCkNL)? What do you want to do? Distutils is used to build extension modules. Do you want to turn your application into a Python module? It seams more likely that you want to embed Python in your application, in which case you're looking at altogether the wrong documentation and you simply have to link with libpythonX.Y like any other library -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On 22/07/11 20:38, rantingrick wrote: On Jul 22, 10:43 am, bruno.desthuilli...@gmail.com bruno.desthuilli...@gmail.com wrote: class names should start with an uppercase letter: WRONG! Class identifiers should use the capwords convention All CamelCase names start with an uppercase letter. You WRONG! is wrong. Twat. -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
2/ the argument name ('len') will shadow the builtin 'len' function
within this function's scope.
self.__myvar = len
I have experience in java programming so using function calling
without () is foolish for me XD, but that a great suggestion
No function is being called. It's just that if you tried using the len()
function within that method (where there is a variable called `len'), it
wouldn't work: Python would take your variable and try to call it, not
the builtin function object.
I do not really already understand the mechanism of using private
public vars in python.
Everything is public.
self._foo (leading underscore) is, by convention, used for internal
member variables and methods.
Two leading underscores are the closest thing there is to private: The
name is mangled, and won't be visible to subclasses or external code
under that name (but there's nothing preventing anybody from changing it)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
In 8b6e5067-8861-4ffe-9e3f-4b932c798...@gc8g2000vbb.googlegroups.com rantingrick rantingr...@gmail.com writes: On Jul 22, 10:43=A0am, bruno.desthuilli...@gmail.com bruno.desthuilli...@gmail.com wrote: class names should start with an uppercase letter: WRONG! Class identifiers should use the capwords convention * class Foo * class FooBar * class FooBarBaz But those names do, in fact, start with an uppercase letter as Bruno said. Perhaps Bruno omitted how the remainder of the name should be handled, but he was certainly right about the first letter being capitalized. Why did you say he was wrong? -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On 2011-07-22, Ian Kelly ian.g.ke...@gmail.com wrote: On Fri, Jul 22, 2011 at 6:59 AM, Neil Cerutti ne...@norwich.edu wrote: Under the assumption that leading white space is important for code formatting, but that all alignment after that is unimportant. ...unless you're trying to adhere to a line length limit. 80 characters is a lot easier to do in a fixed-width font, and 10 inches or 400 pixels or however you want to do it in a proportional font effectively limits you to using that specific font, at that specific size. You can fit much more code per unit of horizontal space with a proportionally spaced font. As a result, that issue, while valid, is significantly reduced. Of some concern are consecutive underscores. Unless your font is designed specifically for programming, it can be hard to distinguish from a single underscore. You generally need to use a programming-specialized font even when using fixed width, though, so I'm not sure this issue is unique. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Sat, Jul 23, 2011 at 5:00 AM, John Gordon gor...@panix.com wrote: ... rantingrick rantingr...@gmail.com writes ... WRONG! Why did you say he was wrong? It's Ranting Rick. Why did you expect anything else? :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
In 98u00kfnf...@mid.individual.net Neil Cerutti ne...@norwich.edu writes: You can fit much more code per unit of horizontal space with a proportionally spaced font. As a result, that issue, while valid, is significantly reduced. Is it? I assume one major reason for the 80-character limit is to help the poor sod who will eventually get stuck working with your code on an 80-column fixed width terminal window. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On 2011-07-22, John Gordon gor...@panix.com wrote: In 98u00kfnf...@mid.individual.net Neil Cerutti ne...@norwich.edu writes: You can fit much more code per unit of horizontal space with a proportionally spaced font. As a result, that issue, while valid, is significantly reduced. Is it? I assume one major reason for the 80-character limit is to help the poor sod who will eventually get stuck working with your code on an 80-column fixed width terminal window. It's probably much better for making hard-copies of code than for sharing directly, that is true. Your recipient would be forced to us a similar font. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On 7/22/2011 2:40 AM, rantingrick wrote: On Jul 22, 12:45 am, Terry Reedytjre...@udel.edu wrote: Let me give some overall comments rather than respond point by point. Python-dev is a volunteer *human* community, not a faceless corporation, with an ever-changing composition (a very mutable set;-). It is too small, really, for the current size of the project. Python 3 was mostly about syntax cleanup. Python-dev was not large enough to also do much stdlib cleanup. With the syntax moratorium, attention *was* focused on the stdlib and problems were found. Some functions names was actively incorrect (due to shift from str-unicode to bytes-strings). Some functions were undocumented and ambiguous as to their public/private status. Some deprecations were made that will take effect in 3.3 or 3.4. This introduced the problem that upgrading to Python 3 is no longer a single thing. We really need 2to3.1 (the current 2to3), 2to3.2, 2to3.3, etc, but someone would have to make the new versions, but no one, currently, has the energy and interest to do that. So people who did not port their 2.x code early now use the problem of multiple Python 3 targets as another excuse not to do so now. (Actually, most 2.x code should not be ported, but their are more libraries that we do need in 3.x.) The way to revamp a module is to introduce a new module. Any anythong now must be released first on PyPI. This has precedent. In 2.x days, urllib2 was an upgrade to urllib though I do not if it was on PyPI. For 3.x, Stephen Behnel's argparse supercedess optparse, but the latter remains with the notice in red: Deprecated since version 2.7: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.. Argparse was first released on pypi and versions compatible with earlier than 2.7 and 3.2 remain there. The new 3.3 module 'distribute' is a renamed distutils2. It is now on PyPI, where it has been tested with current and earlier versions and it will remain there even after 3.3 is released. An archive module should be released or at least listed on PyPI. It will thus be available wherther or not incorporated into the stdlib. (Many useful modules never are, partly because the authors recognize that there are disadvantages as well as advantages to being in the stdlib.) It should be compatible with at least 3.1+ so that people can use it and be compatible with multiple 3.x versions. Starting with a version 1.0 implies that the api is subject to change with user experience. This does not preclude also making compatible changes *also* in stdlib modules. And as I mentioned before, there are already a lot of bug and feature requests on the tracker. Merely putting a new face (api) on a sick pig is not enough. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On Jul 22, 7:42 am, Hrvoje Niksic hnik...@xemacs.org wrote:
Frank Millman fr...@chagford.com writes:
int(float(x)) does the job, and I am happy with that. I was just
asking if there were any alternatives.
int(float(s)) will corrupt integers larger than 2**53, should you ever
need them. int(decimal.Decimal(s)) works with numbers of arbitrary
size.
Correct!
'{0:,.0f}'.format(2**53)
'9,007,199,254,740,992'
That's nine-quadrillion people! Only for galactic measurements or
microscopic reasons would you need such large numbers.
PS: GAWD i love that new string format function!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On Jul 22, 2:32 pm, rantingrick rantingr...@gmail.com wrote:
'{0:,.0f}'.format(2**53)
'9,007,199,254,740,992'
Would have been better to say
'{0:,}'.format(2**53)
'9,007,199,254,740,992'
--
http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
Think that you can call you class as you want. If you use CamelCase notation than you are pro programmer? These are just conventions for better code reading and understanding, if I wanna call mYCLasS() python don't report an error, so I think it's useless discuss in that thread about that stuff. -- http://mail.python.org/mailman/listinfo/python-list
Re: compiling qt app extensions with distutils
I have a simple Qt app that renders a scene in OpenGL does some very basic geometry routines. I originally was planning extending my app just by including Python.h and the corresponding lib possibly using pythonqt, but every time I brought it up on the python mailing list, many would say I should be extending it instead usually referencing this article (http://twistedmatrix.com/users/glyph/rant/ extendit.html). The article makes pretty good sense in most cases. I could see the value of extending it as a module if my app ever wanted to be used a library, but then I would have to do the whole business of making a complex setup.py file to match the current Makefile. I can't find any other docs on doing this to a Qt app/library though (especially since Trolltech uses the terms extend and embed interchangeably). The article does seem to glean over the difficulties of extending a complex app and the python docs, at least, seem to present embedding python as just a viable and worthwhile option. Okay, your terminology was confused: you want to extend Python, not your application. Sorry, after I sent that e-mail, I realized I had already mixed up the terms, where I should have written embedding. First of all, you don't technically need distutils: an extension module is simply a shared library that you can build like any other library, and I'm sure your build system can easily handle that. Then, you can probably use bits of distutils to figure out where to install things to. Hrmm, this seems like the most practical solution for me right now. It makes sense to embed python in my application like I originally planned, where I expose the individual functions I want to expose. Eventually if I actually want to provide the exposed functions as a library, I could actually just compile the application to a shared library instead of an executable (just not using the main function). The bindings in the C++ code are the same, correct? Only the way they're built seems different. Lastly, depending on what your goals are, you might want to consider not integrating Python with your application at all, but exposing what functionality you want to expose to Python via dbus. You could write a skeleton module that exposes dbus proxy objects to Python scripts / modules to make life easier. -- http://mail.python.org/mailman/listinfo/python-list
Re: [PyWart 1001] Inconsistencies between zipfile and tarfile APIs
On 7/22/2011 4:26 AM, Lars Gustäbel wrote: On Thu, Jul 21, 2011 at 08:46:05PM -0700, rantingrick wrote: PS: I will be posting more warts very soon. This stdlib is a gawd awful mess! I do not agree. Although I come across one or two odd things myself from time to time, I think the stdlib as a whole is great, usable and powerful. The stdlib surely needs our attention. Instead of answering your post, I should have been writing code and fixing bugs ... I am glad you posted, both to get your rebuttal and know you are still active. I had presumed that the two modules were written by different people at different times and hence the different apis. I do not know the details of either well enough to know how consistent they could be. You are right that discussing can be a distraction from coding;-). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
Poor sod? Makes it sound bad when you say it like that. I am not forced to work at that fixed width, but when I work with code, I often have my vim session split vertically and it's super important to keep things at 80 character to quickly read/edit code. Brandon L. Harris On 07/22/2011 02:13 PM, John Gordon wrote: In98u00kfnf...@mid.individual.net Neil Ceruttine...@norwich.edu writes: You can fit much more code per unit of horizontal space with a proportionally spaced font. As a result, that issue, while valid, is significantly reduced. Is it? I assume one major reason for the 80-character limit is to help the poor sod who will eventually get stuck working with your code on an 80-column fixed width terminal window. -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On 7/22/2011 1:55 AM, Frank Millman wrote:
As the OP, I will clarify what *my* requirement is. This discussion
has gone off at various tangents beyond what I was asking for.
Typical. Don't worry about it ;-).
As suggested above, I am only talking about a string containing int
literals followed by '.' followed by zero or more zeros.
int(float(x)) does the job,
Not given that specification.
s='123456789012345678901.0'
int(float(s))
123456789012345683968
and I am happy with that.
You should only be if you add 'with fewer than 18 digits' after 'int
literals' to your spec.
I was just asking if there were any alternatives.
int(s.split('.')[0])
123456789012345678901
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Jul 22, 2:00 pm, John Gordon gor...@panix.com wrote: Why did you say he (Bruno) was wrong? I'll admit my yelling the word WRONG may have been interpreted as me suggesting that bruno was completely wrong. Bruno is correct about all class identifiers starting with a capital letter HOWEVER if he just stops at that point and does not explain the CapWords convention lots of people may start down the road of a foolish consistency. My chastisement of Bruno was only on the grounds of him failing to offer the required amount of information to a new python programmer. We should ALWAYS remove any ambiguities from our statements to new users AND we should always link to the PEP8 when these type of style questions come up. It is SO very important that WE as a community are consistent in our syntactical conventions. For me PEP8 does not go far enough and very soon i will draft a PyWart Expose concerning the matter. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can someone help please
On Jul 21, 12:02 pm, Gary woody...@sky.com wrote:
--
total = ' '
os.chdir('/home/woodygar/Desktop/Docs')
for i in os.listdir('.'):
--
i was a bad local var choice here! i and x are typically reserved to
represent integer indexes in local loop scope whilst iterating over a
container object. Likewise y and z are meant to represent the next
levels of indexes. However when looping over a list of strings use
something more appropriate like:
for filename in os.listdir('.'):
do_something_with(filename)
--
if '.txt' in i:
--
No, no, don't do that! Do if str.endswith('.txt') instead. Or use the
os.path methods.
--
f = open(i, 'r')
total += f.read()
f.close()
--
Two bad things happening here;
(1.) Need to catch exceptions.
try:
f = open(i, 'r')
total += f.read()
except IOERROR:
freak_out()
else:
f.close()
(2.) NEVER concatenate a string with += in a loop! Instead load the
strings into a list and then use ''.join(lst) method on the list.
filetext = \
This is line one
this is line two
this is line four\
lst = []
for line in filetext.splitlines():
lst.append(line)
lst
['This is line one', 'this is line two', '', 'this is line four']
'\n'.join(lst)
'This is line one\nthis is line two\n\nthis is line four'
print '\n'.join(lst)
This is line one
this is line two
this is line four
--
message = \
Subject: %s
%s
% (SUBJECT,total)
--
Use the new format spec over the old string interpolation if available
in your version of python.
MSG =
Subject: {0}
{1}
MSG.format(SUBJECT,total)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On Sat, Jul 23, 2011 at 5:32 AM, rantingrick rantingr...@gmail.com wrote: That's nine-quadrillion people! Only for galactic measurements or microscopic reasons would you need such large numbers. Never decide that nobody would need numbers bigger than X. Someone will. One common thing to do with big numbers is to use the pieces separately; although I would never recommend floating point for encoded numbers like that. But I quite happily treat BIND serial numbers as straightforward integers, and they're usually something like 2011072203 for the 3rd change on the 22nd of July 2011. That's a fairly small example (in fact, BIND requires that serial numbers fit inside a 32-bit integer, IIRC), but there are plenty of other examples of numbers that get big fast because of that sort of thing. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
On Sat, Jul 23, 2011 at 5:16 AM, rantingrick rantingr...@gmail.com wrote: My chastisement of Bruno was only on the grounds of him failing to offer the required amount of information to a new python programmer. We should ALWAYS remove any ambiguities from our statements to new users AND we should always link to the PEP8 when these type of style questions come up. In other words, every new Python programmer must be sat down with a massive manual and ordered to read it until his eyes bleed and he goes off and finds some other language to use. Is it better for Python if we ensure that all Python code written is written perfectly, or is it better to allow people to write code, use code, learn code, and then later on, learn to do things more conveniently? You really need to learn the difference between language requirements and stylistic advice. You're trying to turn the latter into the former, but there is a good reason for language flexibility. Why am I responding to these trolls? And why am I being so polite as I do so? Rick, put up or shut up. Get some code down or quit talking. (Oh and those are not exclusive ors.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Decorator behavior
I am just trying to wrap my head around decorators in Python, and I'm confused about some behavior I'm seeing. Run the code below (slightly adapted from a Bruce Eckel article), and I get the following output: inside myDecorator.__init__() inside aFunction() Finished decorating aFunction() inside myDecorator.__call__() My question: Why isn't the first print statement in __main__ the first line of code executed? Is aFunction() not closed somehow? #!/usr/bin/env python class myDecorator(object): def __init__(self, f): print inside myDecorator.__init__() f() # Prove that function definition has completed def __call__(self): print inside myDecorator.__call__() @myDecorator def aFunction(): print inside aFunction() if __name__ == '__main__': print Finished decorating aFunction() aFunction() -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
On Fri, Jul 22, 2011 at 12:13 PM, John Gordon gor...@panix.com wrote: In 98u00kfnf...@mid.individual.net Neil Cerutti ne...@norwich.edu writes: You can fit much more code per unit of horizontal space with a proportionally spaced font. As a result, that issue, while valid, is significantly reduced. Is it? I assume one major reason for the 80-character limit is to help the poor sod who will eventually get stuck working with your code on an 80-column fixed width terminal window. What environments with that limitation are still in common use? It's not the '70s anymore; I think we can safely increase the max column width a bit. Cheers, Chris -- http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorator behavior
On Fri, Jul 22, 2011 at 2:38 PM, mhearne808[insert-at-sign-here]gmail[insert-dot-here]com mhearne...@gmail.com wrote: I am just trying to wrap my head around decorators in Python, and I'm confused about some behavior I'm seeing. Run the code below (slightly adapted from a Bruce Eckel article), and I get the following output: inside myDecorator.__init__() inside aFunction() Finished decorating aFunction() inside myDecorator.__call__() My question: Why isn't the first print statement in __main__ the first line of code executed? Is aFunction() not closed somehow? Because everything in the module is executed in order. First the myDecorator class is defined. Then the aFunction function is defined and the decorator is applied to it (which involves calling the decorator). Finally the if condition is tested, and if it's true, the Finished decorating string is printed and the decorated function is called. If this module were not the main module, the exact same thing would happen, except that the if would evaluate false, and so that part of the code would be skipped. By the way, your email address is not mangled. The label part looks like a mangled email, but the actual address part is intact. -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
In article j0cjaf$mum$1...@dough.gmane.org, Terry Reedy tjre...@udel.edu wrote: This introduced the problem that upgrading to Python 3 is no longer a single thing. We really need 2to3.1 (the current 2to3), 2to3.2, 2to3.3, etc, but someone would have to make the new versions, but no one, currently, has the energy and interest to do that. So people who did not port their 2.x code early now use the problem of multiple Python 3 targets as another excuse not to do so now. (Actually, most 2.x code should not be ported, but their are more libraries that we do need in 3.x.) I don't quite understand this. Since 2to3 is included with Python 3, there are, in fact, separate releases of 2to3 for each release of Python 3 so far. And, unlike with Python 2 with a large installed base across a number of versions, Python 3 version support can be and is much more focused now in its early releases. Support for 3.0 was terminated immediately upon release of 3.1. And 3.1 is now in security-fix mode only. So, except for a brief overlap after the initial release of 3.2, there has only been one Python 3 release that needs to be targeted. Of course, that will change over time as adoption continues and mainstream OS's include specific Python 3 releases. But, for now, it's easy: just target the most recent Python 3 release, currently 3.2.1. Don't worry about earlier releases. -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
Excerpts from Chris Rebert's message of Fri Jul 22 16:56:15 -0400 2011: On Fri, Jul 22, 2011 at 12:13 PM, John Gordon gor...@panix.com wrote: In 98u00kfnf...@mid.individual.net Neil Cerutti ne...@norwich.edu writes: You can fit much more code per unit of horizontal space with a proportionally spaced font. As a result, that issue, while valid, is significantly reduced. Is it? I assume one major reason for the 80-character limit is to help the poor sod who will eventually get stuck working with your code on an 80-column fixed width terminal window. What environments with that limitation are still in common use? It's not the '70s anymore; I think we can safely increase the max column width a bit. I agree. I have my tiling WM setup with two columns, giving each terminal 110 characters of breathing space. I still limit my lines to 78 chars though, if not for any reason besides text is nice and easy to read at that width, and everyone else is doing it. I have no reason to change. I've never desired more characters than that. -- Corey Richardson Those who deny freedom to others, deserve it not for themselves -- Abraham Lincoln -- http://mail.python.org/mailman/listinfo/python-list
Re: Use self.vars in class.method(parameters, self.vars)
In article 0ddc2626-7b99-46ee-9974-87439ae09...@e40g2000yqn.googlegroups.com
caccolangrifata caccolangrif...@gmail.com wrote:
I'm very very new with python, and I have some experience with java
programming, so probably you guys will notice.
Anyway this is my question:
I'd like to use class scope vars in method parameter ...
Others have answered what appears to have been your actual
question. Here's an example of using an actual class scope
variable.
(Note: I have a sinus headache, which is probably the source
of some of the weirder names :-) )
class Florg(object):
_DEFAULT_IPPY = 17
@classmethod
def set_default_ippy(cls, ippy):
cls._DEFAULT_IPPY = ippy
def __init__(self, name, ippy = None):
if ippy is None:
ippy = self.__class__._DEFAULT_IPPY
self.name = name
self.ippy = ippy
def zormonkle(self):
print('%s ippy = %s' % (self.name, self.ippy))
def example():
flist = [Florg('first')]
flist.append(Florg('second'))
flist.append(Florg('third', 5))
Florg.set_default_ippy(-4)
flist.append(Florg('fourth'))
flist.append(Florg('fifth', 5))
for florg in flist:
florg.zormonkle()
if __name__ == '__main__':
example()
--
In-Real-Life: Chris Torek, Wind River Systems
Intel require I note that my opinions are not those of WRS or Intel
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
--
http://mail.python.org/mailman/listinfo/python-list
run a script getting 4 arguments from another script
my initial file name is SpO2Sweep.loops.py In the new file I write this code to run the first one. [code:] import SpO2Sweep.loops.py SpO2Sweep.loops.py.run(com1,0,30,0.0001) and It looks like the arguments are not passed to the first file. can someone help me? -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorator behavior
On 01/-10/-28163 02:59 PM, mhearne808[insert-at-sign-here]gmail[insert-dot-here]com wrote: I am just trying to wrap my head around decorators in Python, and I'm confused about some behavior I'm seeing. Run the code below (slightly adapted from a Bruce Eckel article), and I get the following output: inside myDecorator.__init__() inside aFunction() Finished decorating aFunction() inside myDecorator.__call__() My question: Why isn't the first print statement in __main__ the first line of code executed? Is aFunction() not closed somehow? #!/usr/bin/env python class myDecorator(object): def __init__(self, f): print inside myDecorator.__init__() f() # Prove that function definition has completed def __call__(self): print inside myDecorator.__call__() @myDecorator def aFunction(): print inside aFunction() if __name__ == '__main__': print Finished decorating aFunction() aFunction() classes and functions and decorators have some portions that execute when they occur, long before anybody calls them. (I'm sure there are other examples; one might consider imports the same way) In the case of classes, anything outside of the method definitions will happen before the class definition is completed. For example, class attributes happen at that time. For functions/methods, default arguments are evaluated at the definition time. So if the default value makes a call, the call will happen at that time. Function decorators execute right after the corresponding function definition is built. Such decorators won't normally call the function, but as you notice, if you do call it, it will execute. When you think about it, these behaviors are the only reasonable way these things could be done, unless the compiler tried to do some just in time compiling, not really building the code till somebody uses it. And that would make the language a lot different. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: run a script getting 4 arguments from another script
On 23/07/11 00:46, souleymane yo wrote: my initial file name is SpO2Sweep.loops.py In the new file I write this code to run the first one. [code:] import SpO2Sweep.loops.py SpO2Sweep.loops.py.run(com1,0,30,0.0001) and It looks like the arguments are not passed to the first file. can someone help me? tl;dr: rename your file to a valid Python identifier, without periods, for example loops.py. Then, you can use import loops (note: no .py), and loops.run(...) tl: When you say import SpO2Sweep.loops.py, Python interpets the '.' as a separator between nested package/module names, much like your operating system interpets '/' (or perhaps '\') as a separator between directory/file names. Python thus looks for the module or package py within the package loops within the package SpO2Sweep. For this to work, you'd need the following directory layout: ./ SpO2Sweep/ __init__.py loop/ __init__.py py.py Note: A file named __init__.py turns a plain directory into a package that Python recognises. What you actually have is this: ./ SpO2Sweep.loop.py (That won't work) Since Python treats periods specially, and names in Python cannot contain periods (the special meaning of '.' trumps), you can never import a file with that name. - Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: compiling qt app extensions with distutils
On 22/07/11 21:37, strattonbrazil wrote: Okay, your terminology was confused: you want to extend Python, not your application. Sorry, after I sent that e-mail, I realized I had already mixed up the terms, where I should have written embedding. First of all, you don't technically need distutils: an extension module is simply a shared library that you can build like any other library, and I'm sure your build system can easily handle that. Then, you can probably use bits of distutils to figure out where to install things to. Hrmm, this seems like the most practical solution for me right now. It makes sense to embed python in my application like I originally planned, where I expose the individual functions I want to expose. Eventually if I actually want to provide the exposed functions as a library, I could actually just compile the application to a shared library instead of an executable (just not using the main function). The bindings in the C++ code are the same, correct? Only the way they're built seems different. There's no difference between using C and C++. Obviously, you always need the correct extern C declarations, but IIRC, Python's method definition macros handle that. You could convert your whole application to a Python extension module, expose the main function to Python, and launch the program using a small Python wrapper script. (Or you could embed Python in your application.) Lastly, depending on what your goals are, you might want to consider not integrating Python with your application at all, but exposing what functionality you want to expose to Python via dbus. You could write a skeleton module that exposes dbus proxy objects to Python scripts / modules to make life easier. -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistencies between zipfile and tarfile APIs
On 7/22/2011 5:17 PM, Ned Deily wrote: In articlej0cjaf$mum$1...@dough.gmane.org, Terry Reedytjre...@udel.edu wrote: This introduced the problem that upgrading to Python 3 is no longer a single thing. We really need 2to3.1 (the current 2to3), 2to3.2, 2to3.3, etc, but someone would have to make the new versions, but no one, currently, has the energy and interest to do that. So people who did not port their 2.x code early now use the problem of multiple Python 3 targets as another excuse not to do so now. (Actually, most 2.x code should not be ported, but their are more libraries that we do need in 3.x.) The above should be taken as reporting, accurate or not, rather than advocacy. I don't quite understand this. Since 2to3 is included with Python 3, there are, in fact, separate releases of 2to3 for each release of Python 3 so far. To the best of my knowledge, 2to3 is not being adjusted on a per-release basis. I am for doing this, but as I remember, there was some opposition when the question was discussed on py-dev. If I am wrong, I would be glad to be corrected. And, unlike with Python 2 with a large installed base across a number of versions, Python 3 version support can be and is much more focused now in its early releases. Support for 3.0 was terminated immediately upon release of 3.1. And 3.1 is now in security-fix mode only. So, except for a brief overlap after the initial release of 3.2, there has only been one Python 3 release that needs to be targeted. Of course, that will change over time as adoption continues and mainstream OS's include specific Python 3 releases. But, for now, it's easy: just target the most recent Python 3 release, currently 3.2.1. Don't worry about earlier releases. That would be my attitude too. I would hope that most of the major library are available for 3.2 before 3.3 is out. There there would only be the normal minor adjustments for code that happens to hit the new deprecations. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
[issue12607] subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child
New submission from Christian Häggström paj...@kalvdans.no-ip.org: I hit a variant of issue #12251, namely when you redirect both stdout and stderr of a child process and one of them uses a low fd. Testcase: import subprocess, sys subprocess.call([ls, asda], stderr = sys.stdout, stdout = open(/dev/null, w)) strace output: open(/dev/null, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 [child process] dup2(3, 1) = 1 // overwrites the stdout filedescriptor.. dup2(1, 2) = 2 // that was supposed to be duped here. close(3)= 0 // okay The testcase is supposed to print ls: file not found on stdout, but is silent. -- components: Library (Lib) messages: 140864 nosy: Evgeny.Tarasov, alexey-smirnov, chn, haypo, mmarkk, neologix, r.david.murray priority: normal severity: normal status: open title: subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
STINNER Victor victor.stin...@haypocalc.com added the comment: The problem is in PyLong_FromDouble(): if (Py_IS_INFINITY(dval)) is evaluated as false, whereas dval *is* infinity. Possible causes: - Py_IS_INFINITY is not defined as # define Py_IS_INFINITY(X) isinf(X) (issue with the pyconfig.h file?) - the compiler replaces isinf(X) by something else (!?) - isinf() is not called with the right argument (conversion between 32, 64 and/or 80 floats?) - issue with the FPU mode (unlikely because in your ctypes test, isinf(float(inf)) returns 1, and this test runs in the Python process) Try to run python in gdb. Set a breakpoint on isinf() (or on PyLong_FromDouble() and use step by step) to check that the function is really called, and called with the right argument. You may also try to replace Py_IS_INFINITY(dval) directly by isinf(dval) (or simply if(1) :-)) in PyLong_FromDouble(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12607] subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child
STINNER Victor victor.stin...@haypocalc.com added the comment: stdout = open(/dev/null, w), stderr = sys.stdout You ask to write all outputs to /dev/null. Why do you expect anything on stdout? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12607] subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child
Christian Häggström paj...@kalvdans.no-ip.org added the comment: I expect that 'ls' print the error message on its stderr, which would be redirected to stdout of the test Python program. If I had been using stderr = subprocess.STDOUT, I can agree with you that both output streams would go to /dev/null. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12607] subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child
STINNER Victor victor.stin...@haypocalc.com added the comment: stdout = open(/dev/null, w), stderr = sys.stdout Oh, I read subprocess.STDOUT instead of sys.stdout. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12607] subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child
Ross Lagerwall rosslagerw...@gmail.com added the comment: It is indeed a problem. It seems like the problem comes about due to the swapping of fds. i.e. using stdout as stderr. The reverse appears to work due to the order in which the dup() calls are performed. Attached is a patch which fixes the issue. -- keywords: +patch nosy: +rosslagerwall Added file: http://bugs.python.org/file22716/i12607.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10026] xml.dom.pulldom strange behavior
Myrosia Dzikovska myro...@gmail.com added the comment: I have the same problem, and I tried the solution suggested in here, namely expanding the node at END_ELEMENT. It does not work, raising the following exception: Traceback (most recent call last): File /group/project/onrbee/data/beetle2-eval-09/annotation_tools/logTools/add_start_times.py, line 163, in module main(sys.argv[1:]) File /group/project/onrbee/data/beetle2-eval-09/annotation_tools/logTools/add_start_times.py, line 130, in main events.expandNode(node) File /usr/lib/python2.6/site-packages/_xmlplus/dom/pulldom.py, line 248, in expandNode parents[-1].appendChild(cur_node) IndexError: list index out of range The code fragment was: events = xml.dom.pulldom.parse( outName ) for (event,node) in events: if (event == xml.dom.pulldom.END_ELEMENT) and (node.tagName == message): events.expandNode(node) -- nosy: +Myrosia.Dzikovska ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 0752215f9f91 by Eli Bendersky in branch '2.7': Issue #12434: make StringIO.write error message consistent with Python 2.7 nomenclature http://hg.python.org/cpython/rev/0752215f9f91 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Changes by Eli Bendersky eli...@gmail.com: -- resolution: - fixed status: open - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
