Re: [Python-Dev] Rework nntplib?

[Nick Coghlan]

On Mon, Sep 20, 2010 at 12:25 PM, R. David Murray rdmur...@bitdance.com wrote:
 On Mon, 20 Sep 2010 06:55:50 +1000, Nick Coghlan ncogh...@gmail.com wrote:
 On Mon, Sep 20, 2010 at 3:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
 
  For the record, the code is pretty much done now:
  http://bugs.python.org/issue9360

 Generally looks pretty reasonable. As I noted on the issue, my one
 concern is that the current API seems to rely on the programmer
 remembering which methods return strings and which return bytes
 without any consistent mnemonic as to which is which.

 The mnemonic is: *raw message data* is bytes, everything else is unicode.
 That is, the *content* of head, body, article, post, and ihave commands
 is bytes, otherwise you are dealing with strings.  I think it is a
 very clear and obvious distinction, myself.

Yeah, after Antoine's response, I was happy that was a problem with my
understanding of the API, rather than the API itself.

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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Nick Coghlan]

On Mon, Sep 20, 2010 at 2:12 PM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
 While I don't like the email6 precedent as such (that there would be
 different parsed objects, based on whether you started parsing with bytes or
 with strings), the idea that when you are working directly with bytes or
 text, you should have to know which one you have, is a good one.  +1 for
 keeping the APIs separate with 'urlsplitb' etc.

It's primarily the am I dealing with bytes or am I dealing with
text precedent that I'm copying. That said, I'm not personally
opposed to that distinction propagating to higher level data
structures when it makes sense (e.g., to some degree it will propagate
naturally in urllib.parse, since the tuples of URL fragments can be
seen as higher level data structures analogous to the data structures
in email6).

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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Chris McDonough]

On Sun, 2010-09-19 at 12:03 +1000, Nick Coghlan wrote:
 On Sun, Sep 19, 2010 at 4:18 AM, John Nagle na...@animats.com wrote:
  On 9/18/2010 2:29 AM, python-dev-requ...@python.org wrote:
 
  Polymorphic best practices [was: (Not) delaying the 3.2 release]
 
If you're hung up on this, try writing the user-level documentation
  first.  Your target audience is a working-level Web programmer, not
  someone who knows six programming languages and has a CS degree.
  If the explanation is too complex, so is the design.
 
Coding in this area is quite hard to do right.  There are
  issues with character set, HTML encoding, URL encoding, and
  internationalized domain names.  It's often done wrong;
  I recently found a Google service which botched it.
  Python libraries should strive to deliver textual data to the programmer
  in clean Unicode.  If someone needs the underlying wire representation
  it should be available, but not the default.
 
 Even though URL byte sequences are defined as using only an ASCII
 subset, I'm currently inclined to add raw bytes supports to
 urlib.parse by providing parallel APIs (i.e. urlib.parse.urlsplitb,
 etc) rather than doing it implicitly in the normal functions.
 
 My rationale is as follows:
 - while URLs are *meant* to be encoded correctly as an ASCII subset,
 the real world isn't always quite so tidy (i.e. applications treat as
 URLs things that technically are not because the encoding is wrong)
 - separating the APIs forces the programmer to declare that they know
 they're working with the raw bytes off the wire to avoid the
 decode/encode overhead that comes with working in the Unicode domain
 - easier to change our minds later. Adding implicit bytes support to
 the normal names can be done any time, but removing it would require
 an extensive deprecation period
 
 Essentially, while I can see strong use cases for wanting to
 manipulate URLs in wire format, I *don't* see strong use cases for
 manipulating URLs without *knowing* whether they're in wire format
 (encoded bytes) or display format (Unicode text). For some APIs that
 work for arbitrary encodings (e.g. os.listdir) switching based on
 argument type seems like a reasonable idea. For those that may
 silently produce incorrect output for ASCII-incompatible encodings,
 the os.environ/os.environb seems like a better approach.

urllib.parse.urlparse/urllib.parse.urlsplit will never need to decode
anything when passed bytes input.  Both could just put the bytes
comprising the hex-encoded components (the path and query string) into
its respective place in the parse results, just like it does now for
string input.  As far as I can tell, the only thing preventing it from
working against bytes right now is the use of string literals in the
source instead of input-type-dictated-literals.  There should not really
be any need to create a urllib.parse.urlsplitb unless the goal is to
continue down the (not great IMO) precedent already set by the shadow
bytes API in urllib.parse (*_to_bytes, *_from_bytes) or if we just want
to make it deliberately harder to parse URLs. 

The only decoding that needs to be done to potential bytes input by APIs
in urllib.parse will be in the face of percent encodings in the path and
query components (handled entirely by unquote and unquote_plus,
which already deal in bytes under the hood).  The only encoding that
needs to be done by urllib.parse is in the face of input to the
urlencode and quote APIs.  quote already deals with bytes as input
under the hood.  urlencode does not, but it might be changed use the
same strategy that quote does now (by using a urlencode_to_bytes
under the hood).

However, I think any thought about adding raw bytes support is largely
moot at this point.  This pool has already been peed in.There's
effectively already a shadow bytes-only API in the urlparse module in
the form of the *_to_bytes and *_from_bytes functions in most places
where it counts.  So as I see it, the options are:

1) continue the *_to_bytes and *_from_bytes pattern as necessary.

2) create a new module (urllib.parse2) that has only polymorphic
   functions.

#1 is not very pleasant to think about as a web developer if I need to
maintain a both-2-and-3-compatible codebase.  Neither is #2, really, if
I had to support Python 3.1 and 3.2.  From my (obviously limited)
perspective, a more attractive third option is backwards incompatibility
in a later Python 3 version, where encoding-aware functions like quote,
urlencode, and unquote_plus were polymorphic, accepting both bytes and
string objects and returning same-typed data.

- C


