[Python-Dev] Very old git mirror under github user "python-git"

[John Mark Vandenberg]

Does anyone know who controls this mirror, which is attracting pull requests?

https://github.com/python-git/python/pulls

Can it be pulled down to avoid confusion, since it is using Python's logo?

https://github.com/python-git

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Paul Moore]

On 9 February 2016 at 01:57, Chris Barker - NOAA Federal
 wrote:OTOH, it's a
> All I can say is "ouch". Hard to call it a regression to no longer
> allow this mess..

OTOH, it's a major regression for someone using an 8-bit codepage that
doesn't have these problems. Code that worked fine for them now
doesn't.

I dislike "works for some people" solutions as much as anyone, but
breaking code that does the job that people need it to is not
something we should do lightly (if at all).

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Victor Stinner]

2016-02-09 1:37 GMT+01:00 eryk sun :
> For example, in codepage 932 (Japanese), it's an error if a lead byte
> (i.e. 0x81-0x9F, 0xE0-0xFC) is followed by a trailing byte with a
> value less than 0x40 (note that ASCII 0-9 is 0x30-0x39, so this is not
> uncommon). In this case the ANSI API substitutes the default character
> for Japanese, '・' (U+30FB, Katakana middle dot).
>
> >>> locale.getpreferredencoding()
> 'cp932'
> >>> open(b'\xe05', 'w').close()
> >>> os.listdir('.')
> ['・']
> >>> os.listdir(b'.')
> [b'\x81E']

Hum, I'm not sure that I understand your example. Can you pass the
result of os.listdir(str) to open() on Python 3? Are you able to open
the file? Same question for os.listdir(bytes).

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Victor Stinner]

Hi,

2016-02-08 18:02 GMT+01:00 Brett Cannon :
> If Unicode string don't work in Python 2 then what is Python 2/3 to do as a
> cross-platform solution if we completely remove bytes support in Python 3?
> Wouldn't that mean there is no common type between Python 2 & 3 that one can
> use which will work with the os module except native strings (which are
> difficult to get right)?

IMHO we have to put a line somewhere between Python 2 and Python 3.
For some specific use cases, there is no good solution which works on
both Python versions.

For filenames, there is no simple design on Python 2. bytes is the
natural choice on UNIX, whereas Unicode is preferred on Windows. But
it's difficult to handle two types in the same code base. As a
consequence, most users use bytes on Python 2, which is a bad choice
for Windows...

On Python 3, it's much simpler: always use Unicode. Again, the PEP 383
helps on UNIX.

I wrote a PoC for Mercurial to always use Unicode, but the idea was
rejected since Mercurial must support undecodable filenames on UNIX.
It's possible on Python 3 (str+PEP 383), not on Python 2. I tried to
port Mercurial to Python 3 and use Unicode for filenames in the same
change. It's probably better to do that in two steps: first port to
Python 3, then use Unicode. I guess that the final change is to drop
Python 2? I don't know if it's feasible for Mercurial.

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Stephen J. Turnbull]

Chris Barker - NOAA Federal writes:

 > All I can say is "ouch". Hard to call it a regression to no longer
 > allow this mess...

We can't "disallow" the mess, it's embedded in the lunatic computing
environment (which I happen to live in).  We can't even stop people
from using existing Python programs abusing bytes-oriented APIs.  All
we can do is make it harder for people to port to Python 3, and that
would be bad because it's much easier to refactor once you're in
Python 3.

And as Paul points out, it works fine in ASCII-compatible one-byte
environments (and probably in ISO-2022-compatible 8-bit multibyte
environments, too -- the big problems are the abominations known as
Shift JIS and Big5).  Please, let's leave it alone.

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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Joseph Martinot-Lagarde]

Victor Stinner  gmail.com> writes:

> 
> Hi,
> 
> I changed the Python compiler to ignore any kind "constant
> expressions", whereas it only ignored strings and integers before:
> http://bugs.python.org/issue26204
> 
> The compiler now also emits a SyntaxWarning on such case. IMHO the
> warning can help to detect bugs for developers who just learnt Python.
> 
> The warning is *not* emited for strings, since triple quoted strings
> are a common syntax for multiline comments.
> 
> The warning is *not* emited neither for ellispis (...) since "f():
> ..." is a legit syntax for abstract function.
> 

I frequently use 1/0 as a quick break in a script or a program (it's even
more useful with post-mortem debugging). Would it be considered as a
constant and ignored instead of raising a ZeroDivisionError ?

Joseph




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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Victor Stinner]

2016-02-09 1:37 GMT+01:00 eryk sun :
> For example, in codepage 932 (Japanese), it's an error if a lead byte
> (i.e. 0x81-0x9F, 0xE0-0xFC) is followed by a trailing byte with a
> value less than 0x40 (note that ASCII 0-9 is 0x30-0x39, so this is not
> uncommon). In this case the ANSI API substitutes the default character
> for Japanese, '・' (U+30FB, Katakana middle dot).
>
> >>> locale.getpreferredencoding()
> 'cp932'
> >>> open(b'\xe05', 'w').close()
> >>> os.listdir('.')
> ['・']
> >>> os.listdir(b'.')
> [b'\x81E']
>
> All invalid sequences get mapped to '・', which roundtrips as
> b'\x81\x45', so you can't reliably create and open files with
> arbitrary bytes paths in this locale.

