date:20090723

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread Ben Finney

David Lyon  writes:

> I'm on the python-dev mailing list and somebody gave me a link
> to a page that you have done:
> 
>   http://docs.python.org/install/

That's a document describing how to use ‘distutils’, which is what every
recipient of Python will already have installed.

> Can I ask that you also provide a link for windows users
> to my project:
> 
>   http://sourceforge.net/projects/pythonpkgmgr/

That doesn't seem at all appropriate; promoting third-party packages
isn't at all what the above document should be doing.

> Our project provides an alternative to command line installation.

If people want an alternative to the standard tools provided in Python,
the documentation for Python itself is not the right place to be
looking. The Python Package Index http://pypi.python.org/> is the
right place to be promoting (free-software) third-party tools.

-- 
 \   “There's no excuse to be bored. Sad, yes. Angry, yes. |
  `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, |
_o__)  ever.” —Viggo Mortensen |
Ben Finney

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread david . lyon


> That's a document describing how to use âdistutilsâ, which is what
> every
> recipient of Python will already have installed.
>
>> Can I ask that you also provide a link for windows users
>> to my project:
>>
>>   http://sourceforge.net/projects/pythonpkgmgr/
>
> That doesn't seem at all appropriate; promoting third-party packages
> isn't at all what the above document should be doing.

Distutils was once seperate and was then included in the standard python.

So i guess that I am working with the same goal in mind.

> If people want an alternative to the standard tools provided in Python,
The Python Package Index http://pypi.python.org/> is the
> right place to be promoting (free-software) third-party tools.

Well I can sure try that and thank you for the tip.

Btw, at the moment there exists no inbuilt mechanism within python for
retrieving packages from pypi.

Imho this is an omission for a so called 'batteries included' language.

Distutils is a builtin module for 'pushing' a developer package 'to' pypi.

But there is no corresponging mechanise for a user to 'pull' packages back.

Surely this is a gap in the standard distro?

So it is not inappropriate for me to ask about this on this list.

Take care

David


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GSoC: Replace MS Windows Console with Unicode UI

2009-07-23 Thread Aahz

On Thu, Jul 23, 2009, INADA Naoki wrote:
>
> I found WriteConsoleW() API recently.
> This API can write utf16 string to console directly, without change
> OutputCodepage.
> 
> example:
> http://bitbucket.org/methane/hg-fixutf8-jp/src/tip/win32helper.py#cl-42
> 
> I think this API is good for py3k.
> When stdout is console and not redirected to [pipe|file],
> sys.stdout.write(u"foo")
> can avoid encoding and use WriteConsoleW(L"foo")

Please submit a feature request to bugs.python.org -- with a patch would
be even nicer, of course.
-- 
Aahz ([email protected])   <*> http://www.pythoncraft.com/

"The volume of a pizza of thickness 'a' and radius 'z' is
given by pi*z*z*a"
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread Ben Finney

[email protected] writes:

> >> Can I ask that you also provide a link for windows users
> >> to my project:
> >>
> >>   http://sourceforge.net/projects/pythonpkgmgr/
> >
> > That doesn't seem at all appropriate; promoting third-party packages
> > isn't at all what the above document should be doing.
> 
> Distutils was once seperate and was then included in the standard
> python.
> 
> So i guess that I am working with the same goal in mind.

In which case you should work to get it accepted into standard Python
*before* asking for it to be promoted in the standard Python
documentation.

> So it is not inappropriate for me to ask about this on this list.

Discussing it here is appropriate. The modification you request is not,
IMO.

-- 
 \   “It's easy to play any musical instrument: all you have to do |
  `\   is touch the right key at the right time and the instrument |
_o__)will play itself.” —Johann Sebastian Bach |
Ben Finney

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

2009-07-23 Thread M.-A. Lemburg

David Lyon wrote:
> On Wed, 22 Jul 2009 23:22:56 +0200, "M.-A. Lemburg"  wrote:
>> Maybe I've misunderstood some important detail, but how will
>> their "change" help with anything other than making their
>> distribution a non-standard Python installation ?
> 
> The Debian/ubuntu distribution isn't non-standard. If anything
> I'd prefer to suggest that it is in many ways "a standard"

It's not just Debian mangling their Python installation. Many
other Linux distros do the same.

Keeping up with all those changes has become so hard, that we have
chosen to always build our projects with private (regular)
Python installations on Linux and Macs.

Disk space is cheap and so is bandwidth. Compared to the hours
spent on resolving issues with system provided Python
installations, it's a no-brainer.

> Here's a sys.pth from a mac...
> 
> ['', 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python26.zip', 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6', 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin',
> 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac',
> 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages',
> 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk', 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-old', 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload',
> 
> '/Users/david/.local/lib/python2.6/site-packages', 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages']
> 
> You can see that there are many choices along sys.path for installing
> packages.

No, not really. The above is perfectly standard.

The directories on sys.path are setup by Python itself and make
sure that it can find the stdlib modules. Those entries are not
meant to be used as installation targets.

Python 2.6 has two standard places for installing packages:

1. In the stdlib site-packages/ subdir

2. In the user home dir's .local/lib/python2.6/site-packages dir

The second is a new feature in 2.6.

>> distutils allows for a great deal of flexibility. For some
>> reason, this does not appear to be known to a larger
>> audience.
> 
> People forget command lines - that's why.
> 
>> I can only recommend reading Greg's great write-up about the
>> end-user perspective of installing Python modules:
>>
>> http://docs.python.org/install/
> 
> It's good documentation of course. Cheers to Greg but the
> old method is so tedious. That really is the hard way.

I think that's the main problem in all this... people
just keep on complaining regardless of what you give
them.

If people don't read documentation, are not willing
to at least spend a few minutes on considering what they
really want to do and then shout out loud when Python
doesn't do what they thought it should do (without telling
Python, of course), there's little hope.

> pythonpkgmgr offers a much easier solution by wrapping
> easy_install and/or pip. You just type in parts of the
> package name into a search box, click [search], a search
> of pypi is done, click [install] and your package is
> downloaded and installed.
> 
> It's a much more modern way of doing package installation
> and requires absolutely no typing on a command line.
> 
>> A little known fact is that distutils can easily be customized
>> using config files:
>>
>> http://docs.python.org/install/#distutils-configuration-files
> 
> Perphaps.
> 
> But it seems only for advanced users.. and I couldn't figure
> out on the face of it what advantage it would have.

You define once and for all where you want your
Python packages to install themselves when typing
"python setup.py install". After that's done, you can
forget about all this and move on to get some real
work done ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 23 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread Nick Coghlan

[email protected] wrote:
> Distutils is a builtin module for 'pushing' a developer package 'to' pypi.
> 
> But there is no corresponging mechanise for a user to 'pull' packages back.
> 
> Surely this is a gap in the standard distro?
> 
> So it is not inappropriate for me to ask about this on this list.

Raising it without at least glancing at the list archives which hold
copious amounts of virtual text on that topic is somewhat inappropriate
though :)

Cheers,
Nick.

P.S.
http://www.google.com/search?q=site:mail.python.org+inurl:python-dev+easy_install

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

2009-07-23 Thread Floris Bruynooghe

On Wed, Jul 22, 2009 at 07:08:26PM -0400, Glenn Maynard wrote:
> On Wed, Jul 22, 2009 at 5:22 PM, M.-A. Lemburg wrote:
> > Maybe I've misunderstood some important detail, but how will
> > their "change" help with anything other than making their
> > distribution a non-standard Python installation ?
> 
> I think I'm a little confused, too, because Python supports the
> /usr|/usr/local separation just fine (setup.py install
> --prefix=/usr/local).
> 
> It seems like it's also using "dist-packages" instead of
> "site-packages".  That part, I don't understand at all--distribution
> packages should go in /usr/lib/pythonx.y/site-packages, and "site"
> packages go in /usr/local/pythonx.y/site-packages; /usr/local *itself*
> means "non-distribution site-installed stuff".  If that's what you're
> referring to, then at least on first impression I agree.

The way Debian does this isn't that stupid.  It solves the problem of
the sysadmin intalling Python distibutions for the system Python
without writing in the system locations, which is a very reasonable
thing to do.

Before Debian used dist-packages,
/usr/local/lib/pythonX.Y/site-packages was added to the sys.path of
the system Python and this was the location where a sysadmin should
add packages (although distutils did not default to that location, so
it wasn so it was still easy to mess up the system package
management).  But this caused trouble for people who installed their
own Python in /usr/local since now you have the same
/usr/local/lib/pythonX.Y/site-packages shared by 2 interpreters.

To solve this the system python moved to dist-packages instead, this
allows the local admin location to use
/usr/local/lib/pythonX.Y/dist-packages which does not conflict with
locally installed interpreters.  Together with this they changed
distutils to install to /usr/local/lib/pythonX.Y/dist-packages by
default, so that a sysadmin would have to go out of their way to mess
up the system package management.

