Re: [Python-Dev] cpython: Remove mention of medical condition from the test suite.

[Georg Brandl]

Am 06.07.2011 08:51, schrieb Stefan Behnel:
> Georg Brandl, 06.07.2011 07:35:
>> Well, it was stated that even non-joking use of such words can offend
>> (the example given was "your argument is blind to (these facts)").
>> I consider use in jokes to be more serious, since it's careless use.
>> Sorry if I overreacted here.
> 
> There's a common saying that a disabled person can't be considered "normal" 
> unless he/she can also be called an asshole from time to time.
> 
> Personally, I do not consider the pun in question harmful, simply because 
> it's so clearly just a play on words that doesn't make much sense, apart 
> from having a double meaning.
> 
> In general, however, I think it's important to make jokes with and about 
> disabled people. That keeps them inside of our society, just like anyone 
> else. Treating them as "untouchable" means to single them out.

I don't think we need to rehash this here (not meaning to pick on you, Stefan);
those who are interested can sign up to the diversity list and read/post to
the original thread here:

http://mail.python.org/mailman/private/diversity/2011-July/002509.html

Georg

___
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] cpython: Remove mention of medical condition from the test suite.

[Stefan Behnel]

Georg Brandl, 06.07.2011 09:08:

Am 06.07.2011 08:51, schrieb Stefan Behnel:

Georg Brandl, 06.07.2011 07:35:

Well, it was stated that even non-joking use of such words can offend
(the example given was "your argument is blind to (these facts)").
I consider use in jokes to be more serious, since it's careless use.
Sorry if I overreacted here.


There's a common saying that a disabled person can't be considered "normal"
unless he/she can also be called an asshole from time to time.

Personally, I do not consider the pun in question harmful, simply because
it's so clearly just a play on words that doesn't make much sense, apart
from having a double meaning.

In general, however, I think it's important to make jokes with and about
disabled people. That keeps them inside of our society, just like anyone
else. Treating them as "untouchable" means to single them out.


I don't think we need to rehash this here (not meaning to pick on you, Stefan);


Agreed.



those who are interested can sign up to the diversity list and read/post to
the original thread here:

http://mail.python.org/mailman/private/diversity/2011-July/002509.html


Speaking of "singling out", I've been wondering more than once why that 
list has a private archive ...


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] cpython: Remove mention of medical condition from the test suite.

[Antoine Pitrou]

On Wed, 06 Jul 2011 09:13:58 +0200
Stefan Behnel  wrote:
> 
> > those who are interested can sign up to the diversity list and read/post to
> > the original thread here:
> >
> > http://mail.python.org/mailman/private/diversity/2011-July/002509.html
> 
> Speaking of "singling out", I've been wondering more than once why that 
> list has a private archive ...

I suspect the explanation is itself given somewhere in a message inside
the private archive ;)

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] Python Launcher for Windows (PEP 397) needs testing!

[Vinay Sajip]

The C implementation of the PEP 397-compatible Python Launcher for Windows has
come along nicely in the last few days, and now reached a point where it would
benefit from some testing by interested python-dev members. Points of note:

1. As well as source available on

https://bitbucket.org/vinay.sajip/pylauncher

there are built 32- and 64-bit msi files at

https://bitbucket.org/vinay.sajip/pylauncher/downloads

Please remember that this is beta software. While it appears stable, I've
tested in virtual machines (WinXP 32-bit, Win7 32-bit and 64-bit) which I can
readily restore from backup. There are also msm files which could be used to
e.g. integrate with the Python msi files, if approved, at some later date.

2. On installation, any existing associations are saved, and restored when the
launcher is uninstalled (this is done automatically by Windows Installer).

3. On uninstallation, if there are Pythons installed and no associations, a
dialog pops up listing all the installed Pythons and offering the user the
chance to associate one of the Pythons with the Python extensions. The user
can choose to associate or not, but once they choose an association, then that
association will always be there unless the launcher is reinstalled (in which
case it takes over the association while it's still installed, and restores
the previous one when it's uninstalled).

4. I've tried to cover all of the points in the PEP. There is a test suite -
while this appears to be small (7 tests) the individual shebangs are all
tested, as are the customisable commands etc. However, I'm sure some of you
will break it ;-)