Oh, and I forgot to ask: what is your filesystem? Is it the same
behaviour for NTFS, FAT32, network shared directories, etc.?

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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Victor Stinner]

2016-02-09 10:57 GMT+01:00 Joseph Martinot-Lagarde :
> I frequently use 1/0 as a quick break in a script or a program (it's even
> more useful with post-mortem debugging). Would it be considered as a
> constant and ignored instead of raising a ZeroDivisionError ?

"self.x - self.y" and "1/0" are not removed since they have side effects.

Right now, "(1, 2, 3)" is not removed. But later we may remove it,
since it has no side effect, it's a constant statement.

Note: We are talking about statements. 1 is not removed in "lambda: 1"
which is a valid expression ;-)

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

[Python-Dev] CPython build options for out-of-the box performance

[Patrascu, Alecsandru]

Hi all,

This is Alecsandru from the Dynamic Scripting Languages Optimization Team at 
Intel Corporation. I want to open a discussion regarding the way CPython is 
built, mainly the options that are available to the programmers. Analyzing the 
CPython ecosystem we can see that there are a lot of users that just download 
the sources and hit the commands "./configure", "make" and "make install" once 
and then continue using it with their Python scripts. One of the problems with 
this workflow it that the users do not benefit from the entire optimization 
features that are existing in the build system, such as PGO and LTO.

Therefore, I propose a workflow, like the following. Assume some work has to be 
done into the CPython interpreter, a developer can do the following steps:
A. Implementation and debugging phase. 
1. The command "./configure PYDIST=debug" is ran once. It will enable the 
Py_DEBUG, -O0 and -g flags
2. The command "make" is ran once or multiple times

B. Testing the implementation from step A, in a pre-release environment
1. The command "./configure PYDIST=devel" is ran once. It will disable the 
Py_DEBUG flags and will enable the -O3 and -g flags, and it is just like the 
current implementation in CPython
2. The command "make" is ran once or multiple times

C. For any other CPython usage, for example distributing the interpreter, 
installing it inside an operating system, or just the majority of users who are 
not CPython developers and only want to compile it once and use it as-is:
1. The command "./configure" is ran once. Alternatively, the command  
"./configure PYDIST=release" can be used. It will disable all debugging 
functionality, enable the -O3 flag and will enable PGO and LTO.
2. The command "make" is ran once

If you think this benefits CPython, I can create an issue and post the patches 
that enable all of the above. 

Thank you,
Alecsandru

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[eryk sun]

On Tue, Feb 9, 2016 at 3:22 AM, Victor Stinner  wrote:
> 2016-02-09 1:37 GMT+01:00 eryk sun :
>> For example, in codepage 932 (Japanese), it's an error if a lead byte
>> (i.e. 0x81-0x9F, 0xE0-0xFC) is followed by a trailing byte with a
>> value less than 0x40 (note that ASCII 0-9 is 0x30-0x39, so this is not
>> uncommon). In this case the ANSI API substitutes the default character
>> for Japanese, '・' (U+30FB, Katakana middle dot).
>>
>> >>> locale.getpreferredencoding()
>> 'cp932'
>> >>> open(b'\xe05', 'w').close()
>> >>> os.listdir('.')
>> ['・']
>> >>> os.listdir(b'.')
>> [b'\x81E']
>>
>> All invalid sequences get mapped to '・', which roundtrips as
>> b'\x81\x45', so you can't reliably create and open files with
>> arbitrary bytes paths in this locale.
>
> Oh, and I forgot to ask: what is your filesystem? Is it the same
> behaviour for NTFS, FAT32, network shared directories, etc.?

That was tested using NTFS, but the same would apply to FAT32, exFAT,
and UDF since they all use Unicode [1]. CreateFile[A|W] wraps the
NtCreateFile system call. The NT executive is Unicode, so the system
call receives the filename using a Unicode-only OBJECT_ATTRIBUTES [2]
record. I can't say what an arbitrary non-Microsoft filesystem will do
with the U+30FB character when it processes the IRP_MJ_CREATE. I was
only concerned with ANSI<=>Unicode conversion that's implemented in
the ntdll.dll runtime library.

[1]: https://msdn.microsoft.com/en-us/library/ee681827
[2]: https://msdn.microsoft.com/en-us/library/ff557749
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Experiences with Creating PEP 484 Stub Files

[Phil Thompson]

I've been adding support to the SIP wrapper generator for automatically 
generating PEP 484 compatible stub files so that future versions of PyQt can be 
shipped with them. By way of feedback I thought I'd share my experience, 
confusions and suggestions.

There are a number of things I'd like to express but cannot find a way to do 
so...

- objects that implement the buffer protocol
- type objects
- slice objects
- capsules
- sequences of fixed size (ie. specified in the same way as Tuple)
- distinguishing between instance and class attributes.

The documentation is incomplete - there is no mention of Set or Tuple for 
example.

I found the documentation confusing regarding Optional. Intuitively it seems to 
be the way to specify arguments with default values. However it is explained in 
terms of (for example) Union[str, None] and I (intuitively but incorrectly) 
read that as meaning "a str or None" as opposed to "a str or nothing".

bytes can be used as shorthand for bytes, bytearray and memoryview - but what 
about objects that really only support bytes? Shouldn't the shorthand be called 
something like AnyBytes?

Is there any recommended way to test the validity and completeness of stub 
files? What's the recommended way to parse them?

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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Georg Brandl]