___
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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Nick Coghlan]

On Mon, Sep 20, 2010 at 10:12 PM, Chris McDonough chr...@plope.com wrote:
 urllib.parse.urlparse/urllib.parse.urlsplit will never need to decode
 anything when passed bytes input.

Correct. Supporting manipulation of bytes directly is primarily a
speed hack for when an application wants to avoid the
decoding/encoding overhead needed to perform the operations in the
text domain when the fragments being manipulated are all already
correctly encoded ASCII text.

However, supporting direct manipulation of bytes *implicitly* in the
current functions is problematic, since it means that the function may
fail silently when given bytes that are encoded with an ASCII
incompatible codec (or which there are many, especially when it comes
to multibyte codecs and other stateful codecs). Even ASCII compatible
codecs are a potential source of hard to detect bugs, since using
different encodings for different fragments will lead directly to
mojibake.

Moving the raw bytes support out to separate APIs allows their
constraints to be spelled out clearly and for programmers to make a
conscious decision that that is what they want to do. The onus is then
on the programmer to get their encodings correct.

If we decide to add implicit support later, that's pretty easy (just
have urllib.parse.* delegate to urllib.parse.*b when given bytes).
Taking implicit support *away* after providing it, however, means
going through the whole deprecation song and dance. Given the choice,
I prefer the API design that allows me to more easily change my mind
later if I decide I made the wrong call.

 There's effectively already a shadow bytes-only API in the urlparse module 
 in the form of the *_to_bytes and *_from_bytes functions in most places where 
 it counts.

If by most places where it counts you mean quote and unquote,
then sure. However, those two functions predate most of the work on
fixing the bytes/unicode issues in the OS facing libraries, so they
blur the lines more than may be desirable (although reading
http://bugs.python.org/issue3300 shows that there were a few other
constraints in play when it comes to those two operations, especially
those related to the encoding of the original URL *prior* to
percent-encoding for transmission over the wire).

Regardless, quoteb and unquoteb will both be strictly bytes-bytes
functions, whereas the existing quoting APIs attempt to deal with both
text encoding and URL quoting all at the same time (and become a fair
bit more complicated as a result).

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] Python 2.7 Won't Build

[Tom Browder]

Continuing on with investigating Python 2.7 build problems, one
problem I just discovered is a different installation on one 64-bit
system (Debian Lenny) versus another (Ubuntu 10.04.1 LTS).

I used gcc-4.5.1 on both systems, with no *PY* environment variables set.

On Debian I got two directories:

  /usr/local/lib64/python2.7
  /usr/local/lib/python2.7

and only the first had the config subdirectory.

On Ubuntu I got only

  /usr/local/lib/python2.7

I see that the configure file has some architecture choices
(--with-universal-archs=ARCH) but no explanation about the
consequences.

Can anyone explain the two different default installations I got?

It seems to me I should force the Ubuntu-style installation by  the
--with-universal-archs=64-bit configure option, and I will try that
on Debian while I await expert help.

Thanks.

-Tom
___
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] Buildbot for AIX

[Sébastien Sablé]

Le 17/09/2010 15:05, Antoine Pitrou a écrit :

Following on Martin's comments, you might also want to share things
with the ActiveState guys who, AFAIK, maintain an AIX version of Python
(but you have been the most active AIX user on the bug tracker lately;
perhaps they are keeping their patches to themselves).


I tried to find some source package or subversion repository on their 
web site, but they only distribute binary versions.
Also it is only the Business Edition that supports AIX and it is 
clearly sold with a proprietary license.


So I doubt they would share their patches related to AIX, but I can 
always ask.


Regards

--
Sébastien Sablé
___
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] Buildbot for AIX

[Sébastien Sablé]

Hi Martin,

Le 17/09/2010 14:42, Martin v. Löwis a écrit :

If you are having the build slave compile Python, I'd like to point
out that you *already* run arbitrary shell commands provided by
some external source: if somebody would check some commands into
Python's configure.in, you would unconditionally execute them.
So if it's ok that you run the Python build process at all, it should
(IMO) also be acceptable to run a build slave.

If there are concerns that running it under your Unix account gives it
too much power, you should create a separate, locked-down account.


Someone messing with the configure script in python svn would probably 
get noticed very quickly, but I agree this is also a security risk, and 
the buildbot slave runs with a user with limited privileges.


I will try to convince the IT Team that this is an acceptable risk and 
setup a chroot or something like that for the buildbot slave. That may 
take some time.


Also could you provide me the master.cfg file (with obfuscated 
passwords) that is used by the Python buildbot master or tell me if it 
is in subversion somewhere?
I would like to make my script as close as possible to yours, in order 
to propose a patch for the AIX specific flags that have to be used for 
compilation on this platform when everything will be stable enough.


Regards

--
Sébastien Sablé
___
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] Fwd: Builder: x86 Windows7 3.x OpenSSL compile error

[Hirokazu Yamamoto]

Hello. I've sent following mail to buildbot manager,
but I found that buildbot page saids the problem of unsable
bot should be sent to python-...@python.org. So I'll do it.

 Original Message 
Subject: Builder: x86 Windows7 3.x OpenSSL compile error
Date: Mon, 20 Sep 2010 22:53:04 +0900
From: Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp
To: db3l@gmail.com