This is a pretty neat solution to the problem.  But the weird thing
(IMHO) is that distutils-sig completely refuses to see this
requirement.  Generally it seems accepted that installing modules in
the system location (/usr/) is a bad thing, but last time it got
discussed there was a point blank refusal to accept that the local
admin needs a location in to install packages in.  I think it would be
great if Python instead provided a general guideline or best practice
for this situation which would be explained in the documentation.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Antoine Pitrou

Christian Tismer  stackless.com> writes:
> 
> Despite the fact that Python probably has to be changed:
> If it is true then all the 32-bit Linux Pythons have a 12
> byte GC head, IOW they are *all* badly aligned.

Why are they badly aligned?
The fact that long double is 12 bytes long doesn't mean it will force a 12-byte
alignment - just whatever alignment is enough for a long double on the target
machine. This could be 4, 8 or 16 bytes.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

2009-07-23 Thread david . lyon

Hi Floris,

That's exactly how I see it and i totally agree.

My contribution is to make a Package Manager Gui that tries to be
supportive of what you describe so well.

If i have any complaint about the state of affairs it would only be that
it takes a newcomer such a long time (months) to fully understand what
should be a 5 minute thing as you so well describe below.

> On Wed, Jul 22, 2009 at 07:08:26PM -0400, Glenn Maynard wrote:
>> On Wed, Jul 22, 2009 at 5:22 PM, M.-A. Lemburg wrote:
>> > Maybe I've misunderstood some important detail, but how will
>> > their "change" help with anything other than making their
>> > distribution a non-standard Python installation ?
>>
>> I think I'm a little confused, too, because Python supports the
>> /usr|/usr/local separation just fine (setup.py install
>> --prefix=/usr/local).
>>
>> It seems like it's also using "dist-packages" instead of
>> "site-packages".  That part, I don't understand at all--distribution
>> packages should go in /usr/lib/pythonx.y/site-packages, and "site"
>> packages go in /usr/local/pythonx.y/site-packages; /usr/local *itself*
>> means "non-distribution site-installed stuff".  If that's what you're
>> referring to, then at least on first impression I agree.
>
> The way Debian does this isn't that stupid.  It solves the problem of
> the sysadmin intalling Python distibutions for the system Python
> without writing in the system locations, which is a very reasonable
> thing to do.
>
> Before Debian used dist-packages,
> /usr/local/lib/pythonX.Y/site-packages was added to the sys.path of
> the system Python and this was the location where a sysadmin should
> add packages (although distutils did not default to that location, so
> it wasn so it was still easy to mess up the system package
> management).  But this caused trouble for people who installed their
> own Python in /usr/local since now you have the same
> /usr/local/lib/pythonX.Y/site-packages shared by 2 interpreters.
>
> To solve this the system python moved to dist-packages instead, this
> allows the local admin location to use
> /usr/local/lib/pythonX.Y/dist-packages which does not conflict with
> locally installed interpreters.  Together with this they changed
> distutils to install to /usr/local/lib/pythonX.Y/dist-packages by
> default, so that a sysadmin would have to go out of their way to mess
> up the system package management.
>
> This is a pretty neat solution to the problem.  But the weird thing
> (IMHO) is that distutils-sig completely refuses to see this
> requirement.  Generally it seems accepted that installing modules in
> the system location (/usr/) is a bad thing, but last time it got
> discussed there was a point blank refusal to accept that the local
> admin needs a location in to install packages in.  I think it would be
> great if Python instead provided a general guideline or best practice
> for this situation which would be explained in the documentation.
>
>
> Regards
> Floris
>
>
> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/david.lyon%40preisshare.net
>


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread david . lyon


> Raising it without at least glancing at the list archives which hold
> copious amounts of virtual text on that topic is somewhat inappropriate
> though :)

Well I have consulted every available expert on the distutils list to the
point where I feel 'up' with the issues at hand.

They're great people.. And as helpful as they possibly can be..

But surely Python isn't only about archives and age old problems.

Sure they might be there.. So lets get in and fix them..

Which is totally what i'm attempting to do at the moment even if packaging
isnt perceived as being the most interesting part of python develepment
going on today.

Inapropriate or not, i want to donate my time to it.. Because i think we
need 'fresh' thinking - not archive regurgitation.


David

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Paul Moore

2009/7/22 Christian Tismer :
> Maybe the simple solution is to prevent building extensions
> with mingw, if the python executable was not also built with it?
> Then, all would be fine I guess.

I have never had problems in practice with extensions built with mingw
rather than MSVC - so while I'm not saying that the issue doesn't
exist, it certainly doesn't affect all extensions, so disabling mingw
support seems a bit of an extreme measure.

Having a preprocessor check in the Python headers to check if this bug
is triggered in the actual code, and raising a compile error in that
case, may be an option (but I expect that ensuring such a check is
precise enough would be hard).

Now that VC Express is freely available, the importance of mingw
support is less, but AFAIK many developers cross-compile Windows
binaries on Linux using mingw, or develop on gcc and use mingw to
build on Windows (or Wine) but wouldn't install VC. So removing mingw
support in cases where it does work would cause definite issues for
Windows users relying on prebuilt binaries.

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

2009-07-23 Thread Floris Bruynooghe

On Thu, Jul 23, 2009 at 10:34:30AM +0200, M.-A. Lemburg wrote:
> Python 2.6 has two standard places for installing packages:
> 
> 1. In the stdlib site-packages/ subdir
> 
> 2. In the user home dir's .local/lib/python2.6/site-packages dir

And is missing a 3rd one.  The sysadmin who wants to install packages
globally has to use the first option here, but that conflicts with the
system package management on UNIXes.

Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Christian Heimes

Lisandro Dalcin wrote:
> Eric seems to be working on a GSoC for PFS related to improving
> subprocess. Even in such case this list is not the right place to make
> these posts??

Eric didn't say that he is working on a GSoC project for the PSF. Anyway
the Python general mailing list might still be a better place. IMHO he
can reach many more competent Python developers there who can help him
with this particular problem.

By the way I don't think that ctypes is the right way to go here. ctypes
is very handy if you need a quick solution. However I wouldn't use it as
a permanent solution for the subprocess module. It's tricky to get
ctypes based solutions right on multiple platforms (32 vs 64bit). It's
harder to debug a ctypes solutions rather than a C extension, too. I
assume that calling overhead is greater than a pure C extension. Can
ctypes release the GIL for a function call?

Christian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Amaury Forgeot d'Arc

Hi,

2009/7/23 Christian Heimes :
> Lisandro Dalcin wrote:
>> Eric seems to be working on a GSoC for PFS related to improving
>> subprocess. Even in such case this list is not the right place to make
>> these posts??
>
> Eric didn't say that he is working on a GSoC project for the PSF. Anyway
> the Python general mailing list might still be a better place. IMHO he
> can reach many more competent Python developers there who can help him
> with this particular problem.

Furthermore it was more a Windows question than a Python one.
Anyway we continued the discussion privately and I try to be helpful.

> By the way I don't think that ctypes is the right way to go here. ctypes
> is very handy if you need a quick solution. However I wouldn't use it as
> a permanent solution for the subprocess module. It's tricky to get
> ctypes based solutions right on multiple platforms (32 vs 64bit). It's
> harder to debug a ctypes solutions rather than a C extension, too. I
> assume that calling overhead is greater than a pure C extension.

And some distributions may choose to not distribute the ctypes module.
No stdlib module should require it.
OTOH ctypes is the perfect tool for rapid development with the win32
api, specially when the compiler is far away.

> Can ctypes release the GIL for a function call?

Yes, see http://docs.python.org/library/ctypes.html#ctypes.CFUNCTYPE

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Thomas Heller

Christian Heimes schrieb:

> Can ctypes release the GIL for a function call?

It will do that automatically, except for functions
using the pythonapi callign convention.

-- 
Thanks,
Thomas

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Michael Foord


Amaury Forgeot d'Arc wrote:

Hi,

2009/7/23 Christian Heimes :
  

Lisandro Dalcin wrote:


Eric seems to be working on a GSoC for PFS related to improving
subprocess. Even in such case this list is not the right place to make
these posts??
  

Eric didn't say that he is working on a GSoC project for the PSF. Anyway
the Python general mailing list might still be a better place. IMHO he
can reach many more competent Python developers there who can help him
with this particular problem.



Furthermore it was more a Windows question than a Python one.
Anyway we continued the discussion privately and I try to be helpful.

  

By the way I don't think that ctypes is the right way to go here. ctypes
is very handy if you need a quick solution. However I wouldn't use it as
a permanent solution for the subprocess module. It's tricky to get
ctypes based solutions right on multiple platforms (32 vs 64bit). It's
harder to debug a ctypes solutions rather than a C extension, too. I
assume that calling overhead is greater than a pure C extension.



And some distributions may choose to not distribute the ctypes module.
No stdlib module should require it.
  


A big advantage of using ctypes is that it works cross-implementation - 
on IronPython and PyPy already and on Jython soon. I'd like to see more 
standard library modules use it. Distributions that choose not to 
include it are crippling their Python distribution.


