Re: [Python-Dev] stabilizing for a release

[anatoly techtonik]

There is still a serious regression in zipfile module:
http://bugs.python.org/issue6090

And I would really like to see my issue with difflib tabs committed: =/
http://bugs.python.org/issue7585

-- 
anatoly t.



On Wed, Apr 7, 2010 at 4:09 AM, Benjamin Peterson  wrote:
> Let's do it. Please no commits to the trunk which are not aimed at
> fixing the current buildbot failures. Thank you!
>
> 2010/4/6 "Martin v. Löwis" :
>> Benjamin Peterson wrote:
>>> I propose that we freeze the trunk except for fixes for the buildbots. 
>>> Thoughts?
>>
>> Freezing sounds fine with me.
>>
>> Martin
>>
>
>
>
> --
> 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/techtonik%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] stabilizing for a release

[Martin v. Löwis]

anatoly techtonik wrote:
> There is still a serious regression in zipfile module:
> http://bugs.python.org/issue6090
>
> And I would really like to see my issue with difflib tabs committed: =/
> http://bugs.python.org/issue7585

None of these are buildbot failures, so they can't go into 2.7b1,
by the decision of the release manager. Please accept 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] stabilizing for a release

[anatoly techtonik]

On Wed, Apr 7, 2010 at 2:10 PM, "Martin v. Löwis"  wrote:
>
>> There is still a serious regression in zipfile module:
>> http://bugs.python.org/issue6090
>>
>> And I would really like to see my issue with difflib tabs committed: =/
>> http://bugs.python.org/issue7585
>
> None of these are buildbot failures, so they can't go into 2.7b1,
> by the decision of the release manager. Please accept that.

And where will they go?

-- 
anatoly t.
___
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] stabilizing for a release

[Michael Foord]

On 07/04/2010 11:30, anatoly techtonik wrote:

There is still a serious regression in zipfile module:
http://bugs.python.org/issue6090

And I would really like to see my issue with difflib tabs committed: =/
http://bugs.python.org/issue7585

   
The zipfile issue looks like it could be fixed for beta 2. Not so sure 
about the difflib one.


Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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] stabilizing for a release

[Martin v. Löwis]

anatoly techtonik wrote:
> On Wed, Apr 7, 2010 at 2:10 PM, "Martin v. Löwis"  wrote:
>>> There is still a serious regression in zipfile module:
>>> http://bugs.python.org/issue6090
>>>
>>> And I would really like to see my issue with difflib tabs committed: =/
>>> http://bugs.python.org/issue7585
>> None of these are buildbot failures, so they can't go into 2.7b1,
>> by the decision of the release manager. Please accept that.
> 
> And where will they go?

For the former, a patch is still needed. For the latter, David will decide.

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] ffi junk messages

[Jeroen Ruigrok van der Werven]

Before I file a bug report, is anyone else seeing this (in my case on
FreeBSD 8):

Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first 
unrecognized character is `@'
Modules/_ctypes/libffi/src/x86/sysv.S:387: Error: junk at end of line, first 
unrecognized character is `@'
Modules/_ctypes/libffi/src/x86/sysv.S:423: Error: junk at end of line, first 
unrecognized character is `@'

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Tattva, achintya bheda abheda tattva...
___
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] ffi junk messages

[Mark Dickinson]

On Wed, Apr 7, 2010 at 1:39 PM, Jeroen Ruigrok van der Werven
 wrote:
> Before I file a bug report, is anyone else seeing this (in my case on
> FreeBSD 8):
>
> Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first 
> unrecognized character is `@'
> Modules/_ctypes/libffi/src/x86/sysv.S:387: Error: junk at end of line, first 
> unrecognized character is `@'
> Modules/_ctypes/libffi/src/x86/sysv.S:423: Error: junk at end of line, first 
> unrecognized character is `@'

It's on the buildbots, too.  See:

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/208/steps/compile/logs/stdio

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] ffi junk messages

[Martin v. Löwis]

