[Python-Dev] SF patch #1214889 - file.encoding support
Hi, would anyone care to comment about this patch of mine -- https://sourceforge.net/tracker/?func=detailatid=305470aid=1214889group_id=5470 It makes file.encoding read-write and lets the write() and writelines() methods obey it. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF patch #1214889 - file.encoding support
Reinhold Birkenfeld wrote: Hi, would anyone care to comment about this patch of mine -- https://sourceforge.net/tracker/?func=detailatid=305470aid=1214889group_id=5470 It makes file.encoding read-write and lets the write() and writelines() methods obey it. Done. Please see SF. PS: Please don't use -nospam or the like email addresses when posting to this list. Thanks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 14 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SF patch #1214889 - file.encoding support
M.-A. Lemburg wrote: Reinhold Birkenfeld wrote: Hi, would anyone care to comment about this patch of mine -- https://sourceforge.net/tracker/?func=detailatid=305470aid=1214889group_id=5470 It makes file.encoding read-write and lets the write() and writelines() methods obey it. Done. Please see SF. PS: Please don't use -nospam or the like email addresses when posting to this list. Thanks. Why? This address is perfectly valid (as is written in my signature), and almost completely spam-free. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Hi Neil, With the proposed modification, sys.argv[1] u'\u20ac.txt' is converted through cp1251 Actually, it is not: if you pass in a Unicode argument to one of the file I/O functions and the OS supports Unicode directly or at least provides the notion of a file system encoding, then the file I/O should use the Unicode APIs of the OS or convert the Unicode argument to the file system encoding. AFAIK, this is how posixmodule.c already works (more or less). Yes it is. The initial stage is reading the command line arguments. The proposed modification is to change behaviour when constructing sys.argv, os.environ or when calling os.listdir to Return unicode when the text can not be represented in Python's default encoding. I take this to mean that when the value can be represented in Python's default encoding then it is returned as a byte string in the default encoding. Therefore, for the example, the code that sets up sys.argv has to encode the unicode command line argument into cp1251. Ok, I missed your point about sys.argv *not* returning Unicode in this particular case. However, with the modification of having posixmodule and fileobject recode string input via Unicode (based on the default encoding) into the file system encoding by basically just changing the parser marker from et to es, you get correct behaviour - even in the above case. Both posixmodule and fileobject would then take the cp1251 default encoded string, convert it to Unicode and then to the file system encoding before opening the file. On input, file I/O APIs should accept both strings using the default encoding and Unicode. How these inputs are then converted to suit the OS is up to the OS abstraction layer, e.g. posixmodule.c. This looks to me to be insufficiently compatible with current behaviour whih accepts byte strings outside the default encoding. Existing code may call open(€.txt). This is perfectly legitimate current Python (with a coding declaration) as €.txt is a byte string and file systems will accept byte string names. Since the standard default encoding is ASCII, should such code raise UnicodeDecodeError? Yes. The above proposed change is indeed more restrictive than the current pass-through approach. I'm not sure whether we can impose such a change on the users in the 2.x series... perhaps we should have a two phase approach: Phase 1: try et and if this fails with an UnicodeDecodeError, revert back to the old es pass-through approach, issuing a warning as non-disruptive signal to the user Phase 2: move to et for good and issue decode errors Changing this is easy, though: instead of using the et getargs format specifier, you'd have to use es. The latter recodes strings based on the default encoding assumption to whatever other encoding you specify. Don't you want to convert these into unicode rather than another byte string encoding? It looks to me as though the es format always produces byte strings and the only byte string format that can be passed to the operating system is the file system encoding which may not contain all the characters in the default encoding. If the OS support Unicode directly, we can (and do) have a special case that bypasses the recoding altogheter. However, this currently only appears to be available on Windows versions NT, XP and up, where we already support this. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 14 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Misc developers.txt, 1.15, 1.16
raymond Log Message: raymond Brett requests that Flovis's permissions be dropped. Not to put too fine a spin on things, but I think it was more like Brett got tired of waiting for Flovis's permissions to be increased and retracted his original request. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Miscdevelopers.txt, 1.15, 1.16
On 7/14/05, Raymond Hettinger [EMAIL PROTECTED] wrote: raymond Log Message: raymond Brett requests that Flovis's permissions be dropped. [Skip] Not to put too fine a spin on things, but I think it was more like Brett got tired of waiting for Flovis's permissions to be increased and retracted his original request. Brett and Flovis DID send a private email with a drop request this morning. They have chosen an alternate method of access. Brett's original request was fulfilled within 48 hours. I sent him a confirmation note. Also, there was a concurrent check-in notification for Misc/developers.txt. Additionally, Flovis's id appeared on the SF developer list immediately. If for some reason they did not see any of those three, they could have sent a follow-up note and gotten a fourth confirmation that the job was done. Yeah, I missed all three; I just kept expecting a reply to the python-dev list and wasn't looking for any other signs, so it's my bad. I moved over to Gmail a few weeks ago and I am still working out my Python workflow with it. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick Coghlan wrote: M.-A. Lemburg wrote: May I suggest that you use a different name than context for this ?! The term context is way to broad for the application scopes that you have in mind here (like e.g. managing a resource in a multi-threaded application). It's actually the broadness of the term 'context' which is appealing - the examples in the draft documentation on SF are: - resource management (synchronisation locks, generic 'closing') - HTML tag matching - Decimal arithmetic context Any earlier version used 'suite managers' (partly to avoid confusing the hell out of anyone ever exposed to Ruby's concept of blocks), but the 'context management' term seems to more clearly describe what the protocol is for. This is exactly what I'm getting at: I can see the potential use for resource management (which is what started out the whole idea IIRC), but fail to see why you'd want to use it for anything more complicated than that. Once you start talking about contexts (which usually refers to a combination of environment, state and location) you have to explain things like nesting, scopes, combination of different contexts, their interaction with each other, etc. etc. Note that hiding things away in smart objects like what you call context managers will not make programs easier to understand, unless the specific task that such a context manager is simple enough to grasp by just looking at its definition in the with statement... but then you'd not call it a context manager. BTW, the same argument applies to decorators. Programs don't get easier to read or understand if you overload a function with lots and lots of hidden magic... @put_all_the_smart_stuff_here def program(context): return 42 Of course, you *could* do all these things and Python is not preventing you from doing so, but will life get easier ? I doubt it. Let's keep things simple and Python nice. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 14 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
Keith Dart wrote: On Sat, 18 Jun 2005, Michael Hudson wrote: The shortest way I know of going from 2149871625L to -2145095671 is the still-fairly-gross: v = 2149871625L ~int(~v0x) -2145095671 I suppose the best thing is to introduce an unsignedint type for this purpose. Or some kind of bitfield type, maybe. C uses integers both as bitfields and to count things, and at least in my opinion the default assumption in Python should be that this is what an integer is being used for, but when you need a bitfield it can all get a bit horrible. That said, I think in this case we can just make fcntl_ioctl use the (new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just be able to use 2149871625L and be happy (I think, haven't tried this). Thanks for the reply. I think I will go ahead and add some extension types to Python. Thankfully, Python is extensible with new objects. It is also useful (to me, anyway) to be able to map, one to one, external primitives from other systems to Python primitives. For example, CORBA and SNMP have a set of types (signed ints, unsigned ints, etc.) defined that I would like to interface to Python (actually I have already done this to some degree). But Python makes it a bit more difficult without that one-to-one mapping of basic types. Having an unsigned int type, for example, would make it easier to interface Python to SNMP or even some C libraries. In other words, Since the Real World has these types that I must sometimes interface to, it is useful to have these same (predictable) types in Python. So, it is worth extending the basic set of data types, and I will add it to my existing collection of Python extensions. Therefore, I would like to ask here if anyone has already started something like this? If not, I will go ahead and do it (if I have time). I should make you aware that the new Numeric (Numeric3 now called scipy.base) has a collection of C-types that represent each C-datatype. They are (arguably) useful in the context of eliminating a few problems in data-type coercion in scientific computing. These types are created in C and use multiple inheritance in C. This is very similiar to what you are proposing and so I thought I might make you aware. Right now, the math operations from each of these types comes mostly from Numeric but this could be modified as desired. The code is available in the Numeric3 CVS tree at the numeric python sourceforge site. -Travis Oliphant ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python on PyPI
Hi, to whom it may concern: the Python package on PyPI is at version 2.3.2. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
{MAL]
This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.
Substitute different for complicated.
'with' is not application specific, it is incredibly general. All it
does is abstract recurring uses of try/finally.
Naming it after a specific class of applications would be a mistake.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