On 02/09/2016 10:57 AM, Joseph Martinot-Lagarde wrote:
> Victor Stinner  gmail.com> writes:
> 
>> 
>> Hi,
>> 
>> I changed the Python compiler to ignore any kind "constant
>> expressions", whereas it only ignored strings and integers before:
>> http://bugs.python.org/issue26204
>> 
>> The compiler now also emits a SyntaxWarning on such case. IMHO the
>> warning can help to detect bugs for developers who just learnt Python.
>> 
>> The warning is *not* emited for strings, since triple quoted strings
>> are a common syntax for multiline comments.
>> 
>> The warning is *not* emited neither for ellispis (...) since "f():
>> ..." is a legit syntax for abstract function.
>> 
> 
> I frequently use 1/0 as a quick break in a script or a program (it's even
> more useful with post-mortem debugging). Would it be considered as a
> constant and ignored instead of raising a ZeroDivisionError ?

At first, expressions involving operators are not seen as constant.  But
1/2 would be removed, since the peepholer will evaluate it to 0.5 (or 0)
and the constant-removal pass will recognize it as a constant (assuming
this ordering of the passes).

In the case of 1/0 the peepholer will try to evaluate it, but get an
exception and therefore not touch the expression further.

cheers,
Georg

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Victor Stinner]

2016-02-08 19:26 GMT+01:00 Paul Moore :
> On 8 February 2016 at 14:32, Victor Stinner  wrote:
>> Since 3.3, functions of the os module started to emit
>> DeprecationWarning when called with bytes filenames.
>
> Everywhere? Or just on Windows? I can't tell from your email and I
> don't have a Unix system to hand to check.

I propose to only drop support for bytes filenames on Windows.

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Paul Moore]

On 9 February 2016 at 10:13, Victor Stinner  wrote:
> IMHO we have to put a line somewhere between Python 2 and Python 3.
> For some specific use cases, there is no good solution which works on
> both Python versions.
>
> For filenames, there is no simple design on Python 2. bytes is the
> natural choice on UNIX, whereas Unicode is preferred on Windows. But
> it's difficult to handle two types in the same code base. As a
> consequence, most users use bytes on Python 2, which is a bad choice
> for Windows...
>
> On Python 3, it's much simpler: always use Unicode. Again, the PEP 383
> helps on UNIX.

So if you were proposing "drop the bytes APIs everywhere" that might
be acceptable (for Python 3). But of course it makes porting harder,
so it's probably not a good idea until Python 2 is no longer relevant.

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[eryk sun]

On Tue, Feb 9, 2016 at 3:21 AM, Victor Stinner  wrote:
> 2016-02-09 1:37 GMT+01:00 eryk sun :
>> For example, in codepage 932 (Japanese), it's an error if a lead byte
>> (i.e. 0x81-0x9F, 0xE0-0xFC) is followed by a trailing byte with a
>> value less than 0x40 (note that ASCII 0-9 is 0x30-0x39, so this is not
>> uncommon). In this case the ANSI API substitutes the default character
>> for Japanese, '・' (U+30FB, Katakana middle dot).
>>
>> >>> locale.getpreferredencoding()
>> 'cp932'
>> >>> open(b'\xe05', 'w').close()
>> >>> os.listdir('.')
>> ['・']
>> >>> os.listdir(b'.')
>> [b'\x81E']
>
> Hum, I'm not sure that I understand your example.

Say I create a sequence of files with the names "file_à[N].txt"
encoded in Latin-1, where N is 0-2. They all map to the same file in a
Japanese system locale:

>>> open(b'file_\xe00.txt', 'w').close(); os.listdir('.')
['file_・.txt']
>>> open(b'file_\xe01.txt', 'w').close(); os.listdir('.')
['file_・.txt']
>>> open(b'file_\xe02.txt', 'w').close(); os.listdir('.')
['file_・.txt']
>>> os.listdir(b'.')
[b'file_\x81E.txt']

This isn't a problem with a single-byte codepage such as 1251. For
example, codepage 1251 doesn't map b"\x98" to any character, but
harmlessly maps it to "\x98" (SOS in the C1 Controls block).

Single-byte code pages still have the problem that when a filename is
created using the wide-character API, listing it as bytes may use
either an approximate mapping (e.g. "à" => "a" in 1251) or the
codepage default character (e.g. "\xd7" => "?" in 1251).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Michel Desmoulin]

Hello,

Le 08/02/2016 20:13, Guido van Rossum a écrit :

On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner  wrote:

I changed the Python compiler to ignore any kind "constant
expressions", whereas it only ignored strings and integers before:
http://bugs.python.org/issue26204

The compiler now also emits a SyntaxWarning on such case. IMHO the
warning can help to detect bugs for developers who just learnt Python.

Hum. I'm not excited by this idea. It is not bad syntax. Have you
actually seen newbies who were confused by such things?




I give regular Python trainings and I see similar errors regularly such as:

- not returning something;
- using something without putting the result back in a variable.

However, these are impossible to warn about.

What's more, I have yet to see somebody creating a constant and not 
doing anything with it. I never worked with Ruby dev though.


My sample of dev is not big enough to be significant, but I haven't met 
this issue yet. I still like the idea, anything making Python easier for 
beginers is a good thing for me.


