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

[M.-A. Lemburg]

James Y Knight wrote:
> On Jul 21, 2009, at 7:38 PM, David Lyon wrote:
>> When I go into python on ubuntu I see there is /usr/local/pythonX.X/lib/
>> site-packages and I'm wondering why the hubba setuptools/distutils
>> doesn't put packages there by default. That would solve a lot of
>> problems.
>>
>> Just leave /usr/lib/pythonX.X//lib/site-packages to the O/S.
> 
> Uh guys, I'm not sure if anyone here noticed, but Debian and Ubuntu have
> switched to install their distribution-supplied python libraries into:
> /usr/lib/pythonX.Y/lib/dist-packages
> and distutils by default will install into
> /usr/local/lib/pythonX.Y/dist-packages
> 
> starting with python 2.6.
> 
> See:
> http://lists.debian.org/debian-devel/2009/02/msg00431.html
> 
> Since that email says "Discussed this with Barry Warsaw and Martin v.
> Loewis", I'd assume this change would be more widely known in the
> distutils/python-dev community, but apparently not??

Debian has a long history of doing this different, so it's
not much of a surprise. They also apply such changes to
Python packages.

However, all of this is non-standard and will cause problems
with tools that rely on the standard site-packages/ location. Such
changes should be discouraged.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 22 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Olemis Lang]

Hi !

On Tue, Jul 21, 2009 at 5:32 PM, Steve Holden wrote:
> Christian Heimes wrote:
>> Steve Holden wrote:
>>> Devs:
>>>
>>> If you are interested in offering better Windows support then please
>>> read the email below
>>
>> [...]
>>
 MSDN subscriptions include copies of most Microsoft products (including 
 Office and Exchange) for use while developing and testing software.  For 
 more details, check here - we provide Visual Studio Pro with MSDN Premium 
 under this program 
 (http://msdn.microsoft.com/en-us/subscriptions/subscriptionschart.aspx).
>>
>> Thanks you for getting in touch with Microsoft. The deal is worth a
>> fortune for any Windows developer!
>>
>> Does the MSDN subscription also include the permission to create and
>> release binaries?
[...]
>> Can you
>> please verify that we are allowed to use the subscription for that
>> purpose, too?
>>
> I'll ask. I don't see why not (it would hardly be in Microsoft's
> interest to help us create unreleasable open source projects, would it?)
>

When talking about MS + FOSS everything is possible :-/

My question is the following :

- What are the implications for Py users ?

I mean, even if somebody (not me but enterprises & organizations I
work or may work for in the future ;o) decides to use Windows pay for
that and everything else, I'd not like to qualify as a "pirate" (or
alike) for using a Py distribution or app including MS Intelectual
Property (MSIP) (and MS loves MSIP -even if nobody can see it- and all
kind of legal issues, especially with FOSS) nor even have Py in the
middle of a patent dispute or something ...

And they have some "great" innovations [1]_ to ensure (sometimes, I
know) that (some) apps (who decides ?) wont run on a Win host. I could
mention a lot of snippets in that text (yes it's very "interesting"
and "substantial", and "useful" ) here goes one of them :

{{{
According to another aspect of the invention, the digest catalog
includes, for each program file corresponding to an application or
driver that should be executable by the computer, a digitally signed
hash value that is generated from a hash function based on the
corresponding program file. When attempting to load a particular file,
the loader generates a hash value and compares it to the decrypted
hash values in the digest catalog. If the comparison results in no
matches, then the corresponding program file (and thus the application
or driver) is not loaded.
}}}

OTOH :

- 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 ?
- Will that affect contributions from «future or potential» devs ?
- Will they also need an MS license to see or compile (or whatever)
the changes contributed by Py devs ?
- What about if for some reason, a idea or impl or alg or snippet (or
whatever) is propagated to GNU/Linux distributions and it's MSIP?
(considering former disputes like «Linux kernel violates 42 of MS
patents») ?


.. [1] Restricted software and hardware usage on a computer
(http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=7,536,726)