Hello, David Bolen. I'm Hirokazu Yamamoto, Python committer.
I've noticed your buildbot x86 Windows7 3.x fails to compile OpenSSL,
I'm very sorry because this buildbot is very fast and looks useful.
(Running on Windows7 which I don't have)

Builder: x86 Windows7 3.x
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x

I confirmed this happens when nasmw's version is 2.06.
I'm using 2.07 on my machine, so I didn't notice this. I checked
Windows buildbot's nasmw versions with
Tools/buildbot/external_common.bat hack, the versions were

x86 Windows7 3.x Buildbot (FAILURE)
NASM version 2.06 compiled on Jul  1 2009

x86 XP-5 3.x Buildbot (OK)
NASM version 2.07 compiled on Jul 19 2009

x86 XP-4 3.x Buildbot (OK)
NASM version 2.02 compiled on Feb 23 2008

I didn't check 2.02 but probably it dosen't have this issue.
Could you upgrade nasmw on Windows7 buildbot? Thank you.

Regards,
Yamamoto.

___
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 2.7 Won't Build

[Tom Browder]

On Mon, Sep 20, 2010 at 10:12, Ronald Oussoren ronaldousso...@mac.com wrote:


 On 20 Sep, 2010,at 04:31 PM, Tom Browder tom.brow...@gmail.com wrote:

 Continuing on with investigating Python 2.7 build problems, one
 problem I just discovered is a different installation on one 64-bit
 system (Debian Lenny) versus another (Ubuntu 10.04.1 LTS).

 I used gcc-4.5.1 on both systems, with no *PY* environment variables set.

 On Debian I got two directories:

 /usr/local/lib64/python2.7
 /usr/local/lib/python2.7

 and only the first had the config subdirectory.

 On Ubuntu I got only

 /usr/local/lib/python2.7

Okay, that leads to an install problem with bazaar on the Debian beast:

Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
Traceback (most recent call last):
  File /usr/local/lib/python2.7/site.py, line 549, in module
main()
  File /usr/local/lib/python2.7/site.py, line 531, in main
known_paths = addusersitepackages(known_paths)
  File /usr/local/lib/python2.7/site.py, line 264, in addusersitepackages
user_site = getusersitepackages()
  File /usr/local/lib/python2.7/site.py, line 239, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
  File /usr/local/lib/python2.7/site.py, line 229, in getuserbase
USER_BASE = get_config_var('userbase')
  File /usr/local/lib/python2.7/sysconfig.py, line 518, in get_config_var
return get_config_vars().get(name)
  File /usr/local/lib/python2.7/sysconfig.py, line 421, in get_config_vars
_init_posix(_CONFIG_VARS)
  File /usr/local/lib/python2.7/sysconfig.py, line 275, in _init_posix
raise IOError(msg)
IOError: invalid Python installation: unable to open
/usr/local/lib/python2.7/config/Makefile (No such file or directory)

I tried setting PYTHONHOME to various things but none worked.  The
problem is that the config directory is under /usr/local/lib64 and
none of the documents I have found describes how to handle that
situation.  All the environment variables seem to be for libraries,
modules, and executables, and there is no reference to any lib64.

The pkg-config program looks as if it could be used by such packages
as bazaar but it doesn't look like it's one of the usual installation
tricks.

I'll go to the bazaar mailing list while awaiting an answer here.

Thanks,

-Tom
___
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 2.7 Won't Build

[Terry Reedy]

On 9/20/2010 10:31 AM, Tom Browder wrote:
...

I see that the configure file has some architecture choices
(--with-universal-archs=ARCH) but no explanation about the
consequences.

Can anyone explain the two different default installations I got?


At the moment, this appears to be question about how do I use (build) a 
current release rather than a bug report or how do we develop 
(improve) future releases question. As such, it seems a bit more 
appropriate for python-list. In any case, there are expert gcc/unix 
builders and users there who might be able to answer your question.


--
Terry Jan Reedy

___
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 2.7 Won't Build

[Ronald Oussoren]

On 20 Sep, 2010,at 04:31 PM, Tom Browder tom.brow...@gmail.com wrote:Continuing on with investigating Python 2.7 build problems, one
problem I just discovered is a different installation on one 64-bit
system (Debian Lenny) versus another (Ubuntu 10.04.1 LTS).

I used gcc-4.5.1 on both systems, with no *PY* environment variables set.

On Debian I got two directories:

  /usr/local/lib64/python2.7
  /usr/local/lib/python2.7

and only the first had the "config" subdirectory.

On Ubuntu I got only

  /usr/local/lib/python2.7

I see that the configure file has some architecture choices
(--with-universal-archs=ARCH) but no explanation about the
consequences.

Can anyone explain the two different "default" installations I got?

It seems to me I should force the Ubuntu-style installation by  the
"--with-universal-archs=64-bit" configure option, and I will try that
on Debian while I await expert help.--with-universal-archs only does something on OSX, and then only when --with-universalsdk is specified. It is used to select which processor architectures are included in a "universal binary" build of Python.Ronald

Thanks.

-Tom
___
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/ronaldoussoren%40mac.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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Chris McDonough]

On Mon, 2010-09-20 at 23:23 +1000, Nick Coghlan wrote:
 On Mon, Sep 20, 2010 at 10:12 PM, Chris McDonough chr...@plope.com wrote:
  urllib.parse.urlparse/urllib.parse.urlsplit will never need to decode
  anything when passed bytes input.
 
 Correct. Supporting manipulation of bytes directly is primarily a
 speed hack for when an application wants to avoid the
 decoding/encoding overhead needed to perform the operations in the
 text domain when the fragments being manipulated are all already
 correctly encoded ASCII text.

The urllib.parse.urlparse/urlsplit functions should never need to know
or care whether the input they're passed is correctly encoded.  They
actually don't care right now: both will happily consume non-ASCII
characters and spit out nonsense in the parse results.  If passed
garbage, they'll return garbage:

   urlparse('http://www.cwi.nl:80/%7Eguido/LaPeña.html')
  ParseResult(scheme='http', netloc='www.cwi.nl:80', 
  path='/%7Eguido/LaPeña.html', params='', 
  query='', fragment='')


 However, supporting direct manipulation of bytes *implicitly* in the
 current functions is problematic, since it means that the function may
 fail silently when given bytes that are encoded with an ASCII
 incompatible codec (or which there are many, especially when it comes
 to multibyte codecs and other stateful codecs). Even ASCII compatible
 codecs are a potential source of hard to detect bugs, since using
 different encodings for different fragments will lead directly to
 mojibake.

