>> BTW: there is another implementation (called my_strdup) in
>> Modules/_ctypes/_ctypes_test.c, why not use the one in Python/strdup.c there?
>
> I guess that's historical, from the times when ctypes was still a
> separate package.
my_strdup is an exported function in _ctypes_test.pyd (on Windo
On Wednesday 07 January 2009 16:30:23 Daniel Stutzbach wrote:
> On Wed, Jan 7, 2009 at 5:30 AM, Ulrich Eckhardt wrote:
> > MS Windows CE doesn't provide strdup(), so where should I put it? I guess
> > I should just compile in Python/strdup.c, right?
>
> I'm not an expert on Windows CE, but I belie
On 2009-01-08 01:01, Collin Winter wrote:
> On Wed, Jan 7, 2009 at 2:35 PM, Brett Cannon wrote:
>> On Wed, Jan 7, 2009 at 10:57, M.-A. Lemburg wrote:
>> [SNIP]
>>> BTW: The _codecsmodule.c file is a 4 spaces indent file as well (just
>>> like all Unicode support source files). Someone apparently
From: "M.-A. Lemburg"
The question to put up against this is: How often do you get
irritated by lines not being correctly indented ?
Basically never.
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/
Le Thursday 08 January 2009 10:48:53 M.-A. Lemburg, vous avez écrit :
> svn blame -x "-b" will do the trick for SVN. Perhaps there's even
> some .subversion/config option to set this globally.
>
> The question really is: How often do Python developers use svn blame ?
I use "svn blame" to find a re
Oh dear. C code indented by spaces?
I'll give up programming then.
Just set your editor tab size to 4 and all is well.
K
-Original Message-
From: [email protected]
[mailto:[email protected]] On Behalf Of M.-A.
Lemburg
Se
On 2009-01-08 12:36, Kristján Valur Jónsson wrote:
> Oh dear. C code indented by spaces?
> I'll give up programming then.
> Just set your editor tab size to 4 and all is well.
I know this is flame bait, but TABs are 8 spaces in Python land :-)
and most C files in Python that contain TABs and mix t
On Sat, Jan 3, 2009 at 11:22 PM, Luke Kenneth Casson Leighton
wrote:
> secondly, i want a python25.lib which i can use to cross-compile
> modules for poor windows users _despite_ sticking to my principles and
> keeping my integrity as a free software developer.
If this eventually leads to being a
On Thu, Jan 8, 2009 at 9:42 PM, Simon Cross
wrote:
> On Sat, Jan 3, 2009 at 11:22 PM, Luke Kenneth Casson Leighton
> wrote:
>> secondly, i want a python25.lib which i can use to cross-compile
>> modules for poor windows users _despite_ sticking to my principles and
>> keeping my integrity as a fr
On Thu, Jan 8, 2009 at 12:42 PM, Simon Cross
wrote:
> On Sat, Jan 3, 2009 at 11:22 PM, Luke Kenneth Casson Leighton
> wrote:
>> secondly, i want a python25.lib which i can use to cross-compile
>> modules for poor windows users _despite_ sticking to my principles and
>> keeping my integrity as a f
On Thu, Jan 8, 2009 at 1:11 PM, David Cournapeau wrote:
> On Thu, Jan 8, 2009 at 9:42 PM, Simon Cross
> wrote:
>> On Sat, Jan 3, 2009 at 11:22 PM, Luke Kenneth Casson Leighton
>> wrote:
>>> secondly, i want a python25.lib which i can use to cross-compile
>>> modules for poor windows users _despi
On Thu, Jan 8, 2009 at 11:02 PM, Luke Kenneth Casson Leighton
wrote:
> On Thu, Jan 8, 2009 at 1:11 PM, David Cournapeau wrote:
>> On Thu, Jan 8, 2009 at 9:42 PM, Simon Cross
>> wrote:
>>> On Sat, Jan 3, 2009 at 11:22 PM, Luke Kenneth Casson Leighton
>>> wrote:
secondly, i want a python25.l
> anyway, i'm floundering around a bit and making a bit of a mess of the
> code, looking for where LONG_MAX is messing up.
fixed with this:
PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
if ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
{
return PyInt_FromLong((l
> next bug: distutils.sysconfig.get_config_var('srcdir') is returning None (!!)
ok ... actually, that's correct. oops.
sysconfig.get_config_vars() only returns these, on win32:
{'EXE': '.exe', 'exec_prefix': 'Z:\\mnt\\src\\python2.5-2.5.2',
'LIBDEST': 'Z:\\mnt\\src\\python2.5-2.5.2\\Lib', 'pr
I'd like to suggest some improvements from mmap
1) mmap assign to slice only accepts a string. This is unfortunate, because
AFAIK a string can only be created by copying data, and this is wasteful for
large data transfers. mmap should accept any object supporting buffer protocol
as well as st
Neal Becker wrote:
> I'd like to suggest some improvements from mmap
>
> 1) mmap assign to slice only accepts a string. This is unfortunate, because
> AFAIK a string can only be created by copying data, and this is wasteful for
> large data transfers. mmap should accept any object supporting b
On Wed, Jan 07, 2009, Daniel Stutzbach wrote:
>
> After reading "What's New in Python 2.6" and then upgrading, I quickly
> noticed an omission: string exceptions are no longer supported and raise a
> TypeError.
Please file a report on bugs.python.org so it doesn't get lost -- it's
already Thursday
On Thu, Jan 8, 2009 at 10:33 AM, Aahz wrote:
> On Wed, Jan 07, 2009, Daniel Stutzbach wrote:
> > After reading "What's New in Python 2.6" and then upgrading, I quickly
> > noticed an omission: string exceptions are no longer supported and raise
> a
> > TypeError.
>
> Please file a report on bugs.
One problem is that API wrappers like this sometimes include extra
functionality. When I ran across this example, I wondered whether the
Python interface had been enhanced to work like this
# set these three flags
rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NDELAY)
rv = fcntl.fcntl(f, fcn
Unless documented otherwise, the Python wrappers for system calls are
as low-level as possible, sticking as close to the system call
semantics as possible.
I do think you may be reading too much into the whole thing.
On Thu, Jan 8, 2009 at 9:05 AM, Mike Coleman wrote:
> One problem is that API w
On Thu, Jan 8, 2009 at 01:52, Raymond Hettinger wrote:
> From: "M.-A. Lemburg"
>>
>> The question to put up against this is: How often do you get
>> irritated by lines not being correctly indented ?
>
> Basically never.
And of course I am the polar opposite: frequently enough that I want
to see
On Thu, Jan 8, 2009 at 10:29 AM, Brett Cannon wrote:
> On Thu, Jan 8, 2009 at 01:52, Raymond Hettinger wrote:
>> From: "M.-A. Lemburg"
>>>
>>> The question to put up against this is: How often do you get
>>> irritated by lines not being correctly indented ?
>>
>> Basically never.
>
> And of cour
On Thu, Jan 8, 2009 at 10:41, Guido van Rossum wrote:
> On Thu, Jan 8, 2009 at 10:29 AM, Brett Cannon wrote:
>> On Thu, Jan 8, 2009 at 01:52, Raymond Hettinger wrote:
>>> From: "M.-A. Lemburg"
The question to put up against this is: How often do you get
irritated by lines not bei
My work rewriting import in pure Python code has reached beta.
Basically the code is semantically complete and as
backwards-compatible as I can make it short of widespread testing or
running on a Windows box. There are still some tweaks here and there I
want to make and an API to expose, but __impo
So it turns out that if you try to do a relative import where a parent
is not loaded, it raises a SystemError. This has been in there since
Guido added package support back in the day. But this seems more like
an ImportError than a SystemError to me. My guess is that the original
purpose was to sig
2009/1/8 Brett Cannon :
> My work rewriting import in pure Python code has reached beta.
> Basically the code is semantically complete and as
> backwards-compatible as I can make it short of widespread testing or
> running on a Windows box.
I should have done this earlier, sorry. A quick test on W
On Thu, Jan 8, 2009 at 11:25 AM, Brett Cannon wrote:
> So it turns out that if you try to do a relative import where a parent
> is not loaded, it raises a SystemError. This has been in there since
> Guido added package support back in the day. But this seems more like
> an ImportError than a Syste
On Thu, Jan 8, 2009 at 11:26, Paul Moore wrote:
> 2009/1/8 Brett Cannon :
>> My work rewriting import in pure Python code has reached beta.
>> Basically the code is semantically complete and as
>> backwards-compatible as I can make it short of widespread testing or
>> running on a Windows box.
>
>
On Thu, Jan 8, 2009 at 11:33, Guido van Rossum wrote:
> On Thu, Jan 8, 2009 at 11:25 AM, Brett Cannon wrote:
>> So it turns out that if you try to do a relative import where a parent
>> is not loaded, it raises a SystemError. This has been in there since
>> Guido added package support back in the
Brett Cannon wrote:
> One, does anyone have issues if I check in importlib? We have
> typically said code has to have been selected as best-of-breed by the
> community first, so I realize I am asking for a waiver on this one.
That rule has never really applied to things that are part of the
interp
Brett Cannon wrote:
> Can we then all agree that a policy of re-indenting per function as
> changes are made to the code is acceptable but not required?
Such a rule would certainly make *my* life a lot easier - the reason I
find the tabs annoying is because I have my editor set to switch
everythin
On Thu, Jan 8, 2009 at 12:43, Nick Coghlan wrote:
> Brett Cannon wrote:
>> Can we then all agree that a policy of re-indenting per function as
>> changes are made to the code is acceptable but not required?
>
> Such a rule would certainly make *my* life a lot easier - the reason I
> find the tabs
2009/1/8 Brett Cannon :
> Thanks, Paul! I changed it to _os.getcwd() since that's what nt exposes.
Ta. I wasn't sure _os.getcwd() returned a full pathname.
The only difference between the importlib results and the normal ones
seems to be that with importlib, test_multiprocessing is skipped,
where
On Thu, Jan 8, 2009 at 12:35, Nick Coghlan wrote:
> Brett Cannon wrote:
>> One, does anyone have issues if I check in importlib? We have
>> typically said code has to have been selected as best-of-breed by the
>> community first, so I realize I am asking for a waiver on this one.
>
> That rule has
On Thu, Jan 8, 2009 at 12:57, Paul Moore wrote:
> 2009/1/8 Brett Cannon :
>> Thanks, Paul! I changed it to _os.getcwd() since that's what nt exposes.
>
> Ta. I wasn't sure _os.getcwd() returned a full pathname.
>
> The only difference between the importlib results and the normal ones
> seems to be
> i'd just ... much rather be completely independent of proprietary
> software when it comes to building free software.
I guess my question is then: why do you want to use Windows in the
first place?
Regards,
Martin
___
Python-Dev mailing list
Python-D
> Is there any reason not to change this?
Apart from the effort it makes to talk about it, and to review and
apply the patch? No.
Regards,
Martin
P.S. You really do need to trust that the system calls get forwarded by
Python to the system as-is, with no additional trickery. If there is
additiona
On Thu, Jan 8, 2009 at 3:57 PM, Paul Moore wrote:
> 2009/1/8 Brett Cannon :
>> Thanks, Paul! I changed it to _os.getcwd() since that's what nt exposes.
>
> Ta. I wasn't sure _os.getcwd() returned a full pathname.
>
> The only difference between the importlib results and the normal ones
> seems to
Brett Cannon python.org> writes:
>
> One, does anyone have issues if I check in importlib? We have
> typically said code has to have been selected as best-of-breed by the
> community first, so I realize I am asking for a waiver on this one.
Have you tried to assess its interaction with setuptool
Brett Cannon wrote:
> On Thu, Jan 8, 2009 at 12:35, Nick Coghlan wrote:
>> Brett Cannon wrote:
>>> One, does anyone have issues if I check in importlib? We have
>>> typically said code has to have been selected as best-of-breed by the
>>> community first, so I realize I am asking for a waiver on t
On Thu, Jan 8, 2009 at 13:14, Antoine Pitrou wrote:
> Brett Cannon python.org> writes:
>>
>> One, does anyone have issues if I check in importlib? We have
>> typically said code has to have been selected as best-of-breed by the
>> community first, so I realize I am asking for a waiver on this one
Handle config args for libffi, for cross compilation.
Signed-off-by: Robert Schwebel
---
Makefile.pre.in |2 ++
setup.py|4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
Index: Python-3.0/setup.py
===
--- P
When cross compiling we need a PYTHON_FOR_BUILD, PGEN_FOR_BUILD etc. The
names follow usual autotool nomenclatures.
Patch is originally from here:
http://bugs.gentoo.org/attachment.cgi?id=130627
and was ported to Python 3.0rc2
Signed-off-by: Robert Schwebel
---
Makefile.pre.in | 116
Add a CROSS_COMPILING=yes variable in order to tell setup.py that we are
cross compiling.
Signed-off-by: Robert Schwebel
---
setup.py | 46 --
1 file changed, 36 insertions(+), 10 deletions(-)
Index: Python-3.0/setup.py
When cross compiling, AC_TRY_RUN should not be used. This patch fixes it
in a way that for a cross scenario the test can be overwritten on the
command line.
Signed-off-by: Robert Schwebel
---
configure.in | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
Index: P
If cross compiling it must be possible to overwrite the so_ext from the
outside.
Signed-off-by: Robert Schwebel
---
Lib/distutils/command/build_ext.py |2 ++
1 file changed, 2 insertions(+)
Index: Python-3.0/Lib/distutils/command/build_ext.py
===
When cross compiling, AC_TRY_RUN should not be used. This patch fixes it
in a way that for a cross scenario the test can be overwritten on the
command line.
Signed-off-by: Robert Schwebel
---
configure.in | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
Index: P
Add the necessary bits for feeding PYTHON_FOR_BUILD into the python
build process.
Patch is originally from here, adapted to python 3.0rc2:
http://bugs.gentoo.org/attachment.cgi?id=130627
Signed-off-by: Robert Schwebel
---
configure.in | 90 +++
This patch is originally from here:
http://bugs.gentoo.org/attachment.cgi?id=130627
Add documentation for cross compilation scenario.
Signed-off-by: Robert Schwebel
---
README | 44
1 file changed, 44 insertions(+)
Index: Python-3.0/README
==
Embedded people have cross compiled python for quite some time now, with
more or less success. These activities have taken place in various
embedded build systems, such as PTXdist, OpenEmbedded and others.
I suppose instead of wasting the time over and over again, without
proper review by the Pyt
Robert Schwebel pengutronix.de> writes:
>
> If cross compiling it must be possible to overwrite the so_ext from the
> outside.
Thanks for those patches, but please post them to the issue tracker instead
(http://bugs.python.org/). If each patch is for a distinct purpose, then open
separate issues
On Thu, Jan 8, 2009 at 13:21, Nick Coghlan wrote:
> Brett Cannon wrote:
>> On Thu, Jan 8, 2009 at 12:35, Nick Coghlan wrote:
>>> Brett Cannon wrote:
One, does anyone have issues if I check in importlib? We have
typically said code has to have been selected as best-of-breed by the
c
2009/1/8 Nick Coghlan :
>> Well, it's not part of the interpreter yet. That can be viewed as a
>> separate step.
>
> True, but what you're doing here can be viewed as the continuation of
> the original implementation plan for PEP 302 - it was always intended
> that every module would eventually get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
>> i'd just ... much rather be completely independent of proprietary
>> software when it comes to building free software.
>
> I guess my question is then: why do you want to use Windows in the
> first place?
My guess is that L
The O'Reilly Open Source Convention has opened up the Call For
Participation -- deadline for proposals is Tuesday Feb 3.
OSCON will be held July 20-24 in San Jose, California.
For more information, see
http://conferences.oreilly.com/oscon
http://en.oreilly.com/oscon2009/public/cfp/57
--
Aahz (a.
On Thu, Jan 8, 2009 at 2:52 PM, Brett Cannon wrote:
> On Thu, Jan 8, 2009 at 12:43, Nick Coghlan wrote:
>>
>> Even if we do adopt such a rule, C patches posted to the tracker should
>> still try to avoid including pure whitespace changes though - leaving
>> the whitespace changes in the patch ten
On Thu, Jan 8, 2009 at 17:31, Benjamin Peterson wrote:
> On Thu, Jan 8, 2009 at 2:52 PM, Brett Cannon wrote:
>> On Thu, Jan 8, 2009 at 12:43, Nick Coghlan wrote:
>>>
>>> Even if we do adopt such a rule, C patches posted to the tracker should
>>> still try to avoid including pure whitespace chang
On Thu, Jan 8, 2009 at 7:39 PM, Brett Cannon wrote:
> On Thu, Jan 8, 2009 at 17:31, Benjamin Peterson wrote:
>> On Thu, Jan 8, 2009 at 2:52 PM, Brett Cannon wrote:
>>> On Thu, Jan 8, 2009 at 12:43, Nick Coghlan wrote:
Even if we do adopt such a rule, C patches posted to the tracker sh
I realize assert() is compiled out except in debug builds, but the assert in
the while loop following the fast_block_end label in ceval.c seems
misleading. It looks like it should be hoisted out of the loop and only
checked before entering the loop. There are no jumps into the loop. why is
not a
On Thu, Jan 8, 2009 at 17:42, Benjamin Peterson wrote:
> On Thu, Jan 8, 2009 at 7:39 PM, Brett Cannon wrote:
>> On Thu, Jan 8, 2009 at 17:31, Benjamin Peterson wrote:
>>> On Thu, Jan 8, 2009 at 2:52 PM, Brett Cannon wrote:
On Thu, Jan 8, 2009 at 12:43, Nick Coghlan wrote:
>
> Even
60 matches
Mail list logo
