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
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 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
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 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
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.
-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
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
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
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
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
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
==
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 +++
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 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 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
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
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
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
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
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
> 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
> 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
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
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
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: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
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
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
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
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: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
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
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
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
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
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 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
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
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
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.
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
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
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
> 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
> 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
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
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 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 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 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 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
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: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of M.-A.
Lemburg
Se
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
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
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
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
>> 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
60 matches
Mail list logo
