On Wed, Dec 14, 2011 at 17:33, Tres Seaver wrote:
> Not in the experience of the folks who are actually doing that task: the
> overhead of running 2to3 every time 'setup.py develop' etc. runs dooms
> the effort. For instance, we have a report that the 2to3 step takes more
> than half an hour (on
"Martin v. Löwis", 14.12.2011 22:20:
Am 14.12.2011 20:41, schrieb Stefan Behnel:
"Martin v. Löwis", 14.12.2011 19:14:
Am 12.12.2011 10:04, schrieb Stefan Behnel:
"Martin v. Löwis", 11.12.2011 23:39:
I can't recall anyone working on any substantial improvements
during the
last six years or so,
Am 14.12.2011 20:41, schrieb Stefan Behnel:
> "Martin v. Löwis", 14.12.2011 19:14:
>> Am 12.12.2011 10:04, schrieb Stefan Behnel:
>>> "Martin v. Löwis", 11.12.2011 23:39:
> I can't recall anyone working on any substantial improvements
> during the
> last six years or so, and the reason
On 12/14/2011 2:26 PM, Petri Lehtinen wrote:
The problem boils down to the fact that you cannot really check
whether a filesystem entry is a directory without calling stat() or
fstat().
My personal opinion is that support for DONT_HAVE_STAT and
DONT_HAVE_FSTAT defines should be dropped because
Xavier Morel, 14.12.2011 20:54:
On 2011-12-14, at 20:41 , Stefan Behnel wrote:
I meant: "lack of interest in improving them". It's clear from the
discussion that there are still users and that new code is still being
written that uses MiniDOM. However, I would argue that this cannot
possibly be
On 2011-12-14, at 20:41 , Stefan Behnel wrote:
> I meant: "lack of interest in improving them". It's clear from the discussion
> that there are still users and that new code is still being written that uses
> MiniDOM. However, I would argue that this cannot possibly be performance
> critical cod
> It's 99% definite that I can't compile further without touching the
> source code. I have to #define my own PYOS_whatever and handle files in
> my own way. In that case where should my special file handling cases go?
It's difficult to say how to proceed. On one hand, I don't see an
overwhelming
"Martin v. Löwis", 14.12.2011 19:14:
Am 12.12.2011 10:04, schrieb Stefan Behnel:
"Martin v. Löwis", 11.12.2011 23:39:
I can't recall anyone working on any substantial improvements during the
last six years or so, and the reason for that seems obvious to me.
What do you think is the reason? It
Hossein wrote:
> Hi. I just started to port latest python 2.7.2 to another platform
> (don't think you're eager to know... well it's CASIO ClassPad).
> And I faced a "minor" problem... It hasn't got stat or fstat or
> anything. (It supports a very limited set of c std lib).
> As pyport.c suggested,
Hi. I just started to port latest python 2.7.2 to another platform
(don't think you're eager to know... well it's CASIO ClassPad).
And I faced a "minor" problem... It hasn't got stat or fstat or
anything. (It supports a very limited set of c std lib).
As pyport.c suggested, i defined both DONT_HA
> Just look through the xml-sig page, basically all requests regarding
> PyXML during the last five years deal with problems in installing it,
> i.e. *before* even starting to use it. So you can't use this to claim
> that people really *are* still using it.
I'm not so sure. In many of these cases,
Am 12.12.2011 10:04, schrieb Stefan Behnel:
> "Martin v. Löwis", 11.12.2011 23:39:
>>> I can't recall anyone working on any substantial improvements during the
>>> last six years or so, and the reason for that seems obvious to me.
>>
>> What do you think is the reason? It's not at all obvious to me
"Martin v. Löwis", 14.12.2011 18:23:
overhead of running 2to3 every time 'setup.py develop' etc. runs dooms
the effort.
How so? Running 2to3 after every change is very fast. I never use
setup.py develop, though.
I think the problem starts with the fact that it needs to be run in the
first pl
>> And 2to3 is a good approach to maintaining a common code base.
>
>
> Not in the experience of the folks who are actually doing that task:
Well, I personally actually *did* the task, so that experience certainly
isn't universal.
> the
> overhead of running 2to3 every time 'setup.py develop' e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/2011 04:15 AM, "Martin v. Löwis" wrote:
>> It's "pure" in being optimized for a world where you just stop
>> using Python 2 one day, and start using 3 the next, without any
>> crossover support.
>
> That's not true. 2to3 is well suited for s
On Tue, 13 Dec 2011 23:51:00 -0500
Terry Reedy wrote:
> So by analogy, reserved type value would be ignored, neither corrupting
> data or raising errors, until put in use.
That simply doesn't make sense.
Regards
Antoine.
___
Python-Dev mailing list
> > In effect, 2to3 is a "purity" solution, but
> > six is more like a "practicality" solution.
>
> This sounds like your personal interpretation. I see nothing "pure" in
> 2to3.
>
>
> It's "pure" in being optimized for a world where you just stop using
> Python 2 one day, and st
Le mardi 13 décembre 2011 02:09:02 Jim Jewett a écrit :
> (3) I would feel much less nervous if the remaining 4 values of
> PyUnicode_Kind were explicitly reserved, and the macros raised an
> error when they showed up. (Better still would be to allow other
> values, and to have the macros delegat
18 matches
Mail list logo