The path component result above is potentially useless and broken, and
if it is inserted into a web page as a link, it may cause mojibake, but
urlparse doesn't (can't) complain.  As far as I can tell, there would be
no more and no less potential for mojibake if the same API were able to
be fed a bytes object.  The result can already be nonsense and allowing
for bytes as input doesn't add any greater potential to receive nonsense
back.

Most APIs in urllib.parse exhibit the same behavior today, e.g. urljoin:

urljoin('http://gooñle.com', '%7Eguido/LaPeña.html')
   'http://gooñle.com/%7Eguido/LaPeña.html'

The resulting URL is total nonsense.

 Moving the raw bytes support out to separate APIs allows their
 constraints to be spelled out clearly and for programmers to make a
 conscious decision that that is what they want to do. The onus is then
 on the programmer to get their encodings correct.

I guess my argument is that the onus already *is* on the programmer to
get their encodings right.  They can just as easily screw up while using
str inputs.

 If we decide to add implicit support later, that's pretty easy (just
 have urllib.parse.* delegate to urllib.parse.*b when given bytes).
 Taking implicit support *away* after providing it, however, means
 going through the whole deprecation song and dance. Given the choice,
 I prefer the API design that allows me to more easily change my mind
 later if I decide I made the wrong call.

Existing APIs save for quote don't really need to deal with charset
encodings at all, at least on any level that Python needs to care about.
The potential already exists to emit garbage which will turn into
mojibake from almost all existing APIs.  The only remaining issue seems
to be fear of making a design mistake while designing APIs.

IMO, having a separate module for all urllib.parse APIs, each designed
for only bytes input is a design mistake greater than any mistake that
could be made by allowing for both bytes and str input to existing APIs
and returning whatever type was passed.  The existence of such a module
will make it more difficult to maintain a codebase which straddles
Python 2 and Python 3.

- C


___
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 2.7 Won't Build

[Tom Browder]

On Mon, Sep 20, 2010 at 13:05, Terry Reedy tjre...@udel.edu wrote:
 On 9/20/2010 10:31 AM, Tom Browder wrote:
 ...

 I see that the configure file has some architecture choices
 (--with-universal-archs=ARCH) but no explanation about the
 consequences.

 Can anyone explain the two different default installations I got?

 At the moment, this appears to be question about how do I use (build) a
 current release rather than a bug report or how do we develop (improve)
 future releases question. As such, it seems a bit more appropriate for
 python-list. In any case, there are expert gcc/unix builders and users there
 who might be able to answer your question.

Thanks, I'll do that--docs are pretty sketchy about building from source.

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA
___
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 2.7 Won't Build

[Tom Browder]

On Mon, Sep 20, 2010 at 13:05, Terry Reedy tjre...@udel.edu wrote:
 On 9/20/2010 10:31 AM, Tom Browder wrote:
 ...

 I see that the configure file has some architecture choices
 (--with-universal-archs=ARCH) but no explanation about the
 consequences.

 Can anyone explain the two different default installations I got?

 At the moment, this appears to be question about how do I use (build) a
 current release rather than a bug report or how do we develop (improve)
 future releases question. As such, it seems a bit more appropriate for
 python-list. In any case, there are expert gcc/unix builders and users there
 who might be able to answer your question.

The more I look into it, though, it seems to be a legitimate developer
question.  The python installation scripts know how to install on a
mixed 32/64 bit system but missed fixing it to look like a more
universal system (if that's the proper word) for programs wanting to
read its installation configuration.

Respectfully,

-Tom
___
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] Buildbot for AIX

[Martin v. Löwis]

 Also could you provide me the master.cfg file (with obfuscated
 passwords) that is used by the Python buildbot master or tell me if it
 is in subversion somewhere?

Attached!

Regards,
Martin
# -*- python -*-

# This is a sample buildmaster config file. It must be installed as
# 'master.cfg' in your buildmaster's base directory (although the filename
# can be changed with the --basedir option to 'mktap buildbot master').

# It has one job: define a dictionary named BuildmasterConfig. This
# dictionary has a variety of keys to control different aspects of the
# buildmaster. They are documented in docs/config.xhtml .

import os.path, time
from buildbot.buildslave import BuildSlave
from buildbot.scheduler import Scheduler, Nightly, log
from buildbot.process import factory
from buildbot.status import html
from buildbot.steps.shell import ShellCommand, Test, Compile
from buildbot.steps.source import SVN
from buildbot.steps.transfer import FileUpload, DirectoryUpload
from buildbot import util
s = factory.s

# This is the dictionary that the buildmaster pays attention to. We also use
# a shorter alias to save typing.
c = BuildmasterConfig = {}

# the 'bots' list defines the set of allowable buildslaves. Each element is a
# tuple of bot-name and bot-password. These correspond to values given to the
# buildslave's mktap invocation.
c['slaves'] = [
XXX
]


# the 'change_source' setting tells the buildmaster how it should find out
# about source code changes. Any class which implements IChangeSource can be
# put here: there are several in buildbot/changes/*.py to choose from.

