Re: [Python-Dev] pthread sem PyThread_acquire_lock

[Guido van Rossum]

On Thu, Jul 2, 2009 at 4:04 PM, Jean-Paul Calderone wrote:
> On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith" 
>> If you want signals to actually be handled in a timely manner, its
>> best to leave the main thread of the program alone as a signal
>> handling thread that just spends its time in a loop of time.sleep(123)
>> calls rather than blocking on any sort of lock.  Spawn other threads
>> to do the actual work in your program.  Signals are delivered
>> indirectly in the existing CPython implementation by setting an
>> internal flag that the main interpreter thread polls on occasion so
>> blocking calls that do not interrupt and return early being called
>> from the main thread will effectively block signals.
>
> Yes, this is all true now.  The question is why the implementation
> works that way, and whether it is desirable to keep it working that
> way.
>
> Considering *some* of the lock implementations make themselves not
> interruptable by threads while others don't bother, it seems like
> *some* change to the status quo is desirable.

I'm probably to blame for this, but IIRC when we did it, lock
acquisitions were not interruptible by signals. However, that was
before posix threads were even standardized. Nowadays I believe we use
pthreads everywhere except on Windows. But I know nearly nothing about
pthreads. If pthreads mutex acquisition is (or can easily be made)
interruptible by signals I'd be all for adding signal handling to
them, assuming it doesn't slow things down much. Also, if there are
ways to do the "try to acquire a lock or wait until a given timeout"
natively and while handling signals, that would be a great
improvement.

I'll probably regret saying this within an hour though,

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

Re: [Python-Dev] I am back

[Brett Cannon]

On Thu, Jul 2, 2009 at 11:44, Terry Reedy  wrote:

> Brett Cannon wrote:
>
>>
>>
>> On Thu, Jul 2, 2009 at 04:39, Nick Coghlan > ncogh...@gmail.com>> wrote:
>>
>>Aahz wrote:
>> > On Wed, Jul 01, 2009, Brett Cannon wrote:
>> >> Anything happen while I was gone that I should be aware of that
>>is not
>> >> covered in a PEP?
>> >
>> > Yes.
>>
>>I agree with Aahz ;)
>>
>>
>> Ah, the smart ass remarks never cease. =)
>>
>
> The biggest news is the release of 3.1, but that might have been recorded
> in the relevant PEP, and it certainly hard to miss.
>

Yeah, it hit Twitter immediately thanks to Benjamin.

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

Re: [Python-Dev] [IronPython] Exception for setting attributes of built-in type

[Dino Viehland]

Seo wrote:
> Exception for setting attributes of built-in type differs between
> CPython and IronPython. This is not purely theoretical, as
> zope.interface tries to set Implements declaration as __implemented__
> attribute of built-in type object, and excepts TypeError.
>
> Python 2.6.1
> >>> object.flag = True
> TypeError: can't set attributes of built-in/extension type 'object'
>
> IronPython 2.6
> >>> object.flag = True
> AttributeError: 'object' object has no attribute 'flag'
>
> I was surprised that CPython raises TypeError. Library Reference seems
> to mention it here:
>
> exception AttributeError
> Raised when an attribute reference or assignment fails. (When an
> object does not support attribute references or attribute assignments
> at all, TypeError is raised.)
> http://docs.python.org/library/exceptions.html
>
> What does it mean that "an object does not support attribute
> references or attribute assignments at all"?

Even though Guido said we didn't have to match it I've updated IronPython
so that we'll throw the same exception now.  The change will be in
tomorrow's source push to CodePlex.  We've matched specific exceptions
in the past and this one is at least documented :)
___
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] Mercurial migration: progress report (PEP 385)

[Mark Hammond]

On 3/07/2009 6:42 AM, Dirkjan Ochtman wrote:

In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.


Although this has come up in the past, I don't recall a resolution.

What is your plan to handle svn:eol-style?  We have some files in the 
tree which need that support and it isn't clear to me how that would 
work with the existing win32text extension provided with current 
mercurial releases.  (I've an outstanding patch to hg which should 
address some of these issues, but without the 'rules' being versioned I 
fear that would still fall short.)


Even more generally, how will you suggest Windows users work?  Will 
local files, in general, have windows line endings or unix?  If the 
latter, will there be hooks in-place to prevent editors on Windows 
'accidently' mixing eol styles?  If so, this cycles back to the first 
question - how would we know which files get treated that way?


Thanks,

Mark
___
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] Mercurial migration: progress report (PEP 385)

[Benjamin Peterson]

2009/7/2 Dirkjan Ochtman :
> In response to some rumblings on python-committers and just to request
> more feedback, a progress report. I know it's long, I've tried to put
> to keep it concise and chunked, though.

Thanks very much for working on this, Dirkjan. It may seem rather
thankless now, but I'm sure once we wish to Mercurial, the praise will
flow. :)

>
> - Second of all, some planning. I've thought about it a bit, and I
> think we should aim for going live with hg on August 1. Given that I'm
> on vacation from 8-18 July (and I'm not sure whether I'll be able to
> actually work on it during that time, though I imagine I'll be able to
> spend some time on it at least), that's quite ambitious, so I'm going
> to say it's okay if it slips by a few days. Putting a deadline out
> there is a good thing, anyway.

Sounds good.


