Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Tony Meyer [EMAIL PROTECTED] writes: - Adding ctypes to the standard library - Thomas Heller suggested that ctypes be included in core Python (starting with 2.5). The common response was that while ctypes is a useful, popular, mature module, it does make it very easy to get a core dump, which violates the guideline that if you get a core dump it's a bug in Python or in a third party extension or you're doing something harebrained. On the other hand, it was pointed out that the dl module suffers from the same problem, and is included without any warnings (the documentation was later fixed to include warnings). Martin v. Löwis suggested making ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could opt out of installing it. Everyone seemed happy with prominent warnings in the documentation, and so this is how it was checked in. Well, it is *not* yet checked in. The current state is that ctypes uses GPL'd tools to build libffi, and those can't be committed into Python SVN. http://mail.python.org/pipermail/python-dev/2006-January/059937.html Currently I tend to agree with Martin and drop the idea for now, but this probably doesn't belong into your summary ;-). Thomas ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote: The current state is that ctypes uses GPL'd tools to build libffi, and those can't be committed into Python SVN. http://mail.python.org/pipermail/python-dev/2006-January/059937.html But http://mail.python.org/pipermail/python-dev/2006-January/059938.html was never responded to. And licenses are fluid, it may be a piece of cake to get one of those 'tools' un-GPL'ed, even if they are. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] The path module PEP
[Thomas Wouters] This issue has been brought up before when people were discussing the path module. I think the consensus is that, while the inheritance isn't pure, practicality beats purity. It would require to big changes to Python and would break to much existing code to not extend string. This is my only problem with the PEP. It's all very nice that subclassing from string makes it easier not to break things, but subclassing implies a certain relationship. This is the soul of arguing for purity's sake when practicality would dictate something else. If you remove the basestring superclass, then you remove the ability to use path objects as a drop-in replacement for any path string right now. You will either have to use str(pathobj) or carefully check that the function/framework you are passing the path to does not use isinstance() or any of the string methods that are now gone. http://groups.google.com/group/comp.lang.python/browse_thread/thread/1f5bcb67c4c73f15 -- Michael Hoffman [EMAIL PROTECTED] European Bioinformatics Institute ___ 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] The path module PEP
On Wed, 2006-01-25 at 22:35 -0600, Ian Bicking wrote:
Gustavo J. A. M. Carneiro wrote:
On a slightly different subject, regarding path / path, I think it
feels much more natural path + path. Path.join is really just a string
concatenation, except that it adds a path separator in the middle if
necessary, if I'm not mistaken.
No, it isn't, which maybe is why / is bad. os.path.join(a, b) basically
returns the path as though b is interpreted to be relative to a. I.e.,
os.path.join('/foo', '/bar') == '/bar'. Not much like concatenation at
all.
Really? This is not like the unix command line. At least in
Linux, /foo/bar is the same as /foo//bar and /foo///bar, etc. But I
admit it can be useful in some cases.
Plus string concatenation is quite useful with paths, e.g., to add
an extension.
I see your point. Although perhaps adding an extension to a file
should be the exception and not the rule, since adding extensions is
rarely used compared to joining paths? Maybe Path.add_extension() ?
BTW, regarding Path subclassing basestr, there exists prior art for
this Path thing in SCons. In SCons, we (users, I'm not a scons dev)
have to constantly deal with Node instances. Most scons functions that
accept Nodes also accept strings, but a Node is not a string. When
calling an os function with Nodes, one has to convert it to string
first, using str(). IMHO, having to decorate Node instances with str()
sometimes is no big deal, really. And, given enough time, perhaps most
of the python standard library could be enhanced to accept Path
instances in addition to C strings.
If a URI class implemented the same methods, it would be something of a
question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz'
(and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does).
I assume it would be be the latter, and urljoin would be a different
method, maybe something novel like urljoin.
I honestly don't understand the usefulness of join('/foo/bar', 'baz')
ever returning '/foo/baz' instead of '/foo/bar/baz'. How would the
former be of any use? If it has no use, then please don't complicate
things even more :)
Regards.
--
Gustavo J. A. M. Carneiro
[EMAIL PROTECTED] [EMAIL PROTECTED]
The universe is always one step beyond logic.
___
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] The path module PEP
On 1/26/06, Thomas Wouters [EMAIL PROTECTED] wrote: On Wed, Jan 25, 2006 at 09:37:04PM +0100, BJörn Lindqvist wrote: Inheritance from string (Jason) This issue has been brought up before when people were discussing the path module. I think the consensus is that, while the inheritance isn't pure, practicality beats purity. It would require to big changes to Python and would break to much existing code to not extend string. I don't think there is consensus at all. I've seen plenty of arguments, either directly against inheritance from string, or against features which exist *because* of the inheritance (e.g., we can't use join() because it's a string method). This is my only problem with the PEP. It's all very nice that subclassing from string makes it easier not to break things, but subclassing implies a certain relationship. That relationship doesn't exist, in this case. Having the string subclass behave differently than strings (consider the __iter__ and join methods) is a bad idea. I can dish up a half dozen contrived problem cases, but the main reason I don't like it is that it feels wrong. Agreed. Path objects don't feel like strings to me, either. It's certainly *arguable* that paths are strings in some ideal sense, but in a very practical sense they are not. Operations like split, join, justification, trimming, all of which are part of the Python string type (and hence constitute part of what it means to be a string in Python) do not have any sensible meaning on paths. The only justification for making Path a string subtype seems to me to avoid a few conversions - open(path) rather than open(str(path)), for example. I'd rather have to explicitly convert, to be honest. (But I'd happily accept changes to open etc to take path objects directly). If the reason to subclass string is that it's too hard to make an object 'string-like' at a low enough level for the C API, I suggest fixing that, instead. If that means Path has to wait until Python 2.6, then that's too bad. The inability to feed C functions/types open() non-string objects has troubled me before, and though I haven't invested a lot of time in it, I don't quite understand why it isn't possible. Fixing it in a backward-compatible manner may require a new __hook__, although I think using __str__ or __unicode__ shouldn't be too problematic. Even if fixing the %es/%et etc formats to the arg-parsing methods is infeasible, I would prefer a new format code for 'string-alike as C string' over the unpythonic inappropriate subclassing. Although, even if the subclassing was completely appropriate, I would much rather improve builtin support for ducktyping than showcase subclassing ;) Adaptation (PEP 246) would let paths be *adaptable* to strings, without *being* strings... :-) Paul. ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Thomas Wouters [EMAIL PROTECTED] writes: On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote: The current state is that ctypes uses GPL'd tools to build libffi, and those can't be committed into Python SVN. http://mail.python.org/pipermail/python-dev/2006-January/059937.html But http://mail.python.org/pipermail/python-dev/2006-January/059938.html was never responded to. Lack of time - sorry. And licenses are fluid, it may be a piece of cake to get one of those 'tools' un-GPL'ed, even if they are. I wouldn't even know whom to ask. Thomas ___ 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] The path module PEP
On 1/25/06, BJörn Lindqvist [EMAIL PROTECTED] wrote: My comments on the issues. It was easier this way than trying to reply on every message individually. Inheritance from string (Jason) This issue has been brought up before when people were discussing the path module. I think the consensus is that, while the inheritance isn't pure, practicality beats purity. It would require to big changes to Python and would break to much existing code to not extend string. I'll add this to Resolved Issues if nobody minds. I mind (see my previous post)... Remove __div__ (Ian, Jason, Michael, Oleg) This is one of those where everyone (me too) says I don't care either way. If that is so, then I see no reason to change it unless someone can show a scenario in which it hurts readability. Plus, a few people have said that they like the shortcut. Hardly. I've seen some pretty strong arguments (both for and against) - not what I'd describe as everyone saying they don't care. FWIW, I find the / operator ugly. Also, multiple concatenation (path / a / b / c) results in building lots of intermediates, where path.join(a, b, c) need not. Arguing that you can't reuse string methods is bogus, IMHO, as the requirement to subclass from string is far from clear. Actually, reading that, I'd suggest: - an append() method to add extra components to a path - a multi-arg Path() constructor So, we have - path.append(a, b, c) - Path(C:, Windows, System32) Quick question - how do Path objects constructed from relative paths behave? Are there such things as relative path objects? Consider p1 = Path(a) p2 = Path(b) Is p1.append(p2) (or p1/p2) legal? What does it mean? I'd have to assume it's the same as Path(a, b), but I'm not sure I like that... What about Path(/a).append(Path(/b)) ??? Also note that my example Path(C:, Windows, System32) above is an *absolute* path on Windows. But a relative (albeit stupidly-named :-)) path on Unix. How would that be handled? Not that os.path gets it perfect: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os os.path.join(C:, Windows, System32) 'C:Windows\\System32' os.path.join(., os.path.join(C:, Windows, System32)) '.\\C:Windows\\System32' But os.path manipulates strings representing pathnames (and I can forgive oddities like this by noting that some rules about pathnames are pretty subtle...). I'd have higher standards for a dedicated Path object. Arguably, Path objects should always maintain an absolute path - there should be no such thing as a relative Path. So you would have str(Path(whatever)) === os.path.abspath(whatever) It also allows Path(C:, Windows) to do different things on Windows and Unix (absolute on Windows, relative to os.curdir on Unix). This would imply that Path(a, a_path) or a_path.append(another_path) is an error. And of course, for this to work, Path objects *can't* be a subclass of string... :-) Paul. ___ 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] The path module PEP
[Thomas Wouters] [Subclassing string] is my only problem with the PEP. It's all very nice that subclassing from string makes it easier not to break things, but subclassing implies a certain relationship. [Michael Hoffman] This is the soul of arguing for purity's sake when practicality would dictate something else. [Thomas Wouters] If we're going to argue that point, I don't believe this is the practicality that the 'zen of python' talks about. Practicality is the argument for 'print', and for requiring the ':' before suites, and for some of the special cases in the Python syntax and module behaviour. It isn't about the implementation. The argument to subclass string is, as far as I can tell, only the ease of implementation and the ease of transition. Nothing in the old thread convinced me otherwise, either. I've never seen Guido go for an implementation-practical solution just because he couldn't be arsed to do the work to get a conceptually-practical solution. And subclassing string isn't conceptually-practical at all. I don't understand what conceptually-practical is or how it differs from conceptually pure which is what it seems that you're looking for. It's not hard to give Path a has-a relationship to basestring instead of an is-a relationship, so it really doesn't save much in terms of implementation. If you remove the basestring superclass, then you remove the ability to use path objects as a drop-in replacement for any path string right now. You will either have to use str(pathobj) or carefully check that the function/framework you are passing the path to does not use isinstance() or any of the string methods that are now gone. More to the point, you will have to carefully check whether the function/framework will use the Path object in a way the Path object can handle. There's already discussion about whether certain methods should be 'disabled', in Path objects, or whether they should be doing something conceptually different. Yes, and I think all of this discussion is focused on conceptual purity and misses one of the big wins of the Path module for current users--it can be trivially used anywhere where a str is expected today. If you're going to start deciding that certain str methods should be disabled for some reason, then it shouldn't be a str subclass, because it will no longer behave like string-plus. In previous discussions, string methods were identified that one programmer thought would not be useful on a path, but others disagreed. Disabling methods serves no useful purpose, except to shorten dir(). I've been using path.py for some time, and I can tell you that it would be a lot less useful if it no longer behaved like string-plus. -- Michael Hoffman [EMAIL PROTECTED] European Bioinformatics Institute ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On 26-jan-2006, at 13:29, Thomas Heller wrote: Thomas Wouters [EMAIL PROTECTED] writes: On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote: The current state is that ctypes uses GPL'd tools to build libffi, and those can't be committed into Python SVN. http://mail.python.org/pipermail/python-dev/2006-January/059937.html But http://mail.python.org/pipermail/python-dev/2006-January/ 059938.html was never responded to. Lack of time - sorry. And licenses are fluid, it may be a piece of cake to get one of those 'tools' un-GPL'ed, even if they are. I wouldn't even know whom to ask. It shouldn't be too hard to use Python's main configure script to calculate the information necessary to build libffi. A lot of it is already calculated anyway (sizeof various type, endianness), some can be hardcoded (FFI_NO_RAW_API). In PyObjC I just compile the files I need from my setup.py. But I have an easy task, I just need to support two CPU architectures on one OS. Ronald Thomas ___ 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/ ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ 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] The path module PEP
on 26.01.2006 14:15 Paul Moore said the following: [snip] Also note that my example Path(C:, Windows, System32) above is an *absolute* path on Windows. But a relative (albeit stupidly-named :-)) path on Unix. How would that be handled? wrong, Path(C:, Windows, System32) is a relative path on windows. see below. Not that os.path gets it perfect: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os os.path.join(C:, Windows, System32) 'C:Windows\\System32' os.path.join(., os.path.join(C:, Windows, System32)) '.\\C:Windows\\System32' this is misleading. observe:: In [1]: import os In [2]: os.path.join(., os.path.join(C:, Windows, System32)) Out[2]: '.\\C:Windows\\System32' but:: In [3]: os.path.join(., os.path.join(C:\\, Windows, System32)) Out[3]: 'C:\\Windows\\System32' The second example uses an absolute path as second argument, and as os.path.join should do, the first argument is discarded. The first case is arguably a bug, since, on windows, C:Windows\System32 is a path relative to the *current directory on disk C:* If the cwd on C: would be C:\temp then C:Windows\System32 would point to C:\temp\Windows\System32 The problem is that Windows has a cwd per partition... (I cannot even guess why ;-) For the sake of illustration, the following is a WinXP cmd session:: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\tempd: D:\cd HOME D:\HOMEc: C:\tempd: D:\HOMEc: C:\tempcd d:bin C:\tempd: D:\HOME\bin [snip] Arguably, Path objects should always maintain an absolute path - there should be no such thing as a relative Path. So you would have you realise that one might need and/or want to represent a relative path? ___ 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] The path module PEP
Gustavo J. A. M. Carneiro wrote:
If a URI class implemented the same methods, it would be something of a
question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz'
(and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does).
I assume it would be be the latter, and urljoin would be a different
method, maybe something novel like urljoin.
I honestly don't understand the usefulness of join('/foo/bar', 'baz')
ever returning '/foo/baz' instead of '/foo/bar/baz'. How would the
former be of any use?
it's how URL:s are joined, as noted in the paragraph you replied to
(a baz link on the page /foo/bar refers to /foo/baz, not /foo/bar/baz)
/F
___
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] Include ctypes into core Python?
James Y Knight [EMAIL PROTECTED] writes: On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote: Several of these files are licensed under GPL: aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh ltconfig missing Are you sure? The copies of aclocal.m4 and config-ml.in both disagree with you. aclocal seems to have a completely liberal license, and config-ml has a whatever the license of the program it's building license. It seems you are right: config-ml.in: GPL with special exception. config.guess: GPL with special exception. config.sub: GPL with special exception. configure: no limitation depcomp: GPL with special exception. install-sh: X-11 license ltcf-c.sh:GPL with special exception. ltconfig: GPL with special exception. ltmain.sh:GPL with special exception. aclocal.m4: see below Is aclocal.m4 an exception? It has several copyright notices. The first one gives unlimited permissions to copy and/or distribute, but sections after that have no exception clause. I'm unsure what this means. The files that ctypes uses are in CVS here: http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/source/gcc/libffi/?only_with_tag=branch_1_0 Thomas ___ 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] Path inherits from string
This seems to be the only really major issue with the PEP. Everything
else is negotiable, IMHO. But the string inheritance seem to be such a
critical issue it deserves its own thread. I have tried to address all
criticism of it here:
Really, it is the same arguments that have been rehashed over and over
again. I also think that they have been suitably countered already -
Practicality beats Purity. The fact that you can plug Path into
already existing code is a major benefit. It makes it possible to use
and integrate the Path class *now* and not wait until the mythical
Python 3000 when every single flaw in Python have been fixed. Remember
that the Path module have existed for three years in the wild and is
extra-ordinarily well-liked. If the fact that Path inherits from
string is such a big deal, then *why* is the path module so hugely
popular?? :)
The inheritance is a design trade-off. An implementation detail, an
insignificant wart in an otherwise very practical design. Over the
years I have used the path module this wart has never ever hurt
me. Not even once. But if someone can construct a Path class that does
*not* inherit from string and that works equally well as Path then
ofcourse, that is preferable. However, because of this (and similar
issues) I don't think it is possible:
class Foo:
def __str__(self):
return foo
open(Foo())
TypeError: coercing to Unicode: need string or buffer, instance found
However, I might be wrong because according to [1] it should work. And
having to wrap the Path object in str() (open(str(somepath))) each and
every time the called function expects a string is not a practical
solution.
Also note that because compatibility with existing code is important,
Path can not override or change any methods at all from str - Liskov
Substitution Principle. As Path is, it only violates LSP once:
type(Path()) == type('')
False
And there is absolutely nothing that can be done about that. As far as
I can tell, the string inheritance is either livable with or is a
showstopper. If it is the latter, then:
1. Someone has to make the required modifications to the Python
core.
2. Create a Path class (or adapt the existing one so) that does
not inherit from string.
3. Release it and wait a few years hoping for it to gain
widespread acceptance in the Python community.
4. Make a PEP (or adapt this PEP) that gets accepted.
This scenario makes me sad because it basically means that there will
never be a Path module in Python, atleast not during my lifetime. :(
Why? Because Jason Orendorff's path module already exists and
works. But I may be overestimating the problems and doing what Jason
suggests in [2] may be enough. Maybe someone who knows what he is
talking about can expand on it further?
1 http://mail.python.org/pipermail/python-dev/2001-August/016674.html
2 http://mail.python.org/pipermail/python-dev/2006-January/060030.html
--
mvh Björn
___
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] Path inherits from string
BJörn Lindqvist wrote: However, I might be wrong because according to [1] it should work. And having to wrap the Path object in str() (open(str(somepath))) each and every time the called function expects a string is not a practical solution. in Python, the usual way to access an attribute of an object is to access the attribute; e.g. f = open(p.name) /F ___ 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] Path inherits from string
BJörn Lindqvist wrote: This seems to be the only really major issue with the PEP. Everything else is negotiable, IMHO. But the string inheritance seem to be such a critical issue it deserves its own thread. I have tried to address all criticism of it here: I don't see why this is critical for the success of the Path object. I agree with Thomas that interfaces should be made compatible to Path object. Please note that inheritance from string will cause the C type checks of the form PyString_Check(obj) to return true. C code will then assume that it has an object which is compatible to string C API which instances aren't. If the C code then uses the C API string macros, you get segfaults - and lot's of old code does, since there was no way to inherit from a string type at the time. In fact, you're lucky that open() doesn't give you segfaults, since the code used to fetch the string argument does exactly that... ... And there is absolutely nothing that can be done about that. As far as I can tell, the string inheritance is either livable with or is a showstopper. If it is the latter, then: 1. Someone has to make the required modifications to the Python core. Right. Plus convert a few PyString_Check()s to PyString_CheckExact()... 2. Create a Path class (or adapt the existing one so) that does not inherit from string. 3. Release it and wait a few years hoping for it to gain widespread acceptance in the Python community. 4. Make a PEP (or adapt this PEP) that gets accepted. This scenario makes me sad because it basically means that there will never be a Path module in Python, atleast not during my lifetime. :( Why not ? We've added Unicode support to at least some file I/O APIs - adding support for instances which support the string interface shouldn't be all that difficult :-) BTW, if you're fine with this API: class File: def __unicode__(self): return utest.txt then the required change is minimal: we'd just need to use PyObject_Unicode() in getargs.c:837 and you should be set. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 26 2006) 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] Path inherits from string
Fredrik Lundh wrote: However, I might be wrong because according to [1] it should work. And having to wrap the Path object in str() (open(str(somepath))) each and every time the called function expects a string is not a practical solution. in Python, the usual way to access an attribute of an object is to access the attribute; e.g. f = open(p.name) You mean f = open(Path(p).name), because it is likely that people will also have to accept strings for the nearterm (and probably longeterm) future. And the error message without will be inscrutable (and will still be inscrutable in many cases when you try to access other methods, sadly). And currently .name is taken for something else in the API. And the string path is not really an attribute because the string path *is* the object, it is not *part* of the object. OTOH, str(path) will break unicode filenames. And unicode() breaks anything that simply desires to pass data through without effecting its encoding. An open method on paths simplifies many of these issues, but doesn't do anything for passing a path to legacy code. Changing open() and all the functions that Path replaces (e.g., os.path.join) to accept Path objects may resolve issues with a substantial portion of code. But any code that does a typecheck on arguments will be broken -- which in the case of paths is quite common since many functions take both filename and file object arguments. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On Jan 26, 2006, at 7:29 AM, Thomas Heller wrote: And licenses are fluid, it may be a piece of cake to get one of those 'tools' un-GPL'ed, even if they are. I wouldn't even know whom to ask. On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote: It shouldn't be too hard to use Python's main configure script to calculate the information necessary to build libffi. A lot of it is already calculated anyway (sizeof various type, endianness), some can be hardcoded (FFI_NO_RAW_API). In PyObjC I just compile the files I need from my setup.py. But I have an easy task, I just need to support two CPU architectures on one OS. Let's please be sure the license isn't fine _as is_ before thinking about asking people to change them or rewriting the build system! I did not look at *all* the files listed as being GPL, but the first two in the list were not. James ___ 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] The path module PEP
On Thu, 2006-01-26 at 16:17 +0100, Fredrik Lundh wrote:
Gustavo J. A. M. Carneiro wrote:
If a URI class implemented the same methods, it would be something of a
question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz'
(and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does).
I assume it would be be the latter, and urljoin would be a different
method, maybe something novel like urljoin.
I honestly don't understand the usefulness of join('/foo/bar', 'baz')
ever returning '/foo/baz' instead of '/foo/bar/baz'. How would the
former be of any use?
it's how URL:s are joined, as noted in the paragraph you replied to
(a baz link on the page /foo/bar refers to /foo/baz, not /foo/bar/baz)
That's not how I see it. A web browser, in order to resolve the link
'baz' in the page '/foo/bar', should do:
join(basename('/foo/bar'), 'baz')
== join('/foo', 'baz')
== '/foo/baz'.
Regards.
--
Gustavo J. A. M. Carneiro
[EMAIL PROTECTED] [EMAIL PROTECTED]
The universe is always one step beyond logic.
___
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] Path inherits from string
BJörn Lindqvist wrote: This seems to be the only really major issue with the PEP. I'd like to call for order here. What PEP? I can't find it on http://www.python.org/peps/ Also, if this is a major issue, then the PEP owner should not start a thread discussing it, but instead edit the PEP should summarize the discussion, pointing out the most common arguments, and either declare them as open, or explain why they aren't issues. People can then discuss these explanations. Regards, Martin ___ 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] / as path join operator (was: Re: The path module PEP)
I think that everything that can be said aboud __div__() has already been said. But this argument was really convincing: [Tony Meyer] The vast majority of people (at least at the time) were either +0 or -0, not +1. +0's are not justification for including something. There is no clear consensus either way. Ultimately, Guido will decide if he thinks it is clever or not. Meanwhile I'll remove it from the PEP and keep it as an optional extension. Also, like Jason said, the removal of __div__() leads to the ultimate demise of joinpath(), woho! [Jason Orendorff] in which case I propose using the Path constructor as the replacement for os.path.join(). In that case, Path.joinpath can be dropped. Path.cwd() / foobar == Path(Path.cwd(), foobar) Path(foo) / bar / baz == Path(foo, bar, baz) Still, in the simpler cases, __div__() looks really handy: os.chdir(pkgdir / include) == os.chdir(Path(pkgdir, include)) Oh well. You can't have everything, can you? The updated PEP and an implementation is availible from http://wiki.python.org/moin/PathClass. -- mvh Björn ___ 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] Path inherits from string
M.-A. Lemburg wrote: Please note that inheritance from string will cause the C type checks of the form PyString_Check(obj) to return true. C code will then assume that it has an object which is compatible to string C API which instances aren't. Oh, sure they are. Types inheriting from str have the same layout as str, and C code assuming that layout will work fine with them. Inheritance works (saying inheritance *just* works would deny the many fine details that have been engineered to actually make it work). Regards, Martin ___ 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] The path module PEP
Delurking The path module has a great idea, but it does too much -- it conflates too many ideas into a single module. It has methods for dealing with files (open, bytes, read, etc) as well as methods for dealing with a filesystem tree as a whole (relpath, abspath, etc). Both of these ideas are tangentially related to paths, but really aren't in the same conceptual box. Not too long ago, I had to build something loosely based upon the path module. Instead of using it as-is, I broke it up into three modules: Tree (filesystem interfaces) Path (*just* path interfaces) File (a generic filelike object) Doing it this way had two benefits: First, it put different concepts into different modules. I note that some other virtual filesystem modules also maintedned a similar separation - probably for similar reasons. Second, I was able to define an interface which could be used across remote systems -- e.g. I was able to have an FTPTree (built on the standard library ftplib) and SSHTree (built upon paramiko) as well as FileTree (a standard filesystem). This isn't full-fledged interfaces - I just implemented common functionality in a class and then delegated to a ._ops class which passed through the necessary operations. However, I was able to use the various trees and file-like objects interchangeably. ___ 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] Path inherits from string
Ian Bicking wrote: Fredrik Lundh wrote: However, I might be wrong because according to [1] it should work. And having to wrap the Path object in str() (open(str(somepath))) each and every time the called function expects a string is not a practical solution. in Python, the usual way to access an attribute of an object is to access the attribute; e.g. f = open(p.name) You mean f = open(Path(p).name), because it is likely that people will also have to accept strings for the nearterm (and probably longeterm) future. And the error message without will be inscrutable (and will still be inscrutable in many cases when you try to access other methods, sadly). And currently .name is taken for something else in the API. And the string path is not really an attribute because the string path *is* the object, it is not *part* of the object. OTOH, str(path) will break unicode filenames. And unicode() breaks anything that simply desires to pass data through without effecting its encoding. An open method on paths simplifies many of these issues, but doesn't do anything for passing a path to legacy code. Changing open() and all the functions that Path replaces (e.g., os.path.join) to accept Path objects may resolve issues with a substantial portion of code. But any code that does a typecheck on arguments will be broken -- which in the case of paths is quite common since many functions take both filename and file object arguments. Would it help to redefine file/open so they called an __open__() method on the argument were one defined, otherwise reverting to current behaviour? That way we could just just define an __open__(self) method for path objects. I doubt performance is a huge issue here. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On 26-jan-2006, at 18:04, James Y Knight wrote: On Jan 26, 2006, at 7:29 AM, Thomas Heller wrote: And licenses are fluid, it may be a piece of cake to get one of those 'tools' un-GPL'ed, even if they are. I wouldn't even know whom to ask. On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote: It shouldn't be too hard to use Python's main configure script to calculate the information necessary to build libffi. A lot of it is already calculated anyway (sizeof various type, endianness), some can be hardcoded (FFI_NO_RAW_API). In PyObjC I just compile the files I need from my setup.py. But I have an easy task, I just need to support two CPU architectures on one OS. Let's please be sure the license isn't fine _as is_ before thinking about asking people to change them or rewriting the build system! I did not look at *all* the files listed as being GPL, but the first two in the list were not. Merging the two configure files might be a good idea anyway, that would take away the need to run configure from setup.py. IANAL, but I don't quite get how a GPL'd support script, if there is such a thing, in the build machinery of an extension library would require that Python itself is GPL'd. Anyhow, in my copy of libffi (a snapshot where the last entry in the Changelog is from 2004-04-26) the only the following files at the toplevel op libffi are GPL licensed: config.guess, config.sub, config-ml.in, ltcf-c.sh, ltconfig, ltmain.sh, missing. All of these contain an exception clause like this one in config.guess: # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. I'd say that it should be save to include these in the Python distribution. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On 26-jan-2006, at 16:33, Thomas Heller wrote: Ronald Oussoren [EMAIL PROTECTED] writes: On 26-jan-2006, at 13:29, Thomas Heller wrote: Thomas Wouters [EMAIL PROTECTED] writes: On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote: The current state is that ctypes uses GPL'd tools to build libffi, and those can't be committed into Python SVN. http://mail.python.org/pipermail/python-dev/2006-January/ 059937.html It shouldn't be too hard to use Python's main configure script to calculate the information necessary to build libffi. A lot of it is already calculated anyway (sizeof various type, endianness), some can be hardcoded (FFI_NO_RAW_API). In PyObjC I just compile the files I need from my setup.py. But I have an easy task, I just need to support two CPU architectures on one OS. Thanks for the encouragement - Martin suggested a similar approach. From my understanding (which goes not very far) the configuration does two things: determine the set of source files that needs to go in depending on the cpu architecture, and to determine some information and make them available in #defines. I have to check if this is possible without patching the libffi sources themselves. I guess I could look into the PyObjC setuop script. PyObjC's solution is kind of a hack: I always compile all files needed for i386 and PPC support and use #ifdef statements to make sure only the files for the current platform are actually used. This is a hack to make it easier to build a universal (aka fat) binary of PyObjC. Personally I only have access to machines running windows, linux (x86 and x86_64), and OS X (plus possibly a Mac running ubuntu), so I could only do it for those. Maybe support for other architectures can be added by volunteers? Besides: James Y Knight seems to be correct that all the scripts needed to build libffi seems to have this special exception from the GPL. I should catch up on python-dev before looking into this. I just noted the same thing :-) Ronald Thomas ___ 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/ ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ 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] The path module PEP
One other benefit that I neglected to put into the previous post - I was
able to maintain separate cwd's for each tree.
An example of use:
Each tree has its own context, independent of the context of python:
local, local2 = fs.LocalTree(), fs.LocalTree()
local.pwd
'/home/targoz'
local2.pwd
'/home/targoz'
os.getcwd()
'/home/targoz'
local.chdir('..')
local2.chdir('www')
local.pwd
'/home'
local2.pwd
'/home/targoz/www'
os.getcwd()
'/home/targoz'
Remote trees have the same interface:
remote_login_data = {'username': 'targoz', 'password': 'my_pass',
host': 'hostname.com'}
remote = fs.SSHTree(access=remote_login_data)
remote.pwd()
'/home/nportal'
Trees can interact, regardless of whether they are local or remote:
local2.listdir('files')
['myfile', 'otherfile.txt']
remote.listdir()
[]
localfile = local2.open(('targoz/myfile') # Opens a file-like object
remote.savefile(localfile, 'remote_name')
remote.listdir()
['myfile']
___
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] Path inherits from string
On Thu, Jan 26, 2006 at 07:55:08PM +, Steve Holden wrote: Would it help to redefine file/open so they called an __open__() method on the argument were one defined, otherwise reverting to current behaviour? Not really, open() is (by far!) not the only function that breaks. Most posixmodule functions, by the looks of it, as well as a few in _tkinter and socket. And that's just a quick grep for PyArg_Parse* with 'et' as an argument. Perhaps if __open__ was generalized into __equivalent_string__... but we've been there already. ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] stabilizing builds
On Wed, Jan 25, 2006 at 01:59:18AM +0100, Thomas Wouters wrote: [ iffy isatty behaviour on Solaris ] Considering that: - the approach for opening pty's, while not the only one, is the preferred way of doing it on Solaris, - the actual pty's seem to be completely functional, - the usual way to use pty's is not like the test does (inside a single process), and I'd say using pty's like the test does is extremely unlikely to happen in real life, - testing inside the tty-creating process is quite possibly the reason for the fickleness of the test, since its behaviour isn't guaranteed anywhere, - the test inside a subprocess, the normal way of using pty's, is not failing (as far as I can tell), I'd like to check in the attached patch. It doesn't fix anything, it just removes this one test failure on Solaris. I don't want to skip the entire test, because it still tests whether everything else works as expected, and I don't want spurious failures as they can mask a real failure later in the test. I'd need developer access back to check it in, though. Unless anyone objects, of course :) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! Index: Lib/test/test_pty.py === --- Lib/test/test_pty.py(revision 42187) +++ Lib/test/test_pty.py(working copy) @@ -4,6 +4,13 @@ TEST_STRING_1 = I wish to buy a fish license.\n TEST_STRING_2 = For my pet fish, Eric.\n +# Solaris (at least 2.9 and 2.10) seem to have a ficke isatty(). The first +# test below, testing the result of os.openpty() for tty-ness, sometimes +# (but not always) fails. The second isatty test, in the sub-process, always +# works. Allow that fickle first test to fail on these platforms, since it +# doesn't actually affect functionality. +fickle_isatty = [sunos5] + if verbose: def debug(msg): print msg @@ -26,7 +33,7 @@ # An optional feature could not be imported ... ? raise TestSkipped, Pseudo-terminals (seemingly) not functional. -if not os.isatty(slave_fd): +if not os.isatty(slave_fd) and sys.platform not in fickle_isatty: raise TestFailed, slave_fd is not a tty # IRIX apparently turns \n into \r\n. Allow that, but avoid allowing other ___ 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] building a module catalogue with buildbot
any progress ? does the script work in the buildbot setting, or does it need tweaking ? /F Neal Norwitz wrote: Does that make sense? We would just need /f's script in SVN. in python/Tools/something or sandbox/something ? python/Doc/tools/something? Fredrik were you still working on that? I can make the changes to the bb master. I thought Trent's suggested placement was good. iirc, the script needed some minor tweaking (using os.path.splitext to test for the module.so extension isn't a good idea), and I don't recall if I've fixed that or not... (probably not, since I never checked it in). I'll take a look asap. alright, I just checked in a Doc/tools/listmodules.py which attempts to produce a sorted list of all modules available in a given python build. by default, it prints the list to stdout, which should be good enough for a catalog buildbot step. ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Ronald Oussoren [EMAIL PROTECTED] writes: On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote: It shouldn't be too hard to use Python's main configure script to calculate the information necessary to build libffi. A lot of it is already calculated anyway (sizeof various type, endianness), some can be hardcoded (FFI_NO_RAW_API). In PyObjC I just compile the files I need from my setup.py. But I have an easy task, I just need to support two CPU architectures on one OS. Merging the two configure files might be a good idea anyway, that would take away the need to run configure from setup.py. IANAL, but I don't quite get how a GPL'd support script, if there is such a thing, in the build machinery of an extension library would require that Python itself is GPL'd. Anyhow, in my copy of libffi (a snapshot where the last entry in the Changelog is from 2004-04-26) the only the following files at the toplevel op libffi are GPL licensed: config.guess, config.sub, config-ml.in, ltcf-c.sh, ltconfig, ltmain.sh, missing. All of these contain an exception clause like this one in config.guess: ctypes libffi is somewhat newer, around 2005-05-09. # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. I'd say that it should be save to include these in the Python distribution. As I said in the other thread (where the discussion should probably be continued anyway): http://mail.python.org/pipermail/python-dev/2006-January/060113.html only aclocal.m4 isn't clear to me about the license. Anyway, it could be that this file isn't needed after all - I don't know enough about the GNU toolchain to be sure. Can anyone comment on this? Neither do I know enough to merge the configure scripts. Contributions would really, really gratefully be accepted. Thomas ___ 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] Path inherits from string
Martin v. Löwis wrote: M.-A. Lemburg wrote: Please note that inheritance from string will cause the C type checks of the form PyString_Check(obj) to return true. C code will then assume that it has an object which is compatible to string C API which instances aren't. Oh, sure they are. Types inheriting from str have the same layout as str, and C code assuming that layout will work fine with them. Inheritance works (saying inheritance *just* works would deny the many fine details that have been engineered to actually make it work). You're right, I forgot about how the .__new__() works on new-style classes and that extra space is allocated appended to the base type object for the extra instance features. From PEP 253: class C(B): pass ... In any case, the work for creating C is done by M's tp_new() slot. It allocates space for an extended type structure, containing: the type object; the auxiliary structures (as_sequence etc.); the string object containing the type name (to ensure that this object isn't deallocated while the type object is still referencing it);and some auxiliary storage (to be described later). It initializes this storage to zeros except for a few crucial slots (for example,tp_name is set to point to the type name) and then sets the tp_base slot to point to B. Sorry for the FUD, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 26 2006) 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] building a module catalogue with buildbot
On 1/26/06, Fredrik Lundh [EMAIL PROTECTED] wrote: any progress ? does the script work in the buildbot setting, or does it need tweaking ? I haven't gotten to it and won't be able to in the next week+. If no one beats me to it, I will get to it in a few weeks. I've got most of the buildbot machines green and working towards stable. n ___ 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] The path module PEP
Michael Hoffman wrote: I've been using path.py for some time, and I can tell you that it would be a lot less useful if it no longer behaved like string-plus. As Jason pointed out elsewhere, the strict typechecks that exist *in* the Python core, and the fact that path.py is *outside* that core makes the workaround of subclassing string necessary. Since the PEP process has the power to alter the *core*, then we have other options than this is a string, only not. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Extension to ConfigParser
Hello all, In the past there has been some discussion about a new module to replace ConfigParser. Most notably at http://wiki.python.org/moin/ConfigParserShootout Specific issues that could be addressed include : * Simpler API * Nested subsections * List values * Storing/converting datatypes * Config file schema * Keeps track of order of values Plus other issues. I'm the (co-)author of ConfigObj - http://www.voidspace.org.uk/python/configobj.html This is a reasonably mature project (now in it's fourth incarnation), and is being used in projects like `Bazaar http://www.bazaar-ng.org/`_ and `PlanetPlus http://planetplus.python-hosting.com/`_. It occurs to me that the ConfigObj API and syntax is *almost* fully compatible with ConfigParser. It would be possible to extend to the ConfigObj API to be backwards compatible with ConfigParser. This would bring the added benefits of ConfigObj, without needing to add an extra module to the standard library. Well nearly. ConfigObj supports config file schema with (optional) type conversion, through a companion module called validate. This could be included or left as an added option. Anyway. If this stands a *chance* of acceptance, I'll write the PEP (and if accepted, do the work - which is not inconsiderable). Summary of ConfigObj ConfigObj is a Python 2.2 compatible config file parser. It's major feature is simplicity of use. It reads (and writes) INI file like config files and presents the members using a dictionary interface. The order of keys/sections is preserved, and it allows nested subsections to any level : e.g. :: key = value [section] key = value [[sub-section]] key = value It is fully documented with a barrage of doctests. All comments in the config file are also preserved as attributes of the object, and will be written back out. This can be useful for including comments in programatically generated config files. It is integrated with a powerful validation system. Difficulties Differences = A ConfigObj instance is a sub-class of the dictionary datatpe. This means that the ``get`` method of ConfigParser clashes. ConfigObj allows values in the root section (why not ?). ConfigObj doesn't support line continuations (it does all multi-line values through the use of triple quoted strings). ConfigObj currently only allows '=' as a valid divider. Creating ConfigParser (and related classes) compatibility is a big job. Solution = All of these problems (if deemed necessary) can be resolved. Either through options, or just by extending the ConfigObj API. I'm happy to put the work in. Comments ? All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml ___ 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] The path module (class) PEP
(1) What is the advantage of module Path vs just turning os.path into a class? (except that people already import from os.path, so I suppose it would need to be os.Path) (2) It sounds like quite a few stdlib calls will be both deprecated and wrapped. Having a new stdlib module rely on deprecated features leaves a bad taste. Perhaps move the functionality to the Path class and then forward from the current (about to be deprecated) modules? -jJ ___ 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] [Doc-SIG] that library reference, again
On 29 Dec 2005, at 23:13, Fredrik Lundh wrote: Robey Pointer wrote: [Fredrik Lundh] Really? Yes, really. Just out of curiosity (really -- not trying to jump into the flames) why not just use epydoc? If it's good enough for 3rd-party python libraries, isn't that just a small step from being good enough for the builtin libraries? but epydoc is a docstring-based format, right? I'm trying to put together a light-weight alternative to the markup used for, primarily, the current library reference. moving all of (or parts of) the reference documentation in to the library source code would be an alternative, of course [1], but that would basically mean starting over from scratch. I think that would be a good thing to do no matter what markup is used. It always irritates me when I do 'help(sys.something)' and get one line of ASCII art that's probably useful to the module author but nobody else. robey ___ 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] [Doc-SIG] that library reference, again
On 30 Dec 2005, at 18:29, Christopher Armstrong wrote: On 12/30/05, Robey Pointer [EMAIL PROTECTED] wrote: Just out of curiosity (really -- not trying to jump into the flames) why not just use epydoc? If it's good enough for 3rd-party python libraries, isn't that just a small step from being good enough for the builtin libraries? It's not really even good enough for a lot of my usage without some seriously evil hacks. The fundamental design decision of epydoc to import code, plus some other design decisions on the way it figures types and identity seriously hinder its utility. Ever notice how trying to document your third-party-library-using application will *also* document that third party library, for example? Or how it'll blow up when you're trying to document your gtk-using application on a remote server without an X server running? Or how it just plain blows right up with most Interface systems? etc. Err... no, I haven't. But I may be using a more recent version than you were (I'm using 2.1). It's not perfect, and occasionally annoying, but much better than anything else I've found. Sounds like there's some political reason it's hated, but thought I would bring it up anyway. robey ___ 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