PD: My question is not technical at all but at least for me is
important (even if I'm not a lawyer, nor a core Py dev  ;o) since I
manage (and develop ;o) several Py-based apps running on Win hosts in
different locations .

Finally I clearly see that this msg is strongly influenced by my
biases, paranoia, and maybe I'm overreacting ... but I prefer to ask
before things actually happen (and MS has a long history specially
with FOSS + patents + legal affaires).

I apologize in advance if I'm being rude or naïve or *

-- 
Regards,

Olemis.

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

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

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

[Eric Pruitt]

Hello,

I have written replacements for a few of Mark Hammond's PyWin32 functions
using ctypes to call upon the Windows kernel API. Code can be found here;
http://pastebin.com/m46de01f . When calling ReadFile, it appears that the
kernel API converts '/n' newlines '/r/n' newlines. I have not been able to
find any information about this but as far as I can tell, there is nothing
in my code that is causing the problem. Initially I suspected it related to
newline translation but the function in subprocess.Popen for translating
newlines only converts to '/n' newlines. When I replaced my ReadFile and
WriteFile functions with the PyWin32 functions I was imitating, the problem
still arose. I was hoping someone could confirm this problem for me from
experience or by testing out my code. If you would like the see the
functions used in full context, I have a Mercurial Google Code project that
can be checked out at
http://code.google.com/p/subprocdev/source/list(branch "python3k"). My
work entails modifications to subprocess.py so when
running the code, please update your PYTHONPATH variable so that my
subprocess.py will be imported.

Eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Lyon wrote:
> On Tue, 21 Jul 2009 13:41:41 -0400, Tres Seaver 
> wrote:

>> Consider the case where the user has built a separate python (e.g., to
>> avoid conflicting with the OS version) in /opt/PythonX.y:  are you
>> actually saying that distutils / setuptools should somehow know the
>> difference betweeen /usr/lib/pythonX.y/site-packages and
>> /opt/PythonX.Y/lib/pythonX.Y/site-packages?  
> 
> It already does.
> 
> If you run the python in /opt/pythonX.X you'll get a different value
> for sys.path than when you run the other python from /usr/lib/pythonX.X.
> 
> Try it and see for yourself..

You missed my point:  I know that sys.prefix etc. is set based on the
location of the executable.  You were complaining that setuptools /
distutils wants to put files in an "OS-controlled directory":  I was
asking how Python was supposed to know the difference between
/usr/lib/python2.x/site-packages (presumably "OS-controlled") and
/opt/Python2.x/lib/python2.x/site-packages (definitely not "OS-controlled").

The solution is to avoid doing distutils / setuptools operations as
root, *ever*, and instead use either an alternate install location (such
as /opt/Python2.x) or use something like virtualenv, which provides a
"safe" sandbox for installing stuff.

> That's because sys.path is calculated relatively within site.py
> depending on where the interpretor is run from.
> 
>> Or are you asserting that
>> it is somehow invalid for distutils / setuptools to install things into
>> /opt/PythonX.Y/lib/pythonX.y/site-packages, which is certainly not an
>> "OS controlled directory."
> 
> Not at all.
> 
> All I'm saying is that after so many years of python under linux and
> operating system we should have observed the common use cases and
> learned a thing or two.
> 
> If you hadn't noticed, there is mayhem in package installation because
> the operating system tries to install its packages in the same place
> as setuptools does in development mode.
> 
> That has got to be asking for trouble..

Users who install anything into /usr/lib/python2.x in "development" mode
has already invited all the trouble they can handle into the house.

> When I go into python on ubuntu I see there is /usr/local/pythonX.X/lib/
> site-packages and I'm wondering why the hubba setuptools/distutils
> doesn't put packages there by default. That would solve a lot of
> problems.
> 
> Just leave /usr/lib/pythonX.X//lib/site-packages to the O/S.
> 
> Wrapping up.. most of the functionality that I'm asking for is
> already there. So I don't require anything extra. I don't want
> things taken out.
> 
> All I'm suggesting is that we use what we already have a bit smarter.

That is precisely how I think of virtualenv: it sits on top of distutils
/ setuptools, and makes it sane to do Python development without
compromising the core system.


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

iD8DBQFKZyGz+gerLs4ltQ4RAupxAJ95RZQJm6t1FtcFY+DMyHHmwRjmSACglo+W
TehyHzxUwHQ5LfdibJsgUcA=
=nf13
-END PGP SIGNATURE-

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

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

[David Lyon]

On Wed, 22 Jul 2009 10:26:59 -0400, Tres Seaver 
wrote:
> You were complaining that setuptools /
> distutils wants to put files in an "OS-controlled directory":  

I complain about many things - so what.

> I was
> asking how Python was supposed to know the difference between
> /usr/lib/python2.x/site-packages (presumably "OS-controlled") and
> /opt/Python2.x/lib/python2.x/site-packages (definitely not
> "OS-controlled").

Well, at an interpreter level it doesn't, and I don't expect it
to.

> The solution is to avoid doing distutils / setuptools operations as
> root, *ever*, and instead use either an alternate install location (such
> as /opt/Python2.x) 

Have you tried this ?

When I try to run it without su privelages setuptools crashes... (ubuntu
8.10)


Running installer ... /usr/bin/easy_install "/media/Elements/Pythn
Packages/html5lib-0.10.zip"
ERRORS: Traceback (most recent call last):
  File "/usr/bin/easy_install", line 5, in 
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/apport_python_hook.py", line 78,
in apport_excepthook
report_file = open(pr_filename, 'wt')
IOError: [Errno 13] Permission denied:
'/var/crash/_usr_bin_easy_install.1000.crash'

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/easy_install", line 5, in 
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources


I can only get it to work with sudo.

> That is precisely how I think of virtualenv: it sits on top of distutils
> / setuptools, and makes it sane to do Python development without
> compromising the core system.

For me I prefer using a tool with a GUI interface.

Take care

David

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

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

[Amaury Forgeot d'Arc]

Hi,

2009/7/22 Eric Pruitt :
> Hello,
>
> I have written replacements for a few of Mark Hammond's PyWin32 functions
> using ctypes to call upon the Windows kernel API. Code can be found here;
> http://pastebin.com/m46de01f . When calling ReadFile, it appears that the
> kernel API converts '/n' newlines '/r/n' newlines. I have not been able to
> find any information about this but as far as I can tell, there is nothing
> in my code that is causing the problem. Initially I suspected it related to
> newline translation but the function in subprocess.Popen for translating
> newlines only converts to '/n' newlines. When I replaced my ReadFile and
> WriteFile functions with the PyWin32 functions I was imitating, the problem
> still arose. I was hoping someone could confirm this problem for me from
> experience or by testing out my code. If you would like the see the
> functions used in full context, I have a Mercurial Google Code project that
> can be checked out at http://code.google.com/p/subprocdev/source/list
> (branch "python3k"). My work entails modifications to subprocess.py so when
> running the code, please update your PYTHONPATH variable so that my
> subprocess.py will be imported.

These questions should be redirected to comp.lang.python.

But as a quick response, the subprocess stdout is likely to be opened
in text mode.
So reading \r\n is not a surprise to me.

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

[Python-Dev] mingw32 and gc-header weirdness

[Christian Tismer]

Hi all,

I was hacking to get mingw32 builds of psyco to work
and found a pretty weird thing:

I used mingw32 (stable distro) to build the psyco extension
on top of standard python2.6, built with Visual Studio,
and got weird crashes.

The reason is in objimpl.h:

typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy;  /* force worst-case alignment */
} PyGC_Head;

Mingw32 behaves funny here. The size of long double is 12 ! 8-)