Mark Dickinson wrote:
> On Wed, Apr 7, 2010 at 1:39 PM, Jeroen Ruigrok van der Werven
>  wrote:
>> Before I file a bug report, is anyone else seeing this (in my case on
>> FreeBSD 8):
>>
>> Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first 
>> unrecognized character is `@'
>> Modules/_ctypes/libffi/src/x86/sysv.S:387: Error: junk at end of line, first 
>> unrecognized character is `@'
>> Modules/_ctypes/libffi/src/x86/sysv.S:423: Error: junk at end of line, first 
>> unrecognized character is `@'
> 
> It's on the buildbots, too.  See:
> 
> http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/208/steps/compile/logs/stdio

Instead of submitting a bug report, it would be better to submit a
patch, though. Can you try having the build process use freebsd.S
instead of sysv.S?

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] ffi junk messages

[Jeroen Ruigrok van der Werven]

-On [20100407 15:29], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
>Instead of submitting a bug report, it would be better to submit a
>patch, though. Can you try having the build process use freebsd.S
>instead of sysv.S?

Mark and me are looking at it right now.

I can compile ctypes using --with-system-ffi at least.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Grabbing at angels when I fall, for all my demons to applaud, I am free...
___
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] Proposing PEP 376

[Tarek Ziadé]

2010/4/2 P.J. Eby :
[...]
>
> * Paths under the base installation location are relative to the base
> * Paths not under the base installation location, but under the installation
> prefix, are also stored relative to the base, IF the base location is a
> subpath of the installation prefix
> * All other paths are absolute.
>
> Where "base location" is the effective --install-lib directory, and prefix
> is the effective --prefix.  (Which default of course to site-package and
> sys.prefix respectively, but the spec shouldn't be in terms of those
> defaults.)

Just to make sure we agree on this:

we use relative path if the file is in site-packages, or somewhere
under sys.prefix. For the latter this is only if site-packages is
under sys.prefix.

Examples under debian:

docutils/__init__.py  -> located in
/usr/local/lib/python2.6/site-packages/
../../../bin/rst2html.py   ->  located in /usr/local/bin
/etc/whatever  -> located in /etc

So, everything under /usr/local (sys.prefix) is relative to
/usr/local/lib/python2.6/site-packages.
Other paths are absolute.

In case the site-packages directory was not under sys.prefix, we would
use an absolute path for files under sys.prefix but not in
site-packages. (like rst2html.py)

Regards
Tarek
-- 
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

Re: [Python-Dev] ffi junk messages

[exarkun]

On 01:29 pm, mar...@v.loewis.de wrote:

Mark Dickinson wrote:

On Wed, Apr 7, 2010 at 1:39 PM, Jeroen Ruigrok van der Werven
 wrote:

Before I file a bug report, is anyone else seeing this (in my case on
FreeBSD 8):

Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of 
line, first unrecognized character is `@'
Modules/_ctypes/libffi/src/x86/sysv.S:387: Error: junk at end of 
line, first unrecognized character is `@'
Modules/_ctypes/libffi/src/x86/sysv.S:423: Error: junk at end of 
line, first unrecognized character is `@'


It's on the buildbots, too.  See:

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/208/steps/compile/logs/stdio


Instead of submitting a bug report, it would be better to submit a


In *addition* to submitted a bug report, surely. :)

patch, though. Can you try having the build process use freebsd.S
instead of sysv.S?

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/exarkun%40twistedmatrix.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] ffi junk messages

[Martin v. Löwis]

>> Instead of submitting a bug report, it would be better to submit a
> 
> In *addition* to submitted a bug report, surely. :)

I'm not so sure. It's a ctypes/libffi bug, so most likely, nobody will
be able to fix it when reported. For platform-specific libffi bugs, the
patch most likely will come from the submitter, as nobody else might
have access to the platform, and the knowledge about the platform details.

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] ffi junk messages

[Jeroen Ruigrok van der Werven]

-On [20100407 16:17], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
>I'm not so sure. It's a ctypes/libffi bug, so most likely, nobody will
>be able to fix it when reported. For platform-specific libffi bugs, the
>patch most likely will come from the submitter, as nobody else might
>have access to the platform, and the knowledge about the platform details.

No it is not actually.

Mark and me found the culprit in the Python tree. Commit incoming.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
I dream of Love as Time runs through my hand...
___
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] Proposing PEP 376