> - Fifth, here's a list of things, off the top of my head, that still need 
> doing:
>
> * Get agreement on branch strategy and branch processing (list of
> branches + proposed handling at
> http://hg.python.org/pymigr/file/tip/all-branches.txt) <--- PLEASE
> REVIEW

The io-c branch doesn't need to stay.

> * Get agreement on tag processing (first come up with a list)
> * Set up hg-ssh infra (should be easy)
> * Set up hooks (should be mostly straightforward)
> * Set up roundup integration (should be made easier by quick revision
> map hgweb extension)
> * Write docs
>
> - Sixth (this is the good part), less obvious things that have been
> done or don't need doing:

I suppose this includes modifying sys.subversion as described in the PEP?

> The SVN tags directory contains a lot of old stuff. Some of these are
> not, in fact, full tags, but contain only a smaller subset of the
> repository. I think we should keep all release tags, and consider
> other tags for inclusion based on requests from the developer
> community. I'd like to consider unifying the release tag naming scheme
> to make some things more consistent, if people feel that won't create
> too many problems. For example, Mercurial itself just uses '1.2.1' as
> a tag, where CPython would currently use r121.

+1 to unifying tag name style to the current cpython procedure.

> Author map
>
> In order to provide user names the way they are common in hg (in the
> 'First Last ' format), we need an author map to map
> cvs and svn user names to real names and their email addresses. I have
> a complete version of such a map in my migration tools repository [3].
> The email addresses in it might be out of date; that's bound to
> happen, although it would be nice to try and have as many people as
> possible review it for addresses that are out of date. The current
> version also still seems to contain some encoding problems.
> Generating .hgignore

What effect will the encoding problems have? Does hg require ASCII characters?

> Richard Tew has indicated that he'd like the Stackless repository to
> also be converted. What other projects in the svn.python.org
> repository should be converted? Do we want to convert the peps
> repository? distutils? others?

I think everything should be converted unless there's a reason not to.
(such as the maintainer indicates she doesn't what to migrate)


> A number of hooks is currently in use. The hg equivalents for these
> should be developed and deployed. The following hooks are being used:
>
>    * check whitespace: a hook to reject commits in case the
> whitespace doesn't match the rules for the Python codebase. Should be
> straightforward to re-implement from the current version. We can also
> offer a whitespace hook for use with client-side repositories that
> people can use; it could either warn about whitespace issues and/or
> truncate trailing whitespace from changed lines. Open issue: do we
> check only the tip after each push, or do we check every commit in a
> changegroup?

It might as well be on every commit because it will have to normalized
on push anyway.

> code.python.org was also proposed as the hostname. Personally, I think
> that using the VCS name in the hostname is good because it prevents
> confusion: it should be clear that you can't use svn or bzr for
> hg.python.org.

+1 for hg.python.org

>
> Think first, commit later?
>
> In recent history, old versions of Python have been maintained by a
> select group of people backporting patches from trunk to release
> branches. While this may not scale so well as the development pace
> grows, it also runs into some problems with the current crop of
> distributed versioning tools. These tools (I believe similar problems
> would exist for either git, bzr, or hg, though some may cope better
> than others) are based on the idea of a Directed Acyclic Graph (or
> DAG), meaning they keep track of relations of changesets.

The problem is that Python is much more complicated than the average
project. We have many commits that are only applicable one maintenance
branch, or just 2.x, or just 3.x; the trunk and py3k will never be
subsets of e

Re: [Python-Dev] pthread sem PyThread_acquire_lock

[Jean-Paul Calderone]

On Thu, 2 Jul 2009 15:47:48 -0700, "Gregory P. Smith"  wrote:

On Mon, Jun 29, 2009 at 2:28 PM, "Martin v. Löwis" wrote:

AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.


This is my understanding as well - so I don't think Python actually
"swallows" the signal.


A great example is reading from a socket. Whether or not it can be
interrupted depends on the platform, so catching Ctrl+C often requires
a timeout loop.

Also, remember that signals are asynchronous in the sense that they
are handled outside the normal execution flow of a program. Checking
for EINTR probably isn't the best way to determine if a signal has
been sent to the program.


I think it would be reasonable to support "asynchronous" exceptions,
and Python supports SIGINT fairly well most of the time.

It might be possible to support keyboard interrupts throughout
the system, but changing Python to do so could also cause
incompatibilities. So any change must be done with greatest care,
but simultaneously, should also try to arrange to cover all cases.

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/greg%40krypto.org


If you want signals to actually be handled in a timely manner, its
best to leave the main thread of the program alone as a signal
handling thread that just spends its time in a loop of time.sleep(123)
calls rather than blocking on any sort of lock.  Spawn other threads
to do the actual work in your program.  Signals are delivered
indirectly in the existing CPython implementation by setting an
internal flag that the main interpreter thread polls on occasion so
blocking calls that do not interrupt and return early being called
from the main thread will effectively block signals.


Yes, this is all true now.  The question is why the implementation
works that way, and whether it is desirable to keep it working that
way.

Considering *some* of the lock implementations make themselves not
interruptable by threads while others don't bother, it seems like
*some* change to the status quo is desirable.

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

Re: [Python-Dev] pthread sem PyThread_acquire_lock

[Gregory P. Smith]

On Mon, Jun 29, 2009 at 2:28 PM, "Martin v. Löwis" wrote:
>> AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers.
>
> This is my understanding as well - so I don't think Python actually
> "swallows" the signal.
>
>> A great example is reading from a socket. Whether or not it can be
>> interrupted depends on the platform, so catching Ctrl+C often requires
>> a timeout loop.
>>
>> Also, remember that signals are asynchronous in the sense that they
>> are handled outside the normal execution flow of a program. Checking
>> for EINTR probably isn't the best way to determine if a signal has
>> been sent to the program.
>
> I think it would be reasonable to support "asynchronous" exceptions,
> and Python supports SIGINT fairly well most of the time.
>
> It might be possible to support keyboard interrupts throughout
> the system, but changing Python to do so could also cause
> incompatibilities. So any change must be done with greatest care,
> but simultaneously, should also try to arrange to cover all cases.
>
> 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/greg%40krypto.org

If you want signals to actually be handled in a timely manner, its
best to leave the main thread of the program alone as a signal
handling thread that just spends its time in a loop of time.sleep(123)
calls rather than blocking on any sort of lock.  Spawn other threads
to do the actual work in your program.  Signals are delivered
indirectly in the existing CPython implementation by setting an
internal flag that the main interpreter thread polls on occasion so
blocking calls that do not interrupt and return early being called
from the main thread will effectively block signals.
___
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] [Fwd: [issue6397] Implementing Solaris "poll" in the "select" module]

[Gregory P. Smith]

On Thu, Jul 2, 2009 at 2:52 AM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Alexandre Vassalotti wrote:
>> On Wed, Jul 1, 2009 at 10:05 PM, Guido van Rossum wrote:
>>> The select module already supports the poll() system call. Or is there
>>> a special variant that only Solaris has?
>>>
>>
>> I think Jesus refers to /dev/poll—i.e., the interface for
>> edge-triggered polling on Solaris. This is the Solaris equivalent of
>> FreeBSD's kqueue and Linux's epoll.
>
> Yes. In python 2.6, Linux and *BSD benefice of access to high performing
> "poll"-like interfaces, non portable. Solaris has "/dev/poll" too, so we
> can provide another non-portable interface :). In fact I think it could
> be interesting to investigate the direct use of "/dev/poll" in Solaris
> under "select.poll" implementation, if available, in a transparent way.
> With this could be possible to improve efficiency without adding another
> non-portable interface.
>
> But before investigating options, I want to know if there is interest on
> it. I think so, because Solaris/OpenSolaris is an important platform, I
> will take care of the code, and we already have non-portable interfaces:
> "select.epoll" for Linux and "select.kqueue" for *BSD.