I happened to use the _PyObject_GC_UNTRACK macro in psyco, instead
of the function, and that caused the errors, because psython
and the extension disagreed on the location of the gc pointers...
Using PyObject_GC_Untrack instead fixed the problem,
but there is a bad feeling left.

Question:
Is that considered a mingw bug?
Should we change the above union to a safer construct?

Or maybe I just missed something obvious and made a fool out of me?

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

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

[Antoine Pitrou]

Hi,

> I used mingw32 (stable distro) to build the psyco extension
> on top of standard python2.6, built with Visual Studio,
> and got weird crashes.
> 
> The reason is in objimpl.h:
> 
> typedef union _gc_head {
>   struct {
>   union _gc_head *gc_next;
>   union _gc_head *gc_prev;
>   Py_ssize_t gc_refs;
>   } gc;
>   long double dummy;  /* force worst-case alignment */
> } PyGC_Head;
> 
> Mingw32 behaves funny here. The size of long double is 12 ! 

The size of long double is also 12 under 32-bit Linux. Perhaps mingw disagrees
with Visual Studio on some ABI subtleties (is it expected? is mingw supposed to
be ABI-compatible with Visual Studio? if yes, you may report a bug to them :-)).

Regards

Antoine.


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

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

[Martin v. Löwis]

> My question is the following :
> 
> - What are the implications for Py users ?