[P.J. Eby]

At 04:01 PM 4/7/2010 +0200, Tarek Ziadé wrote:

2010/4/2 P.J. Eby :
[...]
>
> * Paths under the base installation location are relative to the base
> * Paths not under the base installation location, but under the 
installation

> prefix, are also stored relative to the base, IF the base location is a
> subpath of the installation prefix
> * All other paths are absolute.
>
> Where "base location" is the effective --install-lib directory, and prefix
> is the effective --prefix.  (Which default of course to site-package and
> sys.prefix respectively, but the spec shouldn't be in terms of those
> defaults.)

Just to make sure we agree on this:

we use relative path if the file is in site-packages, or somewhere
under sys.prefix. For the latter this is only if site-packages is
under sys.prefix.


Um, sys.prefix, or the prefix set by "setup.py install --prefix" 
(which of course defaults to sys.prefix)?


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

[Tarek Ziadé]

On Wed, Apr 7, 2010 at 4:35 PM, P.J. Eby  wrote:
> At 04:01 PM 4/7/2010 +0200, Tarek Ziadé wrote:
>>
>> 2010/4/2 P.J. Eby :
>> [...]
>> >
>> > * Paths under the base installation location are relative to the base
>> > * Paths not under the base installation location, but under the
>> > installation
>> > prefix, are also stored relative to the base, IF the base location is a
>> > subpath of the installation prefix
>> > * All other paths are absolute.
>> >
>> > Where "base location" is the effective --install-lib directory, and
>> > prefix
>> > is the effective --prefix.  (Which default of course to site-package and
>> > sys.prefix respectively, but the spec shouldn't be in terms of those
>> > defaults.)
>>
>> Just to make sure we agree on this:
>>
>> we use relative path if the file is in site-packages, or somewhere
>> under sys.prefix. For the latter this is only if site-packages is
>> under sys.prefix.
>
> Um, sys.prefix, or the prefix set by "setup.py install --prefix" (which of
> course defaults to sys.prefix)?

Yes, I used default values to make the text clearer.

so for the PEP :

- sys.prefix -> the installation prefix provided by --prefix at
installation time
- site-packages -> the installation libdir, provided by --install-lib
at installation time




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

Re: [Python-Dev] ffi junk messages

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> 
> >> Instead of submitting a bug report, it would be better to submit a
> > 
> > In *addition* to submitted a bug report, surely. :)
> 
> I'm not so sure. It's a ctypes/libffi bug, so most likely, nobody will
> be able to fix it when reported.

It's probably still good to record the existence of these bugs, even if we don't
know how to fix them. That way, other people which get the bug can contribute to
the issue, and perhaps work together towards resolving it.

(also, as I understand it, the latest ctypes issues seem to have popped up after
an update of the bundled libffi, so perhaps that update wasn't totally right,
didn't choose the right libffi version, or missed some files?)

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

[Python-Dev] Episode 11 of A Little Bit of Python

[Michael Foord]

Hello all,

Not *strictly* on topic, but probably of interest nonetheless (so my 
apologies).


Episode 11 of "A Little Bit of Python" is now available. An interview 
with core-CPython developer Antoine Pitrou.


http://advocacy.python.org/podcasts/littlebit/2010-04-07.mp3

Many thanks to Antoine for the interview.

All the best,

Michael Foord

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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] ffi junk messages

[Martin v. Löwis]

