Re: Question about timeit
On Jul 22, 8:37 am, Stefan Behnel 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\Lib>timeit.py "int(float('165.0'))"
> > 10 loops, best of 3: 3.52 usec per loop
>
> > C:\Python32\Lib>timeit.py "int(float('165.0'))"
> > 10 loops, best of 3: 3.51 usec per loop
>
> > C:\Python32\Lib>timeit.py 'int(float("165.0"))'
> > 1000 loops, best of 3: 0.0888 usec per loop
>
> > C:\Python32\Lib>timeit.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 wrote: > > On 7/22/2011 12:48 AM, rantingrick wrote: > > > On Jul 21, 11:13 pm, Corey Richardson 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"
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
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 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 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 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 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 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 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 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 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 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 Mays<81282ed9a88799d21e77957df2d84bd6514d9...@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 >> Mays<81282ed9a88799d21e77957df2d84bd6514d9...@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 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 :
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 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"
wrote:
> On Jul 22, 1:12 pm, caccolangrifata 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 :
> 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 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 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 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 "", line 1, in
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
> > 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 wrote: > On Fri, Jul 22, 2011 at 2:25 AM, Chris Angelico 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 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 as long as the APIs (standard libraries) are consistent! 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 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 '___myvar' appending the prefix '_' 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 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 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 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 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 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"
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 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" > 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 writes: > On Jul 22, 10:43=A0am, "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 wrote: > On Fri, Jul 22, 2011 at 6:59 AM, Neil Cerutti 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 wrote: > ... rantingrick 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 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 wrote: > In <98u00kfnf...@mid.individual.net> Neil Cerutti 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 Reedy 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 wrote:
> Frank Millman 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 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: In<98u00kfnf...@mid.individual.net> Neil Cerutti 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 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 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 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 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 wrote: > In <98u00kfnf...@mid.individual.net> Neil Cerutti 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 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 , Terry Reedy 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 wrote: > > In <98u00kfnf...@mid.individual.net> Neil Cerutti > > 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 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 article, Terry Reedy 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
Re: Question about timeit
On Jul 22, 2:43 pm, Thomas Jollans wrote:
> 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?- Hide quoted text -
>
> - Show quoted text -
Here is the result -
C:\>python -m timeit 'int(float("165.0"))'
["'int(float(165.0))'"]
1000 loops, best of 3: 0.0891 usec per loop
Frank
--
http://mail.python.org/mailman/listinfo/python-list
Re: What Programing Language are the Largest Website Written In?
On 7/12/2011 4:54 AM, Xah Lee wrote: > Then, this question piqued me, even i tried to not waste my time. But > it overpowered me before i resisted, becuase i quickly spend 15 min to > write this list (with help of Google): > > 1 Google ◇ Java > 2 Facebook ◇ PHP > 3 YouTube ◇ Python > 4 Yahoo! ◇ PHP > 5 blogger.com ◇ Java > 6 baidu.com ◇ C/C++. perl/python/ruby > 7 Wikipedia ◇ PHP Aargh. Much misinformation. First, most of the heavy machinery of Google is written in C++. Some user-facing stuff is written in Java, and some scripting is done in Python. Google is starting to use Go internally, but they're not saying much about where. Facebook is PHP on the user-facing side, but there's heavy inter-server communication and caching, mostly in C++. The original user interface for YouTube, before Google bought it, was in Python. But it's since been rewritten. All the stuff that actually handles video is, of course in C/C++. The load of handling the video dwarfs the user interface load. Wikipedia is indeed written in PHP. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Gregory Ewing wrote: >sturlamolden wrote: > >> Or should modern deskop apps be written with something completely >> different, such as HTML5? > >I hope not! HTML is great for web pages, but not >everything should be a web page. I don't think your glibness is justified. There is a legitimate appeal to this notion. The fact is that MANY APIs can be completely and adequately described by HTML. It provides a very natural separation of presentation and behavior. Without style sheets, you can describe simple APIs very compactly and let the renderer do positioning. With style sheets, you can get very complete control over the look and feel. This is very similar to what Microsoft has done with Windows Presentation Foundation, except that they are using a more sophisticated XML DTD. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
On Jul 22, 9:59 pm, Terry Reedy wrote:
> 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
>
The problem with that is that it will silently ignore any non-zero
digits after the point. Of course int(float(x)) does the same, which I
had overlooked.
I do not expect any non-zero digits after the point, but if there are,
I would want to be warned, as I should probably be treating it as a
float, not an int.
To recap, the original problem is that it would appear that some third-
party systems, when serialising int's into a string format, add a .0
to the end of the string. I am trying to get back to the original int
safely.
The ideal solution is the one I sketched out earlier - modify python's
'int' function to accept strings such as '165.0'.
Do you think this would get any traction if I proposed it? Or would it
fall foul of the moratorium?
Frank
--
http://mail.python.org/mailman/listinfo/python-list