After reading your message, I had a difficult time getting your point,
or even finding out what your question is.

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), but
I doubt it will be significantly noticeable.

> I mean, even if somebody (not me but enterprises & organizations I
> work or may work for in the future ;o) decides to use Windows pay for
> that and everything else, I'd not like to qualify as a "pirate" (or
> alike) for using a Py distribution or app including MS Intelectual
> Property (MSIP) (and MS loves MSIP -even if nobody can see it- and all
> kind of legal issues, especially with FOSS) nor even have Py in the
> middle of a patent dispute or something ...

I can't follow here. Why would using a Py distribution or app that
includes MSIP qualify you as a "pirate"? And why would Microsoft's
making free (as in beer) tools available to Python contributors
make you qualify more as a "pirate" than you are currently qualified
as?

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

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

> - 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. You may not be aware that Python
is *already* compiled by MSVC on Windows.

> - What about if for some reason, a idea or impl or alg or snippet (or
> whatever) is propagated to GNU/Linux distributions and it's MSIP?
> (considering former disputes like «Linux kernel violates 42 of MS
> patents») ?

Python contributors should always have the copyright to all changes
they contribute. They should not contribute code owned by Microsoft,
nor should they contribute code owned by anybody else (except
themselves). The latter is the bigger problem: sometimes people
contribute code that is owned by their employer, without an agreement
of the employer.

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

Regards,
Martin

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

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

[Glenn Maynard]

On Wed, Jul 22, 2009 at 10:26 AM, Tres Seaver wrote:
> You missed my point:  I know that sys.prefix etc. is set based on the
> location of the executable.  You were complaining that setuptools /
> distutils wants to put files in an "OS-controlled directory":  I was
> asking how Python was supposed to know the difference between
> /usr/lib/python2.x/site-packages (presumably "OS-controlled") and
> /opt/Python2.x/lib/python2.x/site-packages (definitely not "OS-controlled").

autoconf--for all its warts--solved this ages ago.  On installation,
you specify what prefix you want to install stuff into; if you don't,
you get a sensible default (/usr/local).  If you're creating an OS
package, or if installing directly into /usr is otherwise really what
you really want to do, you specify --prefix=/usr.  The Python core
doesn't need to know anything about this; it just needs to have a
sys.path that includes both /usr/lib/... and /usr/local/lib/

This works for everything else--C headers, libraries, manpages, shared
libraries.  Why is Python special?

> The solution is to avoid doing distutils / setuptools operations as
> root, *ever*, and instead use either an alternate install location (such
> as /opt/Python2.x) or use something like virtualenv, which provides a
> "safe" sandbox for installing stuff.

This is nasty.  I should certainly be able to globally install
packages on my own, without creating a whole new Python installation
or other hacks, just like I can install anything else into /usr/local.

-- 
Glenn Maynard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin v. Löwis]

> Is that considered a mingw bug?

Perhaps. I can't test right now: *if* VS has a long double type
that is smaller, it is apparently an ABI violation for mingw to
not follow VS. It appears that other people also consider it a
bug:

http://www.velocityreviews.com/forums/showpost.php?p=1514923&postcount=2

OTOH, they probably cannot change it without causing

> Should we change the above union to a safer construct?

No. tim_one changed it to be long double in r25454 to support some
system that Dave Abrahams uses, so it needs to stay that way :-)

However, we can certainly acknowledge that this is a bug in MingW,
and special case it. Either introduce a symbolic type gchead_align_t
which gets defined to just double on MingW, or put the #ifdef right
into the structure.

It might also be useful to assert that sizeof(gchead_align_t) is
8 or 16, and reject 12 as a value. The point is that we need the
maximum alignment, and that certainly shouldn't be 12.