> (also, as I understand it, the latest ctypes issues seem to have popped up 
> after
> an update of the bundled libffi, so perhaps that update wasn't totally right,
> didn't choose the right libffi version, or missed some files?)

In the case of the SPARC issue: the bug is still exists in the libffi hg
repository.

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

[Ian Bicking]

On Wed, Apr 7, 2010 at 9:40 AM, Tarek Ziadé  wrote:

> so for the PEP :
>
> - sys.prefix -> the installation prefix provided by --prefix at
> installation time
> - site-packages -> the installation libdir, provided by --install-lib
> at installation time


How do you actually calculate site-packages?  Would you store the directory
name somewhere?  Would you import the module and look at
os.path.dirname(os.path.dirname(module.__file__))?  Or just scan to see
where the module would be?

If you store the directory name somewhere then you have another absolute
path.  This is why, for simplicity, I thought it should be relative to the
directory where the record file is (lots of extraneous ../, but the most
obvious meaning of a relative filename).

-- 
Ian Bicking  |  http://blog.ianbicking.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] Proposing PEP 376

[P.J. Eby]

At 12:48 AM 4/4/2010 +0200, Tarek Ziadé wrote:

The implementation so far will load zip files founded in the paths,
see ZippedDistributionDir/ZippedDistribution.


I was saying that it doesn't support sys.path entries of the form:

  "some/path/to/somezipfile.zip/subdir1"

Python works correctly for importing with this, but the ZipFinder 
class in the implementation throws away 'subdir1' and only scans the 
root of the zipfile, silently generating incorrect results in such a case.


To fix the problem, you would need to make use of the .archive and 
.prefix attributes of defined by the underlying zipimporter 
class.  After you call the super().__init__ method, .archive points 
to the actual zipfile path, and .prefix contains the portion of the 
path that's inside the zipfile.  You can then just adjust your path 
usage in ZipFinder and ZippedDistribution accordingly.


Also, as far as I can tell from the source, ZipFinder instances are 
never actually created, except through explicit usage in some of the 
tests.  i.e., it doesn't work out of the box right now.  However, 
this could be fixed with the addition of the code snippets below...




I am wondering though, if we shouldn't omit this zip story for PEP 376
altogether, and work later on
something more generic wrt import protocols where modules/packages
could be stored anywhere.


Essentially, you could do something like:

@simplegeneric  # <-already in stdlib pkgutil since 2.5
def dist_finder_for(importer):
if hasattr(importer, 'list_distributions'):
return importer
return None

dist_finder_for.register(ImpImporter, FSFinder)
dist_finder_for.register(zipimporter, ZipFinder)

And then your all_finders() function would be reduced to:

def all_finders():
for importer in iter_importers():  # <-already in stdlib pkgutil
finder = dist_finder_for(importer)
if finder is not None:
 yield finder

As you can see, it's pretty easy to integrate with your existing 
code.  simplegeneric and iter_importers (as well as a 
get_importer(pathentry) function, ImpImporter, etc.) have been in 
pkgutil since 2.5, but you can always backport them if you're making 
a standalone version for 2.4.




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

[P.J. Eby]

At 04:40 PM 4/7/2010 +0200, Tarek Ziadé wrote:

On Wed, Apr 7, 2010 at 4:35 PM, P.J. Eby  wrote:
> At 04:01 PM 4/7/2010 +0200, Tarek Ziadé wrote:
>>
>> 2010/4/2 P.J. Eby :
>> [...]
>> >
>> > * Paths under the base installation location are relative to the base
>> > * Paths not under the base installation location, but under the
>> > installation
>> > prefix, are also stored relative to the base, IF the base location is a
>> > subpath of the installation prefix
>> > * All other paths are absolute.
>> >
>> > Where "base location" is the effective --install-lib directory, and
>> > prefix
>> > is the effective --prefix.  (Which default of course to site-package and
>> > sys.prefix respectively, but the spec shouldn't be in terms of those
>> > defaults.)
>>
>> Just to make sure we agree on this:
>>
>> we use relative path if the file is in site-packages, or somewhere
>> under sys.prefix. For the latter this is only if site-packages is
>> under sys.prefix.
>
> Um, sys.prefix, or the prefix set by "setup.py install --prefix" (which of
> course defaults to sys.prefix)?

Yes, I used default values to make the text clearer.

so for the PEP :

- sys.prefix -> the installation prefix provided by --prefix at
installation time
- site-packages -> the installation libdir, provided by --install-lib
at installation time


Yes.  Looking more closely at your example, though:


Examples under debian:

docutils/__init__.py  -> located in
/usr/local/lib/python2.6/site-packages/
../../../bin/rst2html.py   ->  located in /usr/local/bin
/etc/whatever  -> located in /etc


I'm wondering if there's really any benefit to having 
../../../bin/rst2html.py vs. /usr/local/bin/rst2html.py.  Was there a 
use case for that, or should we just go with relative paths ONLY for 
children of the libdir?


(I only suggested this setup in order to preserve as much of the 
prefix-relativity proposal as possible, but I wasn't the one who 
proposed prefix-relativity so I don't recall what the use case is, 
and I don't even remember who proposed it.  I only ever had a usecase 
for libdir-relativity personally.)


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

[P.J. Eby]

At 11:33 AM 4/7/2010 -0500, Ian Bicking wrote:
On Wed, Apr 7, 2010 at 9:40 AM, Tarek Ziadé 
<ziade.ta...@gmail.com> wrote:

so for the PEP :

- sys.prefix -> the installation prefix provided by --prefix at
installation time
- site-packages -> the installation libdir, provided by --install-lib
at installation time


How do you actually calculate site-packages? Â Would you store the 
directory name somewhere? Â Would you import the module and look at 
os.path.dirname(os.path.dirname(module.__file__))? Â Or just scan to 
see where the module would be?


If you store the directory name somewhere then you have another 
absolute path. Â This is why, for simplicity, I thought it should be 
relative to the directory where the record file is (lots of 
extraneous ../, but the most obvious meaning of a relative filename).


The paths are relative to the sys.path entry for which the metadata 
applies - that's how you get to finding the .dist-info in the first 
place, so that's what you os.path.join to the paths in the record.


There's no "storing" of the directory name needed. 


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

[Ian Bicking]

On Wed, Apr 7, 2010 at 12:45 PM, P.J. Eby  wrote:

>  Examples under debian:
>>
>>docutils/__init__.py  -> located in
>> /usr/local/lib/python2.6/site-packages/
>>../../../bin/rst2html.py   ->  located in /usr/local/bin
>>/etc/whatever  -> located in /etc
>>
>
> I'm wondering if there's really any benefit to having
> ../../../bin/rst2html.py vs. /usr/local/bin/rst2html.py.  Was there a use
> case for that, or should we just go with relative paths ONLY for children of
> the libdir?
>
> (I only suggested this setup in order to preserve as much of the
> prefix-relativity proposal as possible, but I wasn't the one who proposed
> prefix-relativity so I don't recall what the use case is, and I don't even
> remember who proposed it.  I only ever had a usecase for libdir-relativity
> personally.)


Yes, in a virtualenv environment there will be ../../../bin/rst2html.py that
will still be under the (virtual) sys.prefix, and the whole bundle can be
usefully moved around.

-- 
Ian Bicking  |  http://blog.ianbicking.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] Proposing PEP 376

[P.J. Eby]

At 12:51 PM 4/7/2010 -0500, Ian Bicking wrote:
On Wed, Apr 7, 2010 at 12:45 PM, P.J. Eby 
<p...@telecommunity.com> wrote:

Examples under debian:

   docutils/__init__.py          ->     located in
/usr/local/lib/python2.6/site-packages/
   ../../../bin/rst2html.py       ->  located in /usr/local/bin
   /etc/whatever                  ->     located in /etc


I'm wondering if there's really any benefit to having 
../../../bin/rst2html.py vs. /usr/local/bin/rst2html.py. Â Was there 
a use case for that, or should we just go with relative paths ONLY 
for children of the libdir?


(I only suggested this setup in order to preserve as much of the 
prefix-relativity proposal as possible, but I wasn't the one who 
proposed prefix-relativity so I don't recall what the use case is, 
and I don't even remember who proposed it. Â I only ever had a 
usecase for libdir-relativity personally.)



Yes, in a virtualenv environment there will be 
../../../bin/rst2html.py that will still be under the (virtual) 
sys.prefix, and the whole bundle can be usefully moved around.


Ah, ok.  Good!  +1, then.

___
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] [python-committers] stabilizing for a release

