Mailman 3 January 2009 - Python-Dev

Re: [Python-Dev] ParseTuple question
by Ulrich Eckhardt Jan. 4, 2009

Jan. 4, 2009

[sorry, dropped one pair of mails off the list, hence also the overquoting] On Sunday 04 January 2009 01:07:08 Mark Hammond wrote: > > > On 'normal' windows you generally would need to use > > > WideCharToMultiByte() to get a 'char *' version of your wchar > > > string but I expect you already know that, so I doubt I understand > > > the question... > > > > Actually, I want the exact opposite. > > I'm not sure you can get it though :) … [View More]Unless you can change Python itself, > you will be forced to convert filenames etc back and forward from wide to > narrow strings. This should roundtrip OK for all character in the current > code set. > > > 'char' strings under CE are mostly useless, in particular for > > filenames. Actually, they are useless under MS Windows in general, > > at least for the versions supported by Python 2.6/3.0, they all use > > UTF-16, only the desktop variants still have backward compatibility > > code to use 'char' strings, though with restricted functionality. > > Exactly - but for python 2.6, we are still somewhat forced to use that > 'char *' API in many cases. If the API didn't offer the automatic unicode > conversion, we would most likely have needed to implement it ourselves. > > > So, point is that I need a UTF-16 string in a function that might > > get either a string or a Unicode string. Preferably, I'd like to take > > the way that poses least resistance, so which one would you suggest? > > I'm not with you still: if a Python implemented function accepts either > string or unicode, then your utf16 string is perfect - its already unicode. > On the other hand, I thought you were faced with a Python function which, > as currently implemented, only accepts whatever the 's' format string > accepts. Such a function only accepts real PyString objects, so attempts at > passing it unicode will be futile. Obviously you could modify it to accept > a unicode, but clearly that would also mean adjusting everything that uses > the existing 'char *', which may end up fanning out to much more than you > expect. > > If I'm still misunderstanding, can you be more specific about the exact > problem (ie, the exact function you are referring to, and how you intend > calling it)? trunk/_fileio.c/fileio_init() Let's leave aside that you can also pass a filedescriptor, that function either takes a string or a Unicode string as first parameter. Now, under CE, I always need a 'wchar_t*' in order to open a file, how would I get at that easiest? My approach now is to simply use "O" as format specifier for the filename and then take a look at the object's type. If it is a char-string, I have to convert (under CE) or call the char-API (desktop MS Windows), if it is a Unicode string, I can use it as it is. Uli [View Less]

2 1

PyOS_GetLastModificationTime
by Ulrich Eckhardt Jan. 3, 2009

Jan. 3, 2009

Hi! The function PyOS_GetLastModificationTime() is documented in sys.rst as taking a "char*". However, in reality, it takes a "char*" and a "FILE*". Actually, it should take a "char const*", as it doesn't and shouldn't modify the path. Further, the normal version doesn't use the path at all, the RISCOS version in 2.7 does however, and for a CE port it would be convenient to have that info, too. There is another issue, and that is that the function isn't declared anywhere, and I'm not … [View More]

2 3

Bytes for the command line, process arguments and environment variables
by Victor Stinner Jan. 3, 2009

Jan. 3, 2009

Hi, Python 3.0 is released and supports unicode everywhere, great! But as pointed by different people, bytes are required on non-Windows OS for backward compatibility. This email is just a sum up all many issues/email threads. Problems with Python 3.0: (1) Invalid unicode string on the command line => some people wants to get the command line arguments as bytes and so start even if non decodable unicode strings are present on the command line => http://bugs.python.… [View More]org/issue3023 (2) Non decodable environment variables are skipped in os.environ => Create os.environb (or anything else) to get these variables as bytes (and be able to setup new variables as bytes) => Read the email thread "Python-3.0, unicode, and os.environ" (Decembre 2008) opened by Toshio Kuratomi (3) Support bytes for os.exec*() and subprocess.Popen(): process arguments and the environment variables => http://bugs.python.org/issue4035: my patch for os.exec*() => http://bugs.python.org/issue4036: my patch for subprocess.Popen() Command line ============ I like the curent behaviour and I don't want to change it. Be free to propose a solution to solve the issue ;-) Environment =========== I already proposed "os.environb" which will have the similar API than "os.environ" but with bytes. Relations between os.environb and os.environ: - for an undecodable variable value in os.environb, os.environ will raise a KeyError. Example with utf8 charset and os.environb[b'PATH'] = '\xff': path=os.environ['PATH'] will raise a KeyError to keep the current behaviour. - os.environ raises an UnicodeDecodeError if the key or value can not be encoded in the current charset. Example with ASCII charset: os.environ['PATH'] = '/home/hayp\xf4' - except undecodable variable values in os.environb, os.environ and os.environb will be consistent. Example: delete a variable in os.environb will also delete the key in os.environ. I think that most of these points (or all points) are ok for everyone (especially ok for Toshio Kuratomi and me :-)). Now I have to try to write an implementation of this, but it's complex, especially to keep os.environ and os.environb consistents! Processes ========= I proposed patches to fix non-Windows OS, but Antoine Pitrou wants also bytes on Windows. Amaury wrote that it's possible using the ANSI version of the Windows API. I don't know this API and so I can not contribute to this point. --- Rejected idea ============= Use a private Unicode block causes interoperability problems: - the block may be already used by other programs/libraires - 3rd party programs/libraries don't understand this block and may have problems this display/process the data (Is the idea really rejected? It has at least many problems) --- I don't have new solutions, it's just an email to restart the discussion about bytes ;-) Martin also asked for a PEP to change the posix module API to support bytes. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ [View Less]