Regards,
Martin

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

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

[James Y Knight]

On Jul 22, 2009, at 4:49 AM, M.-A. Lemburg wrote:


Debian has a long history of doing this different, so it's
not much of a surprise. They also apply such changes to
Python packages.

However, all of this is non-standard and will cause problems
with tools that rely on the standard site-packages/ location. Such
changes should be discouraged.


And yet, the change seems to have some strong reasoning, solves the  
problem discussed in this thread, and was apparently discussed and  
approved of by some core python developers before being implemented.  
It seems a bit foolish to me to thus just dismiss it as "evil debian  
being different"...


If anything it seems like it's a failure of the Python project to make  
easily deployable software, compounded with a failure of communication  
within the python community.


James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[M.-A. Lemburg]

James Y Knight wrote:
> 
> On Jul 22, 2009, at 4:49 AM, M.-A. Lemburg wrote:
> 
>> Debian has a long history of doing this different, so it's
>> not much of a surprise. They also apply such changes to
>> Python packages.
>>
>> However, all of this is non-standard and will cause problems
>> with tools that rely on the standard site-packages/ location. Such
>> changes should be discouraged.
> 
> And yet, the change seems to have some strong reasoning, solves the
> problem discussed in this thread, and was apparently discussed and
> approved of by some core python developers before being implemented. It
> seems a bit foolish to me to thus just dismiss it as "evil debian being
> different"...

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 ?

distutils allows for a great deal of flexibility. For some
reason, this does not appear to be known to a larger
audience.

I can only recommend reading Greg's great write-up about the
end-user perspective of installing Python modules:

http://docs.python.org/install/

A little known fact is that distutils can easily be customized
using config files:

http://docs.python.org/install/#distutils-configuration-files

Together with the PYTHONHOME and PYTHONPATH environment
variables setup in your .bashrc, this gives you full flexibility
regarding the Python package setup and permits setting up
private Python installations, parallel Python installations,
Python installations sharing packages, etc. etc.

It really depends a lot on what you want to achieve. There's
no one fits all configuration.

Using a non-standard Python installation as system Python is
certainly not a good approach to solving anything. It only
makes it harder for users having to fight problems arising
out of this.

You have the same problem in other areas as well. A prominent
example being Microsoft's tendency (in the past) to tweak standards
to better meet their requirements.

> If anything it seems like it's a failure of the Python project to make
> easily deployable software, compounded with a failure of communication
> within the python community.

I lost you there.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 22 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Glenn Maynard]

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.

-- 
Glenn Maynard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[David Lyon]

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"

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.

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

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.

Take care

David



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

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

[Roumen Petrov]

Christian Tismer wrote:

Hi all,

I was hacking to get mingw32 builds of psyco to work
and found a pretty weird thing:

I used mingw32 (stable distro) to build the psyco extension
on top of standard python2.6, built with Visual Studio,
and got weird crashes.

The reason is in objimpl.h:

typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy;  /* force worst-case alignment */
} PyGC_Head;

Mingw32 behaves funny here. The size of long double is 12 ! 8-)


No it is correct. GNU C compiler for windows support 80-bit extended 
precision.




I happened to use the _PyObject_GC_UNTRACK macro in psyco, instead
of the function, and that caused the errors, because psython
and the extension disagreed on the location of the gc pointers...
Using PyObject_GC_Untrack instead fixed the problem,
but there is a bad feeling left.

Question:
Is that considered a mingw bug?


No as sizeof(long double) = sizeof(double) is MSVC limitation.



Should we change the above union to a safer construct?

Or maybe I just missed something obvious and made a fool out of me?

cheers - chris



Regards,
Roumen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Roumen Petrov]

Martin v. Löwis wrote:
[SNIP]

No. tim_one changed it to be long double in r25454 to support some
system that Dave Abrahams uses, so it needs to stay that way :-)

However, we can certainly acknowledge that this is a bug in MingW,
and special case it. Either introduce a symbolic type gchead_align_t
which gets defined to just double on MingW, or put the #ifdef right
into the structure.