[R. David Murray]

On Wed, 07 Apr 2010 12:54:51 +0100, Michael Foord  
wrote:
>On 07/04/2010 11:30, anatoly techtonik wrote:
>> There is still a serious regression in zipfile module:
>> http://bugs.python.org/issue6090
>>
>> And I would really like to see my issue with difflib tabs committed: =/
>> http://bugs.python.org/issue7585
>>
>>
>The zipfile issue looks like it could be fixed for beta 2. Not so sure
>about the difflib one.

As Antoine pointed out, 7585 is actually a bug fix (making difflib follow
the unified diff 'standard', as it was originally specified to do).
So unless Benjamin objects I plan to commit it after the freeze.

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

[Python-Dev] iso-2022 and issue 7472: question for the experts

[Stephen J. Turnbull]

R. David Murray writes:
 > A long time ago (in a galaxy far far...no, wrong show)
 > 
 > Er, as I was saying, a long time ago Barry applied a patch to
 > email that went more or less like this:
 > 
 > ndex: email/Encoders.py
 > ===
 > --- email/Encoders.py   (revision 35918)
 > +++ email/Encoders.py   (revision 35919)
 > @@ -84,7 +83,13 @@
 >  try:
 >  orig.encode('ascii')
 >  except UnicodeError:
 > -msg['Content-Transfer-Encoding'] = '8bit'
 > +# iso-2022-* is non-ASCII but still 7-bit