from buildbot.changes.pb import PBChangeSource
c['change_source'] = PBChangeSource(prefix=python/, 
revlinktmpl=http://svn.python.org/view?rev=%sview=rev;)


# the 'builders' list defines the Builders. Each one is configured with a
# dictionary, using the following keys:
#  name (required): the name used to describe this builder
#  slavename (required): which slave to use, must appear in c['bots']
#  builddir (required): which subdirectory to run the builder in
#  factory (required): a BuildFactory to define how the build is run
#  periodicBuildTime (optional): if set, force a build every N seconds

# We use one scheduler per branch (as the AnyBranchScheduler is useless)
# and one builder per slave and branch

class Clean(ShellCommand):
name = clean
warnOnFailure = 1
description = [cleaning]
descriptionDone = [clean]
command = [make, distclean]
alwaysRun = True

class Kill(ShellCommand):
name = kill.python
warnOnFailure = 1
descripting = [killing python]
descriptionDone = [kill.python]
command = [make, -C, Tools/buildbot]

class MSIUpload(FileUpload):
def __init__(self, build, branch, **buildstep_kwargs):
# determine MSI filename later
FileUpload.__init__(self, build, 'UNSET', 'UNSET', **buildstep_kwargs)
self.branch = branch

def start(self):
# filename matches msi.py
current_version = %s.%s % (self.branch, int(time.time()/3600/24))
self.slavesrc = 'Tools/msi/python-%s.msi' % (current_version)
self.masterdest = 
'/data/ftp.python.org/pub/www.python.org/dev/daily-msi/python-%s.msi' % 
current_version
return FileUpload.start(self)

class UnixBuild(factory.GNUAutoconf):
configureFlags = [--with-pydebug, --with-computed-gotos]
def __init__(self, source, parallel):
compile = ['make', 'all']
test = [make, buildbottest]
if parallel:
compile = ['make', parallel, 'all']
test = [make, buildbottest, TESTOPTS=+parallel]
factory.GNUAutoconf.__init__(self, source,
 configureFlags = self.configureFlags,
 compile=compile,
 test = None)
# XXX(nnorwitz): reduced timeout, no test should take longer than 10m
# XXX(anthony): computer says no. upped to 30m
self.steps.append(s(Test, command=test,
timeout=30*60))
self.steps.append(s(Clean))

class WideUnixBuild(UnixBuild):
configureFlags = [--with-pydebug, --with-computed-gotos, 
--with-wide-unicode]

class CygwinBuild(UnixBuild):
def __init__(self, source, parallel):
UnixBuild.__init__(self, source)
self.steps.insert(1, s(Kill))
# XXX(nnorwitz): test_bsddb3 crashes the interpreter on cygwin.
# Ignore test_bsddb3 to see if we can get some real results.
test_step = self.steps[-2][1]
test_step['env'] = {'EXTRATESTOPTS': '-uall -rw -x test_bsddb3 
test_logging'}

class WindowsBuild(factory.BuildFactory):
def __init__(self, source, parallel):
factory.BuildFactory.__init__(self, [
source,
s(Compile, command=[r'Tools\buildbot\build.bat']),
s(Test, command=[r'Tools\buildbot\test.bat']),
s(Clean, command=[r'Tools\buildbot\clean.bat']),
])

class 

Re: [Python-Dev] Python 2.7 Won't Build

[Antoine Pitrou]

On Mon, 20 Sep 2010 09:31:45 -0500
Tom Browder tom.brow...@gmail.com wrote:
 
 Can anyone explain the two different default installations I got?
 
 It seems to me I should force the Ubuntu-style installation by  the
 --with-universal-archs=64-bit configure option, and I will try that
 on Debian while I await expert help.

I think universal arch builds only apply under OS X where they
produce fat binaries.

Under 64-bit Linux, you can compile either a 64-bit executable (the
default) or a 32-bit executable (by specifying e.g. CC=gcc -m32 to
the configure script).


However, the /usr/local/lib{,64}/python2.7 issue is a bit different,
since those directories can host architecture independent files
(such as .py and .pyc files). For example, on my Mandriva
install, the 64-bit Python executable can import packages from
both /usr/lib/python2.6/site-packages/
and /usr/lib64/python2.6/site-packages/.

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] Python 2.7 Won't Build

[Tom Browder]

On Mon, Sep 20, 2010 at 14:28, Antoine Pitrou solip...@pitrou.net wrote:
 On Mon, 20 Sep 2010 09:31:45 -0500
 Tom Browder tom.brow...@gmail.com wrote:

 Can anyone explain the two different default installations I got?

 It seems to me I should force the Ubuntu-style installation by  the
 --with-universal-archs=64-bit configure option, and I will try that
 on Debian while I await expert help.

 I think universal arch builds only apply under OS X where they
 produce fat binaries.

 Under 64-bit Linux, you can compile either a 64-bit executable (the
 default) or a 32-bit executable (by specifying e.g. CC=gcc -m32 to
 the configure script).


 However, the /usr/local/lib{,64}/python2.7 issue is a bit different,
 since those directories can host architecture independent files
 (such as .py and .pyc files). For example, on my Mandriva
 install, the 64-bit Python executable can import packages from
 both /usr/lib/python2.6/site-packages/
 and /usr/lib64/python2.6/site-packages/.

Thanks, Antoine.

And I think I just found the problem with the installation (it may be
worth a note):  I had  a special configuration file
(/usr/local/share/config.site) for autoconf to force the primary local
libraries to be installed in /usr/local/lib64 (left over from early
64-bit days of this old system).  Removing that file, removing the
/usr/local/lib64/python2.7 directory, and rebuilding and reinstalling
seems to have solved the immediate problem.

Moral of the story: watch out for old cruft in /usr/local when
installing a new distribution.

I apologize for the noise.

However, I'm still investigating the original build problem (gcc trunk
and corrupted byte compile), but it may be related--I'll see.

Regards,

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA
___
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: Builder: x86 Windows7 3.x OpenSSL compile error

[David Bolen]

Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp writes:

 Hello. I've sent following mail to buildbot manager,
 but I found that buildbot page saids the problem of unsable
 bot should be sent to python-...@python.org. So I'll do it.

(I'm fine with direct email for any of my build slaves, and it's
probably the quickest way to get me to pay attention, but this issue
has been around a bit and likely also of general interest)