No this is not GCC bug. GCC support "hardware extended precision" as 
implement long double and mingw w32api implement long double functions.
According to http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx it is 
MSVC limitation.




It might also be useful to assert that sizeof(gchead_align_t) is
8 or 16, and reject 12 as a value. The point is that we need the
maximum alignment, and that certainly shouldn't be 12.


So look like python bug.



Regards,
Martin


Regards,
Roumen

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

[Python-Dev] Update to Python Documentation Website Request

[David Lyon]

Hi Greg,

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/

Can I ask that you also provide a link for windows users
to my project:

  http://sourceforge.net/projects/pythonpkgmgr/

Our project provides an alternative to command line installation.

And can save a lot of time for users when they wish to
install packages.

Thanks

David

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

Re: [Python-Dev] Remove site-packages?!?

[Ben Finney]

"M.-A. Lemburg"  writes:

> James Y Knight wrote:
> > And yet, the change seems to have some strong reasoning, solves the
> > problem discussed in this thread, and was apparently discussed and
> > approved of by some core python developers before being implemented.
> > It seems a bit foolish to me to thus just dismiss it as "evil debian
> > being different"...
> 
> 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 ?

Before this discussion descends further into circular speculation on the
Debian Python developers's intentions, perhaps someone should ask them
directly: http://lists.debian.org/debian-python/>.