5. I used WiX to build the msm/msi files, but that's only because of increased
familiarity over msilib. The build procedure could switch over to msilib at
some later date. All the other code is just plain C and Win32 APIs (gosh -
takes me back! Window procedures, anyone?). The code builds with Visual Studio
and also Visual Studio Express (C++ edition).

Regards,

Vinay Sajip

___
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 3101 implementation vs. documentation

[Ben Wolfson]

FWIW, new patches have been attached to the bug report
(http://bugs.python.org/issue12014), one of which is intended to bring
behavior in line with the documentation, and the other of which is
intended to implement Greg Ewing's proposal to allow only identifiers
(or integers) in the arg_name, attribute_name, and element_index
sections.

On Fri, Jun 10, 2011 at 2:15 PM, Ben Wolfson  wrote:
> Hello,
>
> I'm writing because discussion in a bug report I submitted
> () has suggested that, insofar as
> at least part of the issue revolves around the interpretation of PEP
> 3101, that aspect belonged on python-dev. In particular, I was told
> that the PEP, not the documentation, is authoritative. Since I'm the
> one who thinks something is wrong, it seems appropriate for me to be
> the one to bring it up.
>
> Basically, the issue is that the current behavior of str.format is at
> variance at least with the documentation
> , is almost
> certainly at variance with PEP3101 in one respect, and is in my
> opinion at variance with PEP3101 in another respect as well, regarding
> what characters can be present in what the grammar given in the
> documentation calls an element_index, that is, the bit between the
> square brackets in "{0.attr[idx]}".
>
> Both discovering the current behavior and interpreting the
> documentation are pretty straightforward; interpreting what the PEP
> actually calls for is more vexed. I'll do the first two things first.
> TOC for the remainder:
>
> 1. What does the current implementation do?
> 2. What does the documentation say?
> 3. What does the PEP say? [this part is long, but the PEP is not
> clear, and I wanted to be thorough]
> 4. Who cares?
>
> 1. What does the current implementation do?
>
> Suppose you have this dictionary:
>
> d = {"@": 0,
>     "!": 1,
>     ":": 2,
>     "^": 3,
>     "}": 4,
>     "{": {"}": 5},
>    }
>
> Then the following expressions have the following results:
>
> (a) "{0[@]}".format(d)    --> '0'
> (b) "{0[!]}".format(d)    --> ValueError: Missing ']' in format string
> (c) "{0[:]}".format(d)    --> ValueError: Missing ']' in format string
> (d) "{0[^]}".format(d)    --> '3'
> (e) "{0[}]}".format(d)    --> ValueError: Missing ']' in format string
> (f) "{0[{]}".format(d)    --> ValueError: unmatched '{' in format
> (g) "{0[{][}]}".format(d) --> '5'
>
> Given (e) and (f), I think (g) should be a little surprising, though
> you can probably guess what's going on and it's not hard to see why it
> happens if you look at the source: (e) and (f) fail because
> MarkupIterator_next (in Objects/stringlib/string_format.h) scans
> through the string looking for curly braces, because it treats them as
> semantically significant no matter what context they occur in. So,
> according to MarkupIterator_next, the *first* right curly brace in (e)
> indicates the end of the replacement field, giving "{0[}". In (f), the
> second left curly brace indicates (to MarkupIterator_next) the start
> of a *new* replacement field, and since there's only one right curly
> brace, it complains. In (g), MarkupIterator_next treats the second
> left curly brace as starting a new replacement field and the first
> right curly brace as closing it. However, actually, those braces don't
> define new replacement fields, as indicated by the fact that the whole
> expression treats the element_index fields as just plain old strings.
> (So the current implementation is somewhat schizophrenic, acting at
> one point as if the braces have to be balanced because '{[]}' is a
> replacement field and at another point treating the braces as
> insignificant.)
>
> The explanation for (b) and (c) is that parse_field (same source file)
> treats ':' and '!'  as indicating the end of the field_name section of
> the replacement field, regardless of whether those characters occur
> within square brackets or not.
>
> So, that's what the current implementation does, in those cases.
>
> 2. What does the documentation say?
>
> The documentation gives a grammar for replacement fields:
>
> """
> replacement_field ::=  "{" [field_name] ["!" conversion] [":" format_spec] "}"
> field_name        ::=  arg_name ("." attribute_name | "[" element_index "]")*
> arg_name          ::=  [identifier | integer]
> attribute_name    ::=  identifier
> element_index     ::=  integer | index_string
> index_string      ::=   +
> conversion        ::=  "r" | "s"
> format_spec       ::=  
> """
>
> Given this definition of index_string, all of (a)--(g) should be
> legal, and the results should be the strings '0', '1', '2', '3',
> "{'}': 5}", and '5'. There is no need to exclude ':', '!', '}', or '{'
> from the index_string field; allowing them creates no ambiguity,
> because the field is delimited by square brackets.
>
> Tangent: the definition of attribute_name here also does not describe
> the current behavior ("{0.  ;}".format(x) works fine and will cal

[Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

[Victor Stinner]

Hi,

Last may, I proposed to deprecate open() function, StreamWriter and
StreamReader classes of the codecs module. I accepted to keep open()
after the discussion on python-dev. Here is a more complete proposition
as a PEP. It is a draft and I expect a lot of comments :)

Victor

---

PEP: xxx
Title: Deprecate codecs.StreamReader and codecs.StreamWriter
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-May-2011
Python-Version: 3.3


Abstract


io.TextIOWrapper and codecs.StreamReaderWriter offer the same API
[#f1]_. TextIOWrapper has more features and is faster than
StreamReaderWriter. Duplicate code means that bugs should be fixed
twice and that we may have subtle differences between the two
implementations.

The codecs modules was introduced in Python 2.0, see the PEP 100. The
io module was introduced in Python 2.6 and 3.0 (see the PEP 3116), and
reimplemented in C in Python 2.7 and 3.1.


Motivation
==

When the Python I/O model was updated for 3.0, the concept of a
"stream-with-known-encoding" was introduced in the form of
io.TextIOWrapper. As this class is critical to the performance of
text-based I/O in Python 3, this module has an optimised C version
which is used by CPython by default. Many corner cases in handling
buffering, stateful codecs and universal newlines have been dealt with
since the release of Python 3.0.

This new interface overlaps heavily with the legacy
codecs.StreamReader, codecs.StreamWriter and codecs.StreamReaderWriter
interfaces that were part of the original codec interface design in
PEP 100. These interfaces are organised around the principle of an
encoding with an associated stream (i.e. the reverse of arrangement in
the io module), so the original PEP 100 design required that codec
writers provide appropriate StreamReader and StreamWriter
implementations in addition to the core codec encode() and decode()
methods. This places a heavy burden on codec authors providing these
specialised implementations to correctly handle many of the corner
cases that have now been dealt with by io.TextIOWrapper. While deeper
integration between the codec and the stream allows for additional
optimisations in theory, these optimisations have in practice either
not been carried out and else the associated code duplication means
that the corner cases that have been fixed in io.TextIOWrapper are
still not handled correctly in the various StreamReader and
StreamWriter implementations.

Accordingly, this PEP proposes that:

* codecs.open() be updated to delegate to the builtin open() in Python
  3.3;
* the legacy codecs.Stream* interfaces, including the streamreader and
  streamwriter attributes of codecs.CodecInfo be deprecated in Python
  3.3 and removed in Python 3.4.


Rationale
=

StreamReader and StreamWriter issues


 * StreamReader is unable to translate newlines.
 * StreamReaderWriter handles reads using StreamReader and writes
   using StreamWriter. These two classes may be inconsistent. To stay
   consistent, flush() must be called after each write which slows
   down interlaced read-write.
 * StreamWriter doesn't support "line buffering" (flush if the input
   text contains a newline).
 * StreamReader classes of the CJK encodings (e.g. GB18030) don't
   support universal newlines, only UNIX newlines ('\\n').
 * StreamReader and StreamWriter are stateful codecs but don't expose
   functions to control their state (getstate() or setstate()). Each
   codec has to implement corner cases, see "Issue with stateful
   codecs".
 * StreamReader and StreamWriter are very similar to IncrementalReader
   and IncrementalEncoder, some code is duplicated for stateful codecs
   (e.g. UTF-16).
 * Each codec has to reimplement its own StreamReader and StreamWriter
   class, even if it's trivial (just call the encoder/decoder).
 * codecs.open(filename, "r") creates a io.TextIOWrapper object.
 * No codec implements an optimized method in StreamReader or
   StreamWriter based on the specificities of the codec.


TextIOWrapper features
''

 * TextIOWrapper supports any kind of newline, including translating
   newlines (to UNIX newlines), to read and write.
 * TextIOWrapper reuses incremental encoders and decoders (no
   duplication of code).
 * The io module (TextIOWrapper) is faster than the codecs module
   (StreamReader). It is implemented in C, whereas codecs is
   implemented in Python.
 * TextIOWrapper has a readahead algorithm which speeds up small
   reads: read character by character or line by line (io is 10x
   through 25x faster than codecs on these operations).
 * TextIOWrapper has a write buffer.
 * TextIOWrapper.tell() is optimized.
 * TextIOWrapper supports random access (read+write) using a single
   class which permit to optimize interlaced read-write (but no such
   optimization is implemented).


Possib

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

[Benjamin Peterson]

2011/7/6 Victor Stinner :
> codecs.open() will be changed to reuse the builtin open() function
> (TextIOWrapper).

This doesn't strike me as particularly backwards compatible, since
you've just enumerated the differences between StreamWriter/Reader and
TextIOWrapper.



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

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

[Nick Coghlan]

On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson  wrote:
> 2011/7/6 Victor Stinner :
>> codecs.open() will be changed to reuse the builtin open() function
>> (TextIOWrapper).
>
> This doesn't strike me as particularly backwards compatible, since
> you've just enumerated the differences between StreamWriter/Reader and
> TextIOWrapper.

The API of the resulting object is the same (i.e. they're file-like
objects). The behavioural differences are due to cases where the
codec-specific classes are currently broken.

Victor, could you please check this into the PEPs repo? It's easier to
reference once it has a real number.

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] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

[Benjamin Peterson]

2011/7/6 Nick Coghlan :
> On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson  
> wrote:
>> 2011/7/6 Victor Stinner :
>>> codecs.open() will be changed to reuse the builtin open() function
>>> (TextIOWrapper).
>>
>> This doesn't strike me as particularly backwards compatible, since
>> you've just enumerated the differences between StreamWriter/Reader and
>> TextIOWrapper.
>
> The API of the resulting object is the same (i.e. they're file-like
> objects). The behavioural differences are due to cases where the
> codec-specific classes are currently broken.

Yes, but as we all know too well, people are surely relying on
whatever behavior there is, broken or not.



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

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

[Vinay Sajip]

Benjamin Peterson  python.org> writes:

> 
> 2011/7/6 Nick Coghlan  gmail.com>:

> > The API of the resulting object is the same (i.e. they're file-like
> > objects). The behavioural differences are due to cases where the
> > codec-specific classes are currently broken.
> 
> Yes, but as we all know too well, people are surely relying on
> whatever behavior there is, broken or not.
> 

There's also the fact that code which currently runs under 2.x and 3.x would
stop working if codecs.StreamReader/StreamWriter were to go away. Of course, if
the codecs interfaces were re-implemented using io module code, the only
portability issues would be because of people relying on broken aspects of the
existing codecs code - which is unlikely to be all (or even most) of the people
using codecs.StreamReader/StreamWriter.

Regards,

Vinay Sajip

___
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