Re: [Python-Dev] a few strdup() questions...

[Thomas Heller]

>> 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 Windows),
it is only used in the ctypes tests.

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] a few strdup() questions...

[Ulrich Eckhardt]

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 believe it calls the function
> "_strdup()":
>
> http://msdn.microsoft.com/en-us/library/ms861162.aspx

Search with "Look in VC Include Directories" yields nothing. You are right 
though, the CE6 SDK I have does declare _strdup in stdlib.h and also provides 
an implementation to link with.

Summary: redefine strdup and work around the broken search feature.

thanks

Uli
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[M.-A. Lemburg]

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 has added
>>> tabs when adding support for Py_buffers.
>>>
>> It looks like this formatting mix-up is just going to get worse for
>> the next few years while the 2.x series is still being worked on.
>> Should we just bite the bullet and start adding modelines for Vim and
>> Emacs to .c/.h files that are written in the old 2.x style? For Vim I
>> can then update the vimrc in Misc/Vim to then have 4-space indent be
>> the default for C files.
> 
> Or better yet, really bite the bullet and just reindent everything to
> spaces. Not every one uses vim or emacs, nor do all tools understand
> their modelines. FYI, there are options to svn blame and git to skip
> whitespace-only changes.

+1... and this should be done for both trunk and the 3.x branch
in a single checkin to resync them.

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 ?

If this is only done for a file or two every now and then, I don't
think that adding the above option to the command would be much
to ask for.

The question to put up against this is: How often do you get
irritated by lines not being correctly indented ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 08 2009)
>>> 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 our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Raymond Hettinger]

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/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Victor Stinner]

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 revision number but then I read the commit. There 
are not only spaces changes, sometimes a newline is inserted, or a function 
is just moved, or...

> The question to put up against this is: How often do you get
> irritated by lines not being correctly indented ?