This comment may be inaccurate.  The ISO 2022 family includes what are
normally "8bit" encodings such as the EUC family and ISO 8859.  I
don't know whether there are any IANA-registered 8bit charsets with
names that start with 'iso-2022-', and AFAIK there are none in Python.
(There is an 'iso-2022-8' encoding in Emacs, though.)  Still, I'd be
more comfortable with an explicit list than with the
.startswith('iso-2022-') idiom.

 > +charset = msg.get_charset()
 > +output_cset = charset and charset.output_charset
 > +if output_cset and output_cset.lower().startswith('iso-2202-'):
 > +msg['Content-Transfer-Encoding'] = '7bit'
 > +else:
 > +msg['Content-Transfer-Encoding'] = '8bit'
 >  else:
 >  msg['Content-Transfer-Encoding'] = '7bit'

 > Reading the standards, it looks to me like either the ISO-2022
 > input will be 7-bit, and the except will not trigger, or it will be
 > invalid, because 8bit, and so should be set to 8bit just like all
 > the other cases where there's invalid 8bit data.  So I think this
 > patch should just be reverted.

I have nothing to add to what Martin said about the basic analysis.

It would be possible to just unconditionally set the
Content-Transfer-Encoding to 8bit, although that may violate a SHOULD
in the MIME standard.
___
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] regrtest oddify

[Martin v. Löwis]

I have commented out all tests in test_gdb, yet

http://www.python.org/dev/buildbot/all/builders/sparc%20Ubuntu%20trunk/builds/47/steps/test/logs/stdio

still shows them being run. Can anybody explain that, please?

TIA,
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] regrtest oddify

[Benjamin Peterson]

2010/4/7 "Martin v. Löwis" :
> I have commented out all tests in test_gdb, yet
>
> http://www.python.org/dev/buildbot/all/builders/sparc%20Ubuntu%20trunk/builds/47/steps/test/logs/stdio
>
> still shows them being run. Can anybody explain that, please?

That's because the buildbot only updated to the revision before your change.



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

[Python-Dev] Issue #7978, unexpected EINTR-related exceptions

[Yaniv Aknin]

Issue #7978 (http://bugs.python.org/issue7978) describes a bug in
SocketServer where a received signal in SocketServer's select() call
will raise an uncaught exception due to EINTR. The proposed solution
was to wrap SocketServer's select() with something like twisted's
untilConcludes function, which catches EINTR exceptions and re-calls
the call (see issue for code).

However, before committing this to SocketServer, neologix raised the
(valid) concern that this is generally-useful code, already duplicated
at least in subprocess (_eintr_retry_call, subprocess.py), which can
probably be moved to another module and be shared from there. It was
recommended to bring this issue in the broader context to the list,
but from my look at the archives no one did, hence this message.

There are a few more points of discussion on the issue's roundup
thread which I won't list here, so it's best to look there if you
care. Also, I'm rather new on python-dev and I'm not sure how
duplicate python-dev/roundup threads are usually handled, but I humbly
think if this issue interests you it's best to add your thoughts to
the issue's comments, rather than here; please correct me if this is a
misguided assumption.

Cheers,
 - Yaniv
___
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