2 1

#ifdef __cplusplus?
by Jim Jewett Jan. 3, 2009

Jan. 3, 2009

Alexander Belopolsky wrote: > 4. Should exported symbols be always declared in headers or is it ok > to just declare them as extern in .c files where they are used? Is the concern that moving them to a header makes them part of the API? In other words, does replacing PyObject * PyFile_FromString(char *name, char *mode) { extern int fclose(FILE *); ... } with #include <stdio.h> mean that the <stdio.h> needs to be included from then on, even if … [View More]

2 1

Python 3 - Mac Installer?
by Mark Summerfield Jan. 2, 2009

Jan. 2, 2009

Hi, Just wondered if/when there'd be a Mac installer for Python 3? Thanks! -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Programming in Python 3" - ISBN 0137129297

7 11

A wart which should have been repaired in 3.0?
by skip＠pobox.com Jan. 2, 2009

Jan. 2, 2009

The doc for os.path.commonprefix states: Return the longest path prefix (taken character-by-character) that is a prefix of all paths in list. If list is empty, return the empty string (''). Note that this may return invalid paths because it works a character at a time. I remember encountering this in an earlier version of Python 2.x (maybe 2.2 or 2.3?) and "fixed" it to work by pathname components instead of by characters. That had to be reverted because it was a behavior … [View More]

12 39

Summary of Python tracker Issues
by Python tracker Jan. 2, 2009

Jan. 2, 2009

ACTIVITY SUMMARY (12/26/08 - 01/02/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2261 open (+32) / 14372 closed (+27) / 16633 total (+59) Open issues with patches: 771 Average duration of open issues: 708 days. Median duration of open issues: 2759 days. Open Issues Breakdown open 2237 (+32) pending 24 ( +0) Issues Created Or Reopened (60) … [View More]

1 0

opcode dispatch optimization
by Antoine Pitrou Jan. 2, 2009

Jan. 2, 2009

Hello, I would like to mention that I've written a patch which enables "threaded interpretation" on the ceval loop with gcc (*). On my computer (an Athlon X2 3600+), it is good for a 15-20% speedup of the interpreter on pystone and pybench. I also had the opportunity to test it on a Core2-derived CPU, where it doesn't make a difference (I conjecture it's because Core2 CPUs have hardware-based indirect branch optimizations). It will make no difference if the interpreter is compiled with … [View More]

4 4

floatformat vs float_format
by David Cournapeau Jan. 2, 2009

Jan. 2, 2009

Hi, In python 2.6, there have been some effort to make float formatting more consistent between platforms, which is nice. Unfortunately, there is still one corner case, for example on windows: print a -> print 'inf' print '%f' % a -> print '1.#INF' The difference being that in the second case, the formatting is done in floatformat.c (in stringobject.c), whereas in the first case, it is done in format_float (in floatobject.c). Shouldn't both functions be calling the same underlying … [View More]

2 2

test_subprocess and sparc buildbots
by Nick Coghlan Jan. 1, 2009

Jan. 1, 2009

Does anyone have local access to a sparc machine to try to track down the ongoing buildbot failures in test_subprocess? (I think the problem is specific to 3.x builds on sparc machines, but I haven't checked the buildbots all that closely - that assessment is just based on what I recall of the buildbot failure emails). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

4 6