Michael Foord


OTOH ctypes is the perfect tool for rapid development with the win32
api, specially when the compiler is far away.

  

Can ctypes release the GIL for a function call?



Yes, see http://docs.python.org/library/ctypes.html#ctypes.CFUNCTYPE

  



--
http://www.ironpythoninaction.com/

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Nick Coghlan

Christian Heimes wrote:
> By the way I don't think that ctypes is the right way to go here. ctypes
> is very handy if you need a quick solution. However I wouldn't use it as
> a permanent solution for the subprocess module. It's tricky to get
> ctypes based solutions right on multiple platforms (32 vs 64bit). It's
> harder to debug a ctypes solutions rather than a C extension, too. I
> assume that calling overhead is greater than a pure C extension.

I see ctypes as largely useful when you want to call a native DLL but
don't have any existing infrastructure for accessing native code from
your project. A few lines of ctypes code is then a much better solution
than adding a C or C++ compilation dependency just to access a couple of
functions.

Of course, that definitely isn't the case for CPython - we not only have
plenty of existing C infrastructure, but in the specific case of
subprocess on Windows we already have a dedicated extension module
(PC/_subprocess.c).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Nick Coghlan

Paul Moore wrote:
> 2009/7/22 Christian Tismer :
>> Maybe the simple solution is to prevent building extensions
>> with mingw, if the python executable was not also built with it?
>> Then, all would be fine I guess.
> 
> I have never had problems in practice with extensions built with mingw
> rather than MSVC - so while I'm not saying that the issue doesn't
> exist, it certainly doesn't affect all extensions, so disabling mingw
> support seems a bit of an extreme measure.

For runtime compatibility purposes, mingw is no worse than using
versions of MSVC other than the one that was used to build Python (i.e.
primarily making sure you use the correct memory management APIs and not
trying to call the FILE* APIs).

If there are other things that cause mingw to get structure sizes wrong
then I don't see a major problem with a config check or some #ifdef'ery
to work around it. A patch added to a tracker item would be a necessary
starting point for that idea though.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Christian Heimes

Michael Foord wrote:
> A big advantage of using ctypes is that it works cross-implementation -
> on IronPython and PyPy already and on Jython soon. I'd like to see more
> standard library modules use it. Distributions that choose not to
> include it are crippling their Python distribution.

Interesting, I didn't know that IronPython supports ctypes, too. I still
find ctypes a bit problematic because it doesn't us header files for its
types, structs and function definitions.

Christian

PS: I'n still reading your IronPython book. I hope I'll have some spare
time to write a review anytime soon.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread David Cournapeau

On Thu, Jul 23, 2009 at 6:49 PM, Paul Moore wrote:
> 2009/7/22 Christian Tismer :
>> Maybe the simple solution is to prevent building extensions
>> with mingw, if the python executable was not also built with it?
>> Then, all would be fine I guess.
>
> I have never had problems in practice with extensions built with mingw
> rather than MSVC - so while I'm not saying that the issue doesn't
> exist, it certainly doesn't affect all extensions, so disabling mingw
> support seems a bit of an extreme measure.

I am strongly against this as well. We build numpy with mingw on
windows, and disabling it would make my life even more miserable on
windows. One constant source of pain with MS compilers is when
supporting different versions of python - 2.4, 2.5 and 2.6 require a
different VS version (and free versions are available only for the
last version of VS usually).

I am far from a windows specialist, but I understand that quite a few
problems with mingw-built extensions with python are caused by some
Python decisions as well (the C API with runtime-dependent structures
like FILE, etc...). So mingw is not the only to blame :)

David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Christian Heimes

Nick Coghlan wrote:
> I see ctypes as largely useful when you want to call a native DLL but
> don't have any existing infrastructure for accessing native code from
> your project. A few lines of ctypes code is then a much better solution
> than adding a C or C++ compilation dependency just to access a couple of
> functions.
> 
> Of course, that definitely isn't the case for CPython - we not only have
> plenty of existing C infrastructure, but in the specific case of
> subprocess on Windows we already have a dedicated extension module
> (PC/_subprocess.c).

You've hit the nail on the head! That's it.

Christian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread Nick Coghlan

[email protected] wrote:
>> Raising it without at least glancing at the list archives which hold
>> copious amounts of virtual text on that topic is somewhat inappropriate
>> though :)
> 
> Well I have consulted every available expert on the distutils list to the
> point where I feel 'up' with the issues at hand.

If you're actually up to speed with the issues, then I apologise. It was
just something of a novelty to see the topic brought up without
easy_install and setuptools even getting a mention.

However, the reason for the asymmetry has less to do with code
(easy_install exists after all) and more to do with the complexities of
system administration.

Providing a native ability to download and install packages from PyPI is
a major maintenance commitment due to a couple of major issues:

1. Providing an installation mechanism that is compatibility with a wide
variety of package management systems across at least Windows, Mac OS X
and the assorted flavours of *nix (Linux RPM, Linux APT, Solaris, *BSD,
etc, etc).

distutils cops a lot of heat already for not playing nicely with distro
packages. easy_install is loathed even more by many system
administrators (and that loathing often appears to flow over onto other
parts of setuptools).

2. There are some serious security implications in providing a native
mechanism for downloading, installing and running code in a
non-sandboxed environment.

The latter problem is probably the more technical of the two, but both
pose fairly complex social issues as well in terms of getting agreement
across disparate groups.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Jean-Paul Calderone


On Thu, 23 Jul 2009 14:21:38 +0200, Christian Heimes  wrote:

Michael Foord wrote:

A big advantage of using ctypes is that it works cross-implementation -
on IronPython and PyPy already and on Jython soon. I'd like to see more
standard library modules use it. Distributions that choose not to
include it are crippling their Python distribution.


Interesting, I didn't know that IronPython supports ctypes, too. I still
find ctypes a bit problematic because it doesn't us header files for its
types, structs and function definitions.


This is indeed a big problem with ctypes.  Fortunately, a project exists
to correct it:

   http://pypi.python.org/pypi/ctypes_configure/0.1

Anyone writing code with ctypes should be looking at ctypes_configure as
well.

Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Jean-Paul Calderone


On Thu, 23 Jul 2009 14:23:56 +0200, Christian Heimes  wrote:

Nick Coghlan wrote:

I see ctypes as largely useful when you want to call a native DLL but
don't have any existing infrastructure for accessing native code from
your project. A few lines of ctypes code is then a much better solution
than adding a C or C++ compilation dependency just to access a couple of
functions.

Of course, that definitely isn't the case for CPython - we not only have
plenty of existing C infrastructure, but in the specific case of
subprocess on Windows we already have a dedicated extension module
(PC/_subprocess.c).


You've hit the nail on the head! That's it.



True, CPython has C infrastructure.  What about the other Python runtimes,
though?  At the language summit, there was a lot of discussion (and, I
thought, agreement) about moving the standard library to be a collaborative
project between several of the major runtime projects.  A ctypes-based
solution seems more aligned with this goal than more C code.

Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread Jesse Noller

On Thu, Jul 23, 2009 at 5:43 AM,  wrote:
>
>> Raising it without at least glancing at the list archives which hold
>> copious amounts of virtual text on that topic is somewhat inappropriate
>> though :)
>
> Well I have consulted every available expert on the distutils list to the
> point where I feel 'up' with the issues at hand.
>
> They're great people.. And as helpful as they possibly can be..
>
> But surely Python isn't only about archives and age old problems.
>
> Sure they might be there.. So lets get in and fix them..
>
> Which is totally what i'm attempting to do at the moment even if packaging
> isnt perceived as being the most interesting part of python develepment
> going on today.
>
> Inapropriate or not, i want to donate my time to it.. Because i think we
> need 'fresh' thinking - not archive regurgitation.
>
>
> David

Then why not include pip, easy_install, and this bash script I use to
install packages into core? The more the merrier, right?

Answer: None of these are standards, and as nick points out, there's
issues with sysadmins, security, and other things. Not to mention
they're fundamentally not part of the language.

At the language summit, this was hashed out quite a bit. I think most
everyone agreed that tools like easy_install, pip, virtualenv,
zc.buildout, etc simply do not belong in core python. The
"installation" landscape varies from platform to platform, it can run
full in the face of people who just want to use apt or yum, etc.

What *does* belong in core (distutils) however, and is something Tarek
has been working on, are APIs/Hooks/standards for tools like the ones
I've mentioned, and yours, to be able to do their job better, cleaner
and easier. Standards on metadata, uninstall hooks, etc are what the
stdlib should provide, not applications and tools built on top of
those things.