One particular argument against it is the use of linters, but you must 
realize most beginers don't use linters. Just like they don't use 
virtualenv, pip, pdb, etc. They are part of a toolkit you learn to use 
on the way, but not something you start with. Besides, many people using 
Python are not dev, and will just never take the time to use linters, 
not learn about them.

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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Andrew Barnert via Python-Dev]

On Tuesday, February 9, 2016 8:14 AM, Michel Desmoulin 
 wrote:

> I give regular Python trainings and I see similar errors regularly such as:
> 
> - not returning something;
> - using something without putting the result back in a variable.
> 
> However, these are impossible to warn about.
> 
> What's more, I have yet to see somebody creating a constant and not 
> doing anything with it. I never worked with Ruby dev though.
> 

> My sample of dev is not big enough to be significant, but I haven't met 
> this issue yet. I still like the idea, anything making Python easier for 
> beginers is a good thing for me.

What idea do you like? Somehow warning about the things that are impossible to 
warn about? Or warning about something different that isn't any of the things 
your novices have faced? Or...?

> One particular argument against it is the use of linters, but you must 
> realize most beginers don't use linters.

That doesn't mean the compiler should do everything linters do.

Rank beginners are generally writing very simple programs, where the whole 
thing can be visualized at once, so many warnings aren't relevant. And they 
haven't learned many important language features, so many warnings are 
relevant, but they aren't prepared to deal with them (e.g., global variables 
everywhere because they haven't learned to declare functions yet). As a 
teacher, do you want to explain all those warnings to them? Or teach them the 
bad habit of ignoring warnings? Or just not teach them to use linters (or 
static type checkers, or other such tools) until they're ready to write code 
that should pass without warnings?

Part of learning to use linters effectively is learning to configure them. 
That's almost certainly not something you want to be teaching beginners when 
they're just starting out. But if the compiler started adding a bunch of 
warnings that people had to configure, a la gcc, you'd be forced to teach them 
right off the bat.

And meanwhile, once past the initial stage, many beginners _do_ use linters, 
they just don't realize it. If you use PyCharm or Eclipse/PyDev or almost any 
IDE except IDLE, it may be linting in the background and showing you the 
results as inline code hints, or in some other user-friendly way, or at least 
catching some of the simpler things a linter would check for. Whether you want 
to use those tools in your teaching is up to you, but they exist. And if they 
need any support from the compiler to do their job better, presumably they'd 
ask for it.

> They are part of a toolkit you learn to use 

> on the way, but not something you start with. Besides, many people using 
> Python are not dev, and will just never take the time to use linters, 
> not learn about them.


If people who aren't going to go deep enough into Python to write scripts 
longer than a page don't need linters, then they certainly don't need a bunch 
of warnings from the compiler either.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

[Guido van Rossum]