Nice catch on this - the Win7 3.x branch has failed to build OpenSSL
for a bit now and I hadn't figured out why.  Flushing out the OpenSSL
tree hadn't fixed it, and it was weird that it didn't happen on XP,
nor did the pre-1.0 OpenSSL releases have a problem on Win7.  So I was
thinking it might just be an issue with OpenSSL.  I hadn't even
thought of the possibility of it being the assembler.

I've bumped the slave up to the latest nasm (2.09.02) and restarted
the most recent build and it's gotten past the OpenSSL stage, so it
looks like 2.06 may be the specific bad version.  I guess I just
happened to construct this builder in the relative small interval when
2.06 was current.

Thanks again for figuring this out.

-- David

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

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Nick Coghlan]

On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough chr...@plope.com wrote:
 Existing APIs save for quote don't really need to deal with charset
 encodings at all, at least on any level that Python needs to care about.
 The potential already exists to emit garbage which will turn into
 mojibake from almost all existing APIs.  The only remaining issue seems
 to be fear of making a design mistake while designing APIs.

 IMO, having a separate module for all urllib.parse APIs, each designed
 for only bytes input is a design mistake greater than any mistake that
 could be made by allowing for both bytes and str input to existing APIs
 and returning whatever type was passed.  The existence of such a module
 will make it more difficult to maintain a codebase which straddles
 Python 2 and Python 3.

Failure to use quote/unquote correctly is a completely different
problem from using bytes with an ASCII incompatible encoding, or
mixing bytes with different encodings. Yes, if you don't quote your
URLs you may end up with mojibake. That's not a justification for
creating a *new* way to accidentally create mojibake.

Separating the APIs means that application programmers will be
expected to know whether they are working with data formatted for
display to the user (i.e. Unicode text) or transfer over the wire
(i.e. ASCII compatible bytes).

Can you give me a concrete use case where the application programmer
won't *know* which format they're working with? Py3k made the
conscious decision to stop allowing careless mixing of encoded and
unencoded text. This is just taking that philosophy and propagating it
further up the API stack (as has already been done with several OS
facing APIs for 3.2).

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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Chris McDonough]

On Tue, 2010-09-21 at 07:12 +1000, Nick Coghlan wrote:
 On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough chr...@plope.com wrote:
  Existing APIs save for quote don't really need to deal with charset
  encodings at all, at least on any level that Python needs to care about.
  The potential already exists to emit garbage which will turn into
  mojibake from almost all existing APIs.  The only remaining issue seems
  to be fear of making a design mistake while designing APIs.
 
  IMO, having a separate module for all urllib.parse APIs, each designed
  for only bytes input is a design mistake greater than any mistake that
  could be made by allowing for both bytes and str input to existing APIs
  and returning whatever type was passed.  The existence of such a module
  will make it more difficult to maintain a codebase which straddles
  Python 2 and Python 3.
 
 Failure to use quote/unquote correctly is a completely different
 problem from using bytes with an ASCII incompatible encoding, or
 mixing bytes with different encodings. Yes, if you don't quote your
 URLs you may end up with mojibake. That's not a justification for
 creating a *new* way to accidentally create mojibake.

There's no new way to accidentally create new mojibake here by allowing
bytes input, as far as I can tell.

- If a user passes something that has character data outside the range
  0-127 to an API that expects a URL or a component (in the
  definition that urllib.parse.urlparse uses for component) of a URI,
  he can keep both pieces when it breaks.  Whether that data is
  represented via bytes or text is not relevant.  He provided 
  bad input, he is going to lose one way or another.

- If a user passes a bytestring to ``quote``, because ``quote`` is
  implemented in terms of ``quote_to_bytes`` the case is *already*
  handled by quote_to_bytes implicitly failing to convert nonascii
  characters.

What are the cases you believe will cause new mojibake? 

 Separating the APIs means that application programmers will be
 expected to know whether they are working with data formatted for
 display to the user (i.e. Unicode text) or transfer over the wire
 (i.e. ASCII compatible bytes).
 
 Can you give me a concrete use case where the application programmer
 won't *know* which format they're working with? Py3k made the
 conscious decision to stop allowing careless mixing of encoded and
 unencoded text. This is just taking that philosophy and propagating it
 further up the API stack (as has already been done with several OS
 facing APIs for 3.2).

Yes.  Code which must explicitly deal with bytes input and output meant
to straddle both Python 2 and Python 3.  Please try to write some code
which 1) uses the same codebase to straddle Python 2.6 and Python 3.2
and 2) which uses bytes input, and expects bytes output from, say,
urlsplit.  It becomes complex very quickly.  A proposal to create yet
another bytes-only API only makes it more complex, AFAICT.

- C


___
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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Chris McDonough]

On Tue, 2010-09-21 at 08:19 +1000, Nick Coghlan wrote:
 On Tue, Sep 21, 2010 at 7:39 AM, Chris McDonough chr...@plope.com wrote:
  On Tue, 2010-09-21 at 07:12 +1000, Nick Coghlan wrote:
  On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough chr...@plope.com wrote:
   Existing APIs save for quote don't really need to deal with charset
   encodings at all, at least on any level that Python needs to care about.
   The potential already exists to emit garbage which will turn into
   mojibake from almost all existing APIs.  The only remaining issue seems
   to be fear of making a design mistake while designing APIs.
  
   IMO, having a separate module for all urllib.parse APIs, each designed
   for only bytes input is a design mistake greater than any mistake that
   could be made by allowing for both bytes and str input to existing APIs
   and returning whatever type was passed.  The existence of such a module
   will make it more difficult to maintain a codebase which straddles
   Python 2 and Python 3.
 
  Failure to use quote/unquote correctly is a completely different
  problem from using bytes with an ASCII incompatible encoding, or
  mixing bytes with different encodings. Yes, if you don't quote your
  URLs you may end up with mojibake. That's not a justification for
  creating a *new* way to accidentally create mojibake.
 
  There's no new way to accidentally create new mojibake here by allowing
  bytes input, as far as I can tell.
 
  - If a user passes something that has character data outside the range
   0-127 to an API that expects a URL or a component (in the
   definition that urllib.parse.urlparse uses for component) of a URI,
   he can keep both pieces when it breaks.  Whether that data is
   represented via bytes or text is not relevant.  He provided
   bad input, he is going to lose one way or another.
 
  - If a user passes a bytestring to ``quote``, because ``quote`` is
   implemented in terms of ``quote_to_bytes`` the case is *already*
   handled by quote_to_bytes implicitly failing to convert nonascii
   characters.
 
  What are the cases you believe will cause new mojibake?
 
 Calling operations like urlsplit on byte sequences in non-ASCII
 compatible encodings and operations like urljoin on byte sequences
 that are encoded with different encodings. These errors differ from
 the URL escaping errors you cite, since they can produce true mojibake
 (i.e. a byte sequence without a single consistent encoding), rather
 than merely non-compliant URLs. However, if someone has let their
 encodings get that badly out of whack in URL manipulation they're
 probably doomed anyway...