+1  I'm sure *Solaris users would appreciate this.  Go for it.

>
> - --
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> j...@jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> jabber / xmpp:j...@jabber.org         _/_/    _/_/          _/_/_/_/_/
> .                              _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBSkyDXZlgi5GaxT1NAQJSawP/SUf2AVfzYbqv8F3zZjNBspFu5c3bYVEK
> 6A2YSW0WIrNiQtcI9Ka99dCCzHI6cwohlDhxQddJEG4w30hewsFBFJqftSpPLhkv
> ToSUNDYe37QmRgVrcns//repWoaMwsrt8MMQU6MLb9pyaoT4Pffe1vcbqg+/XgUN
> EJENI7BjSOw=
> =BTMr
> -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/greg%40krypto.org
>
___
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] Mercurial migration: progress report (PEP 385)

[Dirkjan Ochtman]

In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.

- First of all, I've got the basic conversion down, I've done it a few
times now, with progressively better results. You can view some
results at http://hg.python.org/, which has a preliminary cpython
repository. *** The changeset hashes for that repo will change, so you
won't be able to commit or pull from it in the future.***

- Second of all, some planning. I've thought about it a bit, and I
think we should aim for going live with hg on August 1. Given that I'm
on vacation from 8-18 July (and I'm not sure whether I'll be able to
actually work on it during that time, though I imagine I'll be able to
spend some time on it at least), that's quite ambitious, so I'm going
to say it's okay if it slips by a few days. Putting a deadline out
there is a good thing, anyway.

- Third of all, to make this possible, it would be helpful if I got
more feedback on the PEP. Last time I raised it, there was virtually
nothing. This time, I'll include it inline so there's hopefully less
of a barrier to reviewing it.

- Fourth, Mercurial 1.3 was just released! Bet you didn't see that
coming. It's looking like a pretty good release, with an experimental
version of the much-coveted subrepository support (like
svn:externals). This also means that the latest version of
hgsubversion, the tool I used for the conversion, will be more
accessible for converting other projects. You know you want to!

- Fifth, here's a list of things, off the top of my head, that still need doing:

* Get agreement on branch strategy and branch processing (list of
branches + proposed handling at
http://hg.python.org/pymigr/file/tip/all-branches.txt) <--- PLEASE
REVIEW
* Get agreement on tag processing (first come up with a list)
* Set up hg-ssh infra (should be easy)
* Set up hooks (should be mostly straightforward)
* Set up roundup integration (should be made easier by quick revision
map hgweb extension)
* Write docs

- Sixth (this is the good part), less obvious things that have been
done or don't need doing:

* .hgignore generation (I've been convinced it's too hard, the current
version will do)
* revlog reordering (it's painless and a big win)

I'll get through all of these myself, but obviously any help would be
welcome. For any hg users, writing docs should be an easy start. For
others, please review the PEP (below), the branch map in
http://hg.python.org/pymigr/file/tip/all-branches.txt and the author
map at http://hg.python.org/pymigr/file/tip/author-map (not that much
has changed since the start, so if you've looked at it already, feel
free to skip this part). Right now I'm a little stuck on branch
processing, because it's a long running script that needs a bunch of
debugging, but I'll get going on that again.

I think that's all I can think of for now, I'll update the PEP with
new bits soon. Here it is, ready for your review:

==

Motivation

After having decided to switch to the Mercurial DVCS, the actual
migration still has to be performed. In the case of an important piece
of infrastructure like the version control system for a large,
distributed project like Python, this is a significant effort. This
PEP is an attempt to describe the steps that must be taken for further
discussion. It's somewhat similar to PEP 347 [1], which discussed the
migration to SVN.

To make the most of hg, I (Dirkjan) would like to make a high-fidelity
conversion, such that (a) as much of the svn metadata as possible is
retained, and (b) all metadata is converted to formats that are common
in Mercurial. This way, tools written for Mercurial can be optimally
used. In order to do this, I want to use the hgsubversion [2] software
to do an initial conversion. This hg extension is focused on providing
high-quality conversion from Subversion to Mercurial for use in
two-way correspondence, meaning it doesn't throw away as much
available metadata as other solutions.

Such a conversion also seems like a good time to reconsider the
contents of the repository and determine if some things are still
valuable. In this spirit, the following sections also propose
discarding some of the older metadata.
Timeline

TBD; needs fully working hgsubversion and consensus on this document.
Transition plan
Branch strategy

Mercurial has two basic ways of using branches: cloned branches, where
each branch is kept in a separate repository, and named branches,
where each revision keeps metadata to note on which branch it belongs.
The former makes it easier to distinguish branches, at the expense of
requiring more disk space on the client. The latter makes it a little
easier to switch between branches, but often has somewhat unintuitive
results for people (though this has been getting better in recent
versions of Mercurial).

I'm still a bit on the fence abo

Re: [Python-Dev] PEP 376

[P.J. Eby]

At 09:06 PM 7/2/2009 +0100, Paul Moore wrote:

Maybe the answer is that distutils reject *all* uses of absolute paths
on Windows. The PEP can then say whatever you want as far as I'm
concerned, as it doesn't affect me. If the existing bugs don't get
fixed, though, I'd say that the RECORD file should be explicitly
disallowed from containing absolute paths on Windows (for safety
reasons if nothing else).


In non bdist cases (e.g. setup.py with manual options, but also 
easy_install, pip, etc.) you can specify where data files and scripts 
go on Windows, and they don't have to be relative locations.  So, 
absolute paths need to be supported, despite the existence of broken 
bdist targets on Windows.


___
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] semi-regular check that all committers are subscribed to python-committers