IMHO, the only "binary" python-core itself should "ship" is the python
binary itself (and pydoc, maybe :-)) - everything else should be built
with the idea of making integration with internals easier and
standard. That way OS package maintainers can hook into these APIs
(because they don't want to use something "non standard" to them),
people such as yourself can build GUI apps for downloading and
managing things, etc.

I know you want to help, and I don't think anyone is discouraging that
- but I think instead of solely focusing on your application is a
mistake. The bulk of the effort should be spent helping Tarek and
others "fix" distutils and spraying down bikeshedders so progress can
be made.

jesse
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Jesse Noller

On Thu, Jul 23, 2009 at 8:57 AM, Jean-Paul Calderone wrote:
> On Thu, 23 Jul 2009 14:23:56 +0200, Christian Heimes 
> wrote:
>>
>> Nick Coghlan wrote:
>>>
>>> I see ctypes as largely useful when you want to call a native DLL but
>>> don't have any existing infrastructure for accessing native code from
>>> your project. A few lines of ctypes code is then a much better solution
>>> than adding a C or C++ compilation dependency just to access a couple of
>>> functions.
>>>
>>> Of course, that definitely isn't the case for CPython - we not only have
>>> plenty of existing C infrastructure, but in the specific case of
>>> subprocess on Windows we already have a dedicated extension module
>>> (PC/_subprocess.c).
>>
>> You've hit the nail on the head! That's it.
>>
>
> True, CPython has C infrastructure.  What about the other Python runtimes,
> though?  At the language summit, there was a lot of discussion (and, I
> thought, agreement) about moving the standard library to be a collaborative
> project between several of the major runtime projects.  A ctypes-based
> solution seems more aligned with this goal than more C code.
>
> Jean-Paul

Yeah, I remember that too - all of us discussed "breaking out" the
stdlib post mercurial migration to be shared amongst all of the
implementations, marking CPython things as "CPython only" and so on.
That way we all have a common base to work from.

jesse
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for Python/Windows

2009-07-23 Thread Olemis Lang

On Wed, Jul 22, 2009 at 2:43 PM, "Martin v. Löwis" wrote:
>> My question is the following :
>>
>> - What are the implications for Py users ?
>
> So I stick with what you said is your question: What are the
> implications for Py users ?
>
> To this, the answer is mostly: none at all. There may be vague indirect
> effects (such as more Python software being available on Windows),
>

Well this being said, it seems to be cool.

>> - What are the implications for other devs (not core ;o) who use to
>> download sources and try new things, or perhaps use Py code the way
>> they want to solve an specific issue, or modify it somehow to
>> experiment or learn something, or whatever ?
>
> They can now get tools for free that they previously had to buy.
>

Well it seems that this applies to core devs and I was talking about
people not being Py core devs. But anyway, if everybody can still
compile Py sources without worrying about further licensing
side-effects (i.e. more than we have today ;) then the storm is gone.

>> - Will that affect contributions from «future or potential» devs ?
>
> This is an indirect effect; I doubt there is any noticable change
> (in particular as VS Express is free (as in beer) already).
>

Well my concern (and what I didnt understand) was that if some
people, in this case core devs, (need | like to have) the
license to do (use)  something they cannot do (use) without the
license then (possibly) everybody else (i.e. those
not having the license) trying to reproduce what others did (e.g.
compilation) had to purchase the license.

If this is not the case, and non-core devs can do what they do the
way they do it so far, then the storm is over ...

>> - Will they also need an MS license to see or compile (or whatever)
>> the changes contributed by Py devs ?
>
> Not more than currently already, no.

... and it seems that's the case ;o)

> You may not be aware that Python
> is *already* compiled by MSVC on Windows.
>

Yes I am, but since I'm a frustrated lawyer I didnt understand a few
things (and I couldnt sleep yesterday because of that ... XD ...)

>> I apologize in advance if I'm being rude or naïve or *
>
> I didn't consider your message rude. It is perhaps naïve (apparently
> ignoring the status quo), but you don't have to apologize for that.
>

Well I wanted to avoid flamewars or unnecessary disputes or whatever
(you know, this licensing and FOSS vs proprietary debates may be
complicated and sometimes people get excited /me included, of course :
I'm human ;o)

Thnx !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Amaury Forgeot d'Arc

2009/7/23 David Cournapeau :
> On Thu, Jul 23, 2009 at 6:49 PM, Paul Moore wrote:
>> 2009/7/22 Christian Tismer :
>>> Maybe the simple solution is to prevent building extensions
>>> with mingw, if the python executable was not also built with it?
>>> Then, all would be fine I guess.
>>
>> I have never had problems in practice with extensions built with mingw
>> rather than MSVC - so while I'm not saying that the issue doesn't
>> exist, it certainly doesn't affect all extensions, so disabling mingw
>> support seems a bit of an extreme measure.
>
> I am strongly against this as well. We build numpy with mingw on
> windows, and disabling it would make my life even more miserable on
> windows. One constant source of pain with MS compilers is when
> supporting different versions of python - 2.4, 2.5 and 2.6 require a
> different VS version (and free versions are available only for the
> last version of VS usually).
>
> I am far from a windows specialist, but I understand that quite a few
> problems with mingw-built extensions with python are caused by some
> Python decisions as well (the C API with runtime-dependent structures
> like FILE, etc...). So mingw is not the only to blame :)

In this case, the OP tries to use an API that is explicitly documented
as dangerous for extension modules.
The recommended function is not sensitive to compiler differences.

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]

2009-07-23 Thread Stephen J. Turnbull

Floris Bruynooghe writes:

 > [dist-packages] is a pretty neat solution to the problem.

To what problem?  I admit I am no expert on Python packaging, but my
experience with XEmacs suggests that this is the distro trying to help
with a *set* of problems that the user/sysadmins really should be
handling themselves.

There are varied requirements that lead to a need for yet another
place to install modules, but there's no guarantee that a given
user/sysadmin has *just one*.  With the Emacsen, often in trying to
satisfy several requirements they end up with conflicts (different
libraries in the site-lisp that are compiled for, or even require,
different versions of (X)Emacs or even trying to deal with Emacs and
XEmacs simultaneously).  And it's a pain (as an XEmacs maintainer) to
have to field questions about why things don't work in a set up I
didn't design, and don't understand the rationale for.

 > Generally it seems accepted that installing modules in the system
 > location (/usr/) is a bad thing, but last time it got discussed
 > there was a point blank refusal to accept that the local admin
 > needs a location in to install packages in.  I think it would be
 > great if Python instead provided a general guideline or best
 > practice for this situation which would be explained in the
 > documentation.

Yeah, so do we all, but I suspect that for Python, like the Emacsen,
there is *no* general guideline.  You're just asking for various kinds
of trouble, all of which require expert attention, by installing a
command that is invoked as "python" (as opposed to "pythonX.Y") in
/usr/local/bin unless you intend it to be a complete substitute for
the system python.  And that itself is a serious tour de force (as
anybody who remembers Red Hat's love affair with Python 1.5.2 will
agree, I suspect).

As far as I can see, *in general* /usr/local/lib/python/site-packages
is the right place to install local packages for use with the system
python, and no other.  That doesn't mean that there aren't *other*
valid uses for that location, just that I see no general rule for
supporting *all* of them at the same time.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Thomas Heller

Jean-Paul Calderone schrieb:
> On Thu, 23 Jul 2009 14:21:38 +0200, Christian Heimes  wrote:
>>Michael Foord wrote:
>>> A big advantage of using ctypes is that it works cross-implementation -
>>> on IronPython and PyPy already and on Jython soon. I'd like to see more
>>> standard library modules use it. Distributions that choose not to
>>> include it are crippling their Python distribution.
>>
>>Interesting, I didn't know that IronPython supports ctypes, too. I still
>>find ctypes a bit problematic because it doesn't us header files for its
>>types, structs and function definitions.
> 
> This is indeed a big problem with ctypes.  Fortunately, a project exists
> to correct it:
> 
> http://pypi.python.org/pypi/ctypes_configure/0.1
> 
> Anyone writing code with ctypes should be looking at ctypes_configure as
> well.

There is also another project that uses gccxml to parse the header files
and generate ctypes-compatible code.

http://web.archive.org/web/20080115092648/starship.python.net/crew/theller/wiki/CodeGenerator

Especially well on Windows works the dynamic, on-demand code generation.

http://web.archive.org/web/20080115092648/starship.python.net/crew/theller/wiki/CodeGenerator/DynamicModule

I do all win32 api programming with this stuff.

I should note that the ctypeslib project is not well maintained because
I don't have the time for that any longer.

-- 
Thanks,
Thomas

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python sendmsg()/recvmsg() implementation

2009-07-23 Thread Kálmán Gergely


Hello

This is the rewritten-from-scratch implementation of the 
sendmsg()/recvmsg() methods.
Any comments / suggestions / flames are very welcome. Currently it 
supports what I need
and I'm only releasing it, because I don't have much time to develop it 
further in the
forseeable future (1-2 months). It is rewritten from scratch, using the 
python c-api
documents. I've tried my best, but I wouldn't bet that it works as it's 
supposed to. I'd be

glad if someone could give me a review on what I've done wrong.

The core parts are implemented correctly (I think), the features that 
are missing:

- using scatter/gather
- using it with non-stream oriented sockets (doesn't support addresses 
/msg_name/)