-- 
 \   “Let others praise ancient times; I am glad I was born in |
  `\  these.” —Ovid (43 BCE–18 CE) |
_o__)  |
Ben Finney

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

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

[Christian Tismer]

On 7/22/09 4:56 PM, Roumen Petrov wrote:

Martin v. Löwis wrote:
[SNIP]

No. tim_one changed it to be long double in r25454 to support some
system that Dave Abrahams uses, so it needs to stay that way :-)

However, we can certainly acknowledge that this is a bug in MingW,
and special case it. Either introduce a symbolic type gchead_align_t
which gets defined to just double on MingW, or put the #ifdef right
into the structure.


No this is not GCC bug. GCC support "hardware extended precision" as
implement long double and mingw w32api implement long double functions.
According to http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx it is
MSVC limitation.



It might also be useful to assert that sizeof(gchead_align_t) is
8 or 16, and reject 12 as a value. The point is that we need the
maximum alignment, and that certainly shouldn't be 12.


So look like python bug.


The assumption is that the union with long double gives alignment
to the largest possible integral type with a power of 2 size,
which is then wrong, because of the unexpected size.

What do you propose for doing proper alignment, then?

I fear this needs to become yet another special case in pyconfig.h

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

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

[David Cournapeau]

On Thu, Jul 23, 2009 at 4:40 AM, Antoine Pitrou wrote:

>
> The size of long double is also 12 under 32-bit Linux. Perhaps mingw disagrees
> with Visual Studio

Yes, mingw and VS do not have the same long double type. This has been
the source of some problems in numpy as well, since mingw uses the MS
runtime, and everything involving long double and the runtime is
broken (printf, math library calls). I wish there was a way to disable
this in mingw, but there isn't AFAIK.

> on some ABI subtleties (is it expected? is mingw supposed to
> be ABI-compatible with Visual Studio? if yes, you may report a bug to them 
> :-)).

I think mostly ABI compatible is the best description :)

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

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

[Christian Tismer]

On 7/22/09 5:17 PM, David Cournapeau wrote:

On Thu, Jul 23, 2009 at 4:40 AM, Antoine Pitrou  wrote:


The size of long double is also 12 under 32-bit Linux. Perhaps mingw disagrees
with Visual Studio


Yes, mingw and VS do not have the same long double type. This has been
the source of some problems in numpy as well, since mingw uses the MS
runtime, and everything involving long double and the runtime is
broken (printf, math library calls). I wish there was a way to disable
this in mingw, but there isn't AFAIK.


on some ABI subtleties (is it expected? is mingw supposed to
be ABI-compatible with Visual Studio? if yes, you may report a bug to them :-)).


I think mostly ABI compatible is the best description :)


Well, the source of my problems is simply that I tried to build
an extension for a Visual Studio built Python, using mingw.
Did that, because it seems to be common practice so far.

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.

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.
If that matters, of course.

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

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

[INADA Naoki]

Hi.

>> We have to use "IME" to input non-ascii charactor in Windows.
>> When "> chcp 65001" in cmd.exe, we cannot use IME on cmd.exe.
>>
>> So setting codepage to 65001 make output universal but make input ascii-only.
>> Sit!!!
>
> Is there a code page that still allows IME input, but supports all
> of Unicode? I know there is GB18030 - is it any good?

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")

-- 
Naoki INADA  
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Roumen Petrov]

Christian Tismer wrote:

On 7/22/09 4:56 PM, Roumen Petrov wrote:

Martin v. Löwis wrote:
[SNIP]

No. tim_one changed it to be long double in r25454 to support some
system that Dave Abrahams uses, so it needs to stay that way :-)

However, we can certainly acknowledge that this is a bug in MingW,
and special case it. Either introduce a symbolic type gchead_align_t
which gets defined to just double on MingW, or put the #ifdef right
into the structure.


No this is not GCC bug. GCC support "hardware extended precision" as
implement long double and mingw w32api implement long double functions.
According to http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx it is
MSVC limitation.



It might also be useful to assert that sizeof(gchead_align_t) is
8 or 16, and reject 12 as a value. The point is that we need the
maximum alignment, and that certainly shouldn't be 12.


So look like python bug.


The assumption is that the union with long double gives alignment
to the largest possible integral type with a power of 2 size,
which is then wrong, because of the unexpected size.


As is posted for GCC on linux(32-bit) size of structure is 12 = 
sizeof(struct in union) = sizeof(pointer)+sizeof(pointer)+sizeof(ssize_t).


And sizeof(ssize_t) <= sizeof(long) <= sizeof(pointer) .



What do you propose for doing proper alignment, then?


May be "void* dummy[4]" is better for force alignment ?

What about alignment on platforms with pointers > 32 bit ?



I fear this needs to become yet another special case in pyconfig.h

cheers - chris



Regards,
Roumen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin v. Löwis]

Roumen Petrov wrote:
> Martin v. Löwis wrote:
> [SNIP]
>> No. tim_one changed it to be long double in r25454 to support some
>> system that Dave Abrahams uses, so it needs to stay that way :-)
>>
>> However, we can certainly acknowledge that this is a bug in MingW,
>> and special case it. Either introduce a symbolic type gchead_align_t
>> which gets defined to just double on MingW, or put the #ifdef right
>> into the structure.
> 
> No this is not GCC bug. GCC support "hardware extended precision" as
> implement long double and mingw w32api implement long double functions.

And that exactly is the bug. GCC cannot simultaneously be
Windows-compatible, and also support extended precision floating point
under the name "long double".

> According to http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx it is
> MSVC limitation.

Therefore, mingw should also implement that limitation, to be
binary-compatible with MSVC. Since binary compatibility is an explicit
goal of mingw, failing to provide binary compatibility is a bug.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Lisandro Dalcin]

On Wed, Jul 22, 2009 at 12:33 PM, Amaury Forgeot
d'Arc wrote:
>
> These questions should be redirected to comp.lang.python.
>

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??



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

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

[Martin v. Löwis]

>> What do you propose for doing proper alignment, then?
> 
> May be "void* dummy[4]" is better for force alignment ?

That would have the same alignment as a single pointer.

> What about alignment on platforms with pointers > 32 bit ?

The C compiler will choose the alignment of the union to be the
alignment of the union branch that requires that largest alignment.
So if the largest alignment is the one that a pointer has,
then alignof(PyGC_HEAD) == alignof(gc_next). The double is in the
union only in case it has larger alignment than a pointer.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin v. Löwis]

> When stdout is console and not redirected to [pipe|file],
> sys.stdout.write(u"foo")
> can avoid encoding and use WriteConsoleW(L"foo")

I think this would be fairly difficult to implement given
the way the output libraries work. If you think it can be
done, please provide a patch to bugs.python.org.

Regards,
Martin

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

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

[Martin v. Löwis]

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

I fail to see how this project is relevant in the context
of explaining distutils. So you would have to come up with
a proposal of specific wording that makes the relevance more
apparent.

Please provide a patch to bugs.python.org.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com