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 ste
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 jus
[Thomas Wouters]
> ...
> I'd need developer access back to check it in, though.
AFAICT, twouters has developer access to the Python project --
although maybe someone else re-enabled that w/o mentioning it here.
> Unless anyone objects, of course :)
Of course I object! I bow to the group will, t
(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 deprecate
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
* C
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
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 buildbo
On Thu, 26 Jan 2006, Thomas Heller wrote:
[...]
> 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 t
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 the
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, endia
any progress ? does the script work in the buildbot setting, or
does it need tweaking ?
> > 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/som
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 wa
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
posixmodul
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'
>>>
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
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 wrot
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
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 tangent
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
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 consens
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 shou
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/
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
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 attri
on 26.01.2006 16:34 Aaron Bingham said the following:
> Stefan Rank wrote:
>> on 26.01.2006 14:15 Paul Moore said the following:
>> [snip]
>>
>>> Arguably, Path objects should always maintain an absolute path - there
>>> should be no such thing as a relative Path.
>>>
>> you realise that one might
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
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
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 an
Stefan Rank wrote:
>on 26.01.2006 14:15 Paul Moore said the following:
>[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 rela
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
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 th
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 latte
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 r
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.o
[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 practicali
On Thu, Jan 26, 2006 at 09:26:27AM +, Michael Hoffman wrote:
> [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.
> This is the s
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 c
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.
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 inheri
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 th
[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
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-d
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
>
43 matches
Mail list logo
