Announcement: Project to get some CPython C extensions running under IronPython
The great thing about CPython is that it comes with the batteries included. The problem with IronPython is that some of these batteries just don't fit - in particular, most of the the C extensions don't work. We'd like to help fix at least some of this problem, to help people who use IronPython to use their CPython scripts without having to port everything over to .NET. Solving the general problem - plugging an arbitrary C extension into IronPython - is a huge project, and we're not even sure we could work out *how much work it is* without a lot of investigation. What we intend to do is to solve a specific problem, to integrate just one extension, and to use that project as a testbed to examine the possibilities for getting other extensions working - and perhaps, in the long term, solving the general problem. We think that any solution like this will be valuable not just to us, but to the Python community as a whole. And so, we want to make it Open Source. Right now, we'd really like to hear from people about the following: * Who wants to get involved? We're really keen on working with other people on this. * Which module should we go for? NumPy looks like a good start, as it gives us a start on getting SciPy working. But perhaps there are better choices. * Should this be a new project, or should we be talking to other people about getting it into other projects? * Which license? If we're to work on it with a view to building it into Resolver One, then it will need to be commercial-software-friendly. Apart from that - we have no view. * What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would sandwich this layer. Let us know if this is a silly idea :-) * Is there anything else we should be thinking about to get this started? Any thoughts much appreciated! Regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: the secret life of zombies
I fixed it myself -- I had to install a signal handler and use nested 'try-expect' stuff. The link points to the new version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
Hello, I would recommend pyGTK http://www.pygtk.org/ - your app does look the same on all platform (like for Tkinter) (This argurment apply if the same user would like to run the same app on different platform and thus do not want to see something different on each platform...) - easy to install on all platform: An all in one installed exist for windows: http://aruiz.typepad.com/siliconisland/2006/12/allinone_win32_.html - it looks nice and simple (it is originally the Gimp toolkit). Just my two cents, David 2007/10/12, [EMAIL PROTECTED] [EMAIL PROTECTED]: I've been programming in Python for 5 or more years now and whenever I want a quick-n-dirty GUI, I use Tkinter. This is partly because it's the first toolkit I learnt, but also because it's part of the standard Python distribution and therefore easy to get Python apps to work cross platform - it usually requires almost no porting effort. However, when I need a little bit more grunt, I tend to turn to Tix, which I thought was also fairly standard. However, this week, I wrote a Tix application under Linux which I'd really like to work on Mac OS and it's proving fairly painful to get it going. There is no Tix in the standard fink or apt repositories and when I download a tar-ball, it wouldn't build because it had a lot of unmet dependencies. I then read a post which said that only Tkinter/Python people really use Tix anymore and people in tcl/tk moved onto better toolkits long ago. My question is if Tix is old hat, what is the GUI toolkit I *should* be using for quick-n-dirty cross platform GUI development? I guess this is tangentially related to: http://groups.google.com/group/comp.lang.python/browse_thread/thread/2ed58ff6ac7d030c/42ed0d40ffd0b1c0?lnk=gstq=tix+#42ed0d40ffd0b1c0 I hope this isn't a stupid question. I'm wearing flame retardant underwear. Peter -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Foreign Character Problems In Python 2.5 and Tkinter
Hi,
I'm writing a small text editor type application with Python 2.5 and
Tkinter. I'm using the Tk text widget for input and output, and the
problem is that when I try to save its contents to a .txt file, any
Scandinavian letters such as äöå ÄÖÅ are saved incorrectly and show up
as a mess when I open the .txt file in Windows Notepad.
It seems that the characters will only get mixed if the user has typed
them into the widget, but if the program has outputted them, they are
saved correctly.
The function that is saving the file is as follows:
try:
file = open(self.currentSaveFile, 'w+')
file.write(self.text.get(0.0, END))
except IOError:
tkMessageBox.showwarning('Save File', 'An error occurred while trying to
save \' + self.currentSaveFile + '\', parent=self.frame)
finally:
file.close()
Sometimes its output in the file is äöå ÄÖÅ for äöå ÄÖÅ and
sometimes it gives me the error: UnicodeEncodeError: 'ascii' codec
can't encode characters in position 33-35: ordinal not in range(128)
I have tried changing it to:
try:
file = codecs.open(savefilename, 'w+', 'utf-8', 'ignore')
file.write(unicode(self.text.get(0.0, END), 'utf-8', 'ignore'))
self.currentSaveFile = savefilename
except IOError:
tkMessageBox.showwarning('Save File', 'An error occurred while trying to
save \' + self.currentSaveFile + '\', parent=self.frame)
finally:
file.close()
Which does save the user-typed characters correctly, but loses any
newlines and äöå characters outputted by the program.
I have no idea how solve this problem, and would appreciate any help.
--
http://mail.python.org/mailman/listinfo/python-list
Re: raw_input() and utf-8 formatted chars
On Fri, 12 Oct 2007 19:09:46 -0700, 7stud wrote: On Oct 12, 2:43 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: You mean literally!? Then of course I get A\xcc\x88 because that's what I entered. In string literals in source code the backslash has a special meaning but `raw_input()` does not interpret the input in any way. Then why don't I end up with the same situation as this: s = 'A\xcc\x88' #capital A with umlaut print s #displays capital A with umlaut I don't get the question!? In string literals in source code the backslash has a special meaning, like I wrote above. When Python compiles that above snippet you end up with a string of three bytes, one with the ASCII value of an 'A' and two bytes where you typed in the byte value in hexadecimal: In [191]: s = 'A\xcc\x88' In [192]: len(s) Out[192]: 3 In [193]: map(ord, s) Out[193]: [65, 204, 136] In [194]: print s Ä The last works this way only if the receiving/displaying program expected UTF-8 as encoding. Otherwise something other than an Ä would have been shown. If you type in that text when asked by `raw_input()` then you get exactly what you typed because there is no Python source code compiled: In [195]: s = raw_input() A\xcc\x88 In [196]: len(s) Out[196]: 9 In [197]: map(ord, s) Out[197]: [65, 92, 120, 99, 99, 92, 120, 56, 56] In [198]: print s A\xcc\x88 And what is it that your keyboard enters to produce an 'a' with an umlaut? *I* just hit the key. The one right next to the ö key. ;-) ...and what if you don't have an a-with-umlaut key? I find other means to enter it. Alt + some magic number on the numeric keypad in windows, or Compose, a, on Unix/Linux. Some text editors offer special sequences too. If all fails there are character map programs that show all unicode characters to choose from and copy'n'paste them. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Python in HTML Application (HTA)
Hello,
I encounter a display problem in one of my script
...
...
def setValue(divid,data):
elt = document.getElementById(divid)
elt.innerHTML = data
def infoSystem():
setValue(info,Please Wait) #update div info
c = os.popen(cmdDisk%Server).read()
setValue('tabcentre',c)
...
...
When I call 'infoSystem', the 'info' div
is only updated at the end of the 'infoSystem' call.
Did someone have an explication of that behavior ?
Regards
Salvatore
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Pyro] ConnectionClosedError
George Sakkis ge...ail.com wrote:
Didn't have much luck with this in the Pyro mailing list so I am
trying here, just in case. I have a Pyro server running as a daemon
process and occasionally (typically after several hours or days of
uptime) a ConnectionClosedError is raised when a client calls a remote
method. Both client and server run on the same machine, so I don't
think it's an actual network connectivity issue. The problem is that
once this happens, it is persistent; retrying to call a few times does
not work although the server process is still alive. The current
solution is to manually kill the server and restart it but obviously
this is not ideal. Is there a way to either prevent or at least
recover automatically the server when it hangs ?
If restarting the server sorts it, why don't you run the server as a
subprocess in a higher level script, and exit with an error code
if the error strikes?
something like:
While True:
error = os.system('python current_server_name.py')
if error:
print 'Restarting the server - error returned was:',error
continue
else:
break
It would obviously need a try - except in the existing
code to catch the exception, and some jiggery-pokery
if the code is threaded to ensure a clean error exit,
but apart from that, I can't think of a reason for it not
to work.
It may be that the reason for your hang up is also a
threading issue - it could be that the server is alive but
that some critical thread has been killed by the error.
But here I am guessing...
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python in HTML Application (HTA)
In fact, whatever I do in infoSystem (modifiying style attributes of
an object, change cursor appearance...), changes are only reflected
at the end of the function call ...
Salvatore a écrit :
Hello,
I encounter a display problem in one of my script
...
...
def setValue(divid,data):
elt = document.getElementById(divid)
elt.innerHTML = data
def infoSystem():
setValue(info,Please Wait) #update div info
c = os.popen(cmdDisk%Server).read()
setValue('tabcentre',c)
...
...
When I call 'infoSystem', the 'info' div
is only updated at the end of the 'infoSystem' call.
Did someone have an explication of that behavior ?
Regards
Salvatore
--
http://mail.python.org/mailman/listinfo/python-list
Re: Moving objects in Tkinter
Evjen Halverson wrote: I have tried to make a Tkinter program make a rectangle move down the window, but did not succeed. All it does is make a rectangle trail. What am I doing wrong? You are not deleting the old instances of the rectangle. Look at the delete method of the canvas widget. This is Gold Plated Guaranteed (Tm) to work. There is an alternative too, which I have never used, so no Gold Plated Guarantee. Look at the coords method of the canvas widget. It seems to let you get and set the position of something. HTH - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Pyro: ActiveState (wind32) to Unix
Tim Golden wrote: Sells, Fred wrote: I'm using ActiveState python on a windows box to talk to ACtive Directory. I'm running a Pyro Server on the same box. The client is Linux running std Python 2.4. It works just fine until the server codes calls some win32com.client api; then I get ImportError: No module named pywintypes [followed by private email from Fred containing the client/server files] Well it works ok for me running from an XP box to a Ubuntu VMWare image on the same machine. Since I don't have AD running on this laptop I made as few changes as possible to substitute WMI instead which uses the same Python Windows tech. infrastructure -- ie you pass a moniker to win32com.client.GetObject. Obviously there could be something specific to the AD LDAP: interface here but I seriously doubt it. One thing you will have to be aware of -- although I honestly doubt it's behind the issue here -- is that running a Pyro server means implictly running in threads. And *that* means that, since the LDAP: interface is a (D)COM-based interface, you'll need to call pythoncom.CoInitialize to kick COM into threading mode. Failing to do that using WMI causes the mildly bizarre Syntax error when you try to do .GetObject (wimgmts:...). It's just possible that the error you're seeing is the LDAP equivalent. And that Pyro is trying to pull the error message across the link to tell you what it is. (Maybe). In short, then, try adding the line: pythoncom.CoInitialize () within the proxy's .getProperties method (having imported pythoncom up to, of course) and then: pythoncom.CoUninitialize () just before the return in that method. I've only just realised that this is a thread on the main python-list. If this goes nowhere here, try copying it over to the Pyro mailing list; I'm not sure if Irmen (Mr Pyro) follows this list. TJG -- http://mail.python.org/mailman/listinfo/python-list
How to modify EVDEV.py to record Keyboard Key RELEASE times?
I'm using a modified EVDEV.py program (see below) to record inter-keystroke
times for Keystroke triples and doubles (t2 - t1, t3 -t1). These times are
key PRESS times.
How - where can EVDEV.py be modified (without too much trouble) to record
Keystroke RELEASE times also ?
Thanks for your help.
---
#!/usr/bin/env python
evdev.py
This is a Python interface to the Linux input system's event device.
Events can be read from an open event file and decoded into spiffy
python objects. The Event objects can optionally be fed into a Device
object that represents the complete state of the device being monitored.
Copyright (C) 2003-2004 Micah Dowty [EMAIL PROTECTED]
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
import struct, sys, os, time
from socket import gethostname
from fcntl import ioctl
__all__ = [Event, Device]
def demo():
Open the event device named on the command line, use incoming
events to update a device, and show the state of this device.
dev = Device(sys.argv[1])
try:
while 1:
dev.poll()
except:
dev.log.close()
return dev.get_filename()
class BaseDevice:
Base class representing the state of an input device, with axes and
buttons.
Event instances can be fed into the Device to update its state.
def __init__(self):
self.axes = {}
self.buttons = {}
self.name = None
self.next2last = None
self.next2lasttime = None
self.next2lastpress = 'NONE'
self.last = None
self.lasttime = None
self.lastpress = 'NONE'
self.echo = {}
#make log directory
if not os.path.isdir(./logs):
os.mkdir(./logs)
#new filename
hostname = str(gethostname())
filename = str(hostname) + _log_ + str(time.asctime()).replace(:,
_).replace( , _)
#open log file
self.log = open(./logs/ + filename, w)
self.filename = ./logs/ + filename
#self.log.write(\n\n\n\nHOSTNAME: + str(hostname) + \n + (_ *
60) + \n)
def get_filename(self):
return self.filename
def __repr__(self):
return Device name=%r axes=%r buttons=%r % (
self.name, self.axes, self.buttons)
def update(self, event):
f = getattr(self, update_%s % event.type, None)
if f:
f(event)
def update_EV_KEY(self, event):
if event.code not in self.echo:
self.echo[event.code] = 0
if self.echo[event.code] = 1:
self.echo[event.code] = 0
return
else:
self.echo[event.code] += 1
now = time.time()
if self.lasttime == None:
#self.lasttime = time.time()
self.lasttime = now
if self.next2lasttime == None:
self.next2lasttime = now
#now = time.time()
newtime = now - self.lasttime
new3time = now - self.next2lasttime
#self.log.write(repr(self.lastpress) + _ + repr(event.code) + \t\t
+ str(newtime) + \n)
self.log.write(self.lastpress + _ + event.code + \t\t +
str(newtime) + \n)
self.log.write(self.next2lastpress + _ + self.lastpress + _ +
event.code + \t\t + str(new3time) + \n)
self.next2lastpress = self.lastpress
self.lastpress = event.code
self.next2lasttime = self.lasttime
self.lasttime = now
def update_EV_ABS(self, event):
self.axes[event.code] = event.value
def update_EV_REL(self, event):
self.axes[event.code] = self.axes.get(event.code, 0) + event.value
def __getitem__(self, name):
Retrieve the current value of an axis or button,
or zero if no data has been received for it yet.
if name in self.axes:
return self.axes[name]
else:
return self.buttons.get(name, 0)
# evdev ioctl constants. The horrible mess here
# is to silence silly FutureWarnings
EVIOCGNAME_512 = ~int(~0x82004506L 0xL)
EVIOCGID = ~int(~0x80084502L 0xL)
EVIOCGBIT_512 = ~int(~0x81fe4520L 0xL)
EVIOCGABS_512 = ~int(~0x80144540L 0xL)
class Device(BaseDevice):
An abstract input device attached to a Linux evdev device node
def __init__(self,
Re: Python module for making Quicktime or mpeg movies from images
On 12 Oct, 20:53, jeremito [EMAIL PROTECTED] wrote: I actually found NodeBox in my googling. This seems to be a stand alone application. I need to be able to convert my images to a movie from my code I wrote myself. Some Mac-specific options: - QuickTime Player is standard on OS X and its scripting interface (which you can access from Python via appscript, and is fully usable even in unpaid mode) includes an 'open image sequence' command. This would be the simplest solution as long as you don't mind launching another application to do the work. - The Cocoa API's QTKit class (accessible via PyObjC) includes a - addImage:forDuration:withAttributes: method that you could use to build up a movie yourself. - The Mac version of Python includes wrappers for a number of Carbon APIs, including QuickTime. One for brave souls only; QT's C APIs are notoriously complex, and I've no idea of the quality/reliability of the Carbon.Qt wrapper (most of Python's Carbon wrappers haven't been fully maintained since OS9 days). HTH has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
On 2007-10-13, David Tremouilles [EMAIL PROTECTED] wrote: I would recommend pyGTK http://www.pygtk.org/ Native GTK on OSX is still in its infancy. For early adopters only at this point. See http://www.oreillynet.com/articles/author/2414 That leaves PyQt and WxPython as the only other realistic choices. Licensing issues aside, I think Qt has the most polished and well thought out API. The OSX Tiger dev tools include WxPython, though you may want to install a newer version. I suggest installing both and trying some of the included examples. Another possibility is Jython, if you like the Java way of doing things. Dave Cook -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
No issue with pygtk on mac! Actually I develop on this platform everyday. Macport take care of the installation for me http://www.macports.org/ (Fink should do the work too). Of course native GTK on OSX could be nice but definitely not needed at this point in time. David 2007/10/13, Dave Cook [EMAIL PROTECTED]: On 2007-10-13, David Tremouilles [EMAIL PROTECTED] wrote: I would recommend pyGTK http://www.pygtk.org/ Native GTK on OSX is still in its infancy. For early adopters only at this point. See http://www.oreillynet.com/articles/author/2414 That leaves PyQt and WxPython as the only other realistic choices. Licensing issues aside, I think Qt has the most polished and well thought out API. The OSX Tiger dev tools include WxPython, though you may want to install a newer version. I suggest installing both and trying some of the included examples. Another possibility is Jython, if you like the Java way of doing things. Dave Cook -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Hello everybody, I just joined this mailing list. Thanks for your comments about gluon. I have posted a short video about it and I am planning to make more over the week-end. http://www.youtube.com/watch?v=VBjja6N6IYk About some of your comments: - the most complex modules (like html and sql ones) have doctests. - the executable versions (win and mac) come with python2.5. Running from source code does not require 2.5 but you probably want sqlite3. - so far I support sqlite3 and postgresql, not mysql (just because I do not use it and had no time for testing it). - yes, there are typos in the documentation. Please point them out to me so that I can fix them. - I am sure there are some minor bugs I am not aware of but as far I tested, it work. - If you report bugs to me I promise to fix them in 48hrs. - please make sure you have the latest version. I very much appreciate comments about gluon (good and bad). Please send me more so that I can improve it. There will be two talks in chicago about gluon next week: at DePaul Linux Users Group on Thursday evening and at the Chicago Linux Users Group on Saturday afternoon. I will try record them and post them. Massimo P.S. Michele Simionato. I have heard your name before? Is it possible we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist and there is not many of us. Hi Massimo, In what way is gluon different from existing frameworks most notably django and turbogears? What do you think are the advantages to using gluon over these two? Cheers, Daniel -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
On 2007-10-13, David Tremouilles [EMAIL PROTECTED] wrote: No issue with pygtk on mac! If running on top of X11 is no problem. Actually I develop on this platform everyday. Macport take care of the installation for me http://www.macports.org/ (Fink should do the work too). In that case I'd recommend kiwi as well http://www.async.com.br/projects/kiwi/ Dave Cook -- http://mail.python.org/mailman/listinfo/python-list
Re: pyserial doesn't recognize virtual serial port
Hi Grant,
It worked... I had the same suspicion and changed the port names to
COM2 and COM4 and it worked.
--NS
On Oct 12, 8:34 pm, Grant Edwards [EMAIL PROTECTED] wrote:
On 2007-10-12, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I am trying to use virtual serial ports to develop/test my serial
communication program. Running in to trouble...
I am using com0com to create the virtual ports. The virtual ports
seem to be working fine when I test it with Hyperterminal.
I'm not sure what you mean by virtual ports. I've used
pyserial with several different network attached devices that
provide drivers that make them appear as COMnn devices under
windows. I never had any problems.
I am using the example program that comes with pyserial, as below.
---
import serial
ser = serial.Serial('CNCA0') #open virtual serial port
print ser.portstr#check which port was realy used
ser.write(Hello) #write a string
ser.close() #close port
-
The following is the error message:
--
Traceback (most recent call last):
File C:\Python25\Naveen Files\TestSerial, line 2, in module
ser = serial.Serial('CNCA0') #open first serial port
File c:\Python25\Lib\site-packages\serial\serialutil.py, line 156,
in __init__
self.open()
File c:\Python25\Lib\site-packages\serial\serialwin32.py, line 55,
in open
raise SerialException(could not open port: %s % msg)
SerialException: could not open port: (2, 'CreateFile', 'The system
cannot find the file specified.')
--
If you specify a filename that the OS doesn't recognize there's
nothing pyserial can do about it.
When I try with 'COM3', which comes inbuilt in my laptop, COM3 is
recognized. Few other posts on the web seem to indicate pyserial
should work fine with virtual serial ports. What am I missing?
My guess is you're not spelling the device name correctly.
Device names under Windows are even more screwed up than the
rest of the OS. By default there are a limited set of devices
with specially mapped DOS compatible names such as LPT1,
COM3, etc. My guess is that the device you're attempting to
use doesn't have a name that's mapped to the DOS-compatible
namespace as CNCA0.
You could try using the name \\.\CNCA0
Or you could try to figure otu how to map the device into the
DOS namespace as CNCA0.
You could also try running some sort of system call trace on
HyperTerminal to find out what name it's using to open the
device when you tell it to use port CNCA0.
Or you could just give up and switch to Linux. [That's what
I'd recommend, personally.]
--
Grant Edwards grante Yow! YOU PICKED KARL
at MALDEN'S NOSE!!
visi.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Memory Problems in Windows 2003 Server
Hi Brad, I do the reading one line at a time, the problem seems to be with the dictionary I am creating. Andre amdescombes wrote: Hi, I am using Python 2.5.1 I have an application that reads a file and generates a key in a dictionary for each line it reads. I have managed to read a 1GB file and generate more than 8 million keys on an Windows XP machine with only 1GB of memory and all works as expected. When I use the same program on a Windows 2003 Server with 2GB of RAM I start getting MemoryError exceptions! I have tried setting the IMAGE_FILE_LARGE_ADDRESS_AWARE on both Python.exe and Python25.dll and setting the /3GB flag on the boot.ini file to no avail. I still get the MemoryError exceptions. Has anybody encountered this problem before? Thanks in advance for any ideas/suggestions. Best Regards, André M. Descombes I forgot to mention that the OS itself or other processes may be using a lot of memory. So, just because you have 2GB, that does not mean you can access all of that at once. I would guess that 25% of memory is in constant use by the OS. So, do your IO/reads in smaller chunks similar to the example I gave earlier. Brad -- http://mail.python.org/mailman/listinfo/python-list
Re: Observer implementation question ('Patterns in Python')
Thank you, James and Stargaming, for your replies! -- http://mail.python.org/mailman/listinfo/python-list
Re: Last iteration?
On Oct 12, 12:58 pm, Florian Lindner [EMAIL PROTECTED] wrote: Hello, can I determine somehow if the iteration on a list of values is the last iteration? Example: for i in [1, 2, 3]: if last_iteration: print i*i else: print i that would print 1 2 9 Can this be acomplished somehow? Thanks, Florian If you want to do this over a list or a string, I'd just do: for element in iterable[:-1]: print iterable print iterable[-1] * iterable[-1] No need for it to get more advanced than that :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python module for making Quicktime or mpeg movies from images
- The Mac version of Python includes wrappers for a number of Carbon APIs, including QuickTime. One for brave souls only; QT's C APIs are notoriously complex, AMEN. I tried to work with that stuff, and it was close to a totally failure desaster... Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Foreign Character Problems In Python 2.5 and Tkinter
Juha S. kirjoitti:
problem is that when I try to save its contents to a .txt file, any
Scandinavian letters such as äöå ÄÖÅ are saved incorrectly and show up
as a mess when I open the .txt file in Windows Notepad.
It seems that the characters will only get mixed if the user has typed
them into the widget, but if the program has outputted them, they are
saved correctly.
Did you define the encoding for the source file and
put u (for unicode) in front of your strings. The
following piece produces proper UTF-8. Couldn't test with
Notepad though, no Windows here.
Note this message is also encoded in UTF-8, so should be
your editor. I can't believe we are still messing with this
stuff in 2007. In old bad days it was easy, you should
only learn to read { as ä, | as ö etc... and vice versa
with localized terminals -- C code looked rather exotic
with a-umlauts everywhere ;)
#!/usr/bin/python
# -*- coding: utf-8 -*-
from Tkinter import *
import codecs
class Application(Frame):
def save(self):
FILE = codecs.open(outfile.txt, w, utf-8)
FILE.write(uSTART - åäöÅÄÖ\n)
FILE.write(self.text_field.get(0.0, END))
FILE.write(uEND - åäöÅÄÖ\n)
FILE.close()
self.quit()
def __init__(self, master=None):
Frame.__init__(self, master)
self.grid()
self.text_field = Text(self, width=40, height=10)
self.text_field.grid()
self.save_button = Button(self, text=save and exit, command=self.save)
self.save_button.grid()
if __name__ == __main__:
app = Application()
app.mainloop()
--
http://mail.python.org/mailman/listinfo/python-list
how to create a pointer, or is there a better solution ?
hello, I've a program where users can make modules, by just dumping them in a certain directory, then they will dynamically link into the program if needed. One of the communication channels I use, is a general global file, which should be imported by all user modules. One of the things a user should be able to do is to create global variables, which should then be available in all the other program modules. So the global file contains a list, call JAL_Globals = [], where each user can append the globals he want to be exposed to the outside world (for read only). Now if these globals are complex items, no problem, I get pointers and can access them. But if these variables are simple, like integers, I get the value only once ;-) How can I create of dynamic pointers, even to simple variables ? Or is there a better way ? thanks, Stef Mientki -- http://mail.python.org/mailman/listinfo/python-list
Re: Foreign Character Problems In Python 2.5 and Tkinter
Thanks for the reply. I made changes to my code according to your
example. Now any Scandinavian characters that are outputted by the
program are missing in the Tk text box.
I'm using a loading function like this to load the data that is to be
outputted by the program:
def loadWords(self, filename):
ret = []
try:
file = codecs.open(filename, 'r', 'utf-8', 'ignore')
for line in file:
if line.isspace() == False: #Must skip blank lines (read
only lines that contain text).
line = line.replace(u'\n', u'')
ret.append(line)
except IOError:
tkMessageBox.showwarning(u'Open File', u'An error occurred
wile trying to load \' + filename + u'\', parent=self.frame)
finally:
file.close()
return ret
Also, the newlines are still lost when saving the text widget contents
to a file. I'm inserting the program generated text to the text widget
through text.insert(END, txt + u'\n\n').
Janne Tuukkanen wrote:
Juha S. kirjoitti:
problem is that when I try to save its contents to a .txt file, any
Scandinavian letters such as äöå ÄÖÅ are saved incorrectly and show up
as a mess when I open the .txt file in Windows Notepad.
It seems that the characters will only get mixed if the user has typed
them into the widget, but if the program has outputted them, they are
saved correctly.
Did you define the encoding for the source file and
put u (for unicode) in front of your strings. The
following piece produces proper UTF-8. Couldn't test with
Notepad though, no Windows here.
Note this message is also encoded in UTF-8, so should be
your editor. I can't believe we are still messing with this
stuff in 2007. In old bad days it was easy, you should
only learn to read { as ä, | as ö etc... and vice versa
with localized terminals -- C code looked rather exotic
with a-umlauts everywhere ;)
#!/usr/bin/python
# -*- coding: utf-8 -*-
from Tkinter import *
import codecs
class Application(Frame):
def save(self):
FILE = codecs.open(outfile.txt, w, utf-8)
FILE.write(uSTART - åäöÅÄÖ\n)
FILE.write(self.text_field.get(0.0, END))
FILE.write(uEND - åäöÅÄÖ\n)
FILE.close()
self.quit()
def __init__(self, master=None):
Frame.__init__(self, master)
self.grid()
self.text_field = Text(self, width=40, height=10)
self.text_field.grid()
self.save_button = Button(self, text=save and exit,
command=self.save)
self.save_button.grid()
if __name__ == __main__:
app = Application()
app.mainloop()
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to create a pointer, or is there a better solution ?
stef mientki schrieb: hello, I've a program where users can make modules, by just dumping them in a certain directory, then they will dynamically link into the program if needed. One of the communication channels I use, is a general global file, which should be imported by all user modules. One of the things a user should be able to do is to create global variables, which should then be available in all the other program modules. So the global file contains a list, call JAL_Globals = [], where each user can append the globals he want to be exposed to the outside world (for read only). Now if these globals are complex items, no problem, I get pointers and can access them. But if these variables are simple, like integers, I get the value only once ;-) How can I create of dynamic pointers, even to simple variables ? Or is there a better way ? Don't use a list, use a dictionary that has names mapped to values. Then the problem goes away, because instead of mutating an object (which you still can do), you can also rebind a new one -e.g like this: JAL_Globals['name'] += 100 Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
David Tremouilles wrote: No issue with pygtk on mac! Actually I develop on this platform everyday. Macport take care of the installation for me http://www.macports.org/ (Fink should do the work too). Of course native GTK on OSX could be nice but definitely not needed at this point in time. Native Gtk on the Mac still isn't really native. I tried a native build of Wireshark and was very disappointed. Yes, it uses Quartz/Aqua instead of X to draw Windows, but it completely ignores other Aqua interface conventions--the menu is still attached to each window instead of at the top of the screen, buttons aren't Aqua buttons, and so on. Based on what I've seen, I don't think Gtk is really viable as a native Mac development environment; it looks as weird as Fltk, which also uses Aqua windowing but which also draws its own widgets and puts the menubar on each window. Tk does much better; while it's not very pretty, menubars are in the correct place and buttons work correctly. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Foreign Character Problems In Python 2.5 and Tkinter
Sat, 13 Oct 2007 16:13:21 +0300, Juha S. kirjoitti: Thanks for the reply. I made changes to my code according to your example. Now any Scandinavian characters that are outputted by the program are missing in the Tk text box. file = codecs.open(filename, 'r', 'utf-8', 'ignore') Remove that 'ignore'. If you then get error which complains, that utf-8 codec can't handle the file, you've found the culprit. The file might be in iso-8859-1. JanneT -- http://mail.python.org/mailman/listinfo/python-list
Re: ConnectionClosedError
On Oct 13, 4:21 am, Hendrik van Rooyen [EMAIL PROTECTED] wrote: If restarting the server sorts it, why don't you run the server as a subprocess in a higher level script, and exit with an error code if the error strikes? Well as I mentioned the process doesn't exit, it is just unresponsive from the client's side, so this doesn't solve it. It may be that the reason for your hang up is also a threading issue - it could be that the server is alive but that some critical thread has been killed by the error. But here I am guessing... I don't create explicitly any thread in my server code but Pyro itself is multithreaded. Unfortunately I don't have the resources to start digging in Pyro's internals.. George -- http://mail.python.org/mailman/listinfo/python-list
a good website for softwares,sports,movies and music ,sex etc.
www.space666.com go and look!!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Error on base64.b64decode() ?!
On 12 Okt., 17:09, Jean-Paul Calderone [EMAIL PROTECTED] wrote: If you get an incorrect padding error, try appending a = and decoding again. If you get the error again, try appending one more =. If it still doesn't work, then you might be out of luck. This seems to work in some cases, but not all. Whats the deal with this adding of =? Is there an implementation error in python, or are other implemenations of base64 more robust then they have to be? Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Foreign Character Problems In Python 2.5 and Tkinter
Thanks! Opening and saving the file with the iso-8859-1 codec seems to handle the characters correctly. Now the only problem left are the missing newlines in the output file. I tried googling for the iso code for newline and entering it in a Python string as '\x0A' but it doesn't work in the output file which still loses the newlines. Janne Tuukkanen wrote: Sat, 13 Oct 2007 16:13:21 +0300, Juha S. kirjoitti: Thanks for the reply. I made changes to my code according to your example. Now any Scandinavian characters that are outputted by the program are missing in the Tk text box. file = codecs.open(filename, 'r', 'utf-8', 'ignore') Remove that 'ignore'. If you then get error which complains, that utf-8 codec can't handle the file, you've found the culprit. The file might be in iso-8859-1. JanneT -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Hi Daniel, in many respects Gluon is similar to Django and was greatly inspired by Django. Some differences are: Gluon is easier to install - you never need to use the shell, there are no configuration files. Gluon is a web app. You can do all development via a web interface. You can compile Gluon apps and distribute them in byte-code compiled form. Each Gluon app comes with a ticketing system. If an error occurrs it is logged and a ticket is issed. you can then search and retrieve errors by date or client-ip. Making forms is easier than in Django. For example given a db table called db.table you can do: form=SQLForm(db.table) if form.accepts(request.vars,session): pass these two lines will do everything, including generating the form from the table, validating input, inserting in database or modifying the form with error messages. This also prevents multiple submission of the same form because each form has a unique one-time key. The template language is pure python but without indentation requirements. Django has restrictions on what can go in templates. The output in the views is escaped by default. In Django it is not. You can manage internationalization (add language and write translations) from the web interface. Each app has an automatically generated database administrative interface. The Django one is cooler then Gluon's, but the Gluon one allows complicated joins in the filter field. Gluon supports migrations: you just change the definition of a table and it ALTERs the table accordingly (drop works in postgres only). For example if you change a field from boolean to string, the database is altered and the values are converted from boolean to string for existing records. Gluon has a sql.log console to see what changes are made to the database. In Gluon you do not need to import modules. The gluon modules you need already imported for you. Gluon has a top-down design. This means that the Gluon APIs are not under development. They are 100% stable. There may be bugs and they will be fixed but the syntax and signature of functions is not subject to change. This is why I started making Gluon, I am teaching a class on web frameworks and the API of Django and TG are not as stable as I wish they were. Moreover they have a too steep learning curve when compared to Gluon. Please try it, it is no that time consuming, and send me you comments (good or bad)! Massimo On Oct 13, 2007, at 5:01 AM, Daniel Fetchinson wrote: Hello everybody, I just joined this mailing list. Thanks for your comments about gluon. I have posted a short video about it and I am planning to make more over the week-end. http://www.youtube.com/watch?v=VBjja6N6IYk About some of your comments: - the most complex modules (like html and sql ones) have doctests. - the executable versions (win and mac) come with python2.5. Running from source code does not require 2.5 but you probably want sqlite3. - so far I support sqlite3 and postgresql, not mysql (just because I do not use it and had no time for testing it). - yes, there are typos in the documentation. Please point them out to me so that I can fix them. - I am sure there are some minor bugs I am not aware of but as far I tested, it work. - If you report bugs to me I promise to fix them in 48hrs. - please make sure you have the latest version. I very much appreciate comments about gluon (good and bad). Please send me more so that I can improve it. There will be two talks in chicago about gluon next week: at DePaul Linux Users Group on Thursday evening and at the Chicago Linux Users Group on Saturday afternoon. I will try record them and post them. Massimo P.S. Michele Simionato. I have heard your name before? Is it possible we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist and there is not many of us. Hi Massimo, In what way is gluon different from existing frameworks most notably django and turbogears? What do you think are the advantages to using gluon over these two? Cheers, Daniel -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
... I almost forgot ... another difference between Gluon and Django,TG is that in Gluon if you write controllers without view you automatically get generic view that render and BEAUTIFY() the variables returned by the controllers. That means you can develop the logic of your application without writing one line of HTML and you have a working prototype. Massimo On Oct 13, 2007, at 10:44 AM, DiPierro, Massimo wrote: Hi Daniel, in many respects Gluon is similar to Django and was greatly inspired by Django. Some differences are: Gluon is easier to install - you never need to use the shell, there are no configuration files. Gluon is a web app. You can do all development via a web interface. You can compile Gluon apps and distribute them in byte-code compiled form. Each Gluon app comes with a ticketing system. If an error occurrs it is logged and a ticket is issed. you can then search and retrieve errors by date or client-ip. Making forms is easier than in Django. For example given a db table called db.table you can do: form=SQLForm(db.table) if form.accepts(request.vars,session): pass these two lines will do everything, including generating the form from the table, validating input, inserting in database or modifying the form with error messages. This also prevents multiple submission of the same form because each form has a unique one-time key. The template language is pure python but without indentation requirements. Django has restrictions on what can go in templates. The output in the views is escaped by default. In Django it is not. You can manage internationalization (add language and write translations) from the web interface. Each app has an automatically generated database administrative interface. The Django one is cooler then Gluon's, but the Gluon one allows complicated joins in the filter field. Gluon supports migrations: you just change the definition of a table and it ALTERs the table accordingly (drop works in postgres only). For example if you change a field from boolean to string, the database is altered and the values are converted from boolean to string for existing records. Gluon has a sql.log console to see what changes are made to the database. In Gluon you do not need to import modules. The gluon modules you need already imported for you. Gluon has a top-down design. This means that the Gluon APIs are not under development. They are 100% stable. There may be bugs and they will be fixed but the syntax and signature of functions is not subject to change. This is why I started making Gluon, I am teaching a class on web frameworks and the API of Django and TG are not as stable as I wish they were. Moreover they have a too steep learning curve when compared to Gluon. Please try it, it is no that time consuming, and send me you comments (good or bad)! Massimo On Oct 13, 2007, at 5:01 AM, Daniel Fetchinson wrote: Hello everybody, I just joined this mailing list. Thanks for your comments about gluon. I have posted a short video about it and I am planning to make more over the week-end. http://www.youtube.com/watch?v=VBjja6N6IYk About some of your comments: - the most complex modules (like html and sql ones) have doctests. - the executable versions (win and mac) come with python2.5. Running from source code does not require 2.5 but you probably want sqlite3. - so far I support sqlite3 and postgresql, not mysql (just because I do not use it and had no time for testing it). - yes, there are typos in the documentation. Please point them out to me so that I can fix them. - I am sure there are some minor bugs I am not aware of but as far I tested, it work. - If you report bugs to me I promise to fix them in 48hrs. - please make sure you have the latest version. I very much appreciate comments about gluon (good and bad). Please send me more so that I can improve it. There will be two talks in chicago about gluon next week: at DePaul Linux Users Group on Thursday evening and at the Chicago Linux Users Group on Saturday afternoon. I will try record them and post them. Massimo P.S. Michele Simionato. I have heard your name before? Is it possible we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist and there is not many of us. Hi Massimo, In what way is gluon different from existing frameworks most notably django and turbogears? What do you think are the advantages to using gluon over these two? Cheers, Daniel -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
email libraries and threads
Hi, I am writing a threaded application, part of which relies on sending messages to users. However I cannot get the smtplib and some other email related libraries to work inside threads (they work ok when not in threads). Is there a problem with using threads and email? If so is there a solution available or any tips which people can give me? Best, rod -- http://mail.python.org/mailman/listinfo/python-list
Re: email libraries and threads
rodmc schrieb: Hi, I am writing a threaded application, part of which relies on sending messages to users. However I cannot get the smtplib and some other email related libraries to work inside threads (they work ok when not in threads). Is there a problem with using threads and email? If so is there a solution available or any tips which people can give me? I doubt that there are problems using the modules from within threads - at least as long as you don't share connecitons and the like between threads. So - until you show us some of your troubles by providing actual code examples and error messages, nobody will be able to help you. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-platform GUI development
David Tremouilles schrieb: No issue with pygtk on mac! Actually I develop on this platform everyday. Macport take care of the installation for me http://www.macports.org/ (Fink should do the work too). Of course native GTK on OSX could be nice but definitely not needed at this point in time. It sure looks crappy in comparison to the rest of the OSX apps - and given that with Qt (and of course the brilliant PyObjc-bridge) there exist options that look feel waaay better, I wouldn't consider using GTK. -- http://mail.python.org/mailman/listinfo/python-list
Trial of Star-P for Python
In browsing their website, I noticed that Interactive Supercomputing has made available a free evaluation copy of Star-P for Python (http:// www.interactivesupercomputing.com/products/starpandpython.php). I know its a fairly new product, but has anyone on here been able to try it out yet, and if so what are your impressions? I am curious to see what people think about this product and other numerical, parallel computing Python packages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
... I almost forgot ... another difference between Gluon and Django,TG is that in Gluon if you write controllers without view you automatically get generic view that render and BEAUTIFY() the variables returned by the controllers. That means you can develop the logic of your application without writing one line of HTML and you have a working prototype. Massimo Hi Daniel, in many respects Gluon is similar to Django and was greatly inspired by Django. Some differences are: Gluon is easier to install - you never need to use the shell, there are no configuration files. Gluon is a web app. You can do all development via a web interface. You can compile Gluon apps and distribute them in byte-code compiled form. Each Gluon app comes with a ticketing system. If an error occurrs it is logged and a ticket is issed. you can then search and retrieve errors by date or client-ip. Making forms is easier than in Django. For example given a db table called db.table you can do: form=SQLForm(db.table) if form.accepts(request.vars,session): pass these two lines will do everything, including generating the form from the table, validating input, inserting in database or modifying the form with error messages. This also prevents multiple submission of the same form because each form has a unique one-time key. The template language is pure python but without indentation requirements. Django has restrictions on what can go in templates. The output in the views is escaped by default. In Django it is not. You can manage internationalization (add language and write translations) from the web interface. Each app has an automatically generated database administrative interface. The Django one is cooler then Gluon's, but the Gluon one allows complicated joins in the filter field. Gluon supports migrations: you just change the definition of a table and it ALTERs the table accordingly (drop works in postgres only). For example if you change a field from boolean to string, the database is altered and the values are converted from boolean to string for existing records. Gluon has a sql.log console to see what changes are made to the database. In Gluon you do not need to import modules. The gluon modules you need already imported for you. Gluon has a top-down design. This means that the Gluon APIs are not under development. They are 100% stable. There may be bugs and they will be fixed but the syntax and signature of functions is not subject to change. This is why I started making Gluon, I am teaching a class on web frameworks and the API of Django and TG are not as stable as I wish they were. Moreover they have a too steep learning curve when compared to Gluon. Please try it, it is no that time consuming, and send me you comments (good or bad)! Massimo Hello everybody, I just joined this mailing list. Thanks for your comments about gluon. I have posted a short video about it and I am planning to make more over the week-end. http://www.youtube.com/watch?v=VBjja6N6IYk About some of your comments: - the most complex modules (like html and sql ones) have doctests. - the executable versions (win and mac) come with python2.5. Running from source code does not require 2.5 but you probably want sqlite3. - so far I support sqlite3 and postgresql, not mysql (just because I do not use it and had no time for testing it). - yes, there are typos in the documentation. Please point them out to me so that I can fix them. - I am sure there are some minor bugs I am not aware of but as far I tested, it work. - If you report bugs to me I promise to fix them in 48hrs. - please make sure you have the latest version. I very much appreciate comments about gluon (good and bad). Please send me more so that I can improve it. There will be two talks in chicago about gluon next week: at DePaul Linux Users Group on Thursday evening and at the Chicago Linux Users Group on Saturday afternoon. I will try record them and post them. Massimo P.S. Michele Simionato. I have heard your name before? Is it possible we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist and there is not many of us. Hi Massimo, In what way is gluon different from existing frameworks most notably django and turbogears? What do you think are the advantages to using gluon over these two? Cheers, Daniel Massimo, thanks a lot for the reply, I'll give gluon a try. I've just started to use TG about 3 months ago and although I like it it would be fun to have a real comparison (I didn't like django at all after a couple of hours of playing with it). -- http://mail.python.org/mailman/listinfo/python-list
Re: Declarative properties
Dan Stromberg schrieb: On Thu, 11 Oct 2007 18:42:16 +, Marc 'BlackJack' Rintsch wrote: The baggage of possibly fixing (AKA generalizing) how your attributes are accessed is something you lug around while your deadline looms. Sorry I don't get it. If I want to customize the access to a normal attribute I simply turn it into a property. You're right, properties are an intersting language feature. I wasn't aware of them until today. I'm not sure I believe they are better than disallowing public attributes and requiring setters and getters, but they do appear to address the same issue: the needless change in API when your internal representation needs to change. This belief is most probably nurtured by Java. Or am I wrong here? Matter of factly, the whole getter/setter-mamboo-jamboo is nothing but a pathetic attempt to overcome the lack of attribute-access-hooks, as they are e.g. provided by python or C#. By forcing this convention upon the programmer (and supporting it using e.g. BeanInfo and other introspection-based mechanisms), Java allows for the implementation of delegation, lazyness and so forth without all that forcing major interface changes upon the user. Talking of interfaces - they do lack properties as well... so you _can't_ possibly provide an interface with attributes. But I really don't think one can argue over a more aesthetic expressive syntax like a.foo = b.bar * c.baz compared to a.setFoo(b.getBar() * c.getBaz()) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: test if email
Martin Marcher wrote: No need to speek of plus addressing or older messaging systems. But don't disallow a plus in the localpart. Many do. Regards, Björn -- BOFH excuse #180: ether leak -- http://mail.python.org/mailman/listinfo/python-list
Re: Foreign Character Problems In Python 2.5 and Tkinter
On Oct 13, 5:22 pm, Juha S. [EMAIL PROTECTED] wrote: Thanks! Opening and saving the file with the iso-8859-1 codec seems to handle the characters correctly. Now the only problem left are the missing newlines in the output file. I tried googling for the iso code for newline and entering it in a Python string as '\x0A' but it doesn't work in the output file which still loses the newlines. Janne Tuukkanen wrote: Sat, 13 Oct 2007 16:13:21 +0300, Juha S. kirjoitti: Thanks for the reply. I made changes to my code according to your example. Now any Scandinavian characters that are outputted by the program are missing in the Tk text box. file = codecs.open(filename, 'r', 'utf-8', 'ignore') Remove that 'ignore'. If you then get error which complains, that utf-8 codec can't handle the file, you've found the culprit. The file might be in iso-8859-1. JanneT As a noob I've struggled a bit, but basically what I've come up with is = if the information is strings and especially strings stored in any style of list/dict, it takes a loop to write the lines to file myfile[ i ] + '\n' to keep each line for Python I/O purposes. If you're done with Python manipulation and want WIN, MAC, or UNIX to begin file I/O, then, you need the consideration of newline-char from the os module, or code it in yourself, e.g. '\r\n'. The fact you are using codec iso-latin-1 (or iso-8859-1) doesn't change the '\n' from Python's viewpoint -- that is: '\n' is still '\n'. When your efforts are I/O with binary encoding the data, it's all Python's viewpoint. -- http://mail.python.org/mailman/listinfo/python-list
Re: raw_input() and utf-8 formatted chars
On Oct 13, 3:09 am, 7stud [EMAIL PROTECTED] wrote:
On Oct 12, 2:43 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
You mean literally!? Then of course I get A\xcc\x88 because that's what I
entered. In string literals in source code the backslash has a special
meaning but `raw_input()` does not interpret the input in any way.
Then why don't I end up with the same situation as this:
s = 'A\xcc\x88' #capital A with umlaut
print s #displays capital A with umlaut
And what is it that your keyboard enters to produce an 'a' with an umlaut?
*I* just hit the ä key. The one right next to the ö key. ;-)
...and what if you don't have an a-with-umlaut key?
raw_input() returns the string exactly as you entered it. You can
decode that into the actual UTF-8 string with decode(string_escape):
s = raw_input('Enter: ') #A\xcc\x88
s = s.decode(string_escape)
It looks like your system already understands UTF-8 and will decode
the UTF-8 string you print to the Unicode character.
--
http://mail.python.org/mailman/listinfo/python-list
Re: urllib.ProxyHandler HTTPS issues
Devraj [EMAIL PROTECTED] writes: Thanks John. Will investigate sending the CONNECT command to handle proxies. Do you recommend doing this for HTTP proxies as well No. or should I just use the ProxyHandler for HTTP proxies? Yes. John -- http://mail.python.org/mailman/listinfo/python-list
Re: how to get the NT event log properties with OnObjectReady() with python
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
I'm trying to get a notification from the NT event for any new event
using the DispatchWithEvents() function. Everything seems to be
working the way I wanted, but I don't know how to get the properties
of the event (ie. event type, message, etc.) from the OnObjectReady()
callback.
class SinkClass(object):
def OnObjectReady(self, *args): #self may be the wmi_sink object
print OnObjectReady callback ...
print self #.TargetInstance.Message
print args[0]
def OnCompleted(self, *args):
print OnCompleted callback...
print args #.TargetInstance.Message
def OnObjectPut(self, *args):
print OnObjectPut callback...
def OnProgress(self, *args):
print OnProgress callback...
wmi = win32com.client.GetObject(winmgmts:
{impersonationLevel=impersonate,(security)}!//./root/cimv2)
wmi_sink =
win32com.client.DispatchWithEvents(WbemScripting.SWbemSink,SinkClass)
wmi.ExecNotificationQueryAsync(wmi_sink,SELECT * FROM
__InstanceCreationEvent where TargetInstance ISA 'Win32_NTLogEvent')
The argument args in the OnObjectReady() seems to be the interface to
a com object (may be the event object itself).
I want to read the properties (ie. message, eventID, type, etc) of
the triggered NT event.
Please help.
The first arg is passed as a raw IDispatch interface. You can wrap it
as below to access the properties.
def OnObjectReady(self, *args): #self may be the wmi_sink object
print OnObjectReady callback ...
print self #.TargetInstance.Message
wbem_object=win32com.client.gencache.EnsureDispatch(args[0],0)
print wbem_object
ti=wbem_object.Properties_('TargetInstance').Value
print 'TargetInstance',ti
for p in ti.Properties_:
print p.Name, p.Value
Roger
== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet
News==
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
= East and West-Coast Server Farms - Total Privacy via Encryption =
--
http://mail.python.org/mailman/listinfo/python-list
Re: Declarative properties
Stargaming a écrit : On Thu, 11 Oct 2007 18:58:44 +0200, Bruno Desthuilliers wrote: [snip] Your implementation seems particularly broken. You do not return anything from `name()`, Oops, my bad ! Indeed, I forgot the 'return property(**locals())' at the end. And a couple other things too: I'm going to point out a few other mistakes first: (snip other corrections) I'll call you when I'll have code to fix - you're doing a good job !-) -- http://mail.python.org/mailman/listinfo/python-list
unicodedata implementation - categories
Hi, I'm trying to understand how CPython implements unicodedata, with a view to providing an implementation for Jython. This is a background, low priority thing for me, since I last posted to this list about it in February! Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type help, copyright, credits or license for more information. import unicodedata c = unichr(0x10) unicodedata.name(c) Traceback (most recent call last): File stdin, line 1, in module ValueError: no such name unicodedata.category(unichr(0x10)) 'Cn' 0x10 is not a valid codepoint in Unicode 4.1, which is the version of the Unicode standard that Python 2.5 supports. So I have a couple of questions: 1) Why doesn't the category method raise an Exception, like the name method does? 2) Given that the category method doesn't currently raise an Exception, please could someone explain how the category is calculated? I have tried to figure it out based on the CPython code, but I have thus far failed, and I would also prefer to have it explicitly defined, rather than mandating that a Jython (.NET, etc) implementation uses the same (possibly non-optimal for Java) data structures and algorithms. My background is Mathematics rather than pure Computer Science, so doubtless I still have some gaps in my education to be filled when it comes to data structures and algorithms and I would welcome the opportunity to fill some of those in. References to Knuth or some on-line reading would be much appreciated, to help me understand the CPython part. Cheers, James -- View this message in context: http://www.nabble.com/unicodedata-implementation---categories-tf4619497.html#a13193027 Sent from the Python - python-list mailing list archive at Nabble.com. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem of Readability of Python
Delaney, Timothy (Tim) wrote: Licheng Fang wrote: This is enlightening. Surely I shouldn't have worried too much about performance before doing some measurement. And with that statement you have truly achieved enlightenment. Or to put it another way ... performance tuning without profiling is a waste of time. And the performance of a programmer both with and without excessive early performance tweaking has been measured time and again (we do that particular experiment _way_ too often). The early performance tweaking version loses almost every time. -Scott -- http://mail.python.org/mailman/listinfo/python-list
Re: tarfile...bug?
[EMAIL PROTECTED] wrote: On Oct 9, 10:33 pm, Anurag [EMAIL PROTECTED] wrote: Have any one faced such problem, I assume it must be common if it can be replicated so easily , or something wrong with my system Also if I use tar.members instead of tar.getmembers() it works so what is the diff. between tar.members and tar.getmembers() if you are not fully dependant on tarfiles, have a look at the zipfile library in Python. Everytime I start to use the tarfile .lib, the zip .lib turns out to be a better solution. And here's why: The tar-gzip format (sometimes .tar.gz, sometimes .tgz) is defined by taking a fully expanded archive (tar archives), and compressing them _as_a_whole_ with the gzip compression. It is not possible to see the last bytes of the .tgz file without uncompressing _all_ of the file. The zip format compresses the contained files individually, and keeps a separate directory. So it can expand only the file you want whether it is at the beginning or the end of the zip file. This is also (one of) the reason(s) the .zip format gets less compression than the .tgz format. Each file in the zip is separately compressed, so redundancy between files is not compressed out. -Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Question - FM receiver sample - AtttributeError
Hi all, I got some problems while running the FM receiver's example codes from the GNURadio tutorial page; the RF front end is set to call the signal input from daughter board, and when the compiler tried to call mothods to set some parameter values(such as gain, set_AGC() and If frequency, get_output_freq() ), it seems not able to find those methods/ functions... Could someone be kind enough to give some pointers for solving such errors? Traceback (most recent call last): File ./nuradio.py, line 91, in __init__ IF_freq = rf_front_end.get_output_freq () # 5.75e6 File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 181, in __getattr__ return getattr(self._u, name) AttributeError: 'usrp1_source_c_sptr' object has no attribute 'get_output_freq' ps. link for the full script is as below: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html#fm-receiver Thanks, eric -- View this message in context: http://www.nabble.com/Question---FM-receiver-sample---AtttributeError-tf4619680.html#a13193588 Sent from the Python - python-list mailing list archive at Nabble.com. -- http://mail.python.org/mailman/listinfo/python-list
Re: unicodedata implementation - categories
On Oct 13, 4:32 pm, James Abley [EMAIL PROTECTED] wrote: Hi, I'm trying to understand how CPython implements unicodedata, with a view to providing an implementation for Jython. This is a background, low priority thing for me, since I last posted to this list about it in February! Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type help, copyright, credits or license for more information. import unicodedata c = unichr(0x10) unicodedata.name(c) Traceback (most recent call last): File stdin, line 1, in module ValueError: no such name unicodedata.category(unichr(0x10)) 'Cn' 0x10 is not a valid codepoint in Unicode 4.1, which is the version of the Unicode standard that Python 2.5 supports. So I have a couple of questions: 1) Why doesn't the category method raise an Exception, like the name method does? 2) Given that the category method doesn't currently raise an Exception, please could someone explain how the category is calculated? I have tried to figure it out based on the CPython code, but I have thus far failed, and I would also prefer to have it explicitly defined, rather than mandating that a Jython (.NET, etc) implementation uses the same (possibly non-optimal for Java) data structures and algorithms. My background is Mathematics rather than pure Computer Science, so doubtless I still have some gaps in my education to be filled when it comes to data structures and algorithms and I would welcome the opportunity to fill some of those in. References to Knuth or some on-line reading would be much appreciated, to help me understand the CPython part. Cheers, James -- View this message in context:http://www.nabble.com/unicodedata-implementation---categories-tf46194... Sent from the Python - python-list mailing list archive at Nabble.com. Cn is the Other, Not Assigned category in Unicode. No characters in Unicode have this property. I'm not sure why it doesn't raise an Exception, but if category() returns Cn, then you know it's not a valid character. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python in HTML Application (HTA)
Hi! I give a solution in the french newsgroup. Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: Declarative properties
Dan Stromberg a écrit : On Fri, 12 Oct 2007 09:42:28 +0200, Bruno Desthuilliers wrote: So what? Otherwise you carry *always* the baggage of a public property and a private attribute whether you need this or not. At least for me it would be unnecessary in most cases. That baggage of carrying around unneeded methods is something the computer carries for you - IE, no big deal in 99.99% of all cases. 1/ Accessing the value of a property is not free. Accessing a plain attribute is much cheaper. Python's current performance characteristics have no bearing on what is good software engineering practice in general, Neither useless complexity nor tryig to apply inappropriate idioms are good practices. (snip) I'm not omniscient, and neither is anyone else; when one initially codes a class, one doesn't know to what purposes it will need to be bent in the future; using accessor methods instead of exposed attributes is significantly more flexible for the future of your class. Please remember that Python has support for computed attributes (you do know what's a computed attribute, don't you ?), so you can turn a plain attribute into a computed one at any time without breakink the API. IOW, you don't need getters/setter a priori. -- http://mail.python.org/mailman/listinfo/python-list
Re: Declarative properties
Dan Stromberg a écrit :
(snip)
My implementation may or may not be lacking (feel free to improve it - in
fact, please do!),
Since you ask for it:
def makeprop(name):
_name = '_' + name
def fget(self):
return getattr(self, _name, None)
def fset(self, val):
setattr(self, _name, val)
return property(fget, fset)
class AutoPropType(type):
def __init__(cls, clsname, bases, attribs):
for name in cls._autoprops:
if name not in attribs:
setattr(cls, name, makeprop(name))
class Demo(object):
__metaclass__ = AutoPropType
_autoprops = ('foo', 'bar', 'baaz')
def __init__(self, foo, bar=42, baaz='ni'):
self.foo = foo
self.bar = bar
self.baaz = baaz
d = Demo('yadda yadda')
but that's irrelevant to the heart of the matter, which
is what you didn't think to plan for now most definitely can hurt you
later.
Ahem... Please let me know, Mr Professor, what difference it would make,
from client code's POV, if we simply wrote this instead:
class Demo(object):
def __init__(self, foo, bar=42, baaz='ni'):
self.foo = foo
self.bar = bar
self.baaz = baaz
(snip more blah)
Little hackish tricks for performance's sake scattered throughout a
program are very wasteful of something more precious than CPU time.
Indeed. The point you're missing is that, in a language that supports
computed attributes, using plain attributes when that's all you need is
*not* a 'litlle hackish trick'. It's just common sense - and actually
saves on *both* programmer's and CPU time.
--
http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
Matthias Benkard [EMAIL PROTECTED] wrote: continuations. There used to be a project called Stackless Python that tried to add continuations to Python, but as far as I know, it has always been separate from the official Python interpreter. I don't know whether it's still alive. You may want to check http://stackless.com/ Alive and well, but it has removed continuations (which were indeed in early versions, as per the paper at http://www.stackless.com/spcpaper.htm). Alex -- http://mail.python.org/mailman/listinfo/python-list
Python on imac
I'm considering moving from Linux to imac. I've recently returned to Python (was never very expert) to develop a small gui application. At present I plan to use PyGTK with Pango and Cairo. What surprises may I be in for :-) (Currently using slackware 11.0 on an old (8 years) slow (400mhz) machine.) Thanks, John Velman -- http://mail.python.org/mailman/listinfo/python-list
Re: Saving parameters between Python applications?
os.getppid() isn't cross platform. I don't think it works on Windows. I think I'll just create a simple shell script (BAT or Bash) for each platform as needed. Thanks On Sep 20, 3:17 pm, David [EMAIL PROTECTED] wrote: On 9/16/07, Stodge [EMAIL PROTECTED] wrote: I'm trying to do the following. I have a Python application that is run: python app1.py --location=c:\test1 What I want to do is save the location parameter, so I can then do (in the same window): python app2.py And have app2.py automatically have access to the value of location. Now, the difficult part is, that in another window I want to do: python app1.py --location=c:\test2 python app2.py And have app2.py automatically get c:\test2 as the location. So the two windows (consoles) are isolated from each other. I thought I could use os.environ, but that doesn't save the variable for applications that are run afterwards in the same window. Use a value based on your current tty. I don't know how to get this value in Python but you could just shell 'tty' and grab the output. Or, to get your parent process's pid, use os.getppid(). Then, use a temporary file whose name is based on the above info. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 8:29 am, Michele Simionato [EMAIL PROTECTED] wrote: Do you (or something else) have something to say about Beaker? I looked at the source code and it seems fine to me, but I have not used it directly, not stressed it. I need a production-level WSGI session middleware and I wonder what the players are (for instance how Beaker does compare with flup?) Beaker is the only seriously maintained WSGI session at the moment -- flup isn't, AFAIK, very actively maintained or improved. paste.session is a particularly naive implementation of sessions. So as a result, Beaker is kind of the only game in town. Incidentally, it's not really related to SQLAlchemy; it came out of Myghty. Same author, of course, but fairly different domains. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 8:13 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Well... Last year, I had a look at Pylons, then played a bit with wsgi and building my own framework over it. I finally dropped that code and went back to Pylons, which I felt could become far better than my own efforts. Now since then I had way too much to do at work (using other technos) and didn't find the time to work on my own projects, so I still don't know how well Pylons will pass the real world test, but it seems to me that it's rapidly progressing and mostly in the right direction. I still wait for an opportunity to check this out !-) This would be my general suggestion too. It's fine to write your own, and not that hard, but you'll be missing out on the momentum and help from the community. You'll be maintaining your own code instead of having other people work on maintenance -- which actually isn't that much more work, except that you'll be doing it alone and without that collective experience at hand. That said, going without a framework (which at least in his article is what Michele seems to be comparing Pylons against) isn't always so bad. I started writing an Atompub server in Pylons, but felt like I was spending too much time navigating around what the framework setup and not enough time just paying attention to what Atompub really is. So I ended up writing it (as FlatAtomPub), effectively without a framework (though developing it at the same time as WebOb, so I leaned on that quite a bit). The development went quite well, and for a web service like Atompub that's probably what I'd recommend (at least to experienced developers -- you might find yourself left to drift otherwise without a clear idea of where to start). But for writing a traditional web application, I'd still use Pylons. The choices Pylons have made are with that in mind, and it doesn't at all exclude other forms of development in the process. You could actually drop a FlatAtomPub instance right into a Pylons app, for instance. Pylons is a small enough framework that it really is quite reasonable to pick and choose and use a very minimal style with it. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on imac
On Oct 13, 7:21 pm, John Velman [EMAIL PROTECTED] wrote: I'm considering moving from Linux to imac. I've recently returned to Python (was never very expert) to develop a small gui application. At present I plan to use PyGTK with Pango and Cairo. What surprises may I be in for :-) (Currently using slackware 11.0 on an old (8 years) slow (400mhz) machine.) Thanks, John Velman Well... I think OS X currently comes with Python 2.3 or 2.4. I recommend getting Fink (fink.sourceforge.net), which is basically a DPKG/APT repository for OS X plus an added system for automatically building packages from source. It'll keep the system up to date with the latest 2.5 release (and future versions). If you're using PyGTK, you will need to install Apple X11 (can't remember if it's installed by default yet), since OS X's window manager is not X11-based. Fink can also install GTK+, etc. for you. Other than that, most things should work as on Linux, more or less. -- http://mail.python.org/mailman/listinfo/python-list
[issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
New submission from jos : When I compile Python-3.0a1 on Mac OS X with Japanese locale, I've got LookupError like below. == running build_scripts creating build/scripts-3.0 Traceback (most recent call last): File ./setup.py, line 1572, in module main() File ./setup.py, line 1567, in main 'Lib/smtpd.py'] File /private/tmp/Python-3.0a1/Lib/distutils/core.py, line 148, in setup dist.run_commands() File /private/tmp/Python-3.0a1/Lib/distutils/dist.py, line 943, in run_commands self.run_command(cmd) File /private/tmp/Python-3.0a1/Lib/distutils/dist.py, line 963, in run_command cmd_obj.run() File /private/tmp/Python-3.0a1/Lib/distutils/command/build.py, line 106, in run self.run_command(cmd_name) File /private/tmp/Python-3.0a1/Lib/distutils/cmd.py, line 317, in run_command self.distribution.run_command(command) File /private/tmp/Python-3.0a1/Lib/distutils/dist.py, line 963, in run_command cmd_obj.run() File /private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py, line 51, in run self.copy_scripts() File /private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py, line 82, in copy_scripts first_line = f.readline() File /private/tmp/Python-3.0a1/Lib/io.py, line 1259, in readline decoder = self._decoder or self._get_decoder() File /private/tmp/Python-3.0a1/Lib/io.py, line , in _get_decoder make_decoder = codecs.getincrementaldecoder(self._encoding) File /private/tmp/Python-3.0a1/Lib/codecs.py, line 951, in getincrementaldecoder decoder = lookup(encoding).incrementaldecoder LookupError: unknown encoding: X-MAC-JAPANESE make: *** [sharedmods] Error 1 == This problem happens for lack of appropriate codec so also occurs in apps using getdefaultencoding. After patching Tools/unicode/Makefile and running make generates build/mac_japanese.py, mac-japanese codec. -- components: Build, Demos and Tools, Library (Lib), Macintosh, Unicode files: x_mac_japanese.diff messages: 56386 nosy: josm severity: normal status: open title: LookupError: unknown encoding: X-MAC-JAPANESE __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1276 __ x_mac_japanese.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
Bill Janssen added the comment: It's my mistake; I was looking at too many patches at the same time. Thanks for the example. Bill __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Changes by Guido van Rossum: -- assignee: - gvanrossum nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Guido van Rossum added the comment: Couple of nits: - You added a removal of hotshot from setup.py to the patch; but that's been checked in in the mean time. - Why add an 'errors' argument to the function when it's a fatal error to use it? - Using 0 to autodetect the length is scary. Normally we have two APIs for that, one ..._FromString and one ...FromStringAndSize. If you really don't want that, please use -1, which is at least an illegal value. - Why is there code in codeobject.c::PyCode_New() that still accepts a PyString for the filename? - In that file (and possibly others, I didn't check) your code uses spaces to indent while the surrounding code uses tabs. Moreover, your space indent seems to assume there are 4 spaces to a tab, but all our code (Python and C) is formatted assuming tabs are 8 spaces. (The indent isn't always 8 spaces -- but ASCII TAB characters always are 8, for us.) - Why copy the default encoding before mangling it? With a little extra care you will only have to copy it once. Also, consider not mangling at all, but assuming the encoding comes in a canonical form -- several other functions assume that, e.g. PyUnicode_Decode() and PyUnicode_AsEncodedString(). - I haven't run the unit tests yet. Will be doing that next... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Alexandre Vassalotti added the comment:
I found a few problems in your patch. In PyCode_New() the type check
for the filename argument is incorrect:
--- Objects/codeobject.c(revision 58412)
+++ Objects/codeobject.c(working copy)
@@ -59,7 +59,7 @@
freevars == NULL || !PyTuple_Check(freevars) ||
cellvars == NULL || !PyTuple_Check(cellvars) ||
name == NULL || (!PyString_Check(name) !PyUnicode_Check(name)) ||
- filename == NULL || !PyString_Check(filename) ||
+ filename == NULL || (!PyString_Check(name)
!PyUnicode_Check(name)) ||
lnotab == NULL || !PyString_Check(lnotab) ||
!PyObject_CheckReadBuffer(code)) {
PyErr_BadInternalCall();
@@ -260,6 +267,8 @@
ourcellvars = PyTuple_New(0);
if (ourcellvars == NULL)
goto cleanup;
+filename = PyUnicode_DecodeFSDefault(PyString_AS_STRING(filename),
+ 0, NULL);
The following is unnecessary and will cause a reference leak:
@@ -260,6 +267,8 @@
ourcellvars = PyTuple_New(0);
if (ourcellvars == NULL)
goto cleanup;
+filename = PyUnicode_DecodeFSDefault(PyString_AS_STRING(filename),
+ 0, NULL);
co = (PyObject *)PyCode_New(argcount, kwonlyargcount,
nlocals, stacksize, flags,
I think the interface of PyUnicode_DecodeFSDefault() could be improved
a bit. The function doesn't use the last argument 'errors', so why is
there? I am not sure if it is useful to keep second argument,
'length', either. So, I believe the function prototype should be
changed to:
PyObject *PyUnicode_Decode_FSDefault(const char *s);
Another thing that I am not sure about is whether it is correct to
consider ISO-8859-15 the same thing as Latin-1.
Overall, the patch looks good to me and doesn't cause any test to
fail. I attached an updated patch with the above issues fixed.
Thank you, Christian, for the patch. :)
--
nosy: +alexandre.vassalotti
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1272
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Changes by Alexandre Vassalotti: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Alexandre Vassalotti added the comment: Guido wrote: Why copy the default encoding before mangling it? With a little extra care you will only have to copy it once. Also, consider not mangling at all, but assuming the encoding comes in a canonical form -- several other functions assume that, e.g. PyUnicode_Decode() and PyUnicode_AsEncodedString(). It is impossible guarantee that Py_FileSystemDefaultEncoding is normalized, since its value can be set using nl_langinfo(CODESET) during the bootstrapping process. PyUnicode_Decode() and other decoding/encoding functions use the codec module, which is not available during the early bootstrapping process, to normalize the encoding name. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
Changes by Martin v. Löwis: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1276 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Christian Heimes added the comment: Guido van Rossum wrote: - You added a removal of hotshot from setup.py to the patch; but that's been checked in in the mean time. Oh, the change shouldn't make it into the patch. I guess I forgot a svn revert on setup.py - Why add an 'errors' argument to the function when it's a fatal error to use it? I wanted the signature of the method be equal to the other methods PyUnicode_Decode*. I copied the FatalError from *_PyUnicode_AsDefaultEncodedString(). - Using 0 to autodetect the length is scary. Normally we have two APIs for that, one ..._FromString and one ...FromStringAndSize. If you really don't want that, please use -1, which is at least an illegal value. Oh right, -1 is *much* better for autodetect than 0. What do you prefer, a second method or -1 as auto detect? - Why is there code in codeobject.c::PyCode_New() that still accepts a PyString for the filename? Because it's my fault that I've overseen it. :/ - In that file (and possibly others, I didn't check) your code uses spaces to indent while the surrounding code uses tabs. Moreover, your space indent seems to assume there are 4 spaces to a tab, but all our code (Python and C) is formatted assuming tabs are 8 spaces. (The indent isn't always 8 spaces -- but ASCII TAB characters always are 8, for us.) Some C files like unicodeobject.c are using 4 spaces while other files are using tabs for indention. My editor may got confused by the mix. I've manually fixed it in the patch but I may have overseen a line or two. - Why copy the default encoding before mangling it? With a little extra care you will only have to copy it once. Also, consider not mangling at all, but assuming the encoding comes in a canonical form -- several other functions assume that, e.g. PyUnicode_Decode() and PyUnicode_AsEncodedString(). My C is a bit rusty and still need to learn news tricks. I'm trying to see if I can remove the extra copy without causing a problem. The other part of your question was already answered by Alexandre. The aliases map is defined in Python code. It's not available so early in the boot strapping process. We'd have to redesign the assignment of co_filename and __file__ completely if we want to use the aliases and other codecs. For example we could store a PyString at first and redo all names once the codecs are set up. Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1260] PEP 3137: Remove the buffer API from PyUnicode
Alexandre Vassalotti added the comment:
There was a problem with one of the call of PyArg_ParseTuple in the OS/2
version of listdir() in the posix module. I also clarified the error
message of the 't' format unit.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1260
__Index: Python/getargs.c
===
--- Python/getargs.c (revision 58422)
+++ Python/getargs.c (working copy)
@@ -1250,7 +1250,7 @@
arg, msgbuf, bufsize);
if (pb == NULL || pb-bf_getbuffer == NULL)
return converterr(
-string or read-only character buffer,
+bytes or read-only character buffer,
arg, msgbuf, bufsize);
if ((*pb-bf_getbuffer)(arg, view, PyBUF_CHARACTER) != 0)
Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 58422)
+++ Objects/unicodeobject.c (working copy)
@@ -8113,19 +8113,6 @@
};
-static int
-unicode_buffer_getbuffer(PyUnicodeObject *self, Py_buffer *view, int flags)
-{
-
-if (flags PyBUF_CHARACTER) {
-PyErr_SetString(PyExc_SystemError, can't use str as char buffer);
-return -1;
-}
-return PyBuffer_FillInfo(view, (void *)self-str,
- PyUnicode_GET_DATA_SIZE(self), 1, flags);
-}
-
-
/* Helpers for PyUnicode_Format() */
static PyObject *
@@ -8819,11 +8806,6 @@
return NULL;
}
-static PyBufferProcs unicode_as_buffer = {
-(getbufferproc) unicode_buffer_getbuffer,
-NULL,
-};
-
static PyObject *
unicode_subtype_new(PyTypeObject *type, PyObject *args, PyObject *kwds);
@@ -8907,7 +8889,7 @@
(reprfunc) unicode_str, /* tp_str */
PyObject_GenericGetAttr, /* tp_getattro */
0, /* tp_setattro */
-unicode_as_buffer, /* tp_as_buffer */
+0, /* tp_as_buffer */
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE |
Py_TPFLAGS_UNICODE_SUBCLASS, /* tp_flags */
unicode_doc, /* tp_doc */
Index: Modules/_sre.c
===
--- Modules/_sre.c (revision 58422)
+++ Modules/_sre.c (working copy)
@@ -1674,6 +1674,15 @@
void* ptr;
Py_buffer view;
+/* Unicode objects do not support the buffer API. So, get the data
+ directly instead. */
+if (PyUnicode_Check(string)) {
+ptr = (void *)PyUnicode_AS_DATA(string);
+*p_length = PyUnicode_GET_SIZE(string);
+*p_charsize = sizeof(Py_UNICODE);
+return ptr;
+}
+
/* get pointer to string buffer */
view.len = -1;
buffer = Py_Type(string)-tp_as_buffer;
Index: Modules/posixmodule.c
===
--- Modules/posixmodule.c (revision 58422)
+++ Modules/posixmodule.c (working copy)
@@ -2135,7 +2135,8 @@
FILEFINDBUF3 ep;
APIRET rc;
-if (!PyArg_ParseTuple(args, t#:listdir, name, len))
+if (!PyArg_ParseTuple(args, et#:listdir,
+ Py_FileSystemDefaultEncoding, name, len))
return NULL;
if (len = MAX_PATH) {
PyErr_SetString(PyExc_ValueError, path too long);
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Guido van Rossum added the comment: On 10/13/07, Christian Heimes [EMAIL PROTECTED] wrote: Guido van Rossum wrote: - Why add an 'errors' argument to the function when it's a fatal error to use it? I wanted the signature of the method be equal to the other methods PyUnicode_Decode*. I copied the FatalError from *_PyUnicode_AsDefaultEncodedString(). But that function is a terrible example; it was done that way because an earlier version of the function *did* allow using the errors argument and I wanted to make sure to catch all calls that were still passing an errors value. This doesn't apply here, we're creating a brand new API. - Using 0 to autodetect the length is scary. Normally we have two APIs for that, one ..._FromString and one ...FromStringAndSize. If you really don't want that, please use -1, which is at least an illegal value. Oh right, -1 is *much* better for autodetect than 0. What do you prefer, a second method or -1 as auto detect? Even better is Alexandre's version: always autodetect. I think we can assume that filenames are always available as 0-terminated byte arrays, since that's how all system calls need them. Anyway, let me know if you want to change something in Alexandre's version or if you want him to check it in. Oh. Hm. I still wish that PyCode_New() could just insist that the filename argument is a PyUnicode instance. Why can't it? Perhaps the caller should be fixed instead? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Guido van Rossum added the comment: Oh. Hm. I still wish that PyCode_New() could just insist that the filename argument is a PyUnicode instance. Why can't it? Perhaps the caller should be fixed instead? I'll try. I figured out the problem -- it came from marshalled old code objects. If you throw away all .pyc files the problem goes away. You can also get rid of the similar checks for the 'name' argument -- this should just be a PyUnicode too. A systematic approach to invalidating all the .pyc files is updating the magic number in import.c. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Christian Heimes added the comment: Guido van Rossum wrote: - Why copy the default encoding before mangling it? With a little extra care you will only have to copy it once. Now I remember why I added the strncpy() call plus encoding[31] = '\0'. I wanted to make sure that the code doesn't break even if the encoding name is longer than 31 + 1 chars long. I'm aware that it's very unlikely but I didn't want to take chances. You are allowed to call me paranoid. *g* Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Guido van Rossum added the comment: Well, you could ensure that by checking that you haven't reached the end of the mangling buffer. That will have the added advantage that when the input is something silly like 32 spaces followed by utf-8 it will be still be mangled correctly. The slight extra cost of the check (could be a single pointer compare) is offset by saving a call to strncpy(). --Guido On 10/13/07, Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes added the comment: Guido van Rossum wrote: - Why copy the default encoding before mangling it? With a little extra care you will only have to copy it once. Now I remember why I added the strncpy() call plus encoding[31] = '\0'. I wanted to make sure that the code doesn't break even if the encoding name is longer than 31 + 1 chars long. I'm aware that it's very unlikely but I didn't want to take chances. You are allowed to call me paranoid. *g* Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1264] __file__ and co_filename as unicode
Changes by Guido van Rossum: -- resolution: - out of date status: open - closed superseder: - Decode __file__ and co_filename to unicode using fs default __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1264 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1267] Py3K cannot run as ``python -S``
Changes by Guido van Rossum: -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1267 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1268] array unittest problems with UCS4 build
Guido van Rossum added the comment: Can this be closed now that Travis reverted his patch? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1268 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1260] PEP 3137: Remove the buffer API from PyUnicode
Guido van Rossum added the comment: You can check this in. You do have checkin privs right? -- resolution: - accepted __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1260 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Alexandre Vassalotti added the comment:
Guido wrote:
I figured out the problem -- it came from marshalled old code objects.
If you throw away all .pyc files the problem goes away. You can also
get rid of the similar checks for the 'name' argument -- this should
just be a PyUnicode too. A systematic approach to invalidating all the
.pyc files is updating the magic number in import.c.
Done.
I had to remove a few another PyString instances in pyexpat.c and
_ctypes.c. So, here (hopefully) the final version of the patch.
The changes from the last version are:
- Correct a typo in of the comments in PyUnicode_DecodeFSDefault
- Specified in the API doc of PyUnicode_DecodeFSDefault that the
function take a null-terminated string.
- Bumped the magic number in import.c
- Fix PyCode_New calls in _ctypes and pyexpat module.
- Remove the PyString type check on 'filename' and 'name' in PyCode_New.
- Remove the unneeded string coercion code from PyCode_New.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1272
__Index: Python/ceval.c
===
--- Python/ceval.c (revision 58422)
+++ Python/ceval.c (working copy)
@@ -767,7 +767,7 @@
lltrace = PyDict_GetItemString(f-f_globals, __lltrace__) != NULL;
#endif
#if defined(Py_DEBUG) || defined(LLTRACE)
- filename = PyString_AsString(co-co_filename);
+ filename = PyUnicode_AsString(co-co_filename);
#endif
why = WHY_NOT;
Index: Python/traceback.c
===
--- Python/traceback.c (revision 58422)
+++ Python/traceback.c (working copy)
@@ -229,10 +229,10 @@
while (tb != NULL err == 0) {
if (depth = limit) {
err = tb_displayline(f,
- PyString_AsString(
+ PyUnicode_AsString(
tb-tb_frame-f_code-co_filename),
tb-tb_lineno,
- PyString_AsString(tb-tb_frame-f_code-co_name));
+ PyUnicode_AsString(tb-tb_frame-f_code-co_name));
}
depth--;
tb = tb-tb_next;
Index: Python/pythonrun.c
===
--- Python/pythonrun.c (revision 58422)
+++ Python/pythonrun.c (working copy)
@@ -867,7 +867,8 @@
return -1;
d = PyModule_GetDict(m);
if (PyDict_GetItemString(d, __file__) == NULL) {
- PyObject *f = PyString_FromString(filename);
+ PyObject *f;
+ f = PyUnicode_DecodeFSDefault(filename);
if (f == NULL)
return -1;
if (PyDict_SetItemString(d, __file__, f) 0) {
Index: Python/import.c
===
--- Python/import.c (revision 58422)
+++ Python/import.c (working copy)
@@ -74,10 +74,11 @@
3040 (added signature annotations)
3050 (print becomes a function)
3060 (PEP 3115 metaclass syntax)
- 3070 (PEP 3109 raise changes)
+ 3070 (PEP 3109 raise changes)
+ 3080 (PEP 3137 make __file__ and __name__ unicode)
.
*/
-#define MAGIC (3070 | ((long)'\r'16) | ((long)'\n'24))
+#define MAGIC (3080 | ((long)'\r'16) | ((long)'\n'24))
/* Magic word as global; note that _PyImport_Init() can change the
value of this global to accommodate for alterations of how the
@@ -652,7 +653,7 @@
/* Remember the filename as the __file__ attribute */
v = NULL;
if (pathname != NULL) {
- v = PyString_FromString(pathname);
+ v = PyUnicode_DecodeFSDefault(pathname);
if (v == NULL)
PyErr_Clear();
}
@@ -983,7 +984,7 @@
PySys_WriteStderr(import %s # directory %s\n,
name, pathname);
d = PyModule_GetDict(m);
- file = PyString_FromString(pathname);
+ file = PyUnicode_DecodeFSDefault(pathname);
if (file == NULL)
goto error;
path = Py_BuildValue([O], file);
Index: Python/compile.c
===
--- Python/compile.c (revision 58422)
+++ Python/compile.c (working copy)
@@ -4001,7 +4001,7 @@
freevars = dict_keys_inorder(c-u-u_freevars, PyTuple_Size(cellvars));
if (!freevars)
goto error;
- filename = PyString_FromString(c-c_filename);
+ filename = PyUnicode_DecodeFSDefault(c-c_filename);
if (!filename)
goto error;
Index: Python/importdl.c
===
--- Python/importdl.c (revision 58422)
+++ Python/importdl.c (working copy)
@@ -62,7 +62,9 @@
return NULL;
}
/* Remember the filename as the __file__ attribute */
- if (PyModule_AddStringConstant(m, __file__, pathname) 0)
+ PyObject *path;
+ path = PyUnicode_DecodeFSDefault(pathname);
+ if (PyModule_AddObject(m, __file__, path) 0)
PyErr_Clear(); /* Not important enough to report */
if (_PyImport_FixupExtension(name, pathname) == NULL)
Index: Include/unicodeobject.h
===
--- Include/unicodeobject.h (revision 58422)
+++ Include/unicodeobject.h (working copy)
@@ -154,6 +154,7 @@
# define
[issue1272] Decode __file__ and co_filename to unicode using fs default
Alexandre Vassalotti added the comment:
Remove the PyString type check on 'filename' and 'name' in PyCode_New.
Oops. I removed one of the ! the checks by mistake.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1272
__Index: Python/ceval.c
===
--- Python/ceval.c (revision 58454)
+++ Python/ceval.c (working copy)
@@ -767,7 +767,7 @@
lltrace = PyDict_GetItemString(f-f_globals, __lltrace__) != NULL;
#endif
#if defined(Py_DEBUG) || defined(LLTRACE)
- filename = PyString_AsString(co-co_filename);
+ filename = PyUnicode_AsString(co-co_filename);
#endif
why = WHY_NOT;
Index: Python/traceback.c
===
--- Python/traceback.c (revision 58454)
+++ Python/traceback.c (working copy)
@@ -229,10 +229,10 @@
while (tb != NULL err == 0) {
if (depth = limit) {
err = tb_displayline(f,
- PyString_AsString(
+ PyUnicode_AsString(
tb-tb_frame-f_code-co_filename),
tb-tb_lineno,
- PyString_AsString(tb-tb_frame-f_code-co_name));
+ PyUnicode_AsString(tb-tb_frame-f_code-co_name));
}
depth--;
tb = tb-tb_next;
Index: Python/pythonrun.c
===
--- Python/pythonrun.c (revision 58454)
+++ Python/pythonrun.c (working copy)
@@ -867,7 +867,8 @@
return -1;
d = PyModule_GetDict(m);
if (PyDict_GetItemString(d, __file__) == NULL) {
- PyObject *f = PyString_FromString(filename);
+ PyObject *f;
+ f = PyUnicode_DecodeFSDefault(filename);
if (f == NULL)
return -1;
if (PyDict_SetItemString(d, __file__, f) 0) {
Index: Python/import.c
===
--- Python/import.c (revision 58454)
+++ Python/import.c (working copy)
@@ -74,10 +74,11 @@
3040 (added signature annotations)
3050 (print becomes a function)
3060 (PEP 3115 metaclass syntax)
- 3070 (PEP 3109 raise changes)
+ 3070 (PEP 3109 raise changes)
+ 3080 (PEP 3137 make __file__ and __name__ unicode)
.
*/
-#define MAGIC (3070 | ((long)'\r'16) | ((long)'\n'24))
+#define MAGIC (3080 | ((long)'\r'16) | ((long)'\n'24))
/* Magic word as global; note that _PyImport_Init() can change the
value of this global to accommodate for alterations of how the
@@ -652,7 +653,7 @@
/* Remember the filename as the __file__ attribute */
v = NULL;
if (pathname != NULL) {
- v = PyString_FromString(pathname);
+ v = PyUnicode_DecodeFSDefault(pathname);
if (v == NULL)
PyErr_Clear();
}
@@ -983,7 +984,7 @@
PySys_WriteStderr(import %s # directory %s\n,
name, pathname);
d = PyModule_GetDict(m);
- file = PyString_FromString(pathname);
+ file = PyUnicode_DecodeFSDefault(pathname);
if (file == NULL)
goto error;
path = Py_BuildValue([O], file);
Index: Python/compile.c
===
--- Python/compile.c (revision 58454)
+++ Python/compile.c (working copy)
@@ -4001,7 +4001,7 @@
freevars = dict_keys_inorder(c-u-u_freevars, PyTuple_Size(cellvars));
if (!freevars)
goto error;
- filename = PyString_FromString(c-c_filename);
+ filename = PyUnicode_DecodeFSDefault(c-c_filename);
if (!filename)
goto error;
Index: Python/importdl.c
===
--- Python/importdl.c (revision 58454)
+++ Python/importdl.c (working copy)
@@ -62,7 +62,9 @@
return NULL;
}
/* Remember the filename as the __file__ attribute */
- if (PyModule_AddStringConstant(m, __file__, pathname) 0)
+ PyObject *path;
+ path = PyUnicode_DecodeFSDefault(pathname);
+ if (PyModule_AddObject(m, __file__, path) 0)
PyErr_Clear(); /* Not important enough to report */
if (_PyImport_FixupExtension(name, pathname) == NULL)
Index: Include/unicodeobject.h
===
--- Include/unicodeobject.h (revision 58454)
+++ Include/unicodeobject.h (working copy)
@@ -154,6 +154,7 @@
# define PyUnicode_DecodeASCII PyUnicodeUCS2_DecodeASCII
# define PyUnicode_DecodeCharmap PyUnicodeUCS2_DecodeCharmap
# define PyUnicode_DecodeLatin1 PyUnicodeUCS2_DecodeLatin1
+# define PyUnicode_DecodeFSDefault PyUnicodeUCS2_DecodeFSDefault
# define PyUnicode_DecodeRawUnicodeEscape PyUnicodeUCS2_DecodeRawUnicodeEscape
# define PyUnicode_DecodeUTF32 PyUnicodeUCS2_DecodeUTF32
# define PyUnicode_DecodeUTF32Stateful PyUnicodeUCS2_DecodeUTF32Stateful
@@ -245,6 +246,7 @@
# define PyUnicode_DecodeASCII PyUnicodeUCS4_DecodeASCII
# define PyUnicode_DecodeCharmap PyUnicodeUCS4_DecodeCharmap
# define PyUnicode_DecodeLatin1 PyUnicodeUCS4_DecodeLatin1
+# define PyUnicode_DecodeFSDefault PyUnicodeUCS4_DecodeFSDefault
# define PyUnicode_DecodeRawUnicodeEscape PyUnicodeUCS4_DecodeRawUnicodeEscape
# define PyUnicode_DecodeUTF32
[issue1260] PEP 3137: Remove the buffer API from PyUnicode
Alexandre Vassalotti added the comment: Committed in r58455. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1260 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1260] PEP 3137: Remove the buffer API from PyUnicode
Changes by Guido van Rossum: -- status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1260 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Guido van Rossum added the comment: Crys, is this OK with you? On 10/13/07, Alexandre Vassalotti [EMAIL PROTECTED] wrote: Alexandre Vassalotti added the comment: Guido wrote: I figured out the problem -- it came from marshalled old code objects. If you throw away all .pyc files the problem goes away. You can also get rid of the similar checks for the 'name' argument -- this should just be a PyUnicode too. A systematic approach to invalidating all the .pyc files is updating the magic number in import.c. Done. I had to remove a few another PyString instances in pyexpat.c and _ctypes.c. So, here (hopefully) the final version of the patch. The changes from the last version are: - Correct a typo in of the comments in PyUnicode_DecodeFSDefault - Specified in the API doc of PyUnicode_DecodeFSDefault that the function take a null-terminated string. - Bumped the magic number in import.c - Fix PyCode_New calls in _ctypes and pyexpat module. - Remove the PyString type check on 'filename' and 'name' in PyCode_New. - Remove the unneeded string coercion code from PyCode_New. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1272] Decode __file__ and co_filename to unicode using fs default
Christian Heimes added the comment: Guido van Rossum wrote: Guido van Rossum added the comment: Crys, is this OK with you? Alexandre's mangle loop doesn't do the same job as mine. Chars like _ and - aren't removed from the encoding name and the if clauses don't catch for example UTF-8 or ISO-8859-1 only UTF8 or ISO8859-1. Also he has overseen a PyString_Check in the code repr function. I'm working on a better mangler and I believe that I can make Py_FilesystemEncoding available much earlier in Py_InitializeEx(). *after some debugging* I fear that we are on the wrong path. Py_FileSystemEncoding is set *much* later in the boot strapping process unless its value is hard coded (Win32 and Apple only). Any attempt to get the right codec or even a normalized name without the codecs package is going to extremely hard. We have to get the codecs up and Py_FileSystemEncoding before we can decode the filenames. :( I think that the problem needs much more attention and a proper fix. Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1272 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