Right, the bytes issue here is really a red herring in both the urlsplit
and urljoin cases, I think.

 It's certainly possible I hadn't given enough weight to the practical
 issues associated with migration of existing code from 2.x to 3.x
 (particularly with the precedent of some degree of polymorphism being
 set back when Issue 3300 was dealt with).
 
 Given that a separate API still places the onus on the developer to
 manage their encodings correctly, I'm beginning to lean back towards
 the idea of a polymorphic API rather than separate functions. (the
 quote/unquote legacy becomes somewhat unfortunate in that situation,
 as they always returns str objects rather than allowing the type of
 the result to be determined by the type of the argument. Something
 like quotep/unquotep may prove necessary in order to work around that
 situation and provide a bytes-bytes, str-str API)

Yay, sounds much, much better!

- C


___
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] Builder: x86 Windows7 3.x OpenSSL compile error

[Antoine Pitrou]

Hello David,

On Mon, 20 Sep 2010 16:42:10 -0400
David Bolen db3l@gmail.com wrote:
 Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp writes:
 
  Hello. I've sent following mail to buildbot manager,
  but I found that buildbot page saids the problem of unsable
  bot should be sent to python-...@python.org. So I'll do it.
 
 (I'm fine with direct email for any of my build slaves, and it's
 probably the quickest way to get me to pay attention, but this issue
 has been around a bit and likely also of general interest)
 
 Nice catch on this - the Win7 3.x branch has failed to build OpenSSL
 for a bit now and I hadn't figured out why. [...]

There's a remaining problem on the Win7 3.x buildslave.
test_ssl currently fails with the following problem:

Re-running test 'test_ssl' in verbose mode
test_ssl: testing with 'OpenSSL 1.0.0a 1 Jun 2010' (1, 0, 0, 1, 15)
  under Windows ('7', '6.1.7600', '', 'Multiprocessor Free')
test test_ssl failed -- Can't read certificate file
b'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\lib\\test\\keycert.pem'

But the aforementioned certificate file is in the SVN tree and other
buildslaves have no problem reading it. Can you try to check if there's
something wrong on your buildslave?

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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Nick Coghlan]

On Tue, Sep 21, 2010 at 7:39 AM, Chris McDonough chr...@plope.com wrote:
 On Tue, 2010-09-21 at 07:12 +1000, Nick Coghlan wrote:
 On Tue, Sep 21, 2010 at 4:30 AM, Chris McDonough chr...@plope.com wrote:
  Existing APIs save for quote don't really need to deal with charset
  encodings at all, at least on any level that Python needs to care about.
  The potential already exists to emit garbage which will turn into
  mojibake from almost all existing APIs.  The only remaining issue seems
  to be fear of making a design mistake while designing APIs.
 
  IMO, having a separate module for all urllib.parse APIs, each designed
  for only bytes input is a design mistake greater than any mistake that
  could be made by allowing for both bytes and str input to existing APIs
  and returning whatever type was passed.  The existence of such a module
  will make it more difficult to maintain a codebase which straddles
  Python 2 and Python 3.

 Failure to use quote/unquote correctly is a completely different
 problem from using bytes with an ASCII incompatible encoding, or
 mixing bytes with different encodings. Yes, if you don't quote your
 URLs you may end up with mojibake. That's not a justification for
 creating a *new* way to accidentally create mojibake.

 There's no new way to accidentally create new mojibake here by allowing
 bytes input, as far as I can tell.

 - If a user passes something that has character data outside the range
  0-127 to an API that expects a URL or a component (in the
  definition that urllib.parse.urlparse uses for component) of a URI,
  he can keep both pieces when it breaks.  Whether that data is
  represented via bytes or text is not relevant.  He provided
  bad input, he is going to lose one way or another.

 - If a user passes a bytestring to ``quote``, because ``quote`` is
  implemented in terms of ``quote_to_bytes`` the case is *already*
  handled by quote_to_bytes implicitly failing to convert nonascii
  characters.

 What are the cases you believe will cause new mojibake?

Calling operations like urlsplit on byte sequences in non-ASCII
compatible encodings and operations like urljoin on byte sequences
that are encoded with different encodings. These errors differ from
the URL escaping errors you cite, since they can produce true mojibake
(i.e. a byte sequence without a single consistent encoding), rather
than merely non-compliant URLs. However, if someone has let their
encodings get that badly out of whack in URL manipulation they're
probably doomed anyway...

It's certainly possible I hadn't given enough weight to the practical
issues associated with migration of existing code from 2.x to 3.x
(particularly with the precedent of some degree of polymorphism being
set back when Issue 3300 was dealt with).