[Dirkjan Ochtman]

On Thu, Jul 2, 2009 at 22:08, Brett Cannon wrote:
>  Maybe you should just get the commit privileges now. Any objections?

Not from me, obviously.

Cheers,

Dirkjan
___
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] semi-regular check that all committers are subscribed to python-committers

[Brett Cannon]

On Thu, Jul 2, 2009 at 12:56, Dirkjan Ochtman  wrote:

> On Thu, Jul 2, 2009 at 21:04, Brett Cannon wrote:
> > If you have commit privileges on Python but are not subscribed to
> > python-committers, please let me know and I will subscribe you.
> Membership
> > on python-committers is mandatory as that's where we announce branch
> > freezes, etc.
>
> Would it be helpful if I was subscribed? I'm not strictly a committer,
> but what with the Mercurial migration I imagine it won't be long
> before the first cset bearing my name appears in the Python repository
> (plus I just saw there was some discussion about the hg migration
> there which I could weigh in on).


 Maybe you should just get the commit privileges now. Any objections?

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

Re: [Python-Dev] PEP 376

[Paul Moore]

2009/7/2 Tarek Ziadé :
> On Thu, Jul 2, 2009 at 2:39 PM, Paul Moore wrote:
>> 2009/7/2 Tarek Ziadé :
>>> For absolute paths now that gets installed, what would be the
>>> difference between the pre-generated
>>> RECORD file and the RECORD file installed on the win32 target system, if 
>>> any ?
>>
>> When is an absolute path generated? If you can give me a small sample
>> of a distribution that installs a file in an absolute path, I'll do
>> some testing on Windows.
>
> Try this setup.py file:
>
> """
> from distutils.core import setup
>
> setup(name='foo', version='1.0', data_files=[('/tmp', ['data'])])
> """
>
> with this MANIFEST.in file:
> ""
> include data
> """
>
> and add a 'data' file alongside
>
> If you install it, data is copied in /tmp. If you create a bdist
> distribution it will be created in the root of the dumb directory
> which is used to generate the binary distro.
>
> Of course you'll have to change '/tmp' to 'c:\tmp'

>python setup.py bdist_wininst
running bdist_wininst
running build
installing to build\bdist.win32\wininst
running install_data
creating build
creating build\bdist.win32
creating build\bdist.win32\wininst
creating build\bdist.win32\wininst\DATA
Traceback (most recent call last):
  File "setup.py", line 3, in 
setup(name='foo', version='1.0', data_files=[('/tmp', ['data'])])
  File "C:\Apps\Python26\lib\distutils\core.py", line 152, in setup
dist.run_commands()
  File "C:\Apps\Python26\lib\distutils\dist.py", line 975, in run_commands
self.run_command(cmd)
  File "C:\Apps\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "C:\Apps\Python26\lib\distutils\command\bdist_wininst.py", line
171, in run
install.run()
  File "C:\Apps\Python26\lib\distutils\command\install.py", line 589, in run
self.run_command(cmd_name)
  File "C:\Apps\Python26\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Apps\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "C:\Apps\Python26\lib\distutils\command\install_data.py", line 62, in run
dir = convert_path(f[0])
  File "C:\Apps\Python26\lib\distutils\util.py", line 164, in convert_path
raise ValueError, "path '%s' cannot be absolute" % pathname
ValueError: path '/tmp' cannot be absolute

Looks like bdist_wininst doesn't support absolute paths. Which isn't
surprising, really.

Same with bdist_msi.

Actually, with setup.py install:

>python setup.py install
running install
running build
running install_data
Traceback (most recent call last):
  File "setup.py", line 3, in 
setup(name='foo', version='1.0', data_files=[('/tmp', ['data'])])
  File "C:\Apps\Python26\lib\distutils\core.py", line 152, in setup
dist.run_commands()
  File "C:\Apps\Python26\lib\distutils\dist.py", line 975, in run_commands
self.run_command(cmd)
  File "C:\Apps\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "C:\Apps\Python26\lib\distutils\command\install.py", line 589, in run
self.run_command(cmd_name)
  File "C:\Apps\Python26\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\Apps\Python26\lib\distutils\dist.py", line 995, in run_command
cmd_obj.run()
  File "C:\Apps\Python26\lib\distutils\command\install_data.py", line 62, in run
dir = convert_path(f[0])
  File "C:\Apps\Python26\lib\distutils\util.py", line 164, in convert_path
raise ValueError, "path '%s' cannot be absolute" % pathname
ValueError: path '/tmp' cannot be absolute

So how do absolute paths work??? It sure ain't like this!

Changing '/tmp' to c:/tmp' gives this:

>python setup.py bdist_wininst
running bdist_wininst
running build
installing to build\bdist.win32\wininst
running install_data
creating build\bdist.win32\wininst\DATA\c:tmp
error: could not create 'build\bdist.win32\wininst\DATA\c:tmp': The
directory name is invalid

Changing it to 'c:\\tmp' gives (sort of) success:

python setup.py bdist_wininst
running bdist_wininst
running build
installing to build\bdist.win32\wininst
running install_data
creating build\bdist.win32\wininst\tmp
copying data -> build\bdist.win32\wininst\tmp
running install_egg_info
Creating build\bdist.win32\wininst\PURELIB\
Writing build\bdist.win32\wininst\PURELIB\foo-1.0-py2.6.egg-info
creating 'c:\users\gustav\appdata\local\temp\tmpcs9rmi.zip' and adding '.' to it
adding 'PURELIB\foo-1.0-py2.6.egg-info'
adding 'tmp\data'
creating dist
removing 'build\bdist.win32\wininst' (and everything under it)

The installer packs a *relative* path tmp/data - which isn't right.

bdist_msi copies the data file to c:\tmp - when building the msi!.
This is very wrong. I can't introspect a msi file to see what ends up
in it, but if I install it, no c:\tmp\data is installed, so it does
look like it's screwed up.

Frankly, handling of absolute paths looks so broken, that I'd
explicitly state that it's not supported.

I'd raise bugs for some of the

Re: [Python-Dev] semi-regular check that all committers are subscribed to python-committers

[Dirkjan Ochtman]

On Thu, Jul 2, 2009 at 21:04, Brett Cannon wrote:
> If you have commit privileges on Python but are not subscribed to
> python-committers, please let me know and I will subscribe you. Membership
> on python-committers is mandatory as that's where we announce branch
> freezes, etc.

Would it be helpful if I was subscribed? I'm not strictly a committer,
but what with the Mercurial migration I imagine it won't be long
before the first cset bearing my name appears in the Python repository
(plus I just saw there was some discussion about the hg migration
there which I could weigh in on).

Cheers,

Dirkjan
___
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] "re" module and Python 1.6 (GPL incompatible) license?

[Martin v. Löwis]

> PS: if this gets fixed somehow, can the fix be backported to the
> Python 2.5.x releases?

Definitely not - it's not security critical.

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

[Python-Dev] semi-regular check that all committers are subscribed to python-committers

[Brett Cannon]

If you have commit privileges on Python but are not subscribed to
python-committers, please let me know and I will subscribe you. Membership
on python-committers is mandatory as that's where we announce branch
freezes, etc.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I am back

[Terry Reedy]

Brett Cannon wrote:



On Thu, Jul 2, 2009 at 04:39, Nick Coghlan > wrote:


Aahz wrote:
 > On Wed, Jul 01, 2009, Brett Cannon wrote:
 >> Anything happen while I was gone that I should be aware of that
is not
 >> covered in a PEP?
 >
 > Yes.

I agree with Aahz ;)


Ah, the smart ass remarks never cease. =)


The biggest news is the release of 3.1, but that might have been 
recorded in the relevant PEP, and it certainly hard to miss.


In any case, welcome back.

Terry

___
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] PEP 376

[Terry Reedy]

Scott David Daniels wrote:

Antoine Pitrou wrote:

Guido van Rossum  python.org> writes:

I noted an inconsistency: first you say that the RECORD file uses the
excel dialect, but at the end of the same section you say it uses the
default csv settings. Sounds like you need to delete one or the other.


If I remember correctly, the default csv dialect is just the Excel 
dialect, so

this would be two different ways of saying the same things.


Right, but Guido's point is, decide which one is the is the definition
and stick to  talking about it in that form.


Since I think it more likely that Excel will change than cvs default, I 
think the latter should be used.


___
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] I am back

[Brett Cannon]

On Thu, Jul 2, 2009 at 04:39, Nick Coghlan  wrote:

> Aahz wrote:
> > On Wed, Jul 01, 2009, Brett Cannon wrote:
> >> Anything happen while I was gone that I should be aware of that is not
> >> covered in a PEP?
> >
> > Yes.
>
> I agree with Aahz ;)
>

Ah, the smart ass remarks never cease. =)


>
> Cheers,
> Nick.
>
> P.S. Welcome back :)


Thanks!

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

Re: [Python-Dev] PEP 376

[Scott David Daniels]

Antoine Pitrou wrote:

Guido van Rossum  python.org> writes:

I noted an inconsistency: first you say that the RECORD file uses the
excel dialect, but at the end of the same section you say it uses the
default csv settings. Sounds like you need to delete one or the other.


If I remember correctly, the default csv dialect is just the Excel dialect, so
this would be two different ways of saying the same things.


Right, but Guido's point is, decide which one is the is the definition
and stick to  talking about it in that form.

--Scott David Daniels
scott.dani...@acm.org

___
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] I am back

[MRAB]

Stefan Behnel wrote:

s...@pobox.com wrote:

Aahz> On Wed, Jul 01, 2009, Brett Cannon wrote:

>> Anything happen while I was gone that I should be aware of that is
>> not covered in a PEP?

Aahz> Yes.

In particular, Brett, you probably didn't hear that the King of Pop died
last week.  It was hardly mentioned in the major news outlets...


*shrug* who cares about foreign politics anyway. I don't even know where
Pop is, and Google Maps doesn't seem to either.


I believe that "Pop" is an abbreviation for "Populous". You can read
about it here:

http://en.wikipedia.org/wiki/Populous

:-)
___
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] I am back

[Stefan Behnel]

s...@pobox.com wrote:
> Aahz> On Wed, Jul 01, 2009, Brett Cannon wrote:
> 
> >> Anything happen while I was gone that I should be aware of that is
> >> not covered in a PEP?
> 
> Aahz> Yes.
> 
> In particular, Brett, you probably didn't hear that the King of Pop died
> last week.  It was hardly mentioned in the major news outlets...

*shrug* who cares about foreign politics anyway. I don't even know where
Pop is, and Google Maps doesn't seem to either.

Stefan

___
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] Bytes, Strings, Encoding

[Josiah Carlson]

On Wed, Jul 1, 2009 at 6:48 PM, Benjamin Peterson wrote:
> 2009/7/1 Eric Pruitt :
>> Hello,
>>
>> I am working on the subprocess.Popen module for Python 2.7 and am now moving
>> my changes over to Python 3.1 however I am having trouble with the whole
>> byte situation and I can't quite seem to understand how to go back and forth
>> between bytes and strings. I am also looking for the Python 3k equivalent
>> for the Python 2.X built-in buffer class.
>
> Look at the "memoryview" type as a replacement for buffer.
> io.Buffered* is not the same.

FYI, it is used slightly differently.  Rather than x = buffer(y,
offset), you use x = memoryview(y)[offset:].

>> One version of the file with my modifications can be found here  <
>> http://code.google.com/p/subprocdev/source/browse/subprocess.py?spec=svn5b570f8cbfcaae859091eb01b21b183aa5221af9&r=5b570f8cbfcaae859091eb01b21b183aa5221af9
>>>. Lines 1 - 15 are me attempting to get around certain changes between
>> Python 3.0 and Python 2.7. Further down on line 916, we have the function
>> "send" and "recv" in which I am having the most trouble with bytes and
>> strings.
>
> You translate between bytes and strings through encoding and decoding.
> Have you read https://secure.wikimedia.org/wikipedia/en/wiki/Unicode?
>
>>
>> Any help is appreciated. Feel free to comment on my blog
>> http://subdev.blogspot.com/ or reply to the last.
>
> Have you talked with your mentor about these things?
>
>
> --
> Regards,
> Benjamin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.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] I am back

[skip]

Aahz> On Wed, Jul 01, 2009, Brett Cannon wrote:

>> Anything happen while I was gone that I should be aware of that is
>> not covered in a PEP?

Aahz> Yes.

In particular, Brett, you probably didn't hear that the King of Pop died
last week.  It was hardly mentioned in the major news outlets...

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

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

On Thu, Jul 2, 2009 at 4:35 PM, Paul Moore wrote:
> Ta. I'll give it a go tonight. But haven't you made the point yourself
> by saying I'll need to change the directory? This will fail for me as
> I don't have a "/tmp" directory. So I'd expect a bdist installer
> (*any* bdist installer) to fail, as it's got no way to tell where to
> put that file. I can only imagine this type of thing being done by
> someone packaging for Unix, with no interest in cross-platform
> portability (I suspect MAC OS directory names differ from Unix as
> well).

It will fail if your path starts with "/" and you are under win32
because there's
a converter that will raise an error in that case at installation time.

But you can use some code in your setup.py to provide the right directory
name when install is called. I don't see it as a problem.

I'm just afraid it's impossible to use efficiently under win32 because
of the drive
letter. But that's rather a bug.

>
> So maybe absolute filenames should be banned in distutils? (OK, less
> radically, maybe someone should ask where that functionality is used
> in practice, and based on the answers come up with a more portable
> approach).
>

I'll try to see if I can collect that info out of PyPI with a script,
to list the real-world usages.
Maybe Martin you have a simple way to do this on PyPI ?

Tarek
___
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] PEP 376

[Paul Moore]

2009/7/2 Tarek Ziadé :
> Try this setup.py file:
>
> """
> from distutils.core import setup
>
> setup(name='foo', version='1.0', data_files=[('/tmp', ['data'])])
> """
>
> with this MANIFEST.in file:
> ""
> include data
> """
>
> and add a 'data' file alongside