Regulary when I work on patches. Some files in Modules/*c mix spaces and 
tabs :-/ I would prefer spaces everywhere or tabs everywhere, but please 
don't mix both.

--

I also hate trailing spaces. My editor is configured to remove them and so I 
have to use >svn diff --diff-cmd="/usr/bin/diff" -x "-ub"< to ignore any 
space change, which break some patches :-/ So if you choose to change the 
indentation, i would be nice to run also >sed "s/[ \t]\+$//g -i/< ;-)

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Kristján Valur Jónsson]

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
Sent: 8. janúar 2009 09:49
To: Collin Winter
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] Fixing incorrect indentations in C files (Decoder 
functions accept str in py3k)
> Or better yet, really bite the bullet and just reindent everything to
> spaces. Not every one uses vim or emacs, nor do all tools understand
> their modelines. FYI, there are options to svn blame and git to skip
> whitespace-only changes.

+1... and this should be done for both trunk and the 3.x branch
in a single checkin to resync them.

___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[M.-A. Lemburg]

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 them with
spaces rely on this.

BTW: I don't blame anyone for the mixup - some editors simple
go ahead and convert 8 spaces leading whitespace into TABs
without the user knowing about this... after all, white on white
looks all white in the end ;-) (there are even some steganographic
systems out there, applying this scheme to embed data into
text files).

In any case, I think I need to remind people of PEP 7: Style Guide
for C Code ...

http://www.python.org/dev/peps/pep-0007/

It already says: "At some point, the whole codebase may be
converted to use only 4-space indents."

> 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
> Sent: 8. janúar 2009 09:49
> To: Collin Winter
> Cc: Antoine Pitrou; python-dev@python.org
> Subject: Re: [Python-Dev] Fixing incorrect indentations in C files (Decoder 
> functions accept str in py3k)
>> Or better yet, really bite the bullet and just reindent everything to
>> spaces. Not every one uses vim or emacs, nor do all tools understand
>> their modelines. FYI, there are options to svn blame and git to skip
>> whitespace-only changes.
> 
> +1... and this should be done for both trunk and the 3.x branch
> in a single checkin to resync them.
> 
> ___
> 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/mal%40egenix.com

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 08 2009)
>>> 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 our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] compiling python2.5 on linux under wine

[Simon Cross]

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 able to compile Python software for
Windows under Wine (using for example, py2exe) it would make my life a
lot easier.

Schiavo
Simon
___
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] compiling python2.5 on linux under wine

[David Cournapeau]

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 free software developer.
>
> If this eventually leads to being able to compile Python software for
> Windows under Wine (using for example, py2exe) it would make my life a
> lot easier.

You can already do that: just install windows python under wine. It
works quite well, actually. You need mingw, though, of course - Visual
Studio is far from being usable on wine.

cheers,

David
___
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] compiling python2.5 on linux under wine

[Luke Kenneth Casson Leighton]

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 free software developer.
>
> If this eventually leads to being able to compile Python software for
> Windows under Wine (using for example, py2exe) it would make my life a
> lot easier.

 that looks like being an accidental side-effect, yes.

 where i'm up to so far:

 * i'm using -I $(src_dir)/PC at the beginning of the includes, so
that PC/pyconfig.h gets pulled in as a priority over-and-above the
auto-generated pyconfig.h (yukkk - i know); this makes the job of
building almost-exactly-like-the-visual-studio-build much easier.

 * i'm manually compiling-linking the Modules/*.c and PC/*modules.c as
i also pulled in PC/config.c and left out Modules/config.c - that got
me even further

 * as a result i've actually got a python.exe.so that damnit, it
works!  the winreg test actually passes for example!

the fly in the ointment i'm presently trying to track down: len([1,2])
returns 1L which of course screws up sre_parse.py at line 515 with
"TypeError: __nonzero__ should return an int" because duh "if
subpattern" is returning a Long not an Int.

tracking this down further, it would appear that there's some lovely
logic in PyInt_FromSsize_t() which i believe is what's getting called
from PyInt_AsSsize_t() which is what's getting called from
slot_sq_length() (i think) - and, although in this case this build is
_definitely_ returning a Long type when it shouldn't, if the value is
ever over LONG_MAX then the result will be "if subpattern" will
definitely fail.

but... i mean... if ever anyone passes in over 2^^31 items into
sre_parse then they _deserve_ to have their code fail, but that's not
the point.

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.

l.

which of course means that there's a bug in
___
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] compiling python2.5 on linux under wine

[Luke Kenneth Casson Leighton]

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 _despite_ sticking to my principles and
>>> keeping my integrity as a free software developer.
>>
>> If this eventually leads to being able to compile Python software for
>> Windows under Wine (using for example, py2exe) it would make my life a
>> lot easier.
>
> You can already do that: just install windows python under wine.

 i tried that a few months ago - the builder requires the MS
installer, which segfaulted on my installation of wine (i installed it
using winetricks) which left me flummoxed because other people report
successful use of MSI.

 i also don't want "just" the python.exe, i want the libpython25.a, i
want the libpython25.lib, so as to be able to build libraries such as
pywekbit-gtk for win32 (cross-compiled using winegcc of course)

 unpacking the python installer .exe (which was, again, created with a
proprietary program) i found that all of the contents were
name-mangled and so were useless: i wasn't about to work my way
through nearly a hundred files, manually, when i can just as well get
python compiling under wine once and then stand a good chance of being
able to repeat the exercise in the future, also for python 2.6.

 so, basically, i really don't want to use visual studio, i really
don't want to install a proprietary MSI installer, i really don't want
a proprietarily-built python25.exe, and i really don't want a
proprietarily-packed installation.

 i'd just ... much rather be completely independent of proprietary
software when it comes to building free software.

  onwards :)
___
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] compiling python2.5 on linux under wine

[David Cournapeau]

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.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 able to compile Python software for
>>> Windows under Wine (using for example, py2exe) it would make my life a
>>> lot easier.
>>
>> You can already do that: just install windows python under wine.
>
>  i tried that a few months ago - the builder requires the MS
> installer, which segfaulted on my installation of wine (i installed it
> using winetricks) which left me flummoxed because other people report
> successful use of MSI.
>

Hm, I could definitely install python - I have python in wine ATM.

wine python -c 'import sys; print sys.version' -> 2.5.2 (r252:60911,
Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]

IIRC, I could build numpy on it, which is far from a trivial package
from a build POV :) I think it crashes on wine, though - which I why I
did not pursued it so far. But I believe python itself at least is
usable in wine, depending on what you are trying to do.

David
___
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] compiling python2.5 on linux under wine

[Luke Kenneth Casson Leighton]

> 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((long)ival);
}
return _PyLong_FromSsize_t(ival);
}

raised as http://bugs.python.org/issue4880


next bug: distutils.sysconfig.get_config_var('srcdir') is returning None (!!)
___
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] compiling python2.5 on linux under wine

[Luke Kenneth Casson Leighton]

> 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', 'prefix':
'Z:\\mnt\\src\\python2.5-2.5.2', 'SO': '.pyd', 'BINLIBDEST':
'Z:\\mnt\\src\\python2.5-2.5.2\\Lib', 'INCLUDEPY':
'Z:\\mnt\\src\\python2.5-2.5.2\\include'}

 ... nd, that means disabling setup.py or hacking it significantly
to support a win32 build, e.g. to build pyexpat, detect which modules
are left, etc. by examining the remaining vcproj files in PCbuild.

  ok - i'm done for now.

 the project's not complete, but can be regarded as successful so far.
 i think the best thing is being able to do "import _winreg" on a
linux system.  that absolutely tickles me silly :)

been running a few tests  - test_mmap.py is a hoot, esp. the Try
opening a bad file descriptor... that causes a wine segfault.

if anyone wants to play with this further, source is here:

   http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine

at some point - if i feel like taking this further, and if people
offer some advice and hints on where to go (with e.g. setup.py) i'll
continue.

 then once that's done i'll do python 2.6 as well.

 l.
___
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] improvements for mmap

[Neal Becker]

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 string.

2) buffer (mmap_obj) gives a read_only buffer.  There should be a way to make 
this read_write.

3) mmap_obj does not support weak ref.

___
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] improvements for mmap

[Steve Holden]

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 buffer 
> protocol as well as string.
> 
> 2) buffer (mmap_obj) gives a read_only buffer.  There should be a way to make 
> this read_write.
> 
> 3) mmap_obj does not support weak ref.
> 
Can you add these to the tracker as a feature request, please?

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
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] What's New in Python 2.6: no string exceptions

[Aahz]

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 with no response.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."  --Brian W. Kernighan
___
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] What's New in Python 2.6: no string exceptions

[Daniel Stutzbach]

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.python.org so it doesn't get lost -- it's
> already Thursday with no response.


Benjamin Peterson sent me a private email stating that he added some text
and checked it in as r68388.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] error in doc for fcntl module

[Mike Coleman]

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, fcntl.F_SETFL, os.O_APPEND)
rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NOATIME)

Something like this might be nice, but after staring at it for another
minute, I realized that the Python interface itself was standard, and
that it was the example itself that was confusing me.  (I've been
programming Unix/POSIX for over 20 years, so perhaps I simply
outsmarted myself, or am an idiot.  Still, I found it confusing.)

One of the many virtues of Python is that it's oriented towards
learning/teaching.  It seems like it would be useful in this case to
have an example that shows best practice (as in Stevens/Rago and other
similar texts), rather than one that will merely usually work on
present systems.

If it makes any difference, I'd be happy to send a patch.  Is there
any reason not to change this?

Mike



On Wed, Jan 7, 2009 at 6:36 PM, Guido van Rossum  wrote:
> Well my Linux man page says that the only flags supported are
> O_APPEND,  O_ASYNC,  O_DIRECT, O_NOATIME, and O_NONBLOCK; and all of
> those are typically off -- so I'm not sure that it's a mistake or need
> correcting. These APIs should only be used by people who know what
> they're doing anyways; the examples are meant to briefly show the call
> format.
>
> On Wed, Jan 7, 2009 at 1:31 PM, Mike Coleman  wrote:
>> In the doc page for the fcntl module, the example below is given.
>> This seems like an error, or at least very misleading, as the normal
>> usage is to get the flags (F_GETFL), set or unset the bits you want to
>> change, then set the flags (F_SETFL).  A reader might think that the
>> example below merely sets O_NDELAY, but it also stomps all of the
>> other bits to zero.
>>
>> If someone can confirm my thinking, this ought to be changed.
>>
>> import struct, fcntl, os
>>
>> f = open(...)
>> rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NDELAY)
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
___
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] error in doc for fcntl module

[Guido van Rossum]

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 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, fcntl.F_SETFL, os.O_APPEND)
>rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NOATIME)
>
> Something like this might be nice, but after staring at it for another
> minute, I realized that the Python interface itself was standard, and
> that it was the example itself that was confusing me.  (I've been
> programming Unix/POSIX for over 20 years, so perhaps I simply
> outsmarted myself, or am an idiot.  Still, I found it confusing.)
>
> One of the many virtues of Python is that it's oriented towards
> learning/teaching.  It seems like it would be useful in this case to
> have an example that shows best practice (as in Stevens/Rago and other
> similar texts), rather than one that will merely usually work on
> present systems.
>
> If it makes any difference, I'd be happy to send a patch.  Is there
> any reason not to change this?
>
> Mike
>
>
>
> On Wed, Jan 7, 2009 at 6:36 PM, Guido van Rossum  wrote:
>> Well my Linux man page says that the only flags supported are
>> O_APPEND,  O_ASYNC,  O_DIRECT, O_NOATIME, and O_NONBLOCK; and all of
>> those are typically off -- so I'm not sure that it's a mistake or need
>> correcting. These APIs should only be used by people who know what
>> they're doing anyways; the examples are meant to briefly show the call
>> format.
>>
>> On Wed, Jan 7, 2009 at 1:31 PM, Mike Coleman  wrote:
>>> In the doc page for the fcntl module, the example below is given.
>>> This seems like an error, or at least very misleading, as the normal
>>> usage is to get the flags (F_GETFL), set or unset the bits you want to
>>> change, then set the flags (F_SETFL).  A reader might think that the
>>> example below merely sets O_NDELAY, but it also stomps all of the
>>> other bits to zero.
>>>
>>> If someone can confirm my thinking, this ought to be changed.
>>>
>>> import struct, fcntl, os
>>>
>>> f = open(...)
>>> rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NDELAY)
>>
>> --
>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Brett Cannon]

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 this fixed.

-Brett
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Guido van Rossum]

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 course I am the polar opposite: frequently enough that I want
> to see this fixed.

I'm in the middle -- I don't mind so much if some parts of a file are
indented using a different style than other parts. But I am adamant
that local misalignment is horrible. Since mixing tabs and spaces
within one function is bound to lead to local misalignments (either
for the folks who set their tabs at 4 or for the folks who set them at
8, as God intended), I want at least within each function the
indentation to be all spaces or all tabs. (And yes, the convention of
implementing 4-position indents using tabs followed by 4 spaces for
odd indents is evil, as it looks horrible for folks whose tabs are set
to 4.)

Long term (sorry Kristján :-) I prefer 4 spaces per indent level, but
not enough to reindent everything. svn blame may have a way to ignore
whitespace changes, but it's still a pain to deal with.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Brett Cannon]

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 being correctly indented ?
>>>
>>> Basically never.
>>
>> And of course I am the polar opposite: frequently enough that I want
>> to see this fixed.
>
> I'm in the middle -- I don't mind so much if some parts of a file are
> indented using a different style than other parts. But I am adamant
> that local misalignment is horrible. Since mixing tabs and spaces
> within one function is bound to lead to local misalignments (either
> for the folks who set their tabs at 4 or for the folks who set them at
> 8, as God intended), I want at least within each function the
> indentation to be all spaces or all tabs. (And yes, the convention of
> implementing 4-position indents using tabs followed by 4 spaces for
> odd indents is evil, as it looks horrible for folks whose tabs are set
> to 4.)
>

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?

-Brett
___
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] Getting importlib into the standard library for 3.1

[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. There are still some tweaks here and there I
want to make and an API to expose, but __import__ works as expected
when run as the import implementation for all unit tests.

Knowing how waiting for perfection leads to never finishing, I would
like to start figuring out what it will take to get the code added to
the standard library of 3.1 with hopes of getting the bootstrapping
stuff done so that the C implementation of import can go away in 3.1
as well. I see basically three things that need to be decided upfront.

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.

Two, what should the final name be? I originally went with importlib
since this code was developed outside of the trunk, but I can see some
people suggesting using the imp name. That's fine although that does
lead to the question of what to do with the current imp. It could be
renamed _imp, but then that means what is currently named _importlib
would have to be renamed to something else as well. Maybe
imp._bootstrap? Plus I always viewed imp as the place where really
low-level, C-based stuff lived. Otherwise importlib can slowly subsume
the stuff in imp that is still useful.

Three, there are still some structural changes to the code that I want
to make. I can hold off on checking in the code until these changes
are made, but as I said earlier, I know better than to wait forever
for perfection.

And because I know people will ask: no, I do not plan to backport all
the code to 2.7. I want this to be a carrot to people to switch to
3.x. But I will backport the import_module function I wrote to 2.7 so
people do have that oft-requested feature since it is a really simple
bit of Python code.

-Brett
___
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] Is raising SystemError during relative import the best solution?

[Brett Cannon]

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 signify someone specified some relative import name
without the proper stuff to make the name resolve to what it should
be. But that to me is still an ImportError as the name came out wrong,
not that the system did something incorrectly.

So I would like to propose to remove the SystemError and make it an
ImportError. Anyone object?

-Brett
___
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] Getting importlib into the standard library for 3.1

[Paul Moore]

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 Windows XP,
using the released Python 3.0 installer and a hacked regrtest.bat
(which is basically regrtest.sh converted to Windows bat file syntax)
gives:

>regrtest.bat \Apps\Python30\python.exe
Traceback (most recent call last):
  File "_importlib.py", line 836, in _import_module
loader = self._search_meta_path(name, path)
  File "_importlib.py", line 751, in _search_meta_path
raise ImportError("No module named %s" % name)
ImportError: No module named test

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "_importlib.py", line 1047, in __call__
self._import_full_module(name)
  File "_importlib.py", line 887, in _import_full_module
self._import_module(current_name, path_list)
  File "_importlib.py", line 840, in _import_module
loader = self._search_std_path(name, path)
  File "_importlib.py", line 798, in _search_std_path
importer = self._sys_path_importer(entry)
  File "_importlib.py", line 766, in _sys_path_importer
return self.default_path_hook(path_entry)
  File "_importlib.py", line 245, in chained_fs_path_hook
absolute_path = _path_absolute(path_entry)
  File "_importlib.py", line 112, in _path_absolute
return _os._getfullpathname(path)
WindowsError: [Error 2] The system cannot find the file specified: ''

Looks like ntpath._getfullpathname doesn't like an empty string as an
argument. The following patch seems to fix this:

--- _importlib.py.orig  2009-01-03 19:50:22.121422900 +
+++ _importlib.py   2009-01-08 19:23:06.21875 +
@@ -109,6 +109,8 @@
 def _path_absolute(path):
 """Replacement for os.path.abspath."""
 try:
+if path == '':
+return _os._getfullpathname(_os._getcwd())
 return _os._getfullpathname(path)
 except AttributeError:
 if path.startswith('/'):

I then get the following output:

>regrtest.bat \Apps\Python30\python.exe
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
test_unittest
test_doctest
test_doctest2
test_SimpleHTTPServer
test___all__
test___future__
test__locale
test__locale skipped -- cannot import name RADIXCHAR
test_abc
test_abstract_numbers
test_array
test_ast
test_asynchat
test_asyncore
test_atexit
test_audioop
test_augassign
test_base64
test_bigaddrspace
test_bigmem
test_binascii
test test_binascii failed -- Traceback (most recent call last):
  File "C:\Apps\Python30\lib\test\test_binascii.py", line 177, in
test_no_binary_strings
self.assertRaises(TypeError, f, "test")
AssertionError: TypeError not raised by crc32

test_binhex
test_binop
test_bisect
test_bool
test_bufio
test_bytes
test_bz2
test_calendar
test_call
test_capi
test_cfgparser
test_cgi
test_charmapcodec
test_class
test_cmath
test_cmd
test_cmd_line
test_cmd_line_script
test_code
test_codeccallbacks
test_codecencodings_cn
test_codecencodings_hk
test_codecencodings_jp
test_codecencodings_kr
test_codecencodings_tw
test_codecmaps_cn
test_codecmaps_cn skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_hk
test_codecmaps_hk skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_jp
test_codecmaps_jp skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_kr
test_codecmaps_kr skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_tw
test_codecmaps_tw skipped -- Use of the `urlfetch' resource not enabled
test_codecs
test_codeop
test_coding
test_collections
test_colorsys
test_compare
test_compile
test_complex
test_contains
test_contextlib
test_copy
test_copyreg
test_cprofile
test_crypt
test_crypt skipped -- No module named crypt
test_csv
test_ctypes
test_curses
test_curses skipped -- No module named _curses
test_datetime
test_dbm
test_dbm_dumb
test_dbm_gnu
test_dbm_gnu skipped -- No module named _gdbm
test_dbm_ndbm
test_dbm_ndbm skipped -- No module named _dbm
test_decimal
test_decorators
test_defaultdict
test_deque
test_descr
test_descrtut
test_dictcomps
test_dictviews
test_difflib
test_dis
test_docxmlrpc
test_dummy_thread
test_dummy_threading
test_email
test_enumerate
test_eof
test_epoll
test_epoll skipped -- test works only on Linux 2.6
test_errno
test_exception_variations
test_extcall
test_fcntl
test_fcntl skipped -- No module named fcntl
test_file
test_filecmp
test_fileinput
test_fileio
test_float
test_fnmatch
test_fork1
test_fork1 skipped -- os.fork not defined -- skipping test_fork1
test_format
test_fractions
test_frozen
test_ftplib
test_funcattrs
test_functools
test_future
test_future3
test_future4
test_future5
test_gc
test_generators
test_genericpath
test_genexps
test_getargs2
test_getopt
test_gettext
test_glob
test_global
test_grp
test_grp skipped -- 

Re: [Python-Dev] Is raising SystemError during relative import the best solution?

[Guido van Rossum]

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 SystemError to me. My guess is that the original
> purpose was to signify someone specified some relative import name
> without the proper stuff to make the name resolve to what it should
> be. But that to me is still an ImportError as the name came out wrong,
> not that the system did something incorrectly.
>
> So I would like to propose to remove the SystemError and make it an
> ImportError. Anyone object?

Hm. The SystemError is because this is a logical impossibility -- how
could you be doing an import (relative or otherwise) from P.M when P
is not loaded? It could only happen if somebody has been removing
stuff selectively from sys.modules. Why don't you want this to be a
SystemError?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Getting importlib into the standard library for 3.1

[Brett Cannon]

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.
>
> I should have done this earlier, sorry. A quick test on Windows XP,
> using the released Python 3.0 installer and a hacked regrtest.bat
> (which is basically regrtest.sh converted to Windows bat file syntax)
> gives:
>
>>regrtest.bat \Apps\Python30\python.exe
> Traceback (most recent call last):
>  File "_importlib.py", line 836, in _import_module
>loader = self._search_meta_path(name, path)
>  File "_importlib.py", line 751, in _search_meta_path
>raise ImportError("No module named %s" % name)
> ImportError: No module named test
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "_importlib.py", line 1047, in __call__
>self._import_full_module(name)
>  File "_importlib.py", line 887, in _import_full_module
>self._import_module(current_name, path_list)
>  File "_importlib.py", line 840, in _import_module
>loader = self._search_std_path(name, path)
>  File "_importlib.py", line 798, in _search_std_path
>importer = self._sys_path_importer(entry)
>  File "_importlib.py", line 766, in _sys_path_importer
>return self.default_path_hook(path_entry)
>  File "_importlib.py", line 245, in chained_fs_path_hook
>absolute_path = _path_absolute(path_entry)
>  File "_importlib.py", line 112, in _path_absolute
>return _os._getfullpathname(path)
> WindowsError: [Error 2] The system cannot find the file specified: ''
>
> Looks like ntpath._getfullpathname doesn't like an empty string as an
> argument. The following patch seems to fix this:
>
> --- _importlib.py.orig  2009-01-03 19:50:22.121422900 +
> +++ _importlib.py   2009-01-08 19:23:06.21875 +
> @@ -109,6 +109,8 @@
>  def _path_absolute(path):
> """Replacement for os.path.abspath."""
> try:
> +if path == '':
> +return _os._getfullpathname(_os._getcwd())
> return _os._getfullpathname(path)
> except AttributeError:
> if path.startswith('/'):
>

Thanks, Paul! I changed it to _os.getcwd() since that's what nt exposes.

-Brett
___
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] Is raising SystemError during relative import the best solution?

[Brett Cannon]

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 day. But this seems more like
>> an ImportError than a SystemError to me. My guess is that the original
>> purpose was to signify someone specified some relative import name
>> without the proper stuff to make the name resolve to what it should
>> be. But that to me is still an ImportError as the name came out wrong,
>> not that the system did something incorrectly.
>>
>> So I would like to propose to remove the SystemError and make it an
>> ImportError. Anyone object?
>
> Hm. The SystemError is because this is a logical impossibility -- how
> could you be doing an import (relative or otherwise) from P.M when P
> is not loaded? It could only happen if somebody has been removing
> stuff selectively from sys.modules. Why don't you want this to be a
> SystemError?
>

Doesn't fit my mental model as nicely as raising ImportError. And as
an aside this also makes testing a little bit more of a pain, but that
is not the reason I brought this up. But the way you phrased it makes
sense for me not to care enough to press this any farther.

-Brett
___
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] Getting importlib into the standard library for 3.1

[Nick Coghlan]

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
interpreter itself though (how could it?).

My main question would be how it relates to the existing import
machinery emulation in pkgutil. If adding importlib lets us largely drop
that emulation (instead replacing it with invocations of importlib),
then that seems like a big win to me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Nick Coghlan]

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
everything to 4 space indents by default, and I have to fiddle with it
to get it to keep the tabs when I'm editing functions/files that
previously used tabs for indenting.

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 tends to lead to patches that look
like "remove function body, add different function body" when only a
couple of lines have actually had significant changes.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Brett Cannon]

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 annoying is because I have my editor set to switch
> everything to 4 space indents by default, and I have to fiddle with it
> to get it to keep the tabs when I'm editing functions/files that
> previously used tabs for indenting.
>
> 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 tends to lead to patches that look
> like "remove function body, add different function body" when only a
> couple of lines have actually had significant changes.
>

That's fine with me. Correcting whitespace can be considered a committer's job.

-Brett
___
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] Getting importlib into the standard library for 3.1

[Paul Moore]

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,
whereas with the normal import, it fails. The importlib result is

test_multiprocessing skipped -- No module named test.test_support

where the normal result is

test_multiprocessing
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
prepare(preparation_data)
prepare(preparation_data)
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named 
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named 
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
prepare(preparation_data)
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named 
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
prepare(preparation_data)
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named 
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
prepare(preparation_data)
  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named 
test test_multiprocessing crashed -- :

My command line was

\Apps\Python30\python.exe -c "import sys; sys.argv = ['',
'test_pkg', 'test_pydoc', 'test_shlex', 'test_pep263',
'test_distutils', 'test_lib2to3', 'test_pep3120', 'test_import']; from
test.regrtest import main; main(exclude=True)"

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] Getting importlib into the standard library for 3.1

[Brett Cannon]

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 never really applied to things that are part of the
> interpreter itself though (how could it?).
>

Well, it's not part of the interpreter yet. That can be viewed as a
separate step.

> My main question would be how it relates to the existing import
> machinery emulation in pkgutil. If adding importlib lets us largely drop
> that emulation (instead replacing it with invocations of importlib),
> then that seems like a big win to me.

You mean stuff like pkgutil.ImpImporter? importlib will be fully
modular with meta_path importers for everything short of sys.modules
(and even that could be done if people care, but I would rather keep
sys.modules stuff on the fast path). So there will be a meta_path
importer that handles sys.path/sys.path_hooks/sys.path_importer_cache.
That work is part of the "importlib is semantically done, but there
are some things I want to imrpove" todo list. If you are more talking
about something else I am not sure what you are after. Every module
will have a proper loader with importlib.

-Brett
___
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] Getting importlib into the standard library for 3.1

[Brett Cannon]

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 that with importlib, test_multiprocessing is skipped,
> whereas with the normal import, it fails. The importlib result is
>
> test_multiprocessing skipped -- No module named test.test_support
>

Well, that should fail since test.test_support doesn't exist in Python 3.0.

> where the normal result is
>
> test_multiprocessing
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> test test_multiprocessing crashed -- :
>
> My command line was
>
> \Apps\Python30\python.exe -c "import sys; sys.argv = ['',
> 'test_pkg', 'test_pydoc', 'test_shlex', 'test_pep263',
> 'test_distutils', 'test_lib2to3', 'test_pep3120', 'test_import']; from
> test.regrtest import main; main(exclude=True)"
>

This looks like test_subprocessing tries to snag some detail about
what module __main__ is based on the first value of sys.argv.

-Brett
___
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] compiling python2.5 on linux under wine

[Martin v. Löwis]

>  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-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] error in doc for fcntl module

[Martin v. Löwis]

> 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
additional trickery, it has a different name.
___
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] Getting importlib into the standard library for 3.1

[Jesse Noller]

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 be that with importlib, test_multiprocessing is skipped,
> whereas with the normal import, it fails. The importlib result is
>

Zuh?

> test_multiprocessing skipped -- No module named test.test_support
>

This isn't occurring on the build bots.

> where the normal result is
>
> test_multiprocessing
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 342, in main
>prepare(preparation_data)
>  File "C:\Apps\Python30\lib\multiprocessing\forking.py", line 451, in prepare
>file, path_name, etc = imp.find_module(main_name, dirs)
> ImportError: No module named 
> test test_multiprocessing crashed -- :
>
> My command line was
>
> \Apps\Python30\python.exe -c "import sys; sys.argv = ['',
> 'test_pkg', 'test_pydoc', 'test_shlex', 'test_pep263',
> 'test_distutils', 'test_lib2to3', 'test_pep3120', 'test_import']; from
> test.regrtest import main; main(exclude=True)"

This shouldn't be happening (obviously) and doesn't seem to be
occurring on the buildbots.
___
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] Getting importlib into the standard library for 3.1

[Antoine Pitrou]

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 setuptools?
(somebody has done a patch to port setuptools to 3.x, see
http://mail.python.org/pipermail/distutils-sig/2009-January/010659.html)

I'm not saying that it's a showstopper btw, just trying to suggest
experimentation possibilities.

Regards

Antoine.


___
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] Getting importlib into the standard library for 3.1

[Nick Coghlan]

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 this one.
>> That rule has never really applied to things that are part of the
>> interpreter itself though (how could it?).
> 
> 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 a __loader__ attribute, and
that's one of the things an import system based on your importlib would
provide.

>> My main question would be how it relates to the existing import
>> machinery emulation in pkgutil. If adding importlib lets us largely drop
>> that emulation (instead replacing it with invocations of importlib),
>> then that seems like a big win to me.
> 
> You mean stuff like pkgutil.ImpImporter? importlib will be fully
> modular with meta_path importers for everything short of sys.modules
> (and even that could be done if people care, but I would rather keep
> sys.modules stuff on the fast path). So there will be a meta_path
> importer that handles sys.path/sys.path_hooks/sys.path_importer_cache.
> That work is part of the "importlib is semantically done, but there
> are some things I want to imrpove" todo list. If you are more talking
> about something else I am not sure what you are after. Every module
> will have a proper loader with importlib.

I'm talking about the fact that imp.get_loader doesn't exist, hence the
existence of pkgutil.get_loader and its supporting machinery.

My question is whether or not it is possible to replace the current
emulation code in pkgutil with appropriate imports from importlib and
thus get rid of the current semantic differences that exist between the
real import machinery and the pkgutil emulation (mainly in the area of
non-PEP 302 module loaders, such as the special case for the Windows
directory information).

Upgrading the pkgutil interface to match the *actual* semantics of the
import system instead of only approximating them would be a decent win
in its own right, even if there turn out to be other issues that keep us
from switching to importlib as the sole import mechanism.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Getting importlib into the standard library for 3.1

[Brett Cannon]

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.
>
> Have you tried to assess its interaction with setuptools?
> (somebody has done a patch to port setuptools to 3.x, see
> http://mail.python.org/pipermail/distutils-sig/2009-January/010659.html)
>
> I'm not saying that it's a showstopper btw, just trying to suggest
> experimentation possibilities.

Beyond Python's standard library, nope; I am not a setuptools user.

-Brett
___
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] [patch 8/8] hand --host and --build over to libffi

[Robert Schwebel]

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
===
--- Python-3.0.orig/setup.py
+++ Python-3.0/setup.py
@@ -1342,12 +1342,12 @@ class PyBuildExt(build_ext):
  ffi_configfile):
 from distutils.dir_util import mkpath
 mkpath(ffi_builddir)
-config_args = []
+config_args = ['--host=%s' % os.environ.get('GNU_HOST'), 
'--build=%s' % os.environ.get('GNU_BUILD')]
 
 # Pass empty CFLAGS because we'll just append the resulting
 # CFLAGS to Python's; -g or -O2 is to be avoided.
 cmd = "cd %s && env CFLAGS='' '%s/configure' %s" \
-  % (ffi_builddir, ffi_srcdir, " ".join(config_args))
+% (ffi_builddir, ffi_srcdir, " ".join(config_args))
 
 res = os.system(cmd)
 if res or not os.path.exists(ffi_configfile):
Index: Python-3.0/Makefile.pre.in
===
--- Python-3.0.orig/Makefile.pre.in
+++ Python-3.0/Makefile.pre.in
@@ -423,6 +423,7 @@ sharedmods: $(PYTHON_FOR_BUILD)
CC='$(CC)' \
LDSHARED='$(BLDSHARED)' \
OPT='$(OPT)' \
+   CONFIG_ARGS="$(CONFIG_ARGS)" \
$(PYTHON_FOR_BUILD) -E $(srcdir)/setup.py -q build \
;; \
*) \
@@ -431,6 +432,7 @@ sharedmods: $(PYTHON_FOR_BUILD)
CC='$(CC)' \
LDSHARED='$(BLDSHARED)' \
OPT='$(OPT)' \
+   CONFIG_ARGS="$(CONFIG_ARGS)" \
$(PYTHON_FOR_BUILD) -E $(srcdir)/setup.py build \
;; \
esac

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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] [patch 2/8] add _FOR_BUILD infrastructure

[Robert Schwebel]

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 +++-
 1 file changed, 82 insertions(+), 34 deletions(-)

Index: Python-3.0/Makefile.pre.in
===
--- Python-3.0.orig/Makefile.pre.in
+++ Python-3.0/Makefile.pre.in
@@ -28,6 +28,8 @@ VERSION=  @VERSION@
 srcdir=@srcdir@
 VPATH= @srcdir@
 
+export srcdir
+
 CC=@CC@
 CXX=   @CXX@
 MAINCC=@MAINCC@
@@ -72,6 +74,15 @@ cflagsforshar...@cflagsforshared@
 # C flags used for building the interpreter object files
 PY_CFLAGS= $(CFLAGS) $(CPPFLAGS) $(CFLAGSFORSHARED) -DPy_BUILD_CORE
 
+# For cross compile: build compiler options
+CC_FOR_BUILD=  @CC_FOR_BUILD@
+CROSS_COMPILING=   @cross_compiling@
+EXEEXT_FOR_BUILD=  @EXEEXT_FOR_BUILD@
+O_FOR_BUILD=   @O_FOR_BUILD@
+CFLAGS_FOR_BUILD=  @CFLAGS_FOR_BUILD@
+CPPFLAGS_FOR_BUILD=@CPPFLAGS_FOR_BUILD@ -I$(srcdir)/Include
+LDFLAGS_FOR_BUILD= @LDFLAGS_FOR_BUILD@
+LIBS_FOR_BUILD=@LIBS_FOR_BUILD@
 
 # Machine-dependent subdirectories
 MACHDEP=   @MACHDEP@
@@ -173,7 +184,8 @@ LIBOBJDIR=  Python/
 LIBOBJS=   @LIBOBJS@
 
 PYTHON=python$(EXE)
-BUILDPYTHON=   python$(BUILDEXE)
+BUILDPYTHON=   python$(EXE)
+python_for_bui...@python_for_build@
 
 # The task to run while instrument when building the profile-opt target
 PROFILE_TASK=  $(srcdir)/Tools/pybench/pybench.py -n 2 --with-gc 
--with-syscheck
@@ -203,7 +215,8 @@ GRAMMAR_INPUT=  $(srcdir)/Grammar/Grammar
 
 ##
 # Parser
-PGEN=  Parser/pgen$(EXE)
+PGEN_FOR_BUILD=Parser/pgen$(EXEEXT_FOR_BUILD)
+
 
 POBJS= \
Parser/acceler.o \
@@ -220,18 +233,31 @@ POBJS=\
 
 PARSER_OBJS=   $(POBJS) Parser/myreadline.o Parser/tokenizer.o
 
-PGOBJS=\
-   Objects/obmalloc.o \
-   Python/mysnprintf.o \
-   Parser/tokenizer_pgen.o \
-   Parser/printgrammar.o \
-   Parser/pgenmain.o
+POBJS_FOR_BUILD= \
+   Parser/acceler.$(O_FOR_BUILD) \
+   Parser/grammar1.$(O_FOR_BUILD) \
+   Parser/listnode.$(O_FOR_BUILD) \
+   Parser/node.$(O_FOR_BUILD) \
+   Parser/parser.$(O_FOR_BUILD) \
+   Parser/parsetok.$(O_FOR_BUILD) \
+   Parser/bitset.$(O_FOR_BUILD) \
+   Parser/metagrammar.$(O_FOR_BUILD) \
+   Parser/firstsets.$(O_FOR_BUILD) \
+   Parser/grammar.$(O_FOR_BUILD) \
+   Parser/pgen.$(O_FOR_BUILD)
+
+PGOBJS_FOR_BUILD= \
+   Objects/obmalloc.$(O_FOR_BUILD) \
+   Python/mysnprintf.$(O_FOR_BUILD) \
+   Parser/tokenizer_pgen.$(O_FOR_BUILD) \
+   Parser/printgrammar.$(O_FOR_BUILD) \
+   Parser/pgenmain.$(O_FOR_BUILD)
 
 PARSER_HEADERS= \
Parser/parser.h \
Parser/tokenizer.h
 
-PGENOBJS=  $(PGENMAIN) $(POBJS) $(PGOBJS)
+PGENOBJS=  $(POBJS_FOR_BUILD) $(PGOBJS_FOR_BUILD)
 
 ##
 # AST
@@ -385,15 +411,28 @@ $(BUILDPYTHON):   Modules/python.o $(LIBRA
Modules/python.o \
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
 
-platform: $(BUILDPYTHON)
-   $(RUNSHARED) ./$(BUILDPYTHON) -E -c 'import sys ; from distutils.util 
import get_platform ; print(get_platform()+"-"+sys.version[0:3])' >platform
-
+platform: $(PYTHON_FOR_BUILD)
+   $(RUNSHARED) $(PYTHON_FOR_BUILD) -E -c 'import sys ; from 
distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]' 
> platform
 
 # Build the shared modules
-sharedmods: $(BUILDPYTHON)
+sharedmods: $(PYTHON_FOR_BUILD)
@case $$MAKEFLAGS in \
-   *s*) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' OPT='$(OPT)' 
./$(BUILDPYTHON) -E $(srcdir)/setup.py -q build;; \
-   *) $(RUNSHARED) CC='$(CC)' LDSHARED='$(BLDSHARED)' OPT='$(OPT)' 
./$(BUILDPYTHON) -E $(srcdir)/setup.py build;; \
+   *-s*) \
+   $(RUNSHARED) \
+   CROSS_COMPILING=$(CROSS_COMPILING) \
+   CC='$(CC)' \
+   LDSHARED='$(BLDSHARED)' \
+   OPT='$(OPT)' \
+   $(PYTHON_FOR_BUILD) -E $(srcdir)/setup.py -q build \
+   ;; \
+   *) \
+   $(RUNSHARED) \
+   CROSS_COMPILING=$(CROSS_COMPILING) \
+   CC='$(CC)' \
+   LDSHARED='$(BLDSHARED)' \
+   OPT='$(OPT)' \
+   $(PYTHON_FOR_BUILD) -E $(srcdir)/setup.py b

[Python-Dev] [patch 7/8] make setup.py cross compilation aware

[Robert Schwebel]

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
===
--- Python-3.0.orig/setup.py
+++ Python-3.0/setup.py
@@ -18,6 +18,15 @@ from distutils.command.install_lib impor
 # This global variable is used to hold the list of modules to be disabled.
 disabled_module_list = []
 
+import os
+
+if os.environ.get('CROSS_COMPILING') == 'yes':
+sysconfig.get_config_vars()
+sysconfig._config_vars.update (os.environ)
+else:
+sysconfig.get_config_vars()
+sysconfig._config_vars['srcdir'] = os.environ['srcdir']
+
 def add_dir_to_list(dirlist, dir):
 """Add the directory 'dir' to the list 'dirlist' (at the front) if
 1) 'dir' is not already in 'dirlist'
@@ -260,6 +269,10 @@ class PyBuildExt(build_ext):
 self.announce('WARNING: skipping import check for Cygwin-based 
"%s"'
 % ext.name)
 return
+if os.environ.get('CROSS_COMPILING') == 'yes':
+self.announce('WARNING: skipping import check for cross compiled 
"%s"'
+% ext.name)
+return
 ext_filename = os.path.join(
 self.build_lib,
 self.get_ext_filename(self.get_ext_fullname(ext.name)))
@@ -301,16 +314,20 @@ class PyBuildExt(build_ext):
 self.failed.append(ext.name)
 
 def get_platform(self):
-# Get value of sys.platform
+# Get value of target's sys.platform
+p = sys.platform
+if os.environ.get('CROSS_COMPILING') == 'yes':
+p = os.environ.get('CROSS_TARGET')
 for platform in ['cygwin', 'darwin', 'atheos', 'osf1']:
-if sys.platform.startswith(platform):
+if p.startswith(platform):
 return platform
-return sys.platform
+return p
 
 def detect_modules(self):
 # Ensure that /usr/local is always used
-add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
-add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')
+if os.environ.get('CROSS_COMPILING') != 'yes':
+add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
+add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')
 
 # Add paths specified in the environment variables LDFLAGS and
 # CPPFLAGS for header and library files.
@@ -355,11 +372,14 @@ class PyBuildExt(build_ext):
 # lib_dirs and inc_dirs are used to search for files;
 # if a file is found in one of those directories, it can
 # be assumed that no additional -I,-L directives are needed.
-lib_dirs = self.compiler.library_dirs + [
-'/lib64', '/usr/lib64',
-'/lib', '/usr/lib',
-]
-inc_dirs = self.compiler.include_dirs + ['/usr/include']
+lib_dirs = []
+inc_dirs = []
+if os.environ.get('CROSS_COMPILING') != 'yes':
+lib_dirs = self.compiler.library_dirs + [
+'/lib64', '/usr/lib64',
+'/lib', '/usr/lib',
+]
+inc_dirs = self.compiler.include_dirs + ['/usr/include']
 exts = []
 missing = []
 
@@ -675,6 +695,9 @@ class PyBuildExt(build_ext):
 '/sw/include/db3',
 ]
 
+if os.environ.get('CROSS_COMPILING') == 'yes':
+db_inc_paths = []
+
 db_incs = None
 
 # The sqlite interface
@@ -694,6 +717,9 @@ class PyBuildExt(build_ext):
 MIN_SQLITE_VERSION = ".".join([str(x)
 for x in MIN_SQLITE_VERSION_NUMBER])
 
+if os.environ.get('CROSS_COMPILING') == 'yes':
+sqlite_inc_paths = []
+
 # Scan the default include directories before the SQLite specific
 # ones. This allows one to override the copy of sqlite on OSX,
 # where /usr/include contains an old version of sqlite.

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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] [patch 6/8] fix lchflags test

[Robert Schwebel]

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: Python-3.0/configure.in
===
--- Python-3.0.orig/configure.in
+++ Python-3.0/configure.in
@@ -2526,7 +2526,7 @@ no)
 esac
 
 AC_MSG_CHECKING(for lchflags)
-AC_TRY_RUN([
+AC_RUN_IFELSE([
 #include 
 #include 
 int main(int argc, char*argv[])
@@ -2535,10 +2535,27 @@ int main(int argc, char*argv[])
 return 1;
   return 0;
 }
-],AC_DEFINE(HAVE_LCHFLAGS, 1, Define to 1 if you have the `lchflags' function.)
-  AC_MSG_RESULT(yes),
+],[
+  AC_CACHE_VAL(ac_cv_have_lchflags, ac_cv_have_lchflags=yes)
+  AC_MSG_RESULT(yes)
+],[
+  AC_CACHE_VAL(ac_cv_have_lchflags, ac_cv_have_lchflags=no)
   AC_MSG_RESULT(no)
+],[
+  AC_CACHE_VAL(ac_cv_have_lchflags, ac_cv_have_lchflags=undef)
+  AC_MSG_RESULT([crosscompiling, ac_cv_have_lchflags=$ac_cv_have_lchflags])
+]
 )
+case $ac_cv_have_lchflags in
+yes)
+  AC_DEFINE(HAVE_LCHFLAGS, 1, Define to 1 if you have the 'lchflags' function.)
+  ;;
+no)
+  ;;
+*)
+  AC_MSG_ERROR([please specify ac_cv_have_lchflags=yes|no])
+  ;;
+esac
 
 dnl Check if system zlib has *Copy() functions
 dnl

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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] [patch 1/8] distutils need to care about cross compiling

[Robert Schwebel]

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
===
--- Python-3.0.orig/Lib/distutils/command/build_ext.py
+++ Python-3.0/Lib/distutils/command/build_ext.py
@@ -642,6 +642,8 @@ class build_ext(Command):
 ext_path[len(ext_path) - 1] = ext_path[len(ext_path) - 1][:8]
 # extensions in debug_mode are named 'module_d.pyd' under windows
 so_ext = get_config_var('SO')
+if os.environ.get('CROSS_COMPILING') == 'yes':
+so_ext = os.environ.get('SO')
 if os.name == 'nt' and self.debug:
 return os.path.join(*ext_path) + '_d' + so_ext
 return os.path.join(*ext_path) + so_ext

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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] [patch 5/8] fix chflags test

[Robert Schwebel]

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: Python-3.0/configure.in
===
--- Python-3.0.orig/configure.in
+++ Python-3.0/configure.in
@@ -2494,7 +2494,7 @@ AC_CHECK_LIB(c, inet_aton, [$ac_cv_prog_
 # On Tru64, chflags seems to be present, but calling it will
 # exit Python
 AC_MSG_CHECKING(for chflags)
-AC_TRY_RUN([
+AC_RUN_IFELSE([
 #include 
 #include 
 int main(int argc, char*argv[])
@@ -2503,10 +2503,27 @@ int main(int argc, char*argv[])
 return 1;
   return 0;
 }
-],AC_DEFINE(HAVE_CHFLAGS, 1, Define to 1 if you have the `chflags' function.)
-  AC_MSG_RESULT(yes),
+],[
+  AC_CACHE_VAL(ac_cv_have_chflags, ac_cv_have_chflags=yes)
+  AC_MSG_RESULT(yes)
+],[
+  AC_CACHE_VAL(ac_cv_have_chflags, ac_cv_have_chflags=no)
   AC_MSG_RESULT(no)
+],[
+  AC_CACHE_VAL(ac_cv_have_chflags, ac_cv_have_chflags=undef)
+  AC_MSG_RESULT([crosscompiling, ac_cv_have_chflags=$ac_cv_have_chflags])
+]
 )
+case $ac_cv_have_chflags in
+yes)
+  AC_DEFINE(HAVE_CHFLAGS, 1, Define to 1 if you have the 'chflags' function.)
+  ;;
+no)
+  ;;
+*)
+  AC_MSG_ERROR([please specify ac_cv_have_chflags=yes|no])
+  ;;
+esac
 
 AC_MSG_CHECKING(for lchflags)
 AC_TRY_RUN([

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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] [patch 4/8] configure.in fixes

[Robert Schwebel]

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 ---
 1 file changed, 86 insertions(+), 4 deletions(-)

Index: Python-3.0/configure.in
===
--- Python-3.0.orig/configure.in
+++ Python-3.0/configure.in
@@ -12,6 +12,11 @@ AC_INIT(python, PYTHON_VERSION, http://w
 AC_CONFIG_SRCDIR([Include/object.h])
 AC_CONFIG_HEADER(pyconfig.h)
 
+# find compiler while respecting --host setting
+#AC_CANONICAL_HOST()
+AC_CHECK_TOOLS(CC,gcc cc)
+AC_CHECK_TOOLS(CXX,g++ c++)
+
 dnl This is for stuff that absolutely must end up in pyconfig.h.
 dnl Please use pyport.h instead, if possible.
 AH_TOP([
@@ -214,6 +219,7 @@ AC_SUBST(MACHDEP)
 AC_MSG_CHECKING(MACHDEP)
 if test -z "$MACHDEP"
 then
+if test "$cross_compiling" = "no"; then
ac_sys_system=`uname -s`
if test "$ac_sys_system" = "AIX" -o "$ac_sys_system" = "Monterey64" \
-o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
@@ -234,6 +240,19 @@ then
 irix646) MACHDEP="irix6";;
'') MACHDEP="unknown";;
esac
+else
+m=`$CC -dumpmachine`
+changequote(<<, >>)#dnl
+ac_sys_system=`expr "$m" : "[^-]*-\([^-]*\)"`
+changequote([, ])#dnl
+
+case $ac_sys_system in
+cygwin*) ac_sys_system=`echo $ac_sys_system | sed s/cygwin/CYGWIN/g `;;
+darwin*) ac_sys_system=`echo $ac_sys_system | sed s/darwin/Darwin/g `;;
+freebsd*) ac_sys_system=`echo $ac_sys_system | sed s/freebsd/FreeBSD/g 
`;;
+linux*) ac_sys_system=`echo $ac_sys_system | sed s/linux/Linux/g `;;
+esac
+fi
 fi

 # Some systems cannot stand _XOPEN_SOURCE being defined at all; they
@@ -503,9 +522,11 @@ if test -d casesensitivetestdir
 then
 AC_MSG_RESULT(yes)
 BUILDEXEEXT=.exe
+case_sensitive=no
 else
AC_MSG_RESULT(no)
BUILDEXEEXT=$EXEEXT
+   case_sensitive=yes
 fi
 rmdir CaseSensitiveTestDir
 
@@ -705,9 +726,9 @@ fi
 
 AC_MSG_RESULT($LDLIBRARY)
 
-AC_PROG_RANLIB
-AC_SUBST(AR)
-AC_CHECK_PROGS(AR, ar aal, ar)
+# find tools while respecting --host setting
+AC_CHECK_TOOL(RANLIB,ranlib)
+AC_CHECK_TOOLS(AR,ar aal,ar)
 
 AC_SUBST(SVNVERSION)
 AC_CHECK_PROG(SVNVERSION, svnversion, found, not-found)
@@ -3546,6 +3567,7 @@ else
 fi
 
 AC_MSG_CHECKING(for %zd printf() format support)
+AC_CACHE_VAL(ac_cv_printf_zd_format,
 AC_TRY_RUN([#include 
 #include 
 #include 
@@ -3582,7 +3604,9 @@ int main()
 }],
 [AC_MSG_RESULT(yes)
  AC_DEFINE(PY_FORMAT_SIZE_T, "z", [Define to printf format modifier for 
Py_ssize_t])],
- AC_MSG_RESULT(no))
+ AC_MSG_RESULT(no),
+ AC_MSG_RESULT(no)))
+
 
 AC_CHECK_TYPE(socklen_t,,
   AC_DEFINE(socklen_t,int,
@@ -3633,6 +3657,64 @@ for dir in $SRCDIRS; do
 done
 AC_MSG_RESULT(done)
 
+# cross compiling
+AC_SUBST(cross_compiling)
+
+if test "$cross_compiling" = "yes"; then
+AC_MSG_CHECKING(cc for build)
+CC_FOR_BUILD="${CC_FOR_BUILD-cc}"
+else
+CC_FOR_BUILD="${CC_FOR_BUILD-$CC}"
+fi
+
+if test "$cross_compiling" = "yes"; then
+   AC_MSG_RESULT($CC_FOR_BUILD)
+fi
+
+AC_ARG_VAR(CC_FOR_BUILD,[build system C compiler (default: cc)])
+
+if test "$cross_compiling" = "yes"; then
+AC_MSG_CHECKING(python for build)
+PYTHON_FOR_BUILD="${PYTHON_FOR_BUILD-python}"
+PYTHON_FOR_BUILD=`which $PYTHON_FOR_BUILD`
+else
+PYTHON_FOR_BUILD='./$(BUILDPYTHON)'
+fi
+
+if test "$cross_compiling" = "yes"; then
+AC_MSG_RESULT($PYTHON_FOR_BUILD)
+fi
+
+AC_ARG_VAR(PYTHON_FOR_BUILD,[build system python (default: python)])
+AC_SUBST(PYTHON_FOR_BUILD)
+
+if test "$cross_compiling" = "yes"; then
+CFLAGS_FOR_BUILD=${CFLAGS_FOR_BUILD-}
+CPPFLAGS_FOR_BUILD=${CPPFLAGS_FOR_BUILD- -I.}
+CROSS_COMMENT=#
+if test "$case_sensitive" = "yes"
+then
+EXEEXT_FOR_BUILD=
+else
+EXEEXT_FOR_BUILD=.exe
+fi
+LDFLAGS_FOR_BUILD=${LDFLAGS_FOR_BUILD-}
+LIBS_FOR_BUILD=${LIBS_FOR_BUILD-}
+O_FOR_BUILD=x
+RUNSHARED="CROSS_TARGET=$ac_sys_system SRCDIR=$srcdir SO=${SO}"
+else
+CROSS_COMMENT=
+EXEEXT_FOR_BUILD=$BUILDEXEEXT
+O_FOR_BUILD=o
+fi
+AC_SUBST(CFLAGS_FOR_BUILD)
+AC_SUBST(CPPFLAGS_FOR_BUILD)
+AC_SUBST(CROSS_COMMENT)
+AC_SUBST(EXEEXT_FOR_BUILD)
+AC_SUBST(LDFLAGS_FOR_BUILD)
+AC_SUBST(LIBS_FOR_BUILD)
+AC_SUBST(O_FOR_BUILD)
+
 # generate output files
 AC_CONFIG_FILES(Makefile.pre Modules/Setup.config)
 AC_OUTPUT

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
Python-Dev maili

[Python-Dev] [patch 3/8] add readme

[Robert Schwebel]

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
===
--- Python-3.0.orig/README
+++ Python-3.0/README
@@ -156,6 +156,50 @@ there.  For example:
 should do a "make clean" at the toplevel first.)
 
 
+Cross Compiling
+---
+
+Python can be cross compiled by supplying different --build and --host
+parameters to configure. Python is compiled on the "build" system and
+executed on the "host" system. Cross compiling python requires a
+native Python on the build host, and a natively compiled tool `Pgen'.
+
+Before cross compiling, Python must first be compiled and installed on
+the build host. The configure script will use `cc' and `python', or
+environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg:
+
+   CC_FOR_BUILD=gcc-3.3 \
+   PYTHON_FOR_BUILD=python3.0 \
+   .../configure --build=i686-linux --host=i586-mingw32
+
+Cross compiling has been tested under linux, mileage may vary for
+other platforms.
+
+A few reminders on using configure to cross compile:
+
+- Cross compile tools must be in PATH,
+
+- Cross compile tools must be prefixed with the host type
+  (ie i586-mingw32-gcc, powerpc-darwin8-ranlib, ...),
+
+- CC, CXX, AR, and RANLIB must be undefined when running configure,
+  they will be auto-detected.
+
+- Autoconf must be stopped from autodetecting definitions for the
+  build machine.  This is easiest done by creating a config.cache
+  that overrides ac_cv_* variables appropriately.
+
+If you need a cross compiler, Debian ships several several (eg: avr,
+m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise,
+check out one of these cross toolchain projects:
+
+- crosstool:
+  http://www.kegel.com/crosstool
+
+- OSELAS.Toolchain:
+  http://www.pengutronix.de/oselas/toolchain/index_en.html
+
+
 Copyright and License Information
 -
 

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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] [patch 0/8] [RFC] cross compiling python 3.0

[Robert Schwebel]

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 Python core developers, I would like to find out if
it is possible to get cross compilation support integrated in the
upstream tree. This patch series reflects what we currently have in
PTXdist. Please see it as an RFC.

It is probably not perfect yet, but I would like to see some feedback
from you Python guys out there. Do you see issues with these patches?
Would it be possible in general to get something similar to this series
into the Python mainline?

Robert

-- 
Pengutronix e.K.   | Dipl.-Ing. Robert Schwebel  |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
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] [patch 1/8] distutils need to care abo ut cross compiling

[Antoine Pitrou]

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, otherwise please merge the patches into a single one.

Antoine.


___
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] Getting importlib into the standard library for 3.1

[Brett Cannon]

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
 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
>>> interpreter itself though (how could it?).
>>
>> 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 a __loader__ attribute, and
> that's one of the things an import system based on your importlib would
> provide.
>

True. I am just trying to be diplomatic and not force importlib down
anyone's throats. =)

>>> My main question would be how it relates to the existing import
>>> machinery emulation in pkgutil. If adding importlib lets us largely drop
>>> that emulation (instead replacing it with invocations of importlib),
>>> then that seems like a big win to me.
>>
>> You mean stuff like pkgutil.ImpImporter? importlib will be fully
>> modular with meta_path importers for everything short of sys.modules
>> (and even that could be done if people care, but I would rather keep
>> sys.modules stuff on the fast path). So there will be a meta_path
>> importer that handles sys.path/sys.path_hooks/sys.path_importer_cache.
>> That work is part of the "importlib is semantically done, but there
>> are some things I want to imrpove" todo list. If you are more talking
>> about something else I am not sure what you are after. Every module
>> will have a proper loader with importlib.
>
> I'm talking about the fact that imp.get_loader doesn't exist, hence the
> existence of pkgutil.get_loader and its supporting machinery.
>

Ah, OK.

> My question is whether or not it is possible to replace the current
> emulation code in pkgutil with appropriate imports from importlib and
> thus get rid of the current semantic differences that exist between the
> real import machinery and the pkgutil emulation (mainly in the area of
> non-PEP 302 module loaders, such as the special case for the Windows
> directory information).
>

Looking at pkgutil.get_loader it would not be hard to expose the same
thing in importlib. Since one of the motivating factors in this is to
redo the import machinery from a PEP 302 standpoint the need for
pkgutil should quickly go or easily shift to importlib as needed. It's
just a matter of exposing an API.

-Brett
___
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] Getting importlib into the standard library for 3.1

[Paul Moore]

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 a __loader__ attribute, and
> that's one of the things an import system based on your importlib would
> provide.

FWIW, this is certainly the ultimate direction *I* intended PEP 302 to
take. At the time the key deliverable (which was provided by Just) was
the zip importer - but we intended the mechanism to be applicable for
everything, and ultimately to be *used* for eveything. Sadly, neither
Just nor I ever took that extra step - and I'm extremely happy that
Brett has now done so.

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] compiling python2.5 on linux under wine

[Tres Seaver]

-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 Luke wants to cross-compile bdist-win distributions for
the benefit of tool-deprived Windows users.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFJZogZ+gerLs4ltQ4RAoJoAJjw/vCaCo5yTtErbvhx1pndac/kAJ9ttT+d
qtLscKp1Imf2pRFtKE+Wsg==
=JqqK
-END PGP 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

[Python-Dev] OSCON 2009: Call For Participation

[Aahz]

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...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."  --Brian W. Kernighan
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Benjamin Peterson]

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 tends to lead to patches that look
>> like "remove function body, add different function body" when only a
>> couple of lines have actually had significant changes.
>>
>
> That's fine with me. Correcting whitespace can be considered a committer's 
> job.

Maybe a rule could be added to Tools/scripts/patchcheck.py?



-- 
Regards,
Benjamin
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Brett Cannon]

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 changes though - leaving
>>> the whitespace changes in the patch tends to lead to patches that look
>>> like "remove function body, add different function body" when only a
>>> couple of lines have actually had significant changes.
>>>
>>
>> That's fine with me. Correcting whitespace can be considered a committer's 
>> job.
>
> Maybe a rule could be added to Tools/scripts/patchcheck.py?

To do what? Re-indent automatically? Or notify the person that there
seems to be a need to re-indent some code?

-Brett
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Benjamin Peterson]

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 should
 still try to avoid including pure whitespace changes though - leaving
 the whitespace changes in the patch tends to lead to patches that look
 like "remove function body, add different function body" when only a
 couple of lines have actually had significant changes.

>>>
>>> That's fine with me. Correcting whitespace can be considered a committer's 
>>> job.
>>
>> Maybe a rule could be added to Tools/scripts/patchcheck.py?
>
> To do what? Re-indent automatically? Or notify the person that there
> seems to be a need to re-indent some code?

I was thinking about notifying the person that their indentation was
wrong or they had trailing whitespace. Fixing it is bonus. :)



-- 
Regards,
Benjamin
___
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] Needless assert in ceval.c?

[skip]

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 assigned WHY_YIELD within the loop.  If you assert before the loop once
I think that will be sufficient and more clearly state the intent.

fast_block_end:
assert(why != WHY_YIELD);  /* move the assert here */
while (why != WHY_NOT && f->f_iblock > 0) {
PyTryBlock *b = PyFrame_BlockPop(f);

/* get rid of the assert here */
if (b->b_type == SETUP_LOOP && why == WHY_CONTINUE) {
...
}
...
} /* unwind stack */

Reported to the tracker: http://bugs.python.org/issue4888

Skip
___
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] Fixing incorrect indentations in C files (Decoder functions accept str in py3k)

[Brett Cannon]

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 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 tends to lead to patches that look
> like "remove function body, add different function body" when only a
> couple of lines have actually had significant changes.
>

 That's fine with me. Correcting whitespace can be considered a committer's 
 job.
>>>
>>> Maybe a rule could be added to Tools/scripts/patchcheck.py?
>>
>> To do what? Re-indent automatically? Or notify the person that there
>> seems to be a need to re-indent some code?
>
> I was thinking about notifying the person that their indentation was
> wrong or they had trailing whitespace. Fixing it is bonus. :)

Supporting C and header files was a plan of mine from the beginning.
We will see when I get to it. =)

-Brett
___
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