These should be very easy to implement though. I will fix the errors 
that are present right
now, and if no one takes up the task I will implement the missing 
features also. You might

have to wait for it a little though.

Thanks in advance

Cheers,
Kalman Gergely
--- py3k_2/Modules/socketmodule.c	2009-07-23 17:07:55.474581000 +0200
+++ py3k/Modules/socketmodule.c	2009-07-23 17:22:16.880415500 +0200
@@ -2388,6 +2388,7 @@
 	return n;
 }
 
+
 /* s.recvfrom(nbytes [,flags]) method */
 
 static PyObject *
@@ -2440,6 +2441,143 @@
 Like recv(buffersize, flags) but also return the sender's address info.");
 
 
+/* s.recvmsg(datalen, controllen, flags) method */
+
+static PyObject *
+sock_recvmsg(PySocketSockObject *s, PyObject *args)
+{
+	PyObject *dbuf, *cbuf, *alist, *tmp;
+	ssize_t n = -1;
+	int status, timeout;
+	int rdlen, rclen, flags = 0;
+	struct msghdr mhdr;
+	struct cmsghdr *chdr;
+	struct iovec iov[1];
+
+	if (!PyArg_ParseTuple(args, "ii|i:recvmsg", &rdlen, &rclen, &flags))
+		return NULL;
+
+	if (rdlen < 0 || rclen < 0)
+	{
+		PyErr_SetString(PyExc_ValueError, "negative buffersize in recvmsg");
+		return NULL;
+	}
+
+	/* allocate buffers */
+	dbuf = PyBytes_FromStringAndSize((char *) 0, rdlen);
+	if (dbuf == NULL)
+	{
+		return NULL;
+	}
+
+	cbuf = PyBytes_FromStringAndSize((char *) 0, rclen);
+	if (cbuf == NULL)
+	{
+		Py_DECREF(dbuf);
+		return NULL;
+	}
+
+	alist = PyList_New(0);
+	if (alist == NULL)
+	{
+		Py_DECREF(dbuf);
+		Py_DECREF(cbuf);
+		return NULL;
+	}
+
+	/* set up the msghdr struct */
+	memset(&mhdr, 0, sizeof(struct msghdr));
+
+	// iov -- we use only one buffer, and don't use scatter-gather possible TODO
+	iov[0].iov_base = PyBytes_AS_STRING(dbuf);
+	iov[0].iov_len = rdlen;
+	memset(iov[0].iov_base, 0, iov[0].iov_len);
+
+	// msghdr
+	mhdr.msg_name = NULL;// TODO make use of this
+	mhdr.msg_namelen = 0;
+	mhdr.msg_iov = iov;
+	mhdr.msg_iovlen = 1;
+	mhdr.msg_control = PyBytes_AS_STRING(cbuf);
+	mhdr.msg_controllen = rclen;
+	mhdr.msg_flags = 0;
+	memset(mhdr.msg_control, 0, mhdr.msg_controllen);
+
+	/* call recvmsg() */
+	Py_BEGIN_ALLOW_THREADS
+	timeout = internal_select(s, 0);
+	if (!timeout)
+		n = recvmsg(s->sock_fd, &mhdr, flags);
+	Py_END_ALLOW_THREADS
+
+	if (timeout == 1)
+	{
+		PyErr_SetString(socket_timeout, "timed out");
+		goto err;
+	}
+
+	if (n < 0)
+	{
+		s->errorhandler();
+		goto err;
+	}
+
+	/* process the ancillary data */
+	for (chdr = CMSG_FIRSTHDR(&mhdr); chdr != NULL; chdr = CMSG_NXTHDR(&mhdr, chdr))
+	{
+		tmp = Py_BuildValue("(iiy#)", chdr->cmsg_level, chdr->cmsg_type, (char *)CMSG_DATA(chdr),
+// TODO XXX ugly hack, to compute CMSG_DATA's size
+(int)chdr->cmsg_len - ((int)CMSG_DATA(chdr) - (int)chdr));
+		if (tmp == NULL)
+			goto err;
+
+		status = PyList_Append(alist, tmp);
+		Py_DECREF(tmp);
+
+		if (status == -1)
+			goto err;
+	}
+
+	/* if we received less than we anticipated, resize the buffer */
+	if (n != rdlen)
+	{
+		if (_PyBytes_Resize(&dbuf, n) == -1)
+		{
+			Py_DECREF(cbuf);
+			Py_DECREF(alist);
+			return NULL;
+		}
+	}
+
+	/* assemble the final return value, watch out for offsets! */
+	tmp = PyTuple_New(3);
+	if (tmp == NULL)
+		goto err;
+
+	PyTuple_SetItem(tmp, 0, dbuf);
+	PyTuple_SetItem(tmp, 1, alist);
+	PyTuple_SetItem(tmp, 2, Py_BuildValue("i", mhdr.msg_flags));
+
+	/* dbuf and alist are now in tmp, remove reference to cbuf and return */
+	Py_DECREF(cbuf);
+
+	return tmp;
+
+err:
+	Py_DECREF(dbuf);
+	Py_DECREF(cbuf);
+	Py_DECREF(alist);
+	return NULL;
+}
+
+PyDoc_STRVAR(recvmsg_doc,
+"recvmsg(datalen, controllen, flags) method -> (bytes(), [(msglevel, msgtype, msgdata) ... ], flags)\n\
+\n\
+Returns a tuple with three elements, 0: data bytes, 1: list of tuples with three elements\n\
+containing msg_level, msg_type, msg_data, 2: msg_flags\n\
+Currently it's incapable of using multiple buffers and addresses.");
+
+
 /* s.recvfrom_into(buffer[, nbytes [,flags]]) method */
 
 static PyObject *
@@ -2655,6 +2793,140 @@
 For IP sockets, the address is a pair (hostaddr, port).");
 
 
+/* s.sendmsg(data, [(msglevel, msgtype, msgdata), ...], flags) method */
+
+static PyObject *
+sock_sendmsg(PySocketSockObject *s, PyObject *args)
+{
+	Py_buffer dbuf;
+	PyObject *cbuf;
+	PyObject *tmp;
+	Py_buffer tmpdata;
+	PyObject *control;
+	size_t

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Lisandro Dalcin

On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote:

>
> True, CPython has C infrastructure.  What about the other Python runtimes,
> though?
>

Perhaps these other Python runtimes could implement the functionality
of PC/_subprocess.c and use ctypes for that ?



-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python sendmsg()/recvmsg() implementation

2009-07-23 Thread Aahz

On Thu, Jul 23, 2009, K?lm?n Gergely wrote:
>
> This is the rewritten-from-scratch implementation of the
> sendmsg()/recvmsg() methods.  Any comments / suggestions / flames are
> very welcome. Currently it supports what I need and I'm only releasing
> it, because I don't have much time to develop it further in the
> forseeable future (1-2 months). It is rewritten from scratch, using
> the python c-api documents. I've tried my best, but I wouldn't bet
> that it works as it's supposed to. I'd be glad if someone could give
> me a review on what I've done wrong.

Please post this to bugs.python.org
-- 
Aahz ([email protected])   <*> http://www.pythoncraft.com/

"The volume of a pizza of thickness 'a' and radius 'z' is
given by pi*z*z*a"
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Georg Brandl

Hi all,

is the presence of None values in sys.modules considered an implementation
detail?  If not, it should be documented what the None values mean to the
interpreter.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Fred Drake


On Jul 23, 2009, at 2:59 PM, Georg Brandl wrote:
is the presence of None values in sys.modules considered an  
implementation
detail?  If not, it should be documented what the None values mean  
to the

interpreter.



As I recall, they're an optimization.  But since sys.modules is itself  
documented, and many applications actually use it, I think it's worth  
explaining that the None values can reasonably be expected, and what  
they indicate.



  -Fred

--
Fred Drake   

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Guido van Rossum

On Thu, Jul 23, 2009 at 12:09 PM, Fred Drake wrote:
> On Jul 23, 2009, at 2:59 PM, Georg Brandl wrote:
>>
>> is the presence of None values in sys.modules considered an implementation
>> detail?  If not, it should be documented what the None values mean to the
>> interpreter.
>
> As I recall, they're an optimization.  But since sys.modules is itself
> documented, and many applications actually use it, I think it's worth
> explaining that the None values can reasonably be expected, and what they
> indicate.

They should certainly be documented -- without them imports from
inside package would be super expensive (at least for Python versions
where implicit relative import exists). I'm somewhat surprised this
isn't documented, I don't think I've tried to keep this usage hidden.
I've also sometimes abused this to force some module to believe that a
certain other module doesn't exist.

OTOH in Py3k I'm not sure that we even *need* them any more, since
there is no more implicit relative import... They would only speed up
the raising of ImportError, not the finding of a similar-named module
elsewhere in the hierarchy.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Terry Reedy


Lisandro Dalcin wrote:

On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote:


True, CPython has C infrastructure.  What about the other Python runtimes,
though?



Perhaps these other Python runtimes could implement the functionality
of PC/_subprocess.c and use ctypes for that ?


Is it sensibly possible to augment a C file with #ifdefs so that it can 
be compiled either as a directly importable module or as a 
ctypes-accessible shared library?


tjr

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Christian Tismer


On 7/23/09 2:04 AM, Antoine Pitrou wrote:

Christian Tismer  stackless.com>  writes:

Despite the fact that Python probably has to be changed:
If it is true then all the 32-bit Linux Pythons have a 12
byte GC head, IOW they are *all* badly aligned.


Why are they badly aligned?
The fact that long double is 12 bytes long doesn't mean it will force a 12-byte
alignment - just whatever alignment is enough for a long double on the target
machine. This could be 4, 8 or 16 bytes.


Things are a bit different:

Alignment is not the primary concern of the gc header structure.
Note that all the objects are created by malloc (system or python's
arena allocator), and therefore all objects are correctly aligned
by construction.

The point is: The GC header is a structure invisible to the "real"
gc allocated objects. It is opaquely prepended to every gc aware
object. Therefore, it *needs* to have the correct size, in order
to propagate its (already correct) alignment to the real object.

It appears that python, compiled with gcc for all x64 32bit Linuxen
(and mingw32) produces a 12 byte GC header. Not relevant for the
header itself, but all GC objects are misaligned.

This may not be recognized so far, because there is no builtin
GC-enabled type that embeds a double.
But if you create such a type, then the double will be correctly
aligned in your object's structure, but then, when the object
gets allocated, it is misaligned, because the header size is not a
multiple of 8.

To Martin: So I disagree. The gc header is not responsible for
alignment in the first place, but to propagate it, correctly.
And this fails miserably (in principle) since years.

Proposal: We should use a simple construct that makes the
gc header size simply a multiple of 8 or 16, whatever needed.
Even a byte array would be ok.

But please no long double :-)

