Re: A request (was: how to repeat function definitions less
On Mon, 16 Mar 2009 02:59:57 -0700, Michele Simionato wrote: > On Mar 16, 8:08 am, Dennis Lee Bieber wrote: >> On Sun, 15 Mar 2009 23:18:54 -0500, alex goretoy >> Many of your posts are actually exceeding the 500-line >> limit I've >> set in my client for down-load -- yet have nothing worthy of 500 lines! > > Could this be the reason why I cannot see his messages on Google Groups? I don't see them either. My news server provider filters spam too. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mon, 09 Mar 2009 21:14:51 -0700, W. eWatson wrote:
>>> def Set_Enter_Data(self):
>>> sdict = {}
>>> sdict[ "ok" ] = False
>>> sdict[ "anumber" ] = self.anumber
>>> dialog = Enter_Data_Dialog( self.master, sdict ) <---
>>> returning
>>
>> That's not a call to the `body()` method so that ``return`` is
>> irrelevant here. Here an instance of `Enter_Data_Dialog` is created.
>> No ``return`` involved.
>>
>> BTW if this is really just a dialog to enter a number, the functions
>> `askinteger()` or `askfloat()` from the `tkSimpleDialog` module can be
>> used.
>
> What you are seeing here as an example, is a paired down version of the
> 2000 line program to focus on the particular problem at hand. The full
> code uses up to 20 variable of various types, via the dialog object. It
> uses them successfully to get the values the user has entered. How can
> it be irrelevant if it works?
The ``return`` in `body()` has nothing to do with the source line you
marked.
> The author thought this was the way to do it.
And he thought wrong because his `body()` method returns `None`. That
"works" but not the way it is intended.
> It's not my invention. It's no fluke. He does the same thing in
> another dialog that brings back about 6 values.
>
> def body(self,master):
> self.title("Box Settings")
>
> print "body from BSD"
> ...
>
> frame_delay = Entry( master,
> textvariable=self.frame_delay_var,
> width=10 ).grid( row=2, column=1, sticky=W )
> ...
> Entry( master,
> textvariable=self.untrigger_threshold_var, width=10
> ).grid( row=4, column=1, sticky=W )
> self.untrigger_threshold_var.set( "%d" %
> self.sdict["untrigger_threshold"] )
>
> return frame_delay
Then he did it consequently wrong. `frame_delay` is always `None` here
so the ``return`` is useless.
You asked what this code means and now you don't like the answer that
it's somewhat useless code!?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mon, 09 Mar 2009 04:22:57 -0700, W. eWatson wrote:
> Marc 'BlackJack' Rintsch wrote:
>> On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote:
>>
>>> You didn't answer my question why entry is necessary at all. The
>>> original author thought it was necessary to return entry. I'll give
>>> you a peek at a segment of the code I'm working with here:
>>>
>>> class Enter_Data_Dialog(tkSimpleDialog.Dialog):
>>>
>>> def __init__(self, parent, sdict):
>>> self.sdict = sdict
>>> tkSimpleDialog.Dialog.__init__(self, parent)
>>>
>>> def body(self,master):
>>> self.title("Set a Number Entry Dialog")
>>>
>>> Label( master, text="Number ").grid(row=0, sticky=W)
>>> self.anumberVar = StringVar()
>>> entry = Entry(master, width=10,
>>> textvariable=self.anumberVar).grid(row=0,
>> column=1)
>>> self.anumberVar.set( "%d" % self.sdict["anumber"] )
>>>
>>> return entry
>>
>> `entry` is unnecessary here. But that was not obvious from your
>> previous example, as you trimmed the code. Now it is clear that
>> `entry` is always `None` because that's what `grid()` returns.
>>
>> But according to the docs this method should return the widget, that
>> should get the focus, so maybe the author really wanted to return the
>> `Entry` instance here, instead of `None`.
>
> He's got to return something, because he uses it upon return, as here:
`entry` is always `None`, so it is the same as returning nothing because
every function has an implicit ``return None`` at the end.
> def Set_Enter_Data(self):
> sdict = {}
> sdict[ "ok" ] = False
> sdict[ "anumber" ] = self.anumber
> dialog = Enter_Data_Dialog( self.master, sdict ) <--- returning
That's not a call to the `body()` method so that ``return`` is irrelevant
here. Here an instance of `Enter_Data_Dialog` is created. No ``return``
involved.
BTW if this is really just a dialog to enter a number, the functions
`askinteger()` or `askfloat()` from the `tkSimpleDialog` module can be
used.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote:
> You didn't answer my question why entry is necessary at all. The
> original author thought it was necessary to return entry. I'll give you
> a peek at a segment of the code I'm working with here:
>
> class Enter_Data_Dialog(tkSimpleDialog.Dialog):
>
> def __init__(self, parent, sdict):
> self.sdict = sdict
> tkSimpleDialog.Dialog.__init__(self, parent)
>
> def body(self,master):
> self.title("Set a Number Entry Dialog")
>
> Label( master, text="Number ").grid(row=0, sticky=W)
> self.anumberVar = StringVar()
> entry = Entry(master, width=10,
> textvariable=self.anumberVar).grid(row=0,
column=1)
> self.anumberVar.set( "%d" % self.sdict["anumber"] )
>
> return entry
`entry` is unnecessary here. But that was not obvious from your previous
example, as you trimmed the code. Now it is clear that `entry` is always
`None` because that's what `grid()` returns.
But according to the docs this method should return the widget, that
should get the focus, so maybe the author really wanted to return the
`Entry` instance here, instead of `None`.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: "/a" is not "/a" ?
On Fri, 06 Mar 2009 16:26:46 -0800, Paul Rubin wrote: > Gary Herron writes: >> Experts: Singleton immutable types *may* be compared with "is", > > That is absolutely wrong: > > >>> a = 2^100 > >>> b = 2^100 > >>> a == b > True > >>> a is b > False What should this example show? And where's the singleton here? BTW: In [367]: a = 2 ^ 100 In [368]: b = 2 ^ 100 In [369]: a == b Out[369]: True In [370]: a is b Out[370]: True Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Response codes and \r\n
On Thu, 05 Mar 2009 09:37:49 +, Catherine Heathcote wrote: > I am reading an XML file (code at the end if it helps) and all goes well > except I am getting the http response code printed. So everything (hat > works of course) has "200 OK" on the first line. Am I missing some > simple way of surprising this, or should I just delete the 1st line > before playing with the content? Is this line actually part of `data`!? I would guess it is printed in line 22, so it is not part of `data` and there is no need to delete it. > Also everything I get has "\r\n" in it, which atm I am getting rid of > with strip(), is that the best way? At which point do you get rid of it and why? BTW the last line of the code snippet needs parenthesis to actually *call* the `conn.close` method. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: What does self.grid() do?
On Wed, 04 Mar 2009 09:04:50 -0800, chuck wrote: > On Mar 3, 10:40 pm, Marc 'BlackJack' Rintsch wrote: >> On Tue, 03 Mar 2009 18:06:56 -0800, chuck wrote: >> > I am learning python right now. In the lesson on tkinter I see this >> > piece of code >> >> > from Tkinter import * >> >> > class MyFrame(Frame): >> > def __init__(self): >> > Frame.__init__(self) >> > self.grid() >> >> > My question is what does "self.grid()" do? I understand that the >> > grid method registers widgets with the geometry manager and adds them >> > to the frame >> >> Not "the frame" but the container widget that is the parent of the >> widget on which you call `grid()`. In this case that would be a (maybe >> implicitly created) `Tkinter.Tk` instance, because there is no explicit >> parent widget set here. Which IMHO is not a good idea. >> >> And widgets that layout themselves in the `__init__()` are a code smell >> too. No standard widget does this, and it takes away the flexibility >> of the code using that widget to decide how and where it should be >> placed. > > I think I understand what you're saying! How would you recommend I go > about this? How do I create an explicit parent? You create it and pass it as argument to child widgets. import Tkinter as tk class MyFrame(tk.Frame): def __init__(self, parent): tk.Frame.__init__(self, parent) > What exactly is meant by "widgets that layout themselves"- what is the > right way to do this? Call one of the three layout methods on the widget instance after you created it, and not in the `__init__()` of the widget. Your example above "grids" itself at its parent widget, I think at the next free cell on a grid if you don't give the position as argument. There is no chance to use another layout manager or to place it in another cell. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: A Simple Tkinter Control Program--Slight Problem
On Wed, 04 Mar 2009 10:09:10 -0800, W. eWatson wrote:
> Here's what I think the author meant in discussing a control variable
> sample program. <http://effbot.org/tkinterbook/entry.htm>
>
> from Tkinter import *
>
> v=Tk.StringVar()
>
> e = Entry(master, textvariable=v)
> e.pack()
> e.focus_set()
>
> v.set("a default value")
> s = v.get()
>
> mainloop()
>
> The problem is that Python objects to v=.
> v=Tk.StringVar()
> AttributeError: class Tk has no attribute 'StringVar'
>
> What corrects this?
Learn how to copy code 1:1 from a web page or understand Python's import
and namespaces.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Configuration Files and Tkinter--Possible?
On Wed, 04 Mar 2009 06:12:50 -0800, W. eWatson wrote:
> That's fine, but I think my problem boils down to one question. There
> seem to be two ways to communicate with a dialog (I mean a collection of
> widgets assembled in a window that requires the user enter various
> parameters, integers, strings, yes/no button, etc.): 1. a callback and
> 2. control variables. Which one should be used?
That's no two ways. There are two ways to read/set the text in the
`Entry`: using `Entry`'s methods or by passing a `Variable` instance and
use that object's methods. The callback is used in both cases.
> To be more explicit, look at this code from your source above
> <http://effbot.org/tkinterbook/entry.htm>. (This is about the simplest
> "dialog" one can have.) :
> ==start
> from Tkinter import *
>
> master = Tk()
> e = Entry(master)
> e.pack()
> e.focus_set()
> def callback():
> print e.get()
> b = Button(master, text="get", width=10, command=callback) b.pack()
> mainloop()
> ===end
> Note that above this example, the author mentions: "You can also bind
> the entry widget to a StringVar instance, and set or get the entry text
> via that variable:
>
> v = StringVar()
> e = Entry(master, textvariable=v)
> e.pack()
>
> v.set("a default value")
> s = v.get()
> "
In this example the callback is missing. Both operations, setting the
text and getting it back, are performed without any user interaction
directly one after another. Which just demonstrate how to use
`StringVar`.
> Why have two ways of doing this?
Convenience. Setting a `Variable` that is used in a widget,
automatically updates the display of the widget. And `Variable`\s have a
method to add callbacks that get called when the content changes.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: What does self.grid() do?
On Tue, 03 Mar 2009 18:06:56 -0800, chuck wrote: > I am learning python right now. In the lesson on tkinter I see this > piece of code > > from Tkinter import * > > class MyFrame(Frame): >def __init__(self): >Frame.__init__(self) >self.grid() > > My question is what does "self.grid()" do? I understand that the grid > method registers widgets with the geometry manager and adds them to the > frame Not "the frame" but the container widget that is the parent of the widget on which you call `grid()`. In this case that would be a (maybe implicitly created) `Tkinter.Tk` instance, because there is no explicit parent widget set here. Which IMHO is not a good idea. And widgets that layout themselves in the `__init__()` are a code smell too. No standard widget does this, and it takes away the flexibility of the code using that widget to decide how and where it should be placed. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: iterating through files
On Thu, 19 Feb 2009 13:56:38 -0800, oamram wrote:
> new to python. i have a directory with about 50 text file and i need to
> iterate through them and get
> line 7 to 11 from each file and write those lines into another file(one
> file that will contain all lines).
Untested:
from __future__ import with_statement
from glob import glob
from itertools import islice
def main():
with open('result.txt', 'w') as out_file:
for filename in glob('foo/*.txt'):
with open(filename, 'r') as lines:
out_file.writelines(islice(lines, 7, 12))
if __name__ == "__main__":
main()
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: memory recycling/garbage collecting problem
On Mon, 16 Feb 2009 23:21:16 -0600, Yuanxin Xi wrote:
> I'm having some problems with the memory recycling/garbage collecting of
> the following testing code:
>
>>>> a=[str(i) for i in xrange(1000)]
> This takes 635m/552m/2044 memory (VIRT/RES/SHR)
>
>>>> b={}
>>>> for i in xrange(1000):
> ... b[str(i)]=i
>
> Then the memory usage increased to 1726m/1.6g/2048
>
>>>> del b
> I expect the memory usage drop to the ammount before b was
> created(635m/552m/2044), but it's actually 1341m/1.2g/2048
>
> Could anyone please explain why this happens? It seems some memory are
> not freed.
It seems the memory is not given back to the operating system. This
doesn't mean that it is not freed by Python and can't be used again by
Python. Create the dictionary again and see if the memory usage rises
again or if it stays stable.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Untangling pythonWin and IDLE Processes on XP Pro
On Fri, 13 Feb 2009 20:58:33 -0800, W. eWatson wrote: > Scott David Daniels wrote: >> OK, you are using the oldest and least useful revision control system, >> "rename and remember." I'd suggest you get and use bazaar, but you'll >> just ask for shortcuts on how to use it without understanding what it >> does. > It works for me, and, frankly, I'm not interested in going to Linux, > SunOS or other "revision systmes". Linux and SunOS are *operating systems*, something completely different from *revision control systems*. A revision or version control system (VCS) lets you record the evolution of your software. You can tag versions with symbolic names like "Dev4" or "Release-1.0" and can ask the VCS for a copy of the sources with a given tag or even date. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterable Ctypes Struct
On Wed, 11 Feb 2009 17:33:23 -0800, mark.seagoe wrote:
> Not sure what generic attribute container is. I am reading in from xml
> file all reg names for a chip.
Are you using instances of that class to interface C code or to read/
write data intended to be read or written by a C program? If not then
`ctypes` might be the wrong tool.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Tue, 10 Feb 2009 02:11:10 -0800, Michele Simionato wrote:
> Unfortunately there is no good solution. If you have a single
> inheritance hierarchy and you do not use super, you make it impossible
> for users of your hierarchy to subclass it by using multiple
> inheritance in a cooperative way (this is not polite).
So I'm impolite. :-) I'm using multiple inheritance only for mixin
classes and even that quite seldom. No `super()` in my code.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Super()" confusion
On Tue, 10 Feb 2009 02:02:43 +, Benjamin Peterson wrote: > Jean-Paul Calderone divmod.com> writes: >> Consider whether you really need to use super(). >> >> http://fuhm.net/super-harmful/ > > This article chiefly deals with super()'s harm in multiple inteheritance > situations. For the simple case, though, like that presented by the OP, > I believe super() is perfect. But for the simple cases it is unnecessary because it was invented to deal with multiple inheritance problems. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sat, 31 Jan 2009 09:08:25 -0800, thmpsn.m.k wrote: > On Jan 30, 12:15 am, Chris Rebert wrote: >> - Python supports encapsulation. Prefixing an attribute/method with an >> underscore indicates that other programmers should treat it as >> 'private'. However, unlike B&D languages, Python itself does nothing to >> enforce this privacy, leaving it instead to the good judgement of the >> programmer, under the philosophy that "We're all consenting adults >> here". > > How do you know? (I know I'm not.) Then stay with B&D languages. :-) > Seriously, though, the lack of private members does allow for ugly hacks > in user code, and you know there are always ugly hackers. So what? The hacks in Java to access private fields are even uglier IMHO. >> This allows people to meddle with internals, at their own risk, if it >> ends up being absolutely necessary. > > If it ends up being necessary, the class's design is flawed. Maybe that's the reason why it is really necessary. > (Though in this case, the flaw is easily solved by simply providing a > getter.) Simply providing a getter for a private attribute? I thought that's not easily possible in C++ or Java!? ;-) >> The enforcement point is >> largely academic anyway, as most languages' reflection APIs let you >> poke at ostensibly "private" things. > > If you're talking about getters, then note that this doesn't let you > modify the member (unless there's a corresponding setter). It's not about getters but about accessing private fields without any getters or setters through the reflection API. See the article `Subverting Java Access Protection for Unit Testing`_ for examples. .. _Subverting Java Access Protection for Unit Testing: http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sat, 31 Jan 2009 15:28:14 -0800, thmpsn.m.k wrote: > On Jan 31, 2:27 pm, Christian Heimes wrote: >> Do you honestly believe that C++'s private members are really private? >> Privateness is only enforced during parsing time. Nobody can stop you >> from messing around with header files or memory. You can still access >> and modify private members but it's all messy and ugly. Even C# and >> .NET don't stop you from doing nasty things from unmananged assemblies. > > I don't know how you would do it in C# (or Java for that matter). In Java you can use reflection to get your fingers on private fields. > In C++ you can play with pointers to "get at" some memory location > somewhere in the object. > [Snipped pointer fiddling explanation] > So: Sometimes it may work, usually it will be unsafe and/or non- > portable, and in most cases the procedure will look complicated. Or ``#define private public`` before including the header files. Which doesn't look complicated to me. > It certainly isn't something I'd try in a real application. However, it > WOULD be tempting to access the member if the language allows me to just > write: > > print "obj.b =", obj.b > > and be done with it. And that's perfectly okay, because the author would have prepended an underscore to `b` if you should not mess with it. > Personally, in Python, I use double underscores for "private" members, > so the above would look like: > > print "obj.b =", obj._NonPOD__b > > but it's still easier than the C++ example. The name mangling is there to prevent name clashes, not to make attributes inaccessible. It's useful for mixin classes for example. >> Seriously, 'private' and 'protected' are merely tools to stop bad >> programmers from doing bad stuff. And the serve as documentation, too. > > It's not just documentation. For example, suppose you're reading a class > definition and see the declaration of a veryInterestingMember and forget > that you're not supposed to access it. If you try to access it, the > compiler will give you a diagnostic message at compile time. I can't forget that because if I'm not supposed to access it, its name would be `_very_interesting_member`. I don't have to wait till compile time to see that, it is really obvious at the time I write the code to access it, or decide not to because it is not part of the API. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: verilog like class w/ bitslicing & int/long classtype
On Fri, 30 Jan 2009 21:59:34 +0100, Stef Mientki wrote: > Marc 'BlackJack' Rintsch wrote: >> On Fri, 30 Jan 2009 00:25:03 +0100, Stef Mientki wrote: >> >> >>> try this: >>> >>> class MyRegClass ( int ) : >>> def __init__ ( self, value ) : >>> self.Value = value >>> def __repr__ ( self ) : >>> line = hex ( self.Value ) >>> line = line [:2] + line [2:].upper() >>> return line >>> >>> >> def __repr__(self): >> return '0x%X' % self.value >> >> >>> __str__ = __repr__ >>> >>> >> This is unnecessary, the fallback of `__str__` is `__repr__` already. >> >> > well this is what my Python is doing: > > without _str__ = __repr__ > >>print shadow_register > 170 > > with _str__ = __repr__ > >>print shadow_register > 0xAA Then don't inherit from `int`. Why are you doing this anyway? If you inherit from `int` you shouldn't store the value in an extra attribute but use the `int`\s value. This way you have one value used by the `int` methods and one used by your own methods. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: verilog like class w/ bitslicing & int/long classtype
On Fri, 30 Jan 2009 00:25:03 +0100, Stef Mientki wrote: > try this: > > class MyRegClass ( int ) : > def __init__ ( self, value ) : > self.Value = value > def __repr__ ( self ) : > line = hex ( self.Value ) > line = line [:2] + line [2:].upper() > return line def __repr__(self): return '0x%X' % self.value > __str__ = __repr__ This is unnecessary, the fallback of `__str__` is `__repr__` already. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Newby: how to transform text into lines of text
On Mon, 26 Jan 2009 16:10:11 +0100, Andreas Waldenburger wrote: > On 26 Jan 2009 14:51:33 GMT Marc 'BlackJack' Rintsch > wrote: > >> On Mon, 26 Jan 2009 12:22:18 +, Sion Arrowsmith wrote: >> >> > content = a.readlines() >> > >> > (Just because we can now write "for line in file" doesn't mean that >> > readlines() is *totally* redundant.) >> >> But ``content = list(a)`` is shorter. :-) >> > But much less clear, wouldn't you say? Okay, so let's make it clearer and even shorter: ``lines = list(a)``. :-) Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Newby: how to transform text into lines of text
On Mon, 26 Jan 2009 12:22:18 +, Sion Arrowsmith wrote:
> content = a.readlines()
>
> (Just because we can now write "for line in file" doesn't mean that
> readlines() is *totally* redundant.)
But ``content = list(a)`` is shorter. :-)
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Reading the first MB of a binary file
On Sun, 25 Jan 2009 08:37:07 -0800, Max Leason wrote:
> I'm attempting to read the first MB of a binary file and then do a md5
> hash on it so that i can find the file later despite it being moved or
> any file name changes that may have been made to it. These files are
> large (350-1400MB) video files and i often located on a different
> computer and I figure that there is a low risk for generating the same
> hash between two files. The problem occurs in the read command which
> returns all \x00s. Any ideas why this is happening?
>
> Code:
>>>>>open("Chuck.S01E01.HDTV.XViD-YesTV.avi", "rb").read(1024)
> b'\x00\x00\x00\x00\x00\x00\x00'
As MRAB says, maybe the first 1024 actually *are* all zero bytes. Wild
guess: That's a file created by a bittorrent client which preallocates
the files and that file above isn't downloaded completely yet!?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: A different kind of interface
On Sat, 24 Jan 2009 01:02:01 +0100, Дамјан Георгиевски wrote:
>>> I don't know what an IBQ is.
>>
>> +IBQ- seems to be the way your newsreader displays the dashes that
>> where in Ben's posting. I see "em dash" characters there:
>
> I see IBQ too ... also weird is that he has Content-Type: text/plain;
> charset=utf-7
Why weird? Makes perfect sense:
In [98]: print '+IBQ-'.decode('utf-7')
—
In [99]: unicodedata.name('+IBQ-'.decode('utf-7'))
Out[99]: 'EM DASH'
So there are newsreaders out there that can't or at least don't decode
UTF-7.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: A different kind of interface
On Thu, 22 Jan 2009 04:17:57 -0800, bearophileHUGS wrote: > Ben Finney: > >> Many of us solve this by using a single full-featured programmer's >> editor that allows invoking a program +IBQ- written in any of *dozens >> or hundreds* of different languages +IBQ- from within the editor. > > I don't know what an IBQ is. +IBQ- seems to be the way your newsreader displays the dashes that where in Ben's posting. I see "em dash" characters there: In [84]: unicodedata.name(u'—') Out[84]: 'EM DASH' Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Style Guide Questions - Contd.
On Mon, 19 Jan 2009 05:50:54 -0800, koranthala wrote: > Hi, >I have some more questions about python code styling. 1. Global >Variables: In my code, I am using some global variables. > Now, when I ran PyLint, it raised convention errors mentioning that they > should be CAPITAL_ALPHABETS. Now, in PEP 8, I did not see that > mentioned. Please let me know whether that is the usual styling > mechanism which is used. PEP8 doesn't mention constants at all. The all caps naming for constants is a convention in several languages. >2. I have many loops wherein I define a variable as just a counter. >for x in range(counter): > do_something() >Please note that I am not using x anywhere in the program. Pylint >again raises warnings saying that the variable should be > used. >Should I disregard it or use the default variable _ ? for _ in >range(counter): > do_something() >pylint does not raise errors for those. Are there any issues in > using _ ? Pylint doesn't barf on `dummy` either. The point is having a name that makes clear at the head of the loop, that the reader doesn't have to bother looking for places where the value will be used because it is clear from the name that the value won't be used at all. BTW pylint is very configurable, you can dump the default configuration and find out which names are "allowed" by default and of course define your own set of "value doesn't matter" names. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Relax Syntax for Augmented Arithmetic?
On Sun, 18 Jan 2009 04:24:04 -0800, andrew cooke wrote:
> my argument was that *= is not treated as = and *, but as a completely
> new operator (the docs even say that the implementation need not return
> self which suggests some pretty extreme semantics were envisaged).
What do you mean by "suggests … extreme semantics"? Most natural thing
is to use numbers and there you *have* to be able to return something
different than `self` to get anything useful. For instance:
n *= 3
with `n` bound to a number different from zero can't return `self` from
`__imul__`.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Beginner: Data type conversion question
On Thu, 15 Jan 2009 21:09:43 -0800, flagg wrote:
> def checkSerial():
> """
> Checks the current 'date' portion of the serial number and checks
> the current 'counter'(the two digit number at the end of the serial
> number), then returns a complete new serial """
> currentDate = time.strftime("%Y""%m""%d", time.localtime())
The format string can be written as *one* string literal instead of
three: "%Y%m%d".
> for (name, ttl, rdata) in zone.iterate_rdatas(SOA):
> date = str(rdata.serial)[0:8]
> inc = str(rdata.serial)[8:10]
Here you are converting `rdata.serial` twice.
tmp = str(rdata.serial)
date = tmp[0:8]
inc = int(tmp[8:10])
As `inc` is conceptually a number, you should do the conversion here and
treat it as number from now on.
> if date == currentDate:
> int(inc) + 1
> print inc
> newInc = str(inc).zfill(2)
> serial = date + newInc
> print "date is the same"
> return serial
> elif date < currentDate:
> newInc = "01".zfill(2)
> serial = currentDate + newInc
> print "date is different"
> return serial
Both branches do almost the same. You should try to avoid such code
duplication.
if date == currentDate:
inc += 1
elif date < currentDate:
inc = 1
else:
assert False # Should never happen.
return "%s%02d" % (date, inc)
That's it.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Wed, 14 Jan 2009 07:14:06 +, Steven D'Aprano wrote: > On Wed, 14 Jan 2009 15:25:38 +1000, James Mills wrote: > >> On Wed, Jan 14, 2009 at 3:11 PM, Russ P. >> wrote: (...) >> >>>> Give me one use-case where you strictly require that members of an >>>> object be private and their access enforced as such ? >>> >>> You're kidding, right? Think about a ten-million line program being >>> developed by 100 developers. >> >> No I"m sorry this is not a valid use-case. > > Why not? Just saying it isn't doesn't make it not. Because "developer" means people who don't mess with implementation details. So they respect the leading underscore convention. No use case for enforced access restriction. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Implementing file reading in C/Python
On Mon, 12 Jan 2009 21:26:27 -0500, Steve Holden wrote: > The very idea of mapping part of a process's virtual address space onto > an area in which "low-level system code resides, so writing to this > region may corrupt the system, with potentially catastrophic > consequences" seems to be asking for trouble to me. That's why those regions are usually "write protected" and "no execution allowed" from the code in the user area of the virtual address space. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Mon, 12 Jan 2009 07:42:47 -0800, bieffe62 wrote: > On 12 Gen, 14:45, Paul Rubin <http://phr...@nospam.invalid> wrote: >> bieff...@gmail.com writes: >> > > class Foo (DynamicAttributes, object): pass >> >> > You cannot do that, but you can establish a fixed set of attributes >> > by defining the __slot__ class variable. >> >> That is not what __slot__ is for. > > > Really? It seems to work: It works but it is not what `__slot__` was invented for. Some call it a misuse of that feature if you use it to prevent adding attributes dynamically. And it has some drawbacks when you inherit from such classes. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Encoding Title mail
On Mon, 12 Jan 2009 04:32:35 -0800, Andrea Reginato wrote: > Hi to everybody, I'm trying to use libgmail version 0.1.9, to read some > mails from a google account and save the attached files. All works fine, > but when a tile has some letters with accents (like èùàòì) I read a > string like this. > > =?ISO-8859-1?Q?=F2=E0=F9+=E8=EC'_0987654321_\?= =?ISO-8859-1?Q? > _=E9*=A7=B0=E7;:=5F_test_chars?= > > I tried to use the string.decode(ISO-8859-1) function, but nothing > change. > I'm newbie into python, so I wanted to ask if you know how I could solve > this problem, as with a google search i didn't find the solution. Look into the `email` package in the standard library. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Python strings and coding conventions
On Sat, 10 Jan 2009 20:48:21 -0800, Mensanator wrote:
> Damn! I didn't know you could do that! And if I saw it in a program
> listing, such would never occur to me. I was going to suggest the stupid
> way:
>
>>>> ga = ['four score and seven years ago ', \
> 'our fathers brought forth ', \
> 'on this continent a new nation ', \
> 'conceived in liberty and dedicated ', \
> 'to the proposition that all men ', \
> 'are created equal']
What are all those line continuation characters ('\') for? You are aware
that they are unnecessary here?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: are there some special about '\x1a' symbol
On Sat, 10 Jan 2009 07:45:53 -0800, sim.sim wrote:
> I had touch with some different python behavior: I was tried to write
> into a file a string with the '\x1a' symbol, and for FreeBSD system, it
> gives expected result:
>
>>>> open("test", "w").write('before\x1aafter') open('test').read()
> 'before\x1aafter'
>
>
> but for my WinXP box, it gives some strange:
>
>>>> open("test", "w").write('before\x1aafter') open('test').read()
> 'before'
>
> Here I can write all symbols, but not read. I've tested it with python
> 2.6, 2.5 and 2.2 and WinXP SP2.
>
> Why is it so and is it possible to fix it?
\x1a is treated as "end of text" character in text files by Windows. So
if you want all, unaltered data, open the file in binary mode ('rb' and
'wb').
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implementing file reading in C/Python
On Fri, 09 Jan 2009 15:34:17 +, MRAB wrote: > Marc 'BlackJack' Rintsch wrote: > >> def iter_max_values(blocks, block_count): >> for i, block in enumerate(blocks): >> histogram = defaultdict(int) >> for byte in block: >> histogram[byte] += 1 >> >> yield max((count, byte) >> for value, count in histogram.iteritems())[1] >> > [snip] > Would it be faster if histogram was a list initialised to [0] * 256? Don't know. Then for every byte in the 2 GiB we have to call `ord()`. Maybe the speedup from the list compensates this, maybe not. I think that we have to to something with *every* byte of that really large file *at Python level* is the main problem here. In C that's just some primitive numbers. Python has all the object overhead. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Where's Psyco now?
On Fri, 09 Jan 2009 12:37:38 -0800, Roger wrote:
> If that's the case where's the point of diminishing returns on using
> psyco? Why would it not be useful in a general setting?
There is some overhead involved with the runtime analysis and compiling.
Functions that are only called once usually don't benefit from psyco,
even worse they can be slower because of the unnecessary overhead. And
not all code can be accelerated. Best candidates are functions that are
somewhat C-like, i.e. doing lots of operations on simple number types.
Things that can be translated directly to machine code. And for some
very generic functions that are called with lots of different types, the
memory consumption is high because of all the specialized code that will
be compiled.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: string split
On Fri, 09 Jan 2009 12:39:22 -0800, Leland wrote:
> It seems work this way, but is there more elegant way to do this?
Yes, the `csv` module in the standard library.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implementing file reading in C/Python
On Fri, 09 Jan 2009 04:04:41 +0100, Johannes Bauer wrote:
> As this was horribly slow (20 Minutes for a 2GB file) I coded the whole
> thing in C also:
Yours took ~37 minutes for 2 GiB here. This "just" ~15 minutes:
#!/usr/bin/env python
from __future__ import division, with_statement
import os
import sys
from collections import defaultdict
from functools import partial
from itertools import imap
def iter_max_values(blocks, block_count):
for i, block in enumerate(blocks):
histogram = defaultdict(int)
for byte in block:
histogram[byte] += 1
yield max((count, byte)
for value, count in histogram.iteritems())[1]
if i % 1024 == 0:
print 'Progresss: %.1f%%' % (100 * i / block_count)
def write_pgm(filename, width, height, pixel_values):
with open(filename, 'w') as pgm_file:
pgm_file.write('P2\n'
'# CREATOR: Crappyass Python Script\n'
'%d %d\n'
'255\n' % (width, height))
pgm_file.writelines('%d\n' % value for value in pixel_values)
def main():
filename = sys.argv[1]
filesize = os.path.getsize(filename)
width = 1024
height = 1024
pixels = width * height
blocksize = filesize // width // height
print 'Filesize : %d' % filesize
print 'Image size : %dx%d' % (width, height)
print 'Bytes per Pixel: %d' % blocksize
with open(filename, 'rb') as data_file:
blocks = iter(partial(data_file.read, blocksize), '')
pixel_values = imap(ord, iter_max_values(blocks, pixels))
write_pgm(filename + '.pgm', width, height, pixel_values)
if __name__ == '__main__':
main()
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implementing file reading in C/Python
On Fri, 09 Jan 2009 04:04:41 +0100, Johannes Bauer wrote:
> datamap = { }
> for i in range(len(data)):
> datamap[ord(data[i])] = datamap.get(data[i], 0) + 1
Here is an error by the way: You call `ord()` just on the left side of
the ``=``, so all keys in the dictionary are mapped to ones after the
loop which gives a pretty boring PGM. :-)
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Implementing file reading in C/Python
On Fri, 09 Jan 2009 19:33:53 +1000, James Mills wrote: > On Fri, Jan 9, 2009 at 7:15 PM, Marc 'BlackJack' Rintsch > wrote: >> Why parentheses around ``print``\s "argument"? In Python <3 ``print`` >> is a statement and not a function. > > Not true as of 2.6+ and 3.0+ > > print is now a function. Please read again what I wrote. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Implementing file reading in C/Python
On Fri, 09 Jan 2009 04:04:41 +0100, Johannes Bauer wrote:
> I've first tried Python. Please don't beat me, it's slow as hell and
> probably a horrible solution:
>
> #!/usr/bin/python
> import sys
> import os
>
> f = open(sys.argv[1], "r")
Mode should be 'rb'.
> filesize = os.stat(sys.argv[1])[6]
`os.path.getsize()` is a little bit more readable.
> width = 1024
> height = 1024
> pixels = width * height
> blocksize = filesize / width / height
>
> print("Filesize : %d" % (filesize)) print("Image size : %dx%d"
> % (width, height)) print("Bytes per Pixel: %d" % (blocksize))
Why parentheses around ``print``\s "argument"? In Python <3 ``print`` is
a statement and not a function.
> picture = { }
> havepixels = 0
> while True:
> data = f.read(blocksize)
> if len(data) <= 0: break
if data:
break
is enough.
> datamap = { }
> for i in range(len(data)):
> datamap[ord(data[i])] = datamap.get(data[i], 0) + 1
Here you are creating a list full of integers to use them as index into
`data` (twice) instead of iterating directly over the elements in
`data`. And you are calling `ord()` for *every* byte in the file
although you just need it for one value in each block. If it's possible
to write the raw PGM format this conversion wouldn't be necessary at all.
For the `datamap` a `collections.defaultdict()` might be faster.
> maxchr = None
> maxcnt = None
> for (char, count) in datamap.items():
> if (maxcnt is None) or (count > maxcnt):
> maxcnt = count
> maxchr = char
Untested:
maxchr = max((i, c) for c, i in datamap.iteritems())[1]
> most = maxchr
Why?
> posx = havepixels % width
> posy = havepixels / width
posx, posy = divmod(havepixels, width)
Don't know if this is faster though.
> havepixels += 1
> if (havepixels % 1024) == 0:
> print("Progresss %s: %.1f%%" % (sys.argv[1], 100.0 *
havepixels /
> pixels))
>
> picture[(posx, posy)] = most
Why are you using a dictionary as "2d array"? In the C code you simply
write the values sequentially, why can't you just use a flat list and
append here?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: "python -3" not working as expected
On Thu, 08 Jan 2009 16:38:53 +0100, Thorsten Kampe wrote:
> [Python 2.6.1]
>
> Hi,
>
> to test existing Python code, I ran "python -3" ("warn about Python 3.x
> incompatibilities") against a test file that only contains "print
> 'test'".
>
> Unfortunately I saw no warnings about print becoming a function in
> Python 3 ("print()"). Where is the problem?
There is no problem. ``print``\s are handled fine by the 2to3.py
script. The option warns about stuff that is not easily automatically
converted.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: An idea of how to identify Israeli owned software companies
On Wed, 07 Jan 2009 10:17:55 -0800, Mensanator wrote: > On Jan 7, 8:45 am, Terje wrote: >> Is there a web service/API out there identifying Israel owned >> software/software companies/web sites/web services? If I am about to >> buy a piece of software, but don't want to support the Israeli economy, >> it would have been handy if I could just poll a web service to get the >> answer. This information should be kept in a database, and be public to >> the world through a very simple xml API, something along these lines: >> >> Request: >> Some Company Name >> >> Response: >> true >> >> Here's one source for this kind of information (I am sure there are >> plenty others):http://www.science.co.il/SoftwareCo.asp >> >> Of course, a web service like this would be equally useful to those who >> want to support Israeli companies. > > Something like that web-service that publishes the names and addresses > of doctors who perform abortions so that they can be assassinated? Hey, it's about boycott, not killing them. Applied to the doctors example: You go to someone without a doctors degree, a clothes hanger and some experience… ;-) Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: del behavior 2
On Wed, 07 Jan 2009 12:03:36 -0800, Eric Snow wrote: > Thanks for the responses. What I mean is when a python process is > interrupted and does not get a chance to clean everything up then what > is a good way to do so? Well, if it doesn't get a chance then it doesn't get a chance. ;-) > For instance, I have a script that uses child > ptys to facilitate ssh connections (I'm using pxssh). When I ^C the > python process I am left with the child processes running and the ssh > connections open. Naturally I run out of ttys if this happens too much, > which I have had happen. So if python does not get a chance to take > care of those, what is a good way to do so? Does a try/finally or a > with statement address that? Thanks! If you clean up the mess in the ``finally`` branch: yes. + raises a `KeyboardInterrupt`. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: why cannot assign to function call
On Wed, 07 Jan 2009 03:45:00 -0800, sturlamolden wrote:
> On Jan 7, 2:02 am, Steven D'Aprano
> wrote:
>
>> In Python code, there are no references and no dereferencing.
>
> The why does CPython keep track of reference counts?
Show me the *Python* code that does that. Using reference counting for
memory management is an implementation detail. It's possible to use
other garbage collectors without the need of reference counting.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter - problem closing window
On Mon, 05 Jan 2009 12:25:53 -0200, Djames Suhanko wrote:
> I has a litle program that open another window. When I close de root
> window in quit button, I need clicking 2 times to close. is where the
> problem?
>
> […]
>
> 17 def gera_seis(self):
> 18a = {}
> 19for i in range(6):
> 20 a[i] = "%02d" % int (random.randint(0,60))
> 21resultadoA = "%s-%s-%s-%s-%s-%s" %
> (str(a[0]),str(a[1]),str(a[2]),str(a[3]),str(a[4]),str(a[5]))
> 22return resultadoA
Not the problem but unnecessary complex. `random.randint()` already
returns an int, no need to call `int()` on it. The string formatting
with ``%`` returns strings, so there is no need to call `str()` on the
values. Even if the values where not strings: The '%s' place holder
implies a call to `str()` while formatting. If you put something into a
dictionary with consecutive `int` keys, you might use a list instead.
All this can be written as a simple one liner::
'-'.join(str(random.randint(0, 60)) for dummy in xrange(6))
> 24 def say_hi(self):
> 25resultado = self.gera_seis()
> 26raiz = Tk()
The problem is here…
> 27F = Frame(raiz)
> 28F.pack()
> 29hello = Label(F, text=resultado) 30hello.pack()
> 31F.mainloop()
…and here.
There is only one `Tk` instance and mainloop allowed per `Tkinter`
application. Otherwise really strange things can happen. Additional
windows have to be created as `Toplevel` instances.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: why cannot assign to function call
On Sun, 04 Jan 2009 22:55:09 -0600, Derek Martin wrote: > On Sun, Jan 04, 2009 at 09:30:20PM -0500, Steve Holden wrote: >> > I'm going to go out on a limb and assert that there's NO POSSIBLE WAY >> > a student could intuit Python's variable assignment behavior, having >> > never been exposed to that same behavior prior. It needs to be >> > taught. >> > >> As does assignment of any kind. > > I'm not sure that's true. Having taken algebra prior to learning Basic, > I intuitively understood what this program would do when I executed it, > the first time I saw the code, and before I read the explanation: > > 10 let x = 10 > 20 print x Do you really thought of `x` as a named memory location where the bit pattern for the floating point value 10 is stored, with just the algebra knowledge!? Isn't "Ah there the name `x` is bound to the value 10." more likely? As it is the technically easier and IMHO more intuitive explanation when you go from math to programming. > [Well, to be honest it's been a very long time since I've programmed in > Pet BASIC, and the syntax may be wrong. The point is, just as I did > then, I am positive that you intuitively understand what the above is > intended to do, even if it is not valid BASIC syntax -- because if you > did not, we would not be having this discussion.] Syntax is correct. :-) The ``let`` is optional in Commodore BASIC. But where is the difference to x = 10 print x ? Wouldn't you have guessed what this Python program will do just the same? Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: why cannot assign to function call
On Sun, 04 Jan 2009 20:03:11 -0600, Derek Martin wrote: > On Sat, Jan 03, 2009 at 10:15:51AM +0000, Marc 'BlackJack' Rintsch > wrote: >> On Fri, 02 Jan 2009 04:39:15 -0600, Derek Martin wrote: >> >> What's the difference between Python and Java or C# here!? Or are they >> also "BIZARRE"!? > > I am happily ignorant of C#. As for Java, take the following code: > > a = 6; > a = 5; > > In Python, when you execute the equivalent code, it causes two different > objects to spring into existence, the first of which may be cleaned up > by the GC (except that since we're using small integers, that's not > likely to happen). Unless I'm misinformed (which is very possible, my > experience with Java has been extremely limited) in Java that's not the > case... the storage is allocated to the name a when you execute its > declaration, and the *same storage* is reused upon subsequent > assignment. > > That behaves exactly like named bins. So does the equivalent in Python. Or to see it the other way: In both languages it *behaves* like (re)binding the name `a` to two different objects. So it is an implementation detail. Even a Python implementation could reuse the same memory location to store the two numbers. >> > And for that matter, it's pretty unintuitive generally. >> >> Names and objects are quite "natural" IMHO. There are many real world >> objects which we attach one or more names to, or refer to in sequences >> like "please give me the third book on that shelve" (``shelve[2]``). > > Indeed, but the way we assign names to them does not behave as it does > in Python. In what way? >> I think the "bin model" is more complex because you don't just have a >> name and an object but always that indirection of the "bin". > > I cheerfully disagree. :) "Named bins" is essentially how algebra > works, No it isn't. Mathematics is about binding names and not about putting values into bins. And a mathematical variable can't be rebound once you assigned a value to it. The "intuitive" model for people with a math background would be that of functional languages like Haskell, which is even more strange for people used to "named bins" than the Python, Java, Ruby, … approach. > and how several generations of computer languages, not to mention > the actual machine language those generated, behaved, before the current > crop. Those interpretations came first, because, much as in the > evolution of any other science, that was the model which was most > intuitive or easily explained. In terms of the underlying machine, but that is exactly what I meant by the additional indirection of the bins. You just have to drag the low level named bins into the explanation because it is an implementation detail of the languages. And there where always languages that use a model like Python parallel to the "named bins languages", it is nothing new. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Take the first n items of an iterator
On Sun, 04 Jan 2009 10:55:17 +, Steven D'Aprano wrote:
> I thought there was an iterator in itertools for taking the first n
> items of an iterator, then halting, but I can't find it. Did I imagine
> such a tool, or am I missing something?
`itertools.islice()`
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Returning a string
On Sat, 03 Jan 2009 11:46:10 -0800, Kless wrote: > On 3 ene, 19:40, Simon Forman wrote: >> On Jan 3, 11:20 am, Kless wrote: >> >> > Afghanistan >> > AF >> > Out[19]: u'AF' >> > AFG >> > Out[19]: u'AFG' >> > 004 >> > Out[19]: u'004' >> >> What? > > That's the output got from ipython. As you can see, it prints > 'Afghanistan' but it can not returns it. In change, the another strings > are returned. Maybe you should show the *input* too… Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: why cannot assign to function call
On Fri, 02 Jan 2009 04:39:15 -0600, Derek Martin wrote: > On Tue, Dec 30, 2008 at 02:21:29PM +, John O'Hagan wrote: > What the Python community often overlooks, when this discussion again > rears its ugly head (as it seems to every other hour or so), is that its > assignment model is BIZARRE, as in it's conceptually different from > virtually all other languages substantially taught in undergraduate > computer science programs. What's the difference between Python and Java or C# here!? Or are they also "BIZARRE"!? > And for that matter, it's pretty unintuitive generally. Names and objects are quite "natural" IMHO. There are many real world objects which we attach one or more names to, or refer to in sequences like "please give me the third book on that shelve" (``shelve[2]``). > That is, in what I'll call "normal" computer languages, a variable name > is thought of as the address of a bin where some data is stored, and the > name is inexorably tied to that bin. You just call that "normal" or "intuitive" because that's what you learned first. > Python is very different from this. Names are not addresses of bins; > they are instead simply ephemeral labels which are given to bins, where > the bin is a Python object which contains specific data at the time of > assignment. A second assignment of that name doesn't change what's in > the original bin; it actually (probably) first creates a new bin, then > removes the name from the original bin and assigns it to the new one. > Intuitively, it's a bit like saying your kitchen table is no longer a > kitchen table, and now the thing where you wash your dishes is a kitchen > table. It doesn't really make a lot of sense (whether or not it's so > for good reason), and it makes describing the assignment model > necessarily convoluted, whereas the "named bins" model from the majority > of other languages people are likely to have been exposed to is simple > and sensible. I think the "bin model" is more complex because you don't just have a name and an object but always that indirection of the "bin". Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not Ruby?
On Fri, 02 Jan 2009 09:00:01 -0800, r wrote: > On Jan 2, 6:45 am, Steven D'Aprano cybersource.com.au> wrote: >> On Thu, 01 Jan 2009 17:38:02 -0800, r wrote: >> > He was not cross posting. >> >> You don't actually know what cross-posting is, do you? >> >> You've just earned a plonking for the next month. Do try to have at >> least half a clue by February. > > Steven i got you NOW! > Everybody go and look at this thread, there Mr. Makinzie butts in and > posts an off-topic question, and Steven answers it, contributing to the > off-topicalitly of the thread. And has yet to apologize for it, or admit > his screwup, but will he preach to everyone else about making off topic > post... Pot meet Kettle; Kettle Pot! > > http://groups.google.com/group/comp.lang.python/browse_thread/thread/ fc57c18c3cff5937?hl=en&q=recycle+bin#97254d877903bbd No you didn't "got" Steven, as unnecessary cross posting is something different than answering a question that should have been a new thread start. Oh, and: *plonk* for your childish annoying behaviour… Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Videocapture in python
On Thu, 01 Jan 2009 04:28:21 -0800, koranthala wrote:
> Please let me know if you need any more information.
Where does `videocapture.py` coming from? It's not part of the standard
library. And which operating system are we talking about?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Memory leak problem (while using tkinter)
On Tue, 30 Dec 2008 20:21:06 -0800, André wrote: > I have written a small program (my first Tkinter-based app) to play > around the idea mentioned on > http://rogeralsing.com/2008/12/07/genetic-programming-evolution-of-mona- lisa/ > and, in doing so, have encountered a memory leak problem. I have seen > mentions on the web of using the delete() method of canvas to prevent > such problems - which I have tried to do with limited success. Below is > the code I wrote; to run it, you will need a small image file > (I used the one found on http://alteredqualia.com/visualization/evolve/) > that is saved under "mona_lisa.png". > > Any help would be greatly appreciated. I don't see anything obvious but that the program is too long and uses too much components to be sure that `Tkinter` is the culprit. Try too trim it down to the smallest possible program that still has the problem. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Strategy for determing difference between 2 very large dictionaries
On Wed, 24 Dec 2008 03:23:00 -0500, python wrote: > Hi Gabriel, > > Thank you very much for your feedback! > >> k1 = set(dict1.iterkeys()) > > I noticed you suggested .iterkeys() vs. .keys(). Is there any advantage > to using an iterator vs. a list as the basis for creating a set? I > understand that an iterator makes sense if you're working with a large > set of items one at a time, but if you're creating a non-filtered > collection, I don't see the advantage of using an iterator or a list. > I'm sure I'm missing a subtle point here :) `keys()` creates a list in memory, `iterkeys()` does not. With ``set(dict.keys())`` there is a point in time where the dictionary, the list, and the set co-exist in memory. With ``set(dict.iterkeys())`` only the set and the dictionary exist in memory. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, 21 Dec 2008 15:30:34 +, Duncan Booth wrote: > Marc 'BlackJack' Rintsch wrote: > >>> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string >>> concatenations or matrix operations, and a%b%c%d might execute as >>> a.__mod__(b,c,d). >> >> But that needs special casing strings and ``%`` in the comiler, because >> it might not be always safe to do this on arbitrary objects. Only in >> cases where the type of `a` is known at compile time and ``a % b`` >> returns an object of ``type(a)``. >> > I could be wrong, but I don't see that would be the case. > > I think it would be safe (in this hypothetical universe) any time that > 'a' had a method __mod__ which accepted more than one argument. And returns an object of ``type(a)`` or at least a "duck type" so that it is guaranteed that ``a.__mod__(b, c)`` really has the same semantics as ``a.__mod__(b).__mod__(c)``. For arbitrary objects `a`, `b`, and `c` that are not known at compile time, how could the compiler decide if it is safe to emit code that calls `a.__mod__()` with multiple arguments? Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote: > You seem to have made an unwarranted assumption, namely that a binary > operator has to compile to a function with two operands. There is no > particular reason why this has to always be the case: for example, I > believe that C# when given several strings to add together optimises > this into a single call to a concatenation method. > > Python *could* do something similar if the appropriate opcodes/methods > supported more than two arguments: > > a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string > concatenations or matrix operations, and a%b%c%d might execute as > a.__mod__(b,c,d). But that needs special casing strings and ``%`` in the comiler, because it might not be always safe to do this on arbitrary objects. Only in cases where the type of `a` is known at compile time and ``a % b`` returns an object of ``type(a)``. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is slow
On Sat, 20 Dec 2008 14:18:40 -0800, cm_gui wrote: >> Seriously cm_gui, you're a fool. >> Python is not slow. > > haha, getting hostile? > python fans sure are a nasty crowd. > > Python is SLOW. > > when i have the time, i will elaborate on this. You are not fast enough to elaborate on Python's slowness!? :-) cm_gui is slow! Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote: > On Dec 19, 10:25 am, Michael Torrie wrote: > >> Personally the new string formatter is sorely needed in Python. > > Really? You know, it's funny, but when I read problems that people have > with python, I don't remember seeing that. Loads of people complain > about the white space issue. Some people complain about the speed. Lots > of complaints about certain quirky behavior, but I have not come across > any complaints about the string formatting. Many newbie code I have seen avoids it by string concatenation: greeting = 'Hello, my name is ' + name + ' and I am ' + str(age) + ' old.' That's some kind of indirect complaint. :-) > In fact, from what I have seen, many of the "problems" being "fixed" > seem to be non-problems. And even if nobody has problems with the limitations of ``%`` string formatting why shouldn't they add a more flexible and powerful way!? Python 3.0 is not a bug fix release. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 22:15:23 -0800, r wrote: > It would be nice to get a vote together and see what does the average > pythoneer want? What do they like, What do they dislike. What is the > state of the Python Union? Does anybody know, Does anybody care? I think > python is slipping away from it's dominate foothold on the world. > Google's use of python may be the only thing holding this house of cards > together. Ruby's "hype" is defiantly growing and unless we strive for > greatness, python may fail. I think ruby may have their act together a > little better than us right now. And since Ruby is such a hodge-podge of > different languages, the __init__ hold is there for many. > > what does joe-python want??? That's not completely irrelevant but I think one of Python's strength is that we have a BDFL who decides carefully what he thinks is best for the language instead of integrating every random idea some newbie comes up with and which might sound useful at first sight. Python has its quirks but even with things I don't like I often realize later it was a wise decision that integrates well into the language whereas my ideas for "fixes" of the quirks wouldn't. "joe-python" most often doesn't see the whole picture and demands changes that look easy at first sight, but are hard to implement right and efficient or just shifts the problem somewhere else where the next "joe-python" trips over it. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: encoding problem
On Fri, 19 Dec 2008 16:50:39 -0700, Joe Strout wrote: > Marc 'BlackJack' Rintsch wrote: > >>>> And does REALbasic really use byte strings plus an encoding!? >>> You betcha! Works like a dream. >> >> IMHO a strange design decision. > > I get that you don't grok it, but I think that's because you haven't > worked with it. RB added encoding data to its strings years ago, and > changed the default string encoding to UTF-8 at about the same time, and > life has been delightful since then. The only time you ever have to > think about it is when you're importing a string from some unknown > source (e.g. a socket), at which point you need to tell RB what encoding > it is. From that point on, you can pass that string around, extract > substrings, split it into words, concatenate it with other strings, > etc., and it all Just Works (tm). Except that you don't know for sure what the output encoding will be, as it depends on the operations on the strings in the program flow. So to be sure you have to en- or recode at output too. And then it is the same as in Python -- decode when bytes enter the program and encode when (unicode) strings leave the program. > In comparison, Python requires a lot more thought on the part of the > programmer to keep track of what's what (unless, as you point out, you > convert everything into unicode strings as soon as you get them, but > that can be a very expensive operation to do on, say, a 500MB UTF-8 text > file). So it doesn't require more thought. Unless you complicate it yourself, but that is language independent. I would not do operations on 500 MiB text in any language if there is any way to break that down into smaller chunks. Slurping in large files doesn't scale very well. On my Eee-PC even a 500 MiB byte `str` is (too) expensive. > But saying that having only one string type that knows it's Unicode, and > another string type that hasn't the foggiest clue how to interpret its > data as text, is somehow easier than every string knowing what it is and > doing the right thing -- well, that's just silly. Sorry, I meant the implementation not the POV of the programmer, which seems to be quite the same. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Fri, 19 Dec 2008 17:12:00 -0800, r wrote: > Marc, > Why move away from a concise and widely accepted way of sting > formatting, just to supposedly make it a little easier for n00bs? (which > i disagree this is easier) In turn, creating more syntactical clutter. > (%s %f %d) is all you need to remember. If people can't understand that, > i fear for the future of Humans as a species! Yeah, doomsday is near. Curly brackets and a number instead of a percent sign followed by an 's' is a sure sign of the end… You're a funny little troll, Sir. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: encoding problem
On Fri, 19 Dec 2008 15:20:08 -0700, Joe Strout wrote: > Marc 'BlackJack' Rintsch wrote: > >>> And because strings in Python, unlike in (say) REALbasic, do not know >>> their encoding -- they're just a string of bytes. If they were a >>> string of bytes PLUS an encoding, then every string would know what it >>> is, and things like conversion to another encoding, or concatenation >>> of two strings that may differ in encoding, could be handled >>> automatically. >>> >>> I consider this one of the great shortcomings of Python, but it's >>> mostly just a temporary inconvenience -- the world is moving to >>> Unicode, and with Python 3, we won't have to worry about it so much. >> >> I don't see the shortcoming in Python <3.0. If you want real strings >> with characters instead of just a bunch of bytes simply use `unicode` >> objects instead of `str`. > > Fair enough -- that certainly is the best policy. But working with any > other encoding (sometimes necessary when interfacing with any other > software), it's still a bit of a PITA. But it has to be. There is no automagic guessing possible. >> And does REALbasic really use byte strings plus an encoding!? > > You betcha! Works like a dream. IMHO a strange design decision. A lot more hassle compared to an opaque unicode string type which uses some internal encoding that makes operations like getting a character at a given index easy or concatenating without the need to reencode. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: encoding problem
On Fri, 19 Dec 2008 08:20:07 -0700, Joe Strout wrote: > Marc 'BlackJack' Rintsch wrote: > >>> The question is why the Python interpreter use the default encoding >>> instead of "utf-8", which I explicitly declared in the source. >> >> Because the declaration is only for decoding unicode literals in that >> very source file. > > And because strings in Python, unlike in (say) REALbasic, do not know > their encoding -- they're just a string of bytes. If they were a string > of bytes PLUS an encoding, then every string would know what it is, and > things like conversion to another encoding, or concatenation of two > strings that may differ in encoding, could be handled automatically. > > I consider this one of the great shortcomings of Python, but it's mostly > just a temporary inconvenience -- the world is moving to Unicode, and > with Python 3, we won't have to worry about it so much. I don't see the shortcoming in Python <3.0. If you want real strings with characters instead of just a bunch of bytes simply use `unicode` objects instead of `str`. And does REALbasic really use byte strings plus an encoding!? Sounds strange. When concatenating which encoding "wins"? Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Fri, 19 Dec 2008 10:44:25 -0800, r wrote:
> ~Bearophile,
> Thanks for your civil approach to this conversation but I must disagree
> with you on the new string formatting syntax. You said the new syntax is
> suppost to be easier on the n00b , I say it pollutes a students mind.
> What is wrong with similarities to C formatting, I find nothing
> complicated about it.
>
> %s (means put a string here)
> %d (means put a integer here)
> %f (means put a float here)
>
> It does not get any simpler than that,
Well for those simple cases you could simply use '%s' for strings,
integers, and floating point objects in Python. But '{0}' isn't more
complicated. But you get the extra flexibility to decouple the order in
the string and the order of the objects to be formatted.
> and this will just ease the transition to C programming for this
> student. Lets not forget how important C is!
To a Python "n00b"? Not important at all. Beside the point that '%s' is
still possible -- someone who knows C but struggles with replacing '%s'
by '{0}' has far greater problems.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: List comprehension in if clause of another list comprehension
On Fri, 19 Dec 2008 04:26:16 -0800, bearophileHUGS wrote: > Peter Otten: >> The problem is that list comprehensions do not introduce a new >> namespace. > > I think Python3 fixes this bug. Or removes that feature. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: encoding problem
On Fri, 19 Dec 2008 04:05:12 -0800, digisat...@gmail.com wrote: > The below snippet code generates UnicodeDecodeError. > #!/usr/bin/env > python > #--*-- coding: utf-8 --*-- > s = 'äöü' > u = unicode(s) > > > It seems that the system use the default encoding- ASCII to decode the > utf8 encoded string literal, and thus generates the error. > > The question is why the Python interpreter use the default encoding > instead of "utf-8", which I explicitly declared in the source. Because the declaration is only for decoding unicode literals in that very source file. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: How to parsing a sequence of integers
On Fri, 19 Dec 2008 21:20:48 +0800, Steven Woody wrote: > Hi, > > I am a newbie and is reading the python book. Could anyone tell me, how > to parsing the following string >"123 100 12 37 ..." > into a list of integers on which I can then apply max()/min()? In [376]: '123 100 12 37'.split() Out[376]: ['123', '100', '12', '37'] In [377]: map(int, '123 100 12 37'.split()) Out[377]: [123, 100, 12, 37] In [378]: max(map(int, '123 100 12 37'.split())) Out[378]: 123 > In additional to max/min, is there something like average()? No, but it's easy to implement with `sum()`, `len()` and ``/``. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Structure using whitespace vs logical whitespace
On Mon, 15 Dec 2008 12:27:12 -0800, cmdrrickhun...@yaho.com wrote: > On Dec 15, 11:10 am, Terry Reedy wrote: >> > In general, I'm using indentation to show logical flow through code. >> >> That, of course, is what Python does. >> > Python does NOT use indentation to show logical flow. It uses it to > show syntactical flow. What the heck is "syntactical flow"? Of course Python uses indentation for logical flow -- the indentation reflects the program logic. > The XML writer is the perfect example of a case where they are > different. No the program flow there is just some linear calls to methods. It's the XML structure that is not reflected by the indentation, the program flow is represented just fine here. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I return a non-zero status result from a python script?
On Mon, 15 Dec 2008 13:12:08 -0800, silverburgh.me...@gmail.com wrote:
> How can I return a non-zero status result from the script? Just do a
> return 1? at the end?
``sys.exit(42)``
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: the official way of printing unicode strings
On Sun, 14 Dec 2008 06:48:19 +0100, Piotr Sobolewski wrote:
> Then I tried to do this that way:
> sys.stdout = codecs.getwriter("utf-8")(sys.__stdout__)
> s = u"Stanisław Lem"
> print u
> This works but is even more combersome.
>
> So, my question is: what is the official, recommended Python way?
I'd make that first line:
sys.stdout = codecs.getwriter('utf-8')(sys.stdout)
Why is it even more cumbersome to execute that line *once* instead
encoding at every ``print`` statement?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Optimizing methods away or not?
On Sun, 14 Dec 2008 09:19:45 +, Marc 'BlackJack' Rintsch wrote: > class Parrot: > def __init__(self, *args): > print "Initialising instance..." > assert self.verify() Here I meant ``assert self._verify()`` of course. > def _verify(self): > print "Verifying..." > return None Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Optimizing methods away or not?
On Sun, 14 Dec 2008 07:41:55 +, Steven D'Aprano wrote:
> I have a class with a method meant to verify internal program logic (not
> data supplied by the caller). Because it is time-consuming but optional,
> I treat it as a complex assertion statement, and optimize it away if
> __debug__ is false:
>
> class Parrot:
> def __init__(self, *args):
> print "Initialising instance..."
> if __debug__:
> self.verify() # check internal program state, not args
> if __debug__:
> def verify(self):
> print "Verifying..."
>
>
> If I run Python normally, I can do this:
>
>>>> p = Parrot()
> Initialising instance...
> Verifying...
>>>> p.verify()
> Verifying...
>
>
> and if I run Python with the -O flag, I get this:
>
>>>> p = Parrot()
> Initialising instance...
>>>> p.verify()
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: Parrot instance has no attribute 'verify'
>
>
> This is the behaviour I want, but I haven't seen it before in other
> code. What do people think? Is it a good idea or a bad?
>
> If you think it is a bad idea to have verify disappear under
> optimization, would you change your mind if it were called __verify
> instead?
>
>
> One possible alternative is to do something like this:
>
> class Parrot:
> def __init__(self, *args):
> print "Initialising instance..."
> if __debug__:
> self.verify()
> def verify(self):
> if __debug__:
> print "Verifying..."
> return None
> # this is optional
> else:
> warnings.warn("verify() is a null op")
>
>
> which now means that Parrot instances will always have a verify method,
> even if it does nothing. I'm not sure I like that. What do others think?
> Which do you consider better design?
None of it. Why not simply:
class Parrot:
def __init__(self, *args):
print "Initialising instance..."
assert self.verify()
def _verify(self):
print "Verifying..."
return None
If you compile with -O the ``assert`` is optimized away. But you still
can call `_verify()` at specific points even in optimized code if you
want or need.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Umlauts in idle
On Sat, 13 Dec 2008 02:58:48 -0800, a_olme wrote: > On 13 Dec, 10:38, "Martin v. Löwis" wrote: >> > When I try to use umlauts in idle it will only print out as Unicode >> > escape characters. Is it possible to configure idle to print them as >> > ordinary characters? >> >> Did you really use the print statement? They print out fine for me. >> >> Regards, >> Martin > > No I just put the characters in quotes like this "öäå"[::-1] and pressed > return. Then you have two problems: First, you don't have unicode characters but a bunch of bytes which encode the three characters you've showed above. Reversing the bytes might "break" them if your system uses multiple bytes to encode one character, e.g. UTF-8, because the order does matter. Second, if you don't ``print`` but let the interpreter show the result you get the `repr()` form of that character displayed, which always uses escapes for bytes that are non-printable or not within the ASCII range for strings. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: var or inout parm?
On Sat, 13 Dec 2008 02:20:59 +0100, Hrvoje Niksic wrote: > Saner (in this respect) behavior in the tuple example would require a > different protocol. I don't understand why Python doesn't just call > __iadd__ for side effect if it exists. The decision to also rebind the > result of __i*__ methods continues to baffle me. I guess it is a result > of a desire to enable the __i*__ methods to punt and return a different > instance after all, but if so, that design decision brings more problems > than benefits. How often do you use ``+=`` with mutable objects? I use it very often with number types and sometimes with tuples, and there rebinding is necessary. If I couldn't use it in this way: ``x = 0; x += z``, I'd call that a bad design decision. It would be a quite useless operator then. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: var or inout parm?
On Fri, 12 Dec 2008 07:56:58 -0800, sturlamolden wrote: > On Dec 12, 4:55 pm, sturlamolden wrote: > >> def __setitem__(self, index, value): >>if _buf[index] is not value: # given that _buf is the tuple's >> internal buffer >> raise TypeError, 'tuple' object does not support item >> assignment > > blæh, that should be self._buf[index] But then the error message is not true anymore because tuples *would* support item assignment when the old and new value are the same. Which leads to strange things like code that may or may not raise that exception, depending on implementation details: t = (1, 2) t[0] = 1 # Maybe okay -- maybe not. t[1] += 0 # Same here. I'd find that quite odd. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Removing None objects from a sequence
On Fri, 12 Dec 2008 16:51:15 +0100, Marco Mariani wrote: > Filip Gruszczyński wrote: > > >> I am not doing it, because I need it. I can as well use "if not elem is >> None", > > I suggest "if elem is not None", which is not quite the same. In which way is it not the same? Has the same behavior at least: In [256]: elem = None In [257]: not elem is None Out[257]: False In [258]: elem is not None Out[258]: False In [259]: elem = 42 In [260]: not elem is None Out[260]: True In [261]: elem is not None Out[261]: True > If you slip such an error in a post, I suggest to practice some time > writing correct code before having one-liner contests with your > perl-loving friends :) If you call something an error, make sure it really is one. :-) Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: var or inout parm?
On Fri, 12 Dec 2008 05:39:35 -0800, sturlamolden wrote: > On Dec 12, 2:34 pm, Hrvoje Niksic wrote: > >> >>> import numpy >> >>> t = (numpy.zeros(10),) >> >>> t >> >> (array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.]),)>>> t[0] += >> 1 >> >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: 'tuple' object does not support item assignment >> >> Of course, the side effect occurs before the exception, so: >> >> >>> t[0] > >> array([ 1., 1., 1., 1., 1., 1., 1., 1., 1., 1.]) > > > Actually I would consider this to be a bug. The tuple is immutable, but > no mutation of the tuple is ever attempted. No bug because a mutation *is* attempted. ``a += x`` calls `a.__iadd__` which *always* returns the result which is *always* rebound to the name `a`. Even with mutable objects where `__iadd__()` simply returns `self`! It has to be this way because the compiler has no idea if the object bound to `a` will be mutable or immutable when the code actually runs. In [252]: def f(a, x): .: a += x .: In [253]: dis.dis(f) 2 0 LOAD_FAST0 (a) 3 LOAD_FAST 1 (x) 6 INPLACE_ADD 7 STORE_FAST 0 (a) 10 LOAD_CONST 0 (None) 13 RETURN_VALUE Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: (Very Newbie) Problems defining a variable
On Fri, 12 Dec 2008 04:58:36 -0800, feba wrote:
> Actually, I have gedit set to four spaces per tab. I have no reason why
> it's showing up that large on copy/paste, but the file itself is fine.
The file contains one tab character per indentation level and it depends
on the software you use to look at the text how many spaces will be
displayed. Better use four real spaces to indent one level so it looks
the same everywhere.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: File names, character sets and Unicode
On Fri, 12 Dec 2008 23:32:27 +1300, Michal Ludvig wrote:
> is there any way to determine what's the charset of filenames returned
> by os.walk()?
No. Especially under *nix file systems file names are just a string of
bytes, not characters. It is possible to have file names in different
encondings in the same directory.
> The trouble is, if I pass argument to os.walk() I get the
> filenames as byte-strings. Possibly UTF-8 encoded Unicode, who knows.
Nobody knows. :-)
> What's the right and safe way to walk the filesystem and get some
> meaningful filenames?
The safe way is to use `str`.
> Related question - if the directory is given name on a command line
> what's the right way to preprocess the argument before passing it down
> to os.walk()?
Pass it as is.
> For instance with LANG=en_NZ.UTF-8 (i.e. UTF-8 system): * directory is
> called 'smile☺'
> * sys.argv[1] will be 'smile\xe2\x98\xba' (type str) * after
> .decode("utf-8") I get u'smile\u263a' (type unicode)
>
> But how should I decode() it when running on a system where $LANG
> doesn't end with "UTF-8"? Apparently some locales have non-ascii default
> charsets. For instance zh_TW is BIG5 charset by default, ru_RU is
> ISO-8850-5, etc. How do I detect that to get the right charset for
> decode()?
You can't. Even if you know the preferred encoding of the system, e.g.
via $LANG, there is no guarantee that all file names are encoded this way.
> I tend to have everything internally in Unicode but it's often unclear
> how to convert some inputs to Unicode in the first place. What are the
> best practices for dealing with these chraset issues in Python?
I'm usually using UTF-8 as default but offer the user ways, e.g. command
line switches, to change that.
If I have to display file names in a GUI I use a decoded version of the
byte string file name, but keep the byte string for operations on the
file.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Announcement: MindTree for Python beta -- feedback appreciated
On Wed, 10 Dec 2008 23:47:05 +1300, greg wrote: > Johann Spies wrote: > >> % /usr/local/bin/python3.0 MindTree.pyw >> Traceback (most recent call last): >> File "MindTree.pyw", line 2, in >> from future_builtins import * >> ImportError: No module named future_builtins > > Hmmm... does this mean that Python3 has no future? :-) It is just not built in. So it is easier to change the future by replacing the module. ;-) Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 3.0 worth breaking backward compatibility?
On Tue, 09 Dec 2008 20:56:19 +, Lie Ryan wrote: > Interestingly, many linux _distro_ also inhibit this quick version > number change. Fedora 10, Ubuntu is 2 years old, version 8 (they start > from version 6 not 1). Ubuntu's version numbers don't follow the usual rules but are year and month of release. So this year's releases have "version" 8 and the latest is from october so it is 8.10. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: how to get a beep, OS independent ?
On Sun, 07 Dec 2008 07:17:30 -0700, Joe Strout wrote: > But invoking the standard system beep is such a basic function that it > ought to be easier than this. I'm pretty sure it's a single OS call on > all platforms. On OS X, for example, it's > >void NSBeep(void); > > declared in NSGraphics.h. I'm sure it's something similarly simple on > other platforms. I'm not so sure. Under Unix the "system beep" is usually in the terminal emulation and triggered by sending '\a' to it. AFAIK there is no standard beep in X-Windows so every desktop environment implements something like audio notifications. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido's new method definition idea
On Sat, 06 Dec 2008 09:56:12 +0100, Antoine De Groote wrote: > try this: > >>>> import this > > and look at the 15th line... The reason why I'm against that change too. It adds a second, alternative way to express something that is already in the language. > I agree that for newcomers to Python, the class method definition might > seem strange. And after the change it continues to because they will run into *both* variants in tutorials, code, and books, so it might be even more confusing. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: pydoc enforcement.
On Sun, 30 Nov 2008 16:27:07 -0800, [EMAIL PROTECTED] wrote: > Basically I'm interested adding a check to see if: > 1) pydoc's are written for every function/method. Pylint warns for missing docstrings. > 2) There are entries for each parameter, defined by some predetermined syntax. But which syntax? There are several in use out there. Even the (I think) popular epydoc allows at least three, its own, something JavaDoc like, and ReST. And I dislike forcing to document every parameter. There's lots of code that is clear just by the names of the parameters and one or two usage examples in the docs. Forcing to state the obvious again does not add information for the user and is annoying for the programmer. > My idea is that as much as I love dynamic typing, there are times when > using some modules/API's that have less than stellar documentation. I > was thinking that if it was possible to enable some switch that > basically forced compilation to fail if certain documentation criteria > weren't met. But that doesn't enforce good or even real documentation either. Even worse, you can't spot the undocumented parts of the code anymore, because now every "docable" object has "documentation" like this just to make the compiler happy: def spam(foo, bar): """ :param foo: a foo object. :param bar: a bar object. """ Which basically tells the same as no documentation at all. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode and hashlib
On Sat, 29 Nov 2008 06:51:33 -0800, Jeff H wrote:
> Actually, what I am surprised by, is the fact that hashlib cares at all
> about the encoding. A md5 hash can be produced for an .iso file which
> means it can handle bytes, why does it care what it is being fed, as
> long as there are bytes.
But you don't have bytes, you have a `unicode` object. The internal byte
representation is implementation specific and not your business.
> I would have assumed that it would take
> whatever was feed to it and view it as a byte array and then hash it.
How? There is no (sane) way to get at the internal byte representation.
And that byte representation might contain things like pointers to memory
locations that are different for two `unicode` objects which compare
equal, so you would get different hash values for objects that otherwise
look the same from the Python level. Not very useful.
> You can read a binary file and hash it
> print md5.new(file('foo.iso').read()).hexdigest()
> What do I need to do to tell hashlib not to try and decode, just treat
> the data as binary?
It's not about *de*coding, it is about *en*coding your `unicode` object
so you get bytes to feed to the MD5 algorithm.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Instance attributes vs method arguments
On Tue, 25 Nov 2008 10:48:01 +, John O'Hagan wrote: > On Tue, 25 Nov 2008, Marc 'BlackJack' Rintsch wrote: >> On Tue, 25 Nov 2008 07:27:41 +, John O'Hagan wrote: >> > Is it better to do this: >> > >> > class Class_a(): >> >def __init__(self, args): >> >self.a = args.a >> >self.b = args.b >> >self.c = args.c >> >self.d = args.d >> >def method_ab(self): >> >return self.a + self.b >> >def method_cd(self): >> >return self.c + self.d >> > […] >> >> The question is if `args.a`, `args.b`, …, are semantically part of the >> state of the objects or not. Hard to tell in general. > > Would you mind elaborating a little on that first sentence? Do `self.a`, `self.b`, …, define the state of a `Class_a` instance or not? One can't answer that question without knowing the meaning of the class and the attributes. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Instance attributes vs method arguments
On Tue, 25 Nov 2008 07:27:41 +, John O'Hagan wrote: > Is it better to do this: > > class Class_a(): > def __init__(self, args): > self.a = args.a > self.b = args.b > self.c = args.c > self.d = args.d > def method_ab(self): > return self.a + self.b > def method_cd(self): > return self.c + self.d > > or this: > > class Class_b(): > def method_ab(self, args): > a = args.a > b = args.b > return a + b > def method_cd(self, args) > c = args.c > d = args.d > return c + d > > ? > > Assuming we don't need access to the args from outside the class, is > there anything to be gained (or lost) by not initialising attributes > that won't be used unless particular methods are called? The question is if `args.a`, `args.b`, …, are semantically part of the state of the objects or not. Hard to tell in general. I know it's a made up example but in the second class I'd ask myself if those methods are really methods, because they don't use `self` so they could be as well be functions or at least `staticmethod`\s. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Using dictionary to hold regex patterns?
On Mon, 24 Nov 2008 00:46:42 +0100, Gilles Ganault wrote: > On Sun, 23 Nov 2008 23:18:06 +, MRAB <[EMAIL PROTECTED]> > wrote: >>A list is an ordered collection of items. Each item can be anything: a >>string, an integer, a dictionary, a tuple, a list... > > Yup, learned something new today. Naively, I though a list was > index=value, where value=a single piece of data. Your thought was correct, each value is a single piece of data: *one* tuple. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: initialization in argument definitions
On Sun, 23 Nov 2008 13:13:11 +1300, greg wrote: > George Sakkis wrote: > >> Don't worry, it's not obvious to *anyone* new to Python (and many not- >> so-new for that matter). > > That's by no means certain, because we only hear from the people who > guessed the wrong way. We have no way of knowing how many people guessed > the right way. Or how many worked through the tutorial, stumbled across the warning about that behavior and got that question answered before they have even known there's something to guess. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Avoiding local variable declarations?
On Tue, 18 Nov 2008 00:18:51 +, Steven D'Aprano wrote: > On Mon, 17 Nov 2008 12:32:35 +0000, Marc 'BlackJack' Rintsch wrote: > >> Not such illogical crap like >> ``a = a + 1`` which must be obviously false unless 1 is defined as the >> neutral element for the definition of ``+`` here. > > I don't quite know what you mean by "neutral element". I think you mean > the identity element […] I knew I should have looked it up instead of "translating" it from my mother tongue -- yes I ment "identity element". Sorry for the confusion. Ciao, Marc 'BlackJack' Rintch -- http://mail.python.org/mailman/listinfo/python-list
Re: Avoiding local variable declarations?
On Mon, 17 Nov 2008 10:10:16 +, Jorgen Grahn wrote: > On Thu, 13 Nov 2008 12:49:02 -0800 (PST), dpapathanasiou > <[EMAIL PROTECTED]> wrote: ... >>> but what's wrong with you original code? >> >> I come from a functional programming school of thought, where you avoid >> local variable declarations if at all possible. > > I'm not sure that's universal. Using Standard ML at Uni, it was often > useful to use "let name = expr in expr" (or whatever the syntax was) to > simplify an expression. Directly borrowed from mathematics, I assume. That's (also?) Haskell syntax and I agree that it is useful to write readable code. > 'name' is not a variable, of course; there are no variables in > functional programming. Can't remember what it's called -- named > expression, maybe? I think it's called variable and works like variables work in mathematics, i.e. you can assign only once. Not such illogical crap like ``a = a + 1`` which must be obviously false unless 1 is defined as the neutral element for the definition of ``+`` here. :-) Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: [UnicodeEncodeError] Don't know what else to try
On Sat, 15 Nov 2008 14:12:42 +0100, Gilles Ganault wrote: > On Fri, 14 Nov 2008 17:39:00 +0100, "Martin v. Löwis" > <[EMAIL PROTECTED]> wrote: >>Can you first please report what happened when you add the print >>statement? > > Thanks guys, I found how to handle this: > > === > for id in rows: > #Says Unicode, but it's actually not > #print type(id[1]) > # If it says `unicode` *it is* `unicode`. > try: > print id[1]; > except UnicodeEncodeError: > print "Not unicode" But it *is* `unicode` if `type()` says so! Your code still fails when ``id[1]`` can't be encoded in `sys.encoding`, 'iso8859-15', or 'cp1252'. Even worse: The output may be even encoded in different encodings this way. That's garbage you can't decode properly with one encoding anymore. A clean solution would be just one ``print`` with a call of `encode()` and an explicit encoding. I'd use 'utf-8' as default but give the user of the program a possibility to make another choice. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: [UnicodeEncodeError] Don't know what else to try
On Fri, 14 Nov 2008 14:57:42 +0100, Gilles Ganault wrote:
> On Fri, 14 Nov 2008 11:01:27 +0100, "Martin v. Löwis"
> <[EMAIL PROTECTED]> wrote:
>>Add
>>print type(output)
>>here. If it says "unicode", reconsider the next line
>>
>>> print output.decode('utf-8')
>
> In case the string fetched from a web page turns out not to be Unicode
> and Python isn't happy, what is the right way to handle this, know what
> codepage is being used?
How do you fetch the data? If you simply download it with `urllib` or
`urllib` you never get `unicode` but ordinary `str`\s. The you have to
figure out the encoding by looking at the headers from the server and/or
looking at the fetched data if it contains hints.
And when ``print``\ing you should explicitly *encode* the data again
because sooner or later you will come across a `stdout` where Python
can't determine what the process at the other end expects, for example if
output is redirected to a file.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: multiple breaks
On Thu, 13 Nov 2008 11:07:25 +0100, TP wrote: > According to this page, the best way is to modify the loop by affecting > the variables that are tested in the loops. Otherwise, use exception: > > "If, for some reason, the terminating conditions can't be worked out, > exceptions are a fall-back plan." > > In the following example, is this possible to affect the two iterators > to escape the two loops once one "j" has been printed: > > for i in range(5): > for j in range(i): >print j ># I would type "break 2" in shell bash # In C, I would set j=i-1 >and i=4 ># In Python, is this possible to affect the two iterators? > > Or the only means is to use exception? You could put the code into its own, maybe local, function and use ``return``. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: sys.stdout, urllib and unicode... I don't understand.
On Tue, 11 Nov 2008 12:18:26 -0800, Thierry wrote:
> I have realized an wxPython simple application, that takes the input of
> a user, send it to a web service, and get back translations in several
> languages.
> The service itself is fully UTF-8.
>
> The "source" string is first encoded to "latin1" after a passage into
> unicode.normalize(), as urllib.quote() cannot work on unicode
>>>srcText=unicodedata.normalize('NFKD',srcText).encode('latin1','ignore')
If the service uses UTF-8 why don't you just encode the data you send as
UTF-8 but Latin-1 with potentially throwing away data because of the
'ignore' argument!? Make that ``src_text = unicodedata.encode('utf-8')``
>>>req=urllib2.urlopen(con)
>
> First problem, how to determine the encoding of the return ? If I
> inspect a request from firefox, I see that the server return header
> specify UTF-8
> But if I use this code:
>>>ret=U''
>>>for line in req:
>>> ret=ret+string.replace(line.strip(),'\n',chr(10))
> I end up with an UnicodeDecodeError.
Because `line` contains bytes and `ret` is a `unicode` object. If you
add a `unicode` object and a `str` object, Python tries to convert the
`str` to `unicode` using the default == ASCII encoding. And this fails
if there are byte value >127. *You* have to decode `line` from a bunch
of bytes to a bunch of (unicode)characters before you concatenate the
strings.
BTW: ``line.strip()`` removes all whitespace at both ends *including
newlines*, so there are no '\n' to replace anymore. And functions in the
`string` module that are also implemented as method on `str` or `unicode`
are deprecated.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: Simple question about Python lists
On Tue, 11 Nov 2008 11:47:53 -0800, Eric wrote: > I'm learning Python (while coming from MATLAB). One question I have is > that if I have a list with say 8 elements, and I want just a few of them > how do I select them out. In MATLAB, if I just want the first, fifth and > eighth element I might do something like this: > > b = a([1 5 8]); > > I can't seem to figure out a similar Python construct for selecting > specific indices. Any suggestions? b = [a[i] for i in [1, 5, 8]] Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 - is this true?
On Mon, 10 Nov 2008 16:32:47 +, Robin Becker wrote: > on the other hand I find it odd that > > cmp(None,None) fails in Python 3 when None==None returns True. That's because there is no order defined for `NoneType` but equality is. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: C Module question
On Mon, 10 Nov 2008 05:44:44 -0800, [EMAIL PROTECTED] wrote: > All in all I must say that implementing a C extension is a piece of > cake. Had I known that it was this straightforward I wouldn't have asked > my questions in the first place. Making the whole thing more robust will > be a bit more difficult, and I need to find out how to deal with > ressources that are dynamically allocated on the C side. > > But that should be easy, and I'll just keep all the Python OO and > Exceptions stuff in the wrapper and call my C stuff from there in a more > or less straightforward C manner. Then you might considering the `ctypes` module to call your C stuff. This way it is easier to build the extension and it is also independent from the Python version. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: C Module question
On Mon, 10 Nov 2008 05:36:58 -0800, [EMAIL PROTECTED] wrote: > On Nov 10, 1:16 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: >> On Mon, 10 Nov 2008 03:11:06 -0800, [EMAIL PROTECTED] wrote: >> > 1. How can I pass a file-like object into the C part? The PyArg_* >> > functions can convert objects to all sort of types, but not FILE*. >> >> http://docs.python.org/c-api/file.html#PyFile_AsFile > > Yes, got it. At first I thought I had to use the "Parse" functions for > my args, but in fact I can of course just access the args as a tuple > (and then do the type checking myself). > >> Why passing it in and out? Simply use the C module level to store the >> information. > > But if I create several instances of a class (in the wrapper module) my > C methods won't know which object they were called on. Well you talked about functions in the module not about methods on objects. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