[Just adding to Andrew's response]

On Tue, Feb 9, 2016 at 9:58 AM, Andrew Barnert via Python-Dev
 wrote:
> On Feb 9, 2016, at 03:44, Phil Thompson  wrote:
>>
>> There are a number of things I'd like to express but cannot find a way to do 
>> so...
>>
>> - objects that implement the buffer protocol
>
> That seems like it should be filed as a bug with the typing repo. Presumably 
> this is just an empty type that registers bytes, bytearray, and memoryview, 
> and third-party classes have to register with it manually?

Hm, there's no way to talk about these in regular Python code either,
is there? I think that issue should be resolved first. Probably by
adding something to collections.abc. And then we can add the
corresponding name to typing.py. This will take time though (have to
wait for 3.6) so I'd recommend 'Any' for now (and filing those bugs).

>> - type objects

You can use 'type' for this (i.e. the builtin). You can't specify any
properties for types though; that's a feature request:
https://github.com/python/typing/issues/107 -- but it may be a while
before we address it (it's not entirely clear how it should work, and
we have many other pressing issues still).

>> - slice objects

> Can't you just use the concrete types type and slice tor these two? I don't 
> think you need generic or abstract "any metaclass, whether inheriting from 
> type or not" or "any class that meets the slice protocol", do you?

Can't you use 'slice' (i.e. the builtin)? Mypy supports that.

>> - capsules
>
> That one seems reasonable. But maybe there should just be a types.Capsule 
> Type or types.PyCapsule, and then you can just check that the same as any 
> other concrete type?
>
> But how often do you need to verify that something is a capsule, without 
> knowing that it's the *right* capsule? At runtime, you'd usually use 
> PyCapsule_IsValid, not PyCapsule_CheckExacf, right? So should the type 
> checker be tracking the name too?
>
>> - sequences of fixed size (ie. specified in the same way as Tuple)

That's kind of a poor data structure. :-( Why can't you use Tuple here?

> How would you disambiguate between a sequence of one int and a sequence of 0 
> or more ints if they're both spelled "Sequence[int]"? That isn't a problem 
> for Tuple, because it's assumed to be heterogeneous, so Tuple[int] can only 
> be a 1-tuple. (This was actually discussed in some depth. I thought it would 
> be a problem, because some types--including tuple itself--are sometimes used 
> as homogenous arbitrary-length containers and sometimes as heterogeneous 
> fixed-length containers, but Guido and others had some good answers for that, 
> even if I can't remember what they were.)

We solved that by allowing Tuple[int, ...] to spell a homogeneous
tuple of integers.

>> - distinguishing between instance and class attributes.
>
> Where? Are you building a protocol that checks the data members of a type for 
> conformance or something? If so, why is an object that has "spam" and "eggs" 
> as instance attributes but "cheese" as a class attribute not usable as an 
> object conforming to the protocol with all three attributes? (Also, does 
> @property count as a class or instance attribute? What about an arbitrary 
> data descriptor? Or a non-data descriptor?)

It's a known mypy bug. :-( It's somewhat convoluted to fix.
https://github.com/JukkaL/mypy/issues/1097

Some things Andrew snipped:

> The documentation is incomplete - there is no mention of Set or Tuple for 
> example.

Tuple is here: https://docs.python.org/3/library/typing.html#typing.Tuple

collections.Set maps to typing.AbstractSet
(https://docs.python.org/3/library/typing.html#typing.AbstractSet;
present twice in the docs somehow :-( ). typing.Set (corresponding to
builtins.set) is indeed missing, I've a note of that:
http://bugs.python.org/issue26322.

> I found the documentation confusing regarding Optional. Intuitively it seems 
> to be the way to specify arguments with default values. However it is 
> explained in terms of (for example) Union[str, None] and I (intuitively but 
> incorrectly) read that as meaning "a str or None" as opposed to "a str or 
> nothing".

But it *does* mean 'str or None'. The *type* of an argument doesn't
have any bearing on whether it may be omitted from the argument list
by the caller -- these are orthogonal concepts (though sadly the word
optional might apply to both). It's possible (though unusual) to have
an optional argument that must be a str when given; it's also possible
to have a mandatory argument that may be a str or None.

Can you help improve the wording in the docs (preferably by filing an issue)?

> bytes can be used as shorthand for bytes, bytearray and memoryview - but what 
> about objects that really only support bytes? Shouldn't the shorthand be 
> called something like AnyBytes?

We debated that, but found it too annoying to have to import and write
write AnyBytes in so many 

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

[Phil Thompson]

On 9 Feb 2016, at 8:54 pm, Guido van Rossum  wrote:
> 
> [Just adding to Andrew's response]
> 
> On Tue, Feb 9, 2016 at 9:58 AM, Andrew Barnert via Python-Dev
>  wrote:
>> On Feb 9, 2016, at 03:44, Phil Thompson  wrote:
>>> 
>>> There are a number of things I'd like to express but cannot find a way to 
>>> do so...
>>> 
>>> - objects that implement the buffer protocol
>> 
>> That seems like it should be filed as a bug with the typing repo. Presumably 
>> this is just an empty type that registers bytes, bytearray, and memoryview, 
>> and third-party classes have to register with it manually?
> 
> Hm, there's no way to talk about these in regular Python code either,
> is there? I think that issue should be resolved first. Probably by
> adding something to collections.abc. And then we can add the
> corresponding name to typing.py. This will take time though (have to
> wait for 3.6) so I'd recommend 'Any' for now (and filing those bugs).

Ok.

>>> - type objects
> 
> You can use 'type' for this (i.e. the builtin). You can't specify any
> properties for types though; that's a feature request:
> https://github.com/python/typing/issues/107 -- but it may be a while
> before we address it (it's not entirely clear how it should work, and
> we have many other pressing issues still).

Yes, I can use type.

>>> - slice objects
> 
>> Can't you just use the concrete types type and slice tor these two? I don't 
>> think you need generic or abstract "any metaclass, whether inheriting from 
>> type or not" or "any class that meets the slice protocol", do you?
> 
> Can't you use 'slice' (i.e. the builtin)? Mypy supports that.

Yes, I can use slice.

>>> - capsules
>> 
>> That one seems reasonable. But maybe there should just be a types.Capsule 
>> Type or types.PyCapsule, and then you can just check that the same as any 
>> other concrete type?
>> 
>> But how often do you need to verify that something is a capsule, without 
>> knowing that it's the *right* capsule? At runtime, you'd usually use 
>> PyCapsule_IsValid, not PyCapsule_CheckExacf, right? So should the type 
>> checker be tracking the name too?
>> 
>>> - sequences of fixed size (ie. specified in the same way as Tuple)
> 
> That's kind of a poor data structure. :-( Why can't you use Tuple here?

Because allowing any sequence is more flexible that only allowing a tuple.

>> How would you disambiguate between a sequence of one int and a sequence of 0 
>> or more ints if they're both spelled "Sequence[int]"? That isn't a problem 
>> for Tuple, because it's assumed to be heterogeneous, so Tuple[int] can only 
>> be a 1-tuple. (This was actually discussed in some depth. I thought it would 
>> be a problem, because some types--including tuple itself--are sometimes used 
>> as homogenous arbitrary-length containers and sometimes as heterogeneous 
>> fixed-length containers, but Guido and others had some good answers for 
>> that, even if I can't remember what they were.)
> 
> We solved that by allowing Tuple[int, ...] to spell a homogeneous
> tuple of integers.
> 
>>> - distinguishing between instance and class attributes.
>> 
>> Where? Are you building a protocol that checks the data members of a type 
>> for conformance or something? If so, why is an object that has "spam" and 
>> "eggs" as instance attributes but "cheese" as a class attribute not usable 
>> as an object conforming to the protocol with all three attributes? (Also, 
>> does @property count as a class or instance attribute? What about an 
>> arbitrary data descriptor? Or a non-data descriptor?)
> 
> It's a known mypy bug. :-( It's somewhat convoluted to fix.
> https://github.com/JukkaL/mypy/issues/1097
> 
> Some things Andrew snipped:
> 
>> The documentation is incomplete - there is no mention of Set or Tuple for 
>> example.
> 
> Tuple is here: https://docs.python.org/3/library/typing.html#typing.Tuple

Yes, I missed that.

> collections.Set maps to typing.AbstractSet
> (https://docs.python.org/3/library/typing.html#typing.AbstractSet;
> present twice in the docs somehow :-( ). typing.Set (corresponding to
> builtins.set) is indeed missing, I've a note of that:
> http://bugs.python.org/issue26322.
> 
>> I found the documentation confusing regarding Optional. Intuitively it seems 
>> to be the way to specify arguments with default values. However it is 
>> explained in terms of (for example) Union[str, None] and I (intuitively but 
>> incorrectly) read that as meaning "a str or None" as opposed to "a str or 
>> nothing".
> 
> But it *does* mean 'str or None'. The *type* of an argument doesn't
> have any bearing on whether it may be omitted from the argument list
> by the caller -- these are orthogonal concepts (though sadly the word
> optional might apply to both). It's possible (though unusual) to have
> an optional argument that must be a str when given; it's also possible
> to have a mandatory argument that may be a str or None.

In 

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Yury Selivanov]

On 2016-02-08 8:02 PM, Steven D'Aprano wrote:

On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote:


On 2016-02-08 5:19 PM, Terry Reedy wrote:

On 2/8/2016 4:51 PM, Victor Stinner wrote:

2016-02-08 22:28 GMT+01:00 Alexander Walters :

What incantation do you need to do to make that behavior apparent?

I didn't know. I just checked. It's assert used with a non-empty tuple:


assert ("tuple",)

:1: SyntaxWarning: assertion is always true, perhaps remove
parentheses?

I think this should be left to linters also.


I agree.  I'd remove that warning.


Please don't remove the warning, it is very useful.

Compare an assertion written correctly:

py> assert 1==2, "Error in arithmetic"
Traceback (most recent call last):
   File "", line 1, in 
AssertionError: Error in arithmetic


with the simple mistake of wrapping the "tuple" in parens:

py> assert (1==2, "Error in arithmetic")
:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
py>


You're right!  It's indeed a trap that we should warn about.

Thanks!

Yury

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

[Steve Dower]

Could we perhaps redefine bytes paths on Windows as utf8 and use Unicode 
everywhere internally?

I really don't like the idea of not being able to use bytes in cross platform 
code. Unless it's become feasible to use Unicode for lossless filenames on 
Linux - last I heard it wasn't.

Top-posted from my Windows Phone

-Original Message-
From: "Victor Stinner" 
Sent: ‎2/‎9/‎2016 5:05
To: "Paul Moore" 
Cc: "Python Dev" 
Subject: Re: [Python-Dev] Windows: Remove support of bytes filenames in theos 
module?

2016-02-08 19:26 GMT+01:00 Paul Moore :
> On 8 February 2016 at 14:32, Victor Stinner  wrote:
>> Since 3.3, functions of the os module started to emit
>> DeprecationWarning when called with bytes filenames.
>
> Everywhere? Or just on Windows? I can't tell from your email and I
> don't have a Unix system to hand to check.

I propose to only drop support for bytes filenames on Windows.

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

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

[Ethan Furman]

On 02/09/2016 03:48 PM, Guido van Rossum wrote:

> (Assuming you meant Option*al*.) There seems to be an utter confusion
> of the two uses of the term "optional" here. An "optional argument"
> (outside PEP 484) is one that has a default value. The "Optional[T]"
> notation in PEP 484 means "Union[T, None]". They mean different
> things.

In an effort to be (crystal) clear:

option argument in Python: has a default value, so may be omitted when 
the function is called.


Optional[T] in MyPy: the argument has no default value, and must be 
supplied when the function is called, but the argument can be None.


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

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

[Guido van Rossum]

[Phil]
>>> I found the documentation confusing regarding Optional. Intuitively it 
>>> seems to be the way to specify arguments with default values. However it is 
>>> explained in terms of (for example) Union[str, None] and I (intuitively but 
>>> incorrectly) read that as meaning "a str or None" as opposed to "a str or 
>>> nothing".
[me]
>> But it *does* mean 'str or None'. The *type* of an argument doesn't
>> have any bearing on whether it may be omitted from the argument list
>> by the caller -- these are orthogonal concepts (though sadly the word
>> optional might apply to both). It's possible (though unusual) to have
>> an optional argument that must be a str when given; it's also possible
>> to have a mandatory argument that may be a str or None.
[Phil]
> In the case of Python wrappers around a C++ library then *every* optional 
> argument will have to have a specific type when given.

IIUC you're saying that every argument that may be omitted must still
have a definite type other than None. Right? In that case just don't
use Optional[]. If a signature has the form

def foo(a: str = 'xyz') -> str: ...

then this means that str may be omitted or it may be a str -- you
cannot call foo(a=None).

You can even (in a stub file) write this as:

def foo(a: str = ...) -> str: ...

(literal '...' i.e. ellipsis) if you don't want to commit to a
specific default value (it makes no difference to mypy).

> So you are saying that a mandatory argument that may be a str or None would 
> be specified as Union[str, None]?

Or as Optional[str], which means the same.

> But the docs say that that is the underlying implementation of Option[str] - 
> which (to me) means an optional argument that should be a string when given.

(Assuming you meant Option*al*.) There seems to be an utter confusion
of the two uses of the term "optional" here. An "optional argument"
(outside PEP 484) is one that has a default value. The "Optional[T]"
notation in PEP 484 means "Union[T, None]". They mean different
things.

>> Can you help improve the wording in the docs (preferably by filing an issue)?
>
> When I eventually understand what it means...

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

[Stephen J. Turnbull]

Steve Dower writes:
 > On 09Feb2016 1801, Andrew Barnert wrote:
 > > On Feb 9, 2016, at 17:37, Steve Dower  > > wrote:
 > >
 > >> Could we perhaps redefine bytes paths on Windows as utf8 and use
 > >> Unicode everywhere internally?
 > >
 > > When you receive bytes from argv, stdin, a text file, a GUI, a named
 > > pipe, etc., and then use them as a path, Python treating them as UTF-8
 > > would break everything.
 > 
 > Sure, but that's already broken today if you're communicating bytes via 
 > some protocol without manually managing the encoding, in which case you 
 > should be decoding it (and potentially re-encoding to 
 > sys.getfilesystemencoding()).

The problem is that treating them as UTF-8 in Python will raise errors
on any file name that isn't valid UTF-8, or corrupt the filename if
you use one of the handlers available in Python 2.

If you use Latin-1, that (1) handles all 256 bytes, and (2) roundtrips
to Unicode.  Although semantically useless to users, if it's just read
from a directory, then used to manipulate file contents, no problem.

Of course if you then edit a multibyte file name as Unicode it is
likely that all hell will break loose.  But you can take that sentence
and s/Unicode/bytes/, too. :-/

 > The problem here is the protocol that Python uses to return bytes paths, 
 > and that protocol is inconsistent between APIs and information is lost.

No, the problem is that the necessary information simply isn't always
available.  Not even today: think removable media, especially archival
content.  Also network file systems: I don't know if it still happens,
but I've seen Shift JIS, GB2312, and KOI8-R all in the same directory,
and sometimes two of those in the *same path*.  (Don't ask me how
non-malicious users managed to do the latter!)

 > It really requires going through all the OS calls and either (a) making 
 > them consistently decode bytes to str using the declared FS encoding 
 > (currently 'mbcs', but I see no reason we can't make it 'utf_8'),

If it were that easy, it would have been done two decades ago.  I'm no
fan of Windows[1], but it's obvious that Microsoft has devoted
enormous amounts of brainpower to the problem of encoding
rationalization since the early 90s.  I don't think they would have
missed this idea.



Footnotes: 
[1]  Its complete inability to DTRT for mixed English and Japanese was
what drove me to Unix-like OSes in the early 90s.

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

[Steve Dower]

On 09Feb2016 2017, Stephen J. Turnbull wrote:

  > The problem here is the protocol that Python uses to return bytes paths,
  > and that protocol is inconsistent between APIs and information is lost.

No, the problem is that the necessary information simply isn't always
available.  Not even today: think removable media, especially archival
content.  Also network file systems: I don't know if it still happens,
but I've seen Shift JIS, GB2312, and KOI8-R all in the same directory,
and sometimes two of those in the *same path*.  (Don't ask me how
non-malicious users managed to do the latter!)


But if we return bytes paths and the user passes them back in unchanged, 
that should be irrelevant. The earlier issue was that that doesn't work 
(e.g. a bytes path from os.scandir couldn't be passed back into open()).



  > It really requires going through all the OS calls and either (a) making
  > them consistently decode bytes to str using the declared FS encoding
  > (currently 'mbcs', but I see no reason we can't make it 'utf_8'),

If it were that easy, it would have been done two decades ago.  I'm no
fan of Windows[1], but it's obvious that Microsoft has devoted
enormous amounts of brainpower to the problem of encoding
rationalization since the early 90s.  I don't think they would have
missed this idea.


I meant with Python's calls into the API. Anywhere Python does the 
conversion from bytes to LPCWSTR (the UTF-16 type) there's a chance 
it'll be wrong.


Your earlier comments (regarding encoding/decoding to/from Unicode, 
which I didn't have anything valuable to add to) basically reflect the 
fact that developers need to treat bytes paths as blobs on all platforms 
and the core Python runtime needs to obtain and use them consistently. 
Which means *always* using the Win32 *A APIs and never doing a 
conversion ourselves.


Microsoft's solution here is the user's active code page, much like 
*nix's solution as I understand it, except that where *nix will convert 
_to_ the encoding as a normalized form, Windows will convert _from_ the 
encoding to its UTF-16 "normalized" form. Back-compat concerns have 
prevented any significant changes being made here, otherwise there 
wouldn't be a 'bytes' interface at all. (Or more likely, everything 
would be UTF-8 based, but back-compat is king in Windows-land.)


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

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

[Chris Angelico]

On Wed, Feb 10, 2016 at 12:37 PM, Steve Dower  wrote:
> I really don't like the idea of not being able to use bytes in cross
> platform code. Unless it's become feasible to use Unicode for lossless
> filenames on Linux - last I heard it wasn't.

It has, but only in Python 3 - anyone who needs to support 2.7 and
arbitrary bytes in filenames can't use Unicode strings.

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

[Andrew Barnert via Python-Dev]

On Feb 9, 2016, at 17:37, Steve Dower  wrote:
> 
> Could we perhaps redefine bytes paths on Windows as utf8 and use Unicode 
> everywhere internally?

When you receive bytes from argv, stdin, a text file, a GUI, a named pipe, 
etc., and then use them as a path, Python treating them as UTF-8 would break 
everything.

Plus, the problem only exists in Python 2, and Python is not going to fix 
Unicode support in Python 2, both because it's too late for such a major change 
in Python 2, and because it's probably impossible* (which is why we have Python 
3 in the first place). 

> I really don't like the idea of not being able to use bytes in cross platform 
> code. Unless it's become feasible to use Unicode for lossless filenames on 
> Linux - last I heard it wasn't.

It is, and has been for years. Surrogate escaping solved the linux problem. 
That doesn't help for Python 2, but again, it's too late for Python 2.


* Well, maybe in the future, some linux distros will bite the same bullet OS X 
did and mandate that filesystem drivers must expose UTF-8, doing whatever 
transcoding or other munging is necessary under the covers, to be valid. But 
I'm guessing any such distros will be all-Python-3 long before then, and the 
people using Python 2 will also be using old versions or conservative distros.___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

[Steve Dower]

On 09Feb2016 1801, Andrew Barnert wrote:

On Feb 9, 2016, at 17:37, Steve Dower > wrote:


Could we perhaps redefine bytes paths on Windows as utf8 and use
Unicode everywhere internally?


When you receive bytes from argv, stdin, a text file, a GUI, a named
pipe, etc., and then use them as a path, Python treating them as UTF-8
would break everything.


Sure, but that's already broken today if you're communicating bytes via 
some protocol without manually managing the encoding, in which case you 
should be decoding it (and potentially re-encoding to 
sys.getfilesystemencoding()).


The problem here is the protocol that Python uses to return bytes paths, 
and that protocol is inconsistent between APIs and information is lost. 
It really requires going through all the OS calls and either (a) making 
them consistently decode bytes to str using the declared FS encoding 
(currently 'mbcs', but I see no reason we can't make it 'utf_8'), or (b) 
make them consistently use the user's current system locale setting by 
always using the *A Win32 APIs rather than the *W ones.



I really don't like the idea of not being able to use bytes in cross
platform code. Unless it's become feasible to use Unicode for lossless
filenames on Linux - last I heard it wasn't.


It is, and has been for years. Surrogate escaping solved the linux
problem. That doesn't help for Python 2, but again, it's too late for
Python 2.


Okay, guess I was operating out of old information. Thanks (and thanks 
Chris for the same answer).

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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Victor Stinner]

Le mercredi 10 février 2016, Steve Dower  a écrit :
>
> I really don't like the idea of not being able to use bytes in cross
> platform code. Unless it's become feasible to use Unicode for lossless
> filenames on Linux - last I heard it wasn't.
>

The point of my email is that even on Python 3, users kept bad habits
because of Python 2. *Yes*, you can use Unicode filenames on all platforms
on Python 3 since 2009 thanks to the following PEP:
 https://www.python.org/dev/peps/pep-0383/

In my first email, I mentioned a bug report of an user still using bytes
filenames on Windows with Python 3. It is on the Blender project which
*only* supports Python 3. Or maybe I missed something huge which really
force Blender to use bytes??? But if a few functions still require bytes, I
would suggest to use instead os.fsencode() for them. It's more much
convenient to handle filenames as Unicode on Python 3.

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

Re: [Python-Dev] Experiences with Creating PEP 484 Stub Files

[Andrew Barnert via Python-Dev]

On Feb 9, 2016, at 03:44, Phil Thompson  wrote:
> 
> There are a number of things I'd like to express but cannot find a way to do 
> so...
> 
> - objects that implement the buffer protocol

That seems like it should be filed as a bug with the typing repo. Presumably 
this is just an empty type that registers bytes, bytearray, and memoryview, and 
third-party classes have to register with it manually?

> - type objects
> - slice objects

Can't you just use the concrete types type and slice tor these two? I don't 
think you need generic or abstract "any metaclass, whether inheriting from type 
or not" or "any class that meets the slice protocol", do you?

> - capsules

That one seems reasonable. But maybe there should just be a types.Capsule Type 
or types.PyCapsule, and then you can just check that the same as any other 
concrete type?

But how often do you need to verify that something is a capsule, without 
knowing that it's the *right* capsule? At runtime, you'd usually use 
PyCapsule_IsValid, not PyCapsule_CheckExacf, right? So should the type checker 
be tracking the name too?

> - sequences of fixed size (ie. specified in the same way as Tuple)

How would you disambiguate between a sequence of one int and a sequence of 0 or 
more ints if they're both spelled "Sequence[int]"? That isn't a problem for 
Tuple, because it's assumed to be heterogeneous, so Tuple[int] can only be a 
1-tuple. (This was actually discussed in some depth. I thought it would be a 
problem, because some types--including tuple itself--are sometimes used as 
homogenous arbitrary-length containers and sometimes as heterogeneous 
fixed-length containers, but Guido and others had some good answers for that, 
even if I can't remember what they were.)

> - distinguishing between instance and class attributes.

Where? Are you building a protocol that checks the data members of a type for 
conformance or something? If so, why is an object that has "spam" and "eggs" as 
instance attributes but "cheese" as a class attribute not usable as an object 
conforming to the protocol with all three attributes? (Also, does @property 
count as a class or instance attribute? What about an arbitrary data 
descriptor? Or a non-data descriptor?)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com