cheers - chris
--
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Antoine Pitrou

Christian Tismer  stackless.com> writes:
> 
> The point is: The GC header is a structure invisible to the "real"
> gc allocated objects. It is opaquely prepended to every gc aware
> object. Therefore, it *needs* to have the correct size, in order
> to propagate its (already correct) alignment to the real object.

Indeed.

> This may not be recognized so far, because there is no builtin
> GC-enabled type that embeds a double.
> But if you create such a type, then the double will be correctly
> aligned in your object's structure, but then, when the object
> gets allocated, it is misaligned, because the header size is not a
> multiple of 8.

I'm not sure a double aligned on a 4-byte boundary is "misaligned" on a x86 CPU.
Alignment is primarily important to avoid access violations on CPUs and
datatypes which don't support arbitrary alignment, although it can also be
useful for performance reasons.

In any case, you seem to be right on this particular point: the PyGC_Head union
should probably contain a "double" alternative in addition to the "long double"
(and perhaps even a "long long" one).
Of course, it will also make memory consumption a tad bigger for GC-enabled
objects (but GC-enabled objects are generally not that small anyway).

(I disagree, however, that we should remove the "long double". After all, we
also want alignment of PyObjects to allow inclusion of a "long double" in them)

Feel free to propose a patch on bugs.python.org, by the way.

Regards

Antoine.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Antoine Pitrou

Antoine Pitrou  pitrou.net> writes:
> 
> In any case, you seem to be right on this particular point: the PyGC_Head 
> union
> should probably contain a "double" alternative in addition to the "long 
> double"
> (and perhaps even a "long long" one).

Sorry, I realize that this doesn't really address the point.
In addition to that union, we should also have a particular mechanism to compute
what the proper offset should be between the PyGC_Head and the PyObject.
Probably something like:

typedef struct {
PyGC_Head head;
union {
  /* ... similar union as in PyGC_head */
} body;
} _PyGC_dummy;

#define _PyGC_Head_OFFSET offsetof(_PyGC_dummy, body)
#define _Py_AS_GC(o) ((PyGC_Head *) ((void *)(o) - _PyGC_Head_OFFSET))

Regards

Antoine.



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Christian Tismer


On 7/23/09 2:27 PM, Antoine Pitrou wrote:

Christian Tismer  stackless.com>  writes:

...


I'm not sure a double aligned on a 4-byte boundary is "misaligned" on a x86 CPU.


I'm also not sure. Anyway, the result was neither intended nor
expected, I guess.


Alignment is primarily important to avoid access violations on CPUs and
datatypes which don't support arbitrary alignment, although it can also be
useful for performance reasons.


Performance, performance, of course (that's my job, after all :-) )
...


Of course, it will also make memory consumption a tad bigger for GC-enabled
objects (but GC-enabled objects are generally not that small anyway).


For that reason, I don't like the addition of the opaque header
too much. If there were an option to make the header explicit,
we would not have to round up the object size to a multiple
of (8, 16), but could arrange embedded doubles as they fit the best.


(I disagree, however, that we should remove the "long double". After all, we
also want alignment of PyObjects to allow inclusion of a "long double" in them)


Well, I doubt that a 12 byte long double causes any other
alignment but 4.
--
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread David Lyon

On Thu, 23 Jul 2009 18:30:58 +1000, Ben Finney 
wrote:
> In which case you should work to get it accepted into standard Python
> *before* asking for it to be promoted in the standard Python
> documentation.

I'm very interested in how I would go about doing that. 

Die-hard users probably know all the python issues relating to
package installation and appear to have thick skins. An "easy-way"
might not mean to much to them because they've settled down into
their own comfort zone.

But new users, who's first operating system comes complete with a
polished GUI, have an expectation for having a polished GUI tool
to download their python packages in.

Under Windows, we get IDLE. And ActiveState as I understand are
working on their own package manager for their own python distribution.

So maybe it is appropriate to consider having a GUI Package Manager
within at least the Windows distribution of Python.

Yes, please tell me the process...

I'm very interested.

David

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread Christian Heimes

[email protected] wrote:
>> That's a document describing how to use âdistutilsâ, which is what
>> every
>> recipient of Python will already have installed.
>>
>>> Can I ask that you also provide a link for windows users
>>> to my project:
>>>
>>>   http://sourceforge.net/projects/pythonpkgmgr/
>> That doesn't seem at all appropriate; promoting third-party packages
>> isn't at all what the above document should be doing.
> 
> Distutils was once seperate and was then included in the standard python.
> 
> So i guess that I am working with the same goal in mind.

I'm sorry to inform you that a wxWindows based solution has zero change
to get into the Python standard library ever. We are not going to add
another GUI toolkit to the core distribution. We might even remove TK
from the core and ship it as a separate package like bsddb3.

Christian

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pthreads, fork, import, and execvp

2009-07-23 Thread Thomas Wouters

So attached (and at http://codereview.appspot.com/96125/show ) is a
preliminary fix, correcting the problem with os.fork(), os.forkpty() and
os.fork1(). This doesn't expose a general API for C code to use, for two
reasons: it's not easy, and I need this fix more than I need the API change
:-) (I actually need this fix myself for Python 2.4, but it applies fairly
cleanly.)

To fix the mutex-across-fork problem correctly we should really acquire
three locks (the import lock, the GIL and the TLS lock, in that order.) The
import lock is re-entrant, and the TLS lock is tightly confined to the
thread-local-storage lookup functions, but the GIL is neither re-entrant nor
inspectable. That means we can't use pthread_atfork (we can't tell whether
we have the GIL already or not, right before the fork), nor can we provide a
convenient API for extension modules to use, really. The best we can do is
provide three functions, pthread_atfork-style: a 'prepare' function, an
'after-fork-in-child' function, and an 'after-fork-in-parent' function. The
'prepare' function would start by releasing the GIL, then acquire the import
lock, the GIL and the TLS lock in that order. It would also record
*somewhere* the thread_ident of the current thread. The 'in-parent' function
would simply release the TLS lock and the import lock, and the 'in-child'
would release those locks, call the threading._at_fork() function, and fix
up the TLS data, using the recorded thread ident to do lookups. The
'in-child' function would replace the current PyOS_AfterFork() function
(which blindly reinitializes the GIL and the TLS lock, and calls
threading._at_fork().)

Alternatively we could do what we do now, which is to ignore the fact that
thread idents may change by fork() and thus that thread-local data may
disappear, in which case the 'in-child' function could do a little less
work. I'm suitably scared and disgusted of the TLS implementation, the
threading implementations we support (including the pthread one) and the way
we blindly type-pun a pthread_t to a long, that I'm not sure I want to try
and build something correct and reliable on top of it.

-- 
Thomas Wouters 

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
Index: Python/import.c
===
--- Python/import.c	(revision 74154)
+++ Python/import.c	(working copy)
@@ -256,8 +256,8 @@
 static long import_lock_thread = -1;
 static int import_lock_level = 0;
 
-static void
-lock_import(void)
+void
+_PyImport_AcquireLock(void)
 {
 	long me = PyThread_get_thread_ident();
 	if (me == -1)
@@ -281,8 +281,8 @@
 	import_lock_level = 1;
 }
 