Ta. I'll give it a go tonight. But haven't you made the point yourself
by saying I'll need to change the directory? This will fail for me as
I don't have a "/tmp" directory. So I'd expect a bdist installer
(*any* bdist installer) to fail, as it's got no way to tell where to
put that file. I can only imagine this type of thing being done by
someone packaging for Unix, with no interest in cross-platform
portability (I suspect MAC OS directory names differ from Unix as
well).

So maybe absolute filenames should be banned in distutils? (OK, less
radically, maybe someone should ask where that functionality is used
in practice, and based on the answers come up with a more portable
approach).

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

Re: [Python-Dev] PEP 376

[Antoine Pitrou]

Guido van Rossum  python.org> writes:
> 
> I noted an inconsistency: first you say that the RECORD file uses the
> excel dialect, but at the end of the same section you say it uses the
> default csv settings. Sounds like you need to delete one or the other.

If I remember correctly, the default csv dialect is just the Excel dialect, so
this would be two different ways of saying the same things.

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] PEP 376

[Tarek Ziadé]

On Thu, Jul 2, 2009 at 2:39 PM, Paul Moore wrote:
> 2009/7/2 Tarek Ziadé :
>> For absolute paths now that gets installed, what would be the
>> difference between the pre-generated
>> RECORD file and the RECORD file installed on the win32 target system, if any 
>> ?
>
> When is an absolute path generated? If you can give me a small sample
> of a distribution that installs a file in an absolute path, I'll do
> some testing on Windows.