Given that a separate API still places the onus on the developer to
manage their encodings correctly, I'm beginning to lean back towards
the idea of a polymorphic API rather than separate functions. (the
quote/unquote legacy becomes somewhat unfortunate in that situation,
as they always returns str objects rather than allowing the type of
the result to be determined by the type of the argument. Something
like quotep/unquotep may prove necessary in order to work around that
situation and provide a bytes-bytes, str-str API)

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] Builder: x86 Windows7 3.x OpenSSL compile error

[David Bolen]

Antoine Pitrou solip...@pitrou.net writes:

 (...)

 test test_ssl failed -- Can't read certificate file
 b'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\lib\\test\\keycert.pem'

 But the aforementioned certificate file is in the SVN tree and other
 buildslaves have no problem reading it. Can you try to check if there's
 something wrong on your buildslave?

I suspect it's an actual Python bug, though perhaps Win7-specific.

The file is in fact in the tree, and I can read it just fine from the
command line.  If I'm reading the test right, and regardless of the
actual error message, it's really failing an existence test
(os.path.exists) rather than any failure to open or read the file.

Looks like some issue with using bytes for os.path.exists - I
borrowed a Python 3.x build currently in the tree as part of build
1611 and tried:

d...@buildbot-win7 ~
$ buildarea/3.x.bolen-windows7/build/pcbuild/python_d
Python 3.2a2+ (py3k, Sep 20 2010, 18:49:03) [MSC v.1500 32 bit (Intel)] on win32

Type help, copyright, credits or license for more information.
 import os
[50683 refs]
 os.path.exists('d:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\lib\\test\\keycert.pem')
True
[50689 refs]
 os.path.exists(b'd:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\buil
d\\lib\\test\\keycert.pem')
False
[50718 refs]

So the bug appears to be why those two calls return a different result.

-- David

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

Re: [Python-Dev] Builder: x86 Windows7 3.x OpenSSL compile error

[Antoine Pitrou]

On Mon, 20 Sep 2010 19:02:33 -0400
David Bolen db3l@gmail.com wrote:
 
 Looks like some issue with using bytes for os.path.exists - I
 borrowed a Python 3.x build currently in the tree as part of build
 1611 and tried:
 
 d...@buildbot-win7 ~
 $ buildarea/3.x.bolen-windows7/build/pcbuild/python_d
 Python 3.2a2+ (py3k, Sep 20 2010, 18:49:03) [MSC v.1500 32 bit (Intel)] on 
 win32
 
 Type help, copyright, credits or license for more information.
  import os
 [50683 refs]
  os.path.exists('d:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\lib\\test\\keycert.pem')
 True
 [50689 refs]
  os.path.exists(b'd:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\buil
 d\\lib\\test\\keycert.pem')
 False
 [50718 refs]

Ah, indeed. I can confirm the above issue on a Windows 7 VM as well.
I'm gonna try to investigate.

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] [Python-checkins] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst

[Éric Araujo]

Hello

+   NOTE: If you are thinking of defining your own levels, please see
the section
+   on :ref:`custom-levels`.

I think those instances of upper-case-as-markup should either be real
reST note/warning/etc. directives or plain English (that is, integrating
“NOTE:” into the text flow, for example “Note that...”/“Pay attention
to...”).

Regards

___
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] Builder: x86 Windows7 3.x OpenSSL compile error

[Antoine Pitrou]

On Mon, 20 Sep 2010 19:02:33 -0400
David Bolen db3l@gmail.com wrote:
 
 d...@buildbot-win7 ~
 $ buildarea/3.x.bolen-windows7/build/pcbuild/python_d
 Python 3.2a2+ (py3k, Sep 20 2010, 18:49:03) [MSC v.1500 32 bit (Intel)] on 
 win32
 
 Type help, copyright, credits or license for more information.
  import os
 [50683 refs]
  os.path.exists('d:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\lib\\test\\keycert.pem')
 True
 [50689 refs]
  os.path.exists(b'd:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\buil
 d\\lib\\test\\keycert.pem')
 False
 [50718 refs]
 
 So the bug appears to be why those two calls return a different result.

Ok, see http://bugs.python.org/issue9908 for the bug report and a patch.

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] [Python-checkins] r84871 + committing distutils fixes

[Éric Araujo]

+@unittest.skipIf(sys.platform.startswith('win'),
+This test is only appropriate for POSIX-like
systems.)

Is win32 the only non-POSIX supported platform now that OS 9 support is
gone?  I find those values in the docs for sys.platform: win32, cygwin,
darwin, os2, os2emx.  Is OS/2 a POSIX system?  Isn’t it more robust not
to ask this question and just use unittest.skipUnless(os.name ==
'posix', msg)?

On a related note, I’m very grateful that other developers take time to
reply to bugs and commit simple fixes that don’t require knowledge of
distutils dark corners.  Recent changes have tended to turn buildbots
red though, so I’d like to respectfully ask/remind you to make sure to
run tests before committing in each branch (3.2, 3.1, 2.7), if possible
on POSIX and Windows.  (Those are Tarek’s rules, not mine; I hope don’t
sound bossy or ungrateful for your help.)  I apologize in advance if you
did run the test and the buildbots just revealed an unforeseen
platform-specific quirk; I’m not accusing anyone of anything—I have my
share of embarrassing commits, so be sure I’m not judging here, I just
want to improve the process. :)

It would also be very helpful to always add the Distutils2 component so
that synchronizing the fixes is not overlooked.  (Maybe I should add a
tracker admin to automate that.)

mport-unittest-ly yours

___
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-checkins] r84906 - python/branches/py3k/Doc/library/ssl.rst

[Éric Araujo]

 Log:
 Remove references to read() and write() methods, which are useless
 synonyms of recv() and send()

Unless I’m mistaken, ssl.SSLSocket.write is still useful for use with
print, pprint and maybe other functions, so I think the method should be
listed somewhere.

Regards

___
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