-static int
-unlock_import(void)
+int
+_PyImport_ReleaseLock(void)
 {
 	long me = PyThread_get_thread_ident();
 	if (me == -1 || import_lock == NULL)
@@ -303,17 +303,8 @@
 void
 _PyImport_ReInitLock(void)
 {
-#ifdef _AIX
-	if (import_lock != NULL)
-		import_lock = PyThread_allocate_lock();
-#endif
 }
 
-#else
-
-#define lock_import()
-#define unlock_import() 0
-
 #endif
 
 static PyObject *
@@ -330,7 +321,7 @@
 imp_acquire_lock(PyObject *self, PyObject *noargs)
 {
 #ifdef WITH_THREAD
-	lock_import();
+	_PyImport_AcquireLock();
 #endif
 	Py_INCREF(Py_None);
 	return Py_None;
@@ -340,7 +331,7 @@
 imp_release_lock(PyObject *self, PyObject *noargs)
 {
 #ifdef WITH_THREAD
-	if (unlock_import() < 0) {
+	if (_PyImport_ReleaseLock() < 0) {
 		PyErr_SetString(PyExc_RuntimeError,
 "not holding the import lock");
 		return NULL;
@@ -2183,9 +2174,9 @@
 			 PyObject *fromlist, int level)
 {
 	PyObject *result;
-	lock_import();
+	_PyImport_AcquireLock();
 	result = import_module_level(name, globals, locals, fromlist, level);
-	if (unlock_import() < 0) {
+	if (_PyImport_ReleaseLock() < 0) {
 		Py_XDECREF(result);
 		PyErr_SetString(PyExc_RuntimeError,
 "not holding the import lock");
Index: Include/import.h
===
--- Include/import.h	(revision 74154)
+++ Include/import.h	(working copy)
@@ -27,6 +27,14 @@
 PyAPI_FUNC(void) PyImport_Cleanup(void);
 PyAPI_FUNC(int) PyImport_ImportFrozenModule(char *);
 
+#ifdef WITH_THREAD
+PyAPI_FUNC(void) _PyImport_AcquireLock(void);
+PyAPI_FUNC(int) _PyImport_ReleaseLock(void);
+#else
+#define _PyImport_AcquireLock()
+#define _PyImport_ReleaseLock() 1
+#endif
+
 PyAPI_FUNC(struct filedescr *) _PyImport_FindModule(
 	const char *, PyObject *, char *, size_t, FILE **, PyObject **);
 PyAPI_FUNC(int) _PyImport_IsScript(struct filedescr *);
Index: Lib/test/test_fork1.py
===
--- Lib/test/test_fork1.py	(revision 74154)
+++ Lib/test/test_fork1.py	(working copy)
@@ -1,11 +1,18 @@
 """This test checks for correct fork() behavior.
 """
 
+import errno
+import imp
 import os
+import signal
+import sys
 import time
+import threading
+
 from test.fork_wait import ForkWait
 from test.test_support import TestSkipped, run_unittest, reap_children

Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-23 Thread Antoine Pitrou

Christian Tismer  stackless.com> writes:
> 
> Well, I doubt that a 12 byte long double causes any other
> alignment but 4.

In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!).

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] REVIEW: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.

2009-07-23 Thread Sean Reifschneider

Please review this, I'm worried that there are cases where convertitem() is
returning a string that really should be overridden by the argument "help
string".  However, I'm worried that this change will get rid of useful
messages (via the format "; help string"), when there otherwise wouldn't
be.

PyArg_ParseTuple when handling a string format "s", raises a TypeError
when the passed string contains a NUL.  However, the TypeError doesn't
contain useful information.

For example:

   syslog.syslog('hello\0there')
   TypeError: [priority,] message string

This seems to be a thinko in Python/getargs.c at line 331:

   msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va,
flags, levels, msgbuf,
sizeof(msgbuf), &freelist);
   if (msg) {
  seterror(i+1, msg, levels, fname, message);   <<< Line 331
  return cleanreturn(0, freelist);
   }

This also applies to Python 3 trunk in line 390.

I think that's supposed to be "msg" instead of "message" in the last
argument.  If I change it, I get:

   >>> import syslog; syslog.syslog('hello\0there')
   Traceback (most recent call last):
 File "", line 1, in 
   TypeError: must be string without null bytes, not str

I think it's safe to change "message" to "msg" because:

   "message" is the "help" string "[priority,] message string",
   but "msg" contains much more useful information.

   "msg" is in the "fall back if the last argument doesn't contain useful
   information" argument position, but "msg" is never NULL.

   "message" only is NULL if the format string doesn't contain ";".

   In every case I can find in the code, convertitem() is returning a
   much more useful string than the help string.

Or perhaps it should do something like:

   if (msg) {
  seterror(i+1, msg, levels, fname, '%s (%s)' % ( msg, message ));

Pardon my mixed C+Python, but you get the idea.

Thoughts?

Thanks,
Sean
-- 
 [...] Premature optimization is the root of all evil.
 -- Donald Knuth
Sean Reifschneider, Member of Technical Staff 
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update to Python Documentation Website Request

2009-07-23 Thread David Lyon

On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes 
wrote:
> I'm sorry to inform you that a wxWindows based solution has zero change
> to get into the Python standard library ever. We are not going to add
> another GUI toolkit to the core distribution. 

In executable form, the Package Manager does not require wxWidgets
to be installed.

There is no dependency for this to be installed.

I'm not requesting that wxPython be added to the standard python
distribution.

> We might even remove TK
> from the core and ship it as a separate package like bsddb3.

That doesn't affect the Python Package Manager in any way.

David

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Brett Cannon

On Thu, Jul 23, 2009 at 13:05, Guido van Rossum  wrote:

> On Thu, Jul 23, 2009 at 12:09 PM, Fred Drake wrote:
> > On Jul 23, 2009, at 2:59 PM, Georg Brandl wrote:
> >>
> >> is the presence of None values in sys.modules considered an
> implementation
> >> detail?  If not, it should be documented what the None values mean to
> the
> >> interpreter.
> >
> > As I recall, they're an optimization.  But since sys.modules is itself
> > documented, and many applications actually use it, I think it's worth
> > explaining that the None values can reasonably be expected, and what they
> > indicate.
>
> They should certainly be documented -- without them imports from
> inside package would be super expensive (at least for Python versions
> where implicit relative import exists). I'm somewhat surprised this
> isn't documented, I don't think I've tried to keep this usage hidden.
> I've also sometimes abused this to force some module to believe that a
> certain other module doesn't exist.
>

It has not been hidden, but the only place I ever came across it was in the
original essay about packages.


>
> OTOH in Py3k I'm not sure that we even *need* them any more, since
> there is no more implicit relative import... They would only speed up
> the raising of ImportError, not the finding of a similar-named module
> elsewhere in the hierarchy.


None in Python 3.1 is really useless in terms of its semantics in relative
imports; importlib doesn't support it and still passes as __import__ (at
least last time I ran the test suite that way). I thought we had agreed a
while back that supporting None was not warranted in Python 3.0? Otherwise I
will do whatever work is necessary for this to happen.

-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Benjamin Peterson

2009/7/23 Brett Cannon :
> None in Python 3.1 is really useless in terms of its semantics in relative
> imports; importlib doesn't support it and still passes as __import__ (at
> least last time I ran the test suite that way). I thought we had agreed a
> while back that supporting None was not warranted in Python 3.0? Otherwise I
> will do whatever work is necessary for this to happen.

I think it's still nice for the rare cases where you need to trick a
module into thinking another one doesn't exist.

-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Brett Cannon

On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson wrote:

> 2009/7/23 Brett Cannon :
> > None in Python 3.1 is really useless in terms of its semantics in
> relative
> > imports; importlib doesn't support it and still passes as __import__ (at
> > least last time I ran the test suite that way). I thought we had agreed a
> > while back that supporting None was not warranted in Python 3.0?
> Otherwise I
> > will do whatever work is necessary for this to happen.
>
> I think it's still nice for the rare cases where you need to trick a
> module into thinking another one doesn't exist.

But None does not strictly mean "I don't exist". None is supposed to trigger
an another import attempt for the module with a top-level name. It's that
extra import trigger that has no real use in 3.0 and just complicates import
semantics (IMO) needlessly. If you want a module to not exist then you
either stick something else in (e.g. '42') or we remove the special
semantics for None (which I thought we had).

-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Benjamin Peterson

2009/7/23 Brett Cannon :
>
>
> On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson 
> wrote:
>>
>> 2009/7/23 Brett Cannon :
>> > None in Python 3.1 is really useless in terms of its semantics in
>> > relative
>> > imports; importlib doesn't support it and still passes as __import__ (at
>> > least last time I ran the test suite that way). I thought we had agreed
>> > a
>> > while back that supporting None was not warranted in Python 3.0?
>> > Otherwise I
>> > will do whatever work is necessary for this to happen.
>>
>> I think it's still nice for the rare cases where you need to trick a
>> module into thinking another one doesn't exist.
>
> But None does not strictly mean "I don't exist". None is supposed to trigger
> an another import attempt for the module with a top-level name. It's that
> extra import trigger that has no real use in 3.0 and just complicates import
> semantics (IMO) needlessly. If you want a module to not exist then you
> either stick something else in (e.g. '42') or we remove the special
> semantics for None (which I thought we had).


I didn't realize None had other semantics attached to it. (Imagine
that dealing with import!) +1 for making it simply indicate an
ImportError.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Brett Cannon