Try this setup.py file:

"""
from distutils.core import setup

setup(name='foo', version='1.0', data_files=[('/tmp', ['data'])])
"""

with this MANIFEST.in file:
""
include data
"""

and add a 'data' file alongside

If you install it, data is copied in /tmp. If you create a bdist
distribution it will be created in the root of the dumb directory
which is used to generate the binary distro.

Of course you'll have to change '/tmp' to 'c:\tmp'

(which makes me realizes that there's no way to force the installation
data_files in another drive under windows:
  the binary distribution will be the same, no matter what drive you
use in the absolute path used in data_files
I'll add an issue on this)

>
> But the immediate answer is that there are *no* reliable "absolute"
> paths on Windows, so you're not looking at the likes of /usr/doc, but
> rather paths that are relative to sys.prefix, but not to the package
> directory. In that case, the key point is that if the installer is
> built on a system where Python is installed in a different directory
> than the system where the installer is run, paths need to be
> relocated. (E.g., C:\Python27 vs D:\Apps\Python27).

I get the point: they are three levels we should handle in the RECORD file

1. absolute paths
2. paths relative to sys.prefix or sys.exec_prefix
3. paths relative to the directory where the .egg-info directory is located

the RECORD file doesn't handle 2. indeed. For instance you can add a script:

setup(
..
scripts=['myscript.py']
..)

that will get installed in : sys.prefix + 'Scripts/myscript.py'  under
win32 for instance

So a possible solution is to add 2. in the RECORD files by using a
notation such as
"$PREFIX" "$EXEC_PREFIX" when we detect that the file is under on of
these paths.

The query functions will then be able to use sys.prefix and
sys.exec_prefix for recompose
the absolute pat on the target system


>
> Paul.
>



-- 
Tarek Ziadé | http://ziade.org
___
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] "re" module and Python 1.6 (GPL incompatible) license?

[Anderson Lizardo]

Hi,

I noticed that some files of the "re" module still have the (GPL
incompatible) 1.6 license notice. Is that on purpose or
unintentionally forgotten?

If that is on purpose, does that mean that some GPL Python code cannot
use the "re" module?

For reference, here are the links to these files (from trunk):

http://svn.python.org/view/python/trunk/Lib/re.py?view=markup
http://svn.python.org/view/python/trunk/Modules/_sre.c?view=markup

Additionally, the files below do not have a complete license header,
or they just point to one of the files above:

http://svn.python.org/view/python/trunk/Lib/sre_compile.py?view=markup
http://svn.python.org/view/python/trunk/Lib/sre_constants.py?view=markup
http://svn.python.org/view/python/trunk/Lib/sre_parse.py?view=markup
http://svn.python.org/view/python/trunk/Modules/sre.h?view=markup
http://svn.python.org/view/python/trunk/Modules/sre_constants.h?view=markup

PS: if this gets fixed somehow, can the fix be backported to the
Python 2.5.x releases? Let me know what needs to be done to get this
fixed on next release.

Thanks,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
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] PEP 376

[Paul Moore]

2009/7/2 Tarek Ziadé :
> For absolute paths now that gets installed, what would be the
> difference between the pre-generated
> RECORD file and the RECORD file installed on the win32 target system, if any ?

When is an absolute path generated? If you can give me a small sample
of a distribution that installs a file in an absolute path, I'll do
some testing on Windows.

But the immediate answer is that there are *no* reliable "absolute"
paths on Windows, so you're not looking at the likes of /usr/doc, but
rather paths that are relative to sys.prefix, but not to the package
directory. In that case, the key point is that if the installer is
built on a system where Python is installed in a different directory
than the system where the installer is run, paths need to be
relocated. (E.g., C:\Python27 vs D:\Apps\Python27).

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

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

On Wed, Jul 1, 2009 at 1:44 PM, Paul Moore wrote:
> "Adding a RECORD file"
>
> You say "at installation time" - please clarify. Do you only mean
> setup.py install? What about bdist_wininst and bdist_msi? What about
> third party bdist style tools? How will they ensure they get a RECORD
> file?
>
> "The RECORD format"
>
> The line separator shouldn't be os-dependent. What value is used for a
> pure-python (ie, platform independent) package? Unless the file is
> generated when the install is done, in which case see the previous
> point...
>
> Absolute file paths - this implies that RECORD has to be generated by
> the installer (which is the only place that knows absolute paths)
> which means that every bdist_xxx installer has to write its own RECORD
> file. Does the PEP offer no support for this? In any case, the
> bdist_wininst and bdist_msi code (which is core distutils) will need
> to be amended to manage RECORD files appropriately.

Since all bdist_* commands are using the install command in a
temporary build directory to create
a binary distribution, the RECORD file (and the INSTALLER) will be
pre-generated then installed
alongside the packages/modules.

For absolute paths now that gets installed, what would be the
difference between the pre-generated
RECORD file and the RECORD file installed on the win32 target system, if any ?
___
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] PEP 376

[Ben Finney]

Paul Moore  writes:

> 2009/7/2 Ben Finney :
> > I think that calling distutils an “install program” is confusing.
> > When I discuss distutils, I don't call it a program at all; it's a
> > library (or perhaps “framework”) that provides part of the job of
> > package installation.
> 
> I agree, but I consider the fact that distutils "provides" python
> setup.py install means that it "is an install program" in some
> people's minds. These are the same people who complain about the lack
> of a distutils uninstall feature.

Well, I don't suffer from that confusion between the library and a
specific program, yet I still want distutils to support uninstall :-)
and hence am interested in seeing the fate of this PEP.

-- 
 \ “Men never do evil so completely and cheerfully as when they do |
  `\it from religious conviction.” —Blaise Pascal (1623–1662), |
_o__)   Pensées, #894. |
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] I am back

[Nick Coghlan]

Aahz wrote:
> On Wed, Jul 01, 2009, Brett Cannon wrote:
>> Anything happen while I was gone that I should be aware of that is not
>> covered in a PEP?
> 
> Yes.

I agree with Aahz ;)

Cheers,
Nick.

P.S. Welcome back :)

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

Re: [Python-Dev] PEP 376

[Tarek Ziadé]

On Thu, Jul 2, 2009 at 1:32 PM, Nick Coghlan wrote:
>>
>> Yes exactly, I was going to add:
>>
>> $ python -m distutils.uninstall some_package
>
> A directly executable submodule is an even better idea than making
> distutils itself executable. Definitely worth mentioning in the PEP in
> the section on uninstallation support.
>

The PEP is updated for this, and takes into account several feedback
from this thread,
(like removing implementation details)

I am working now on describing the behavior with the bdist_* commands
___
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] PEP 376

[Nick Coghlan]

Tarek Ziadé wrote:
> On Wed, Jul 1, 2009 at 10:20 AM, Michael Foord 
> wrote:
>>> Uninstall as a command feels a little weird. Since "python setup.py
>>> [some-command]" implies that the setup.py contains information about the
>>> distribution that the command is being applied to. So instead of:
>>>
>>> $ python setup.py uninstall some_package
>> It could be:
>>
>>   $ python -m distutils uninstall some_package
>>
>> Asymmetrical with the install of course.
>>
> 
> Yes exactly, I was going to add:
> 
> $ python -m distutils.uninstall some_package

A directly executable submodule is an even better idea than making
distutils itself executable. Definitely worth mentioning in the PEP in
the section on uninstallation support.

Cheers,
Nick.

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

Re: [Python-Dev] PEP 376

[Paul Moore]

2009/7/2 Ben Finney :
> I think that calling distutils an “install program” is confusing. When
> I discuss distutils, I don't call it a program at all; it's a library
> (or perhaps “framework”) that provides part of the job of package
> installation.

I agree, but I consider the fact that distutils "provides" python
setup.py install means that it "is an install program" in some
people's minds. These are the same people who complain about the lack
of a distutils uninstall feature.

Personally, I want distutils to provide all the individual bits that I
get from bdist_wininst, so that I can put together an alternative for
specialised situations (notably, non-site installs of some packages).
So uninstall and being able to list installed packages are important
to me - hence my interest in this PEP.

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

Re: [Python-Dev] PEP 376

[Ben Finney]

Paul Moore  writes:

> 2009/7/1 R. David Murray :
> > The uninstall function is part of that infrastructure, but since
> > distutils isn't a package manager itself (it's an install program),
> > distutils as currently organized can't really handle uninstall
> > except as outlined in a section you may have clipped from the above
> > context (ie: when setup.py from the original package is available).
> 
> >From a Windows user's POV, "install program" = "package manager". And
> an install program needs an uninstall feature. I know Linux users with
> their advanced dependency-managing package managers feel that this is
> a stone-age view, and they may be right, but the PEP needs to take the
> Windows situation into account.

Actually, your view seems quite reasonable to me: as a GNU user with my
advanced dependency-managing package manager, I feel just as strongly
that a program that installs is implicitly promising that it can also
uninstall cleanly.

I think that calling distutils an “install program” is confusing. When
I discuss distutils, I don't call it a program at all; it's a library
(or perhaps “framework”) that provides part of the job of package
installation.

-- 
 \  “I think it would be a good idea.” —Mahatma Gandhi (when asked |
  `\  what he thought of Western civilization) |
_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] [Fwd: [issue6397] Implementing Solaris "poll" in the "select" module]

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexandre Vassalotti wrote:
> On Wed, Jul 1, 2009 at 10:05 PM, Guido van Rossum wrote:
>> The select module already supports the poll() system call. Or is there
>> a special variant that only Solaris has?
>>
> 
> I think Jesus refers to /dev/poll—i.e., the interface for
> edge-triggered polling on Solaris. This is the Solaris equivalent of
> FreeBSD's kqueue and Linux's epoll.

Yes. In python 2.6, Linux and *BSD benefice of access to high performing
"poll"-like interfaces, non portable. Solaris has "/dev/poll" too, so we
can provide another non-portable interface :). In fact I think it could
be interesting to investigate the direct use of "/dev/poll" in Solaris
under "select.poll" implementation, if available, in a transparent way.
With this could be possible to improve efficiency without adding another
non-portable interface.

But before investigating options, I want to know if there is interest on
it. I think so, because Solaris/OpenSolaris is an important platform, I
will take care of the code, and we already have non-portable interfaces:
"select.epoll" for Linux and "select.kqueue" for *BSD.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSkyDXZlgi5GaxT1NAQJSawP/SUf2AVfzYbqv8F3zZjNBspFu5c3bYVEK
6A2YSW0WIrNiQtcI9Ka99dCCzHI6cwohlDhxQddJEG4w30hewsFBFJqftSpPLhkv
ToSUNDYe37QmRgVrcns//repWoaMwsrt8MMQU6MLb9pyaoT4Pffe1vcbqg+/XgUN
EJENI7BjSOw=
=BTMr
-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] PEP 376

[Tarek Ziadé]

On Thu, Jul 2, 2009 at 5:44 AM, Stephen J. Turnbull wrote:
> That's a judgment you must make.  However, Paul's opinion seems to be
> that it is internal, and not needed by third-parties who are working
> "on the top" of these classes.  If upon consideration you agree, you
> should take those "details" out of the PEP proper.  If you disagree,
> you should promote them to the "official"/public API.
>
> The point of a PEP is not to construct a duck; it is to explain what
> "quack" means.

Yes, while the APIs I have written in the prototype+PEP helped us
claryfing what we wanted,
I agree they would be better in a second document.

They are two target audience, the users of distutils and the builders
of package managers,
so removing this details from the PEP will also make it easier to read
for the first crowd.

>
> Another general principle: even in the draft PEP, say "is", not "will
> be".

Ok I'll fix that. That's a French stuff : in french, "will be" isn't
speculative at all.

Thx
___
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] PEP 376

[Tarek Ziadé]

On Thu, Jul 2, 2009 at 4:41 AM, P.J. Eby wrote:
> Yes and no.  Not providing uninstall support is reasonable, but the PEP also
> has features to query packages in general.
>
> (There's also no technical reason why comparable manifest and uninstall
> support can't be provided for .egg files and directoriees, since they
> already have an implicit manifest: their contents.  However, since I'm not
> currently possessed of the time to provide a patch myself, I'm not going to
> lobby for this as a feature.)
>

Yes that's not technical : I am in favor of keeping a single format. I
don't see but confusion in keeping several formats,
___
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] PEP 376

[Paul Moore]

2009/7/1 R. David Murray :
> I haven't read the PEP in detail since it's outside my area of interest
> and knowledge(*), but my understanding of the goal is that the PEP is
> providing an _infrastructure_ for system-level package management tools.
> The uninstall function is part of that infrastructure, but since
> distutils isn't a package manager itself (it's an install program),
> distutils as currently organized can't really handle uninstall except
> as outlined in a section you may have clipped from the above context
> (ie: when setup.py from the original package is available).

>From a Windows user's POV, "install program" = "package manager". And
an install program needs an uninstall feature. I know Linux users with
their advanced dependency-managing package managers feel that this is
a stone-age view, and they may be right, but the PEP needs to take the
Windows situation into account.

> The question is what do the people who do real package management
> (linux distribution level package management and the equivalent) think?
> I'm guessing they are happy with just having the function for their
> package management tools to call when needed, since (I'm hoping) they
> are part of the distutils sig

Don't forget that the maintainers of the bdist_wininst, bdist_msi and
bdist_rpm code *are* the distutils maintainers - so to that extent,
the PEP has to say how *those* aspects of package managers are
covered. Unless another PEP is accepted saying that support for
bdist_xxx is being dropped [1], this part of distutils cannot be
ignored.

>
> So, if my understanding of the overall goal is correct, it looks to me
> like the PEP is missing a "motivation" section that talks about system
> package managers.

Possibly. If so, though, it must discuss the above 3 cases which are
part of core distutils.

Paul.

[1] A PEP I plan on strongly opposing!
___
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