On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson wrote:

> 2009/7/23 Brett Cannon :
> >
> >
> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson 
> > wrote:
> >>
> >> 2009/7/23 Brett Cannon :
> >> > None in Python 3.1 is really useless in terms of its semantics in
> >> > relative
> >> > imports; importlib doesn't support it and still passes as __import__
> (at
> >> > least last time I ran the test suite that way). I thought we had
> agreed
> >> > a
> >> > while back that supporting None was not warranted in Python 3.0?
> >> > Otherwise I
> >> > will do whatever work is necessary for this to happen.
> >>
> >> I think it's still nice for the rare cases where you need to trick a
> >> module into thinking another one doesn't exist.
> >
> > But None does not strictly mean "I don't exist". None is supposed to
> trigger
> > an another import attempt for the module with a top-level name. It's that
> > extra import trigger that has no real use in 3.0 and just complicates
> import
> > semantics (IMO) needlessly. If you want a module to not exist then you
> > either stick something else in (e.g. '42') or we remove the special
> > semantics for None (which I thought we had).
>
>
> I didn't realize None had other semantics attached to it. (Imagine
> that dealing with import!) +1 for making it simply indicate an
> ImportError.


I'm +0 with having import raise ImportError if None is set in sys.modules as
long as we don't suddenly expect loaders to trigger the same thing if they
return None (actually, as of right now what loaders return count for
nothing, but just want to be clear).

-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Lisandro Dalcin

On Thu, Jul 23, 2009 at 5:42 PM, Terry Reedy wrote:
> Lisandro Dalcin wrote:
>>
>> On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone
>> wrote:
>>
>>> True, CPython has C infrastructure.  What about the other Python
>>> runtimes,
>>> though?
>>>
>>
>> Perhaps these other Python runtimes could implement the functionality
>> of PC/_subprocess.c and use ctypes for that ?
>
> Is it sensibly possible to augment a C file with #ifdefs so that it can be
> compiled either as a directly importable module or as a ctypes-accessible
> shared library?
>

Of course it is posible... Moreover, you could likely reuse 100 % of
code intended for ctypes in implementing the extension module calls
intended for Python. Mac OS X could have some issues though (IIUC, .so
ext modules are not the same as .dylib dynamic libs, though perhaps
ctypes can still dlopen() .so files?)

However, how that would help these other Python runtimes without C
infraestructure ??



-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Guido van Rossum

So, I guess, we'll live with it for a while longer. Given that it
managed to evade our attention for so long, I think that's fine.

I agree that there's no reason for a None result from loaders to be
interpreted the same way, assuming that's not how it works ATM.

And we can live with import and importlib differing on this in 3.1
(though you could call it a bug in importlib and fix it for 3.1.1 --
not sure if you were planning on that).

--Guido

On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon wrote:
>
>
> On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson 
> wrote:
>>
>> 2009/7/23 Brett Cannon :
>> >
>> >
>> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson 
>> > wrote:
>> >>
>> >> 2009/7/23 Brett Cannon :
>> >> > None in Python 3.1 is really useless in terms of its semantics in
>> >> > relative
>> >> > imports; importlib doesn't support it and still passes as __import__
>> >> > (at
>> >> > least last time I ran the test suite that way). I thought we had
>> >> > agreed
>> >> > a
>> >> > while back that supporting None was not warranted in Python 3.0?
>> >> > Otherwise I
>> >> > will do whatever work is necessary for this to happen.
>> >>
>> >> I think it's still nice for the rare cases where you need to trick a
>> >> module into thinking another one doesn't exist.
>> >
>> > But None does not strictly mean "I don't exist". None is supposed to
>> > trigger
>> > an another import attempt for the module with a top-level name. It's
>> > that
>> > extra import trigger that has no real use in 3.0 and just complicates
>> > import
>> > semantics (IMO) needlessly. If you want a module to not exist then you
>> > either stick something else in (e.g. '42') or we remove the special
>> > semantics for None (which I thought we had).
>>
>>
>> I didn't realize None had other semantics attached to it. (Imagine
>> that dealing with import!) +1 for making it simply indicate an
>> ImportError.
>
> I'm +0 with having import raise ImportError if None is set in sys.modules as
> long as we don't suddenly expect loaders to trigger the same thing if they
> return None (actually, as of right now what loaders return count for
> nothing, but just want to be clear).
> -Brett



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Document None values in sys.modules?

2009-07-23 Thread Brett Cannon

On Thu, Jul 23, 2009 at 20:18, Guido van Rossum  wrote:

> So, I guess, we'll live with it for a while longer. Given that it
> managed to evade our attention for so long, I think that's fine.
>

Can someone double-check me that the semantics can even be triggered in 3.1?
I just tried and couldn't come up with anything. Heck, I quick search for a
Py_None comparison in 3.1's import.c turned up nothing useful (other than
mark_miss() is the function used to set None in sys.modules). We might have
actually already removed it or made it so that the semantics can't be
triggered.


>
> I agree that there's no reason for a None result from loaders to be
> interpreted the same way, assuming that's not how it works ATM.
>
> And we can live with import and importlib differing on this in 3.1
> (though you could call it a bug in importlib and fix it for 3.1.1 --
> not sure if you were planning on that).
>

I can if people can trigger the semantics somehow so I have a test to go by.

-Brett


>
> --Guido
>
> On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon wrote:
> >
> >
> > On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson 
> > wrote:
> >>
> >> 2009/7/23 Brett Cannon :
> >> >
> >> >
> >> > On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson  >
> >> > wrote:
> >> >>
> >> >> 2009/7/23 Brett Cannon :
> >> >> > None in Python 3.1 is really useless in terms of its semantics in
> >> >> > relative
> >> >> > imports; importlib doesn't support it and still passes as
> __import__
> >> >> > (at
> >> >> > least last time I ran the test suite that way). I thought we had
> >> >> > agreed
> >> >> > a
> >> >> > while back that supporting None was not warranted in Python 3.0?
> >> >> > Otherwise I
> >> >> > will do whatever work is necessary for this to happen.
> >> >>
> >> >> I think it's still nice for the rare cases where you need to trick a
> >> >> module into thinking another one doesn't exist.
> >> >
> >> > But None does not strictly mean "I don't exist". None is supposed to
> >> > trigger
> >> > an another import attempt for the module with a top-level name. It's
> >> > that
> >> > extra import trigger that has no real use in 3.0 and just complicates
> >> > import
> >> > semantics (IMO) needlessly. If you want a module to not exist then you
> >> > either stick something else in (e.g. '42') or we remove the special
> >> > semantics for None (which I thought we had).
> >>
> >>
> >> I didn't realize None had other semantics attached to it. (Imagine
> >> that dealing with import!) +1 for making it simply indicate an
> >> ImportError.
> >
> > I'm +0 with having import raise ImportError if None is set in sys.modules
> as
> > long as we don't suddenly expect loaders to trigger the same thing if
> they
> > return None (actually, as of right now what loaders return count for
> > nothing, but just want to be clear).
> > -Brett
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] command line attachable debugger

2009-07-23 Thread Edward Peschko

all,

I'I was wondering if there was a command line python debugger that was
able to attach to an existing process. I'd very much like to be able
to debug over a ssh session using screen.

Ed

(ps - and yes, I know about winpdb, etc... that is not exactly what
I'm looking for..)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

2009-07-23 Thread Terry Reedy


Lisandro Dalcin wrote:

On Thu, Jul 23, 2009 at 5:42 PM, Terry Reedy wrote:

Lisandro Dalcin wrote:

On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone
wrote:


True, CPython has C infrastructure.  What about the other Python
runtimes,
though?


Perhaps these other Python runtimes could implement the functionality
of PC/_subprocess.c and use ctypes for that ?

Is it sensibly possible to augment a C file with #ifdefs so that it can be
compiled either as a directly importable module or as a ctypes-accessible
shared library?



Of course it is posible... Moreover, you could likely reuse 100 % of
code intended for ctypes in implementing the extension module calls
intended for Python. Mac OS X could have some issues though (IIUC, .so
ext modules are not the same as .dylib dynamic libs, though perhaps
ctypes can still dlopen() .so files?)

However, how that would help these other Python runtimes without C
infraestructure ??


I believe someone just posted that PyPy and IronPython have ctypes and 
Jython is working on it. That is what triggered this post.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

57 matches

Mail list logo