Re: [Python-Dev] cpython: Improve struct cache locality by bring commonly accessed fields close together.

[Antoine Pitrou]

On Fri, 20 Feb 2015 08:50:10 +
raymond.hettinger  wrote:
> https://hg.python.org/cpython/rev/0ba4bcc0a7a6
> changeset:   94696:0ba4bcc0a7a6
> user:Raymond Hettinger 
> date:Fri Feb 20 00:50:04 2015 -0800
> summary:
>   Improve struct cache locality by bring commonly accessed fields close 
> together.
> 
> files:
>   Modules/_randommodule.c |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/Modules/_randommodule.c b/Modules/_randommodule.c
> --- a/Modules/_randommodule.c
> +++ b/Modules/_randommodule.c
> @@ -78,8 +78,8 @@
>  
>  typedef struct {
>  PyObject_HEAD
> +int index;
>  unsigned long state[N];
> -int index;
>  } RandomObject;

I may be missing something something, but I don't see how that improves
cache locality. The index is only ever looked up when the state is also
looked up, and since the state is used sequentially there are equal
chances for the state lookup to be near the end rather than near the
front.

Regards

Antoine.


___
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] TypeError messages

[Brett Cannon]

On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka 
wrote:

> Different patterns for TypeError messages are used in the stdlib:
>
>  expected X, Y found
>  expected X, found Y
>  expected X, but Y found
>  expected X instance, Y found
>  X expected, not Y
>  expect X, not Y
>  need X, Y found
>  X is required, not Y
>  Z must be X, not Y
>  Z should be X, not Y
>
> and more.
>
> What the pattern is most preferable?
>

My preference is for "expected X, but found Y".


>
> Some messages use the article before X or Y. Should the article be used
> or omitted?
>
> Some messages (only in C) truncate actual type name (%.50s, %.80s,
> %.200s, %.500s). Should type name be truncated at all and for how limit?
>

I assume this is over some worry of string size blowing out memory
allocation or something? If someone can show that's an actual worry then
fine, otherwise I say don't truncate.


> Type names newer truncated in TypeError messages raised in Python code.
>
> Some messages enclose actual type name with single quotes ('%s',
> '%.200s'). Should type name be quoted? It is uncommon if type name
> contains spaces.
>

 I agree that type names don't need to be quoted.
___
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] Idea: __length_hint__ wrapper in itertools

[Carlos Pita]

Hi all,

python now supports the __length_hint__ method but not for every use
case that could potentially benefit from it, v.g.:

1) Some common builtins like map don't set the hint.
2) Generators.
3) Application specific hints that, by definition, can't be predicted
by a general strategy.

I know 1 and 2 were discussed at some length in the past, but still
there is no agreement about what to do with them.

In the meantime, and because of 3, what do you think about adding a
simple iterator wrapper to itertools which would allow to provide the
hint by the user without any significant performance lost (__next__ in
the wrapper could be just the original __next__). AFAIK there is no
such thing in the standard library or anywhere else and it seems
pretty easy to implement, although maybe I'm completely wrong.

Say:

hinted_iter = it.length_hint(iter, hint)

Cheers
--
Carlos
___
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] TypeError messages

[Stefan Richthofer]

Honestly, the right solution would be to have a function or macro that generates the TypeError messages

from X, Y, Z arguments. (Until now I actually believed this would be already the case)

- type errors would be of uniform style

- if for some reoson the format should be changed, this can be done in one central place

- if someone would want to parse the error message this would be feasible

I suppose it should be straight forward to find error message creations in the source by searching for "TypeError" or something.

Maybe this kind of cleanup could be done along with the implementation of PEP 484?

 

-Stefan

 

Gesendet: Freitag, 20. Februar 2015 um 15:05 Uhr
Von: "Brett Cannon" 
An: "Serhiy Storchaka" , python-dev@python.org
Betreff: Re: [Python-Dev] TypeError messages


 
On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka  wrote:

Different patterns for TypeError messages are used in the stdlib:

     expected X, Y found
     expected X, found Y
     expected X, but Y found
     expected X instance, Y found
     X expected, not Y
     expect X, not Y
     need X, Y found
     X is required, not Y
     Z must be X, not Y
     Z should be X, not Y

and more.

What the pattern is most preferable?

 

My preference is for "expected X, but found Y".

 


Some messages use the article before X or Y. Should the article be used
or omitted?

Some messages (only in C) truncate actual type name (%.50s, %.80s,
%.200s, %.500s). Should type name be truncated at all and for how limit?

 

I assume this is over some worry of string size blowing out memory allocation or something? If someone can show that's an actual worry then fine, otherwise I say don't truncate.

 

Type names newer truncated in TypeError messages raised in Python code.

Some messages enclose actual type name with single quotes ('%s',
'%.200s'). Should type name be quoted? It is uncommon if type name
contains spaces.

 

 I agree that type names don't need to be quoted.


___ 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/stefan.richthofer%40gmx.de



___
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] TypeError messages

[Brett Cannon]

On Fri Feb 20 2015 at 10:27:35 AM Stefan Richthofer <
stefan.richtho...@gmx.de> wrote:

> Honestly, the right solution would be to have a function or macro that
> generates the TypeError messages
> from X, Y, Z arguments. (Until now I actually believed this would be
> already the case)
> - type errors would be of uniform style
> - if for some reoson the format should be changed, this can be done in one
> central place
> - if someone would want to parse the error message this would be feasible
> I suppose it should be straight forward to find error message creations in
> the source by searching for "TypeError" or something.
> Maybe this kind of cleanup could be done along with the implementation of
> PEP 484?
>

Actually PEP 473 covers standardizing error messages by introducing
keyword-only arguments which would lead to a standardized message being
generated. From the C side there can be a function provided to make it easy
to get the same result as constructing the exception with the keyword-only
argument.

-Brett


>
> -Stefan
>
> *Gesendet:* Freitag, 20. Februar 2015 um 15:05 Uhr
> *Von:* "Brett Cannon" 
> *An:* "Serhiy Storchaka" , python-dev@python.org
> *Betreff:* Re: [Python-Dev] TypeError messages
>
> On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka 
> wrote:
>>
>> Different patterns for TypeError messages are used in the stdlib:
>>
>>  expected X, Y found
>>  expected X, found Y
>>  expected X, but Y found
>>  expected X instance, Y found
>>  X expected, not Y
>>  expect X, not Y
>>  need X, Y found
>>  X is required, not Y
>>  Z must be X, not Y
>>  Z should be X, not Y
>>
>> and more.
>>
>> What the pattern is most preferable?
>
>
> My preference is for "expected X, but found Y".
>
>
>>
>> Some messages use the article before X or Y. Should the article be used
>> or omitted?
>>
>> Some messages (only in C) truncate actual type name (%.50s, %.80s,
>> %.200s, %.500s). Should type name be truncated at all and for how limit?
>
>
> I assume this is over some worry of string size blowing out memory
> allocation or something? If someone can show that's an actual worry then
> fine, otherwise I say don't truncate.
>
>
>> Type names newer truncated in TypeError messages raised in Python code.
>>
>> Some messages enclose actual type name with single quotes ('%s',
>> '%.200s'). Should type name be quoted? It is uncommon if type name
>> contains spaces.
>
>
>  I agree that type names don't need to be quoted.
>  ___ 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/stefan.richthofer%40gmx.de
>   ___
> 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/
> brett%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] TypeError messages

[Eric V. Smith]

On 02/20/2015 09:05 AM, Brett Cannon wrote:
> Some messages (only in C) truncate actual type name (%.50s, %.80s,
> %.200s, %.500s). Should type name be truncated at all and for how limit?
> 
> 
> I assume this is over some worry of string size blowing out memory
> allocation or something? If someone can show that's an actual worry then
> fine, otherwise I say don't truncate.

I asked about this years ago, and was told it was in case the type name
pointer was bad, and to limit the amount of garbage printed. Whether
that's an actual problem or not, I can't say. It seems more likely that
you'd get a segfault, but maybe if it was pointing to reused memory it
could be useful.

Eric.

___
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] str(IntEnum)

[Demian Brecht]

While working on a bug in the issue tracker, I came across something that I 
thought was a little odd around the behaviour of IntEnum. Should the behaviour 
of an instance of an IntEnum not be symmetric to an int where possible? For 
example:

>>> class MyEnum(IntEnum):
... FOO = 1
...
>>> MyEnum.FOO == 1
True
>>> MyEnum.FOO * 3 == 3
True
>>> str(MyEnum.FOO) == str(1)
False

In my mind, the string representation here should be “1” and not the label. Was 
this simply an oversight of the specialized IntEnum implementation, or was 
there a concrete reason for this that I’m not seeing?


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] str(IntEnum)

[Brett Cannon]

On Fri Feb 20 2015 at 11:39:11 AM Demian Brecht 
wrote:

> While working on a bug in the issue tracker, I came across something that
> I thought was a little odd around the behaviour of IntEnum. Should the
> behaviour of an instance of an IntEnum not be symmetric to an int where
> possible? For example:
>
> >>> class MyEnum(IntEnum):
> ... FOO = 1
> ...
> >>> MyEnum.FOO == 1
> True
> >>> MyEnum.FOO * 3 == 3
> True
> >>> str(MyEnum.FOO) == str(1)
> False
>
> In my mind, the string representation here should be “1” and not the
> label. Was this simply an oversight of the specialized IntEnum
> implementation, or was there a concrete reason for this that I’m not seeing?
>

Concrete reason. The string is 'MyEnum.FOO' which is much more readable and
obvious where the value came from. The fact that it can be treated as an
int is the same as the reason True and False are subclasses of int; it made
practical sense for compatibility with what they typically replaced, but
where it made more sense to diverge and introduce new behaviour then we did
so.
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2015-02-13 - 2015-02-20)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4770 (-20)
  closed 30484 (+54)
  total  35254 (+34)

Open issues with patches: 2239 


Issues opened (24)
==

#23018: Add version info to python
http://bugs.python.org/issue23018  reopened by serhiy.storchaka

#23460: Decimals do not obey ':g' exponential notation formatting rule
http://bugs.python.org/issue23460  opened by ikelly

#23462: All os.exec*e variants crash on Windows
http://bugs.python.org/issue23462  opened by nicolaje

#23464: Remove or deprecate JoinableQueue in asyncio docs
http://bugs.python.org/issue23464  opened by emptysquare

#23465: Implement PEP 486 - Make the Python Launcher aware of virtual 
http://bugs.python.org/issue23465  opened by pmoore

#23466: PEP 461: Inconsistency between str and bytes formatting of int
http://bugs.python.org/issue23466  opened by serhiy.storchaka

#23467: Improve byte formatting compatibility between Py2 and Py3
http://bugs.python.org/issue23467  opened by serhiy.storchaka

#23469: Delete Misc/*.wpr files
http://bugs.python.org/issue23469  opened by berker.peksag

#23470: OpenBSD buildbot uses wrong stdlib
http://bugs.python.org/issue23470  opened by serhiy.storchaka

#23471: 404 Not Found when downloading Python 3.4.3rc1 Documentation
http://bugs.python.org/issue23471  opened by stringsonfire

#23472: Setup locales on buildbots
http://bugs.python.org/issue23472  opened by serhiy.storchaka

#23476: SSL cert verify fail for "www.verisign.com"
http://bugs.python.org/issue23476  opened by nagle

#23477: Increase coverage for wsgiref module
http://bugs.python.org/issue23477  opened by ashkop

#23484: SemLock acquire() keyword arg 'blocking' is invalid
http://bugs.python.org/issue23484  opened by td

#23485: PEP 475: handle EINTR in the select and selectors module
http://bugs.python.org/issue23485  opened by haypo

#23486: Enum member lookup is 20x slower than normal class attribute l
http://bugs.python.org/issue23486  opened by craigh

#23487: argparse: add_subparsers 'action' broken
http://bugs.python.org/issue23487  opened by derks

#23488: Random objects twice as big as necessary on 64-bit builds
http://bugs.python.org/issue23488  opened by rhettinger

#23489: atexit handlers are not executed when using multiprocessing.Po
http://bugs.python.org/issue23489  opened by juj

#23490: allocation (and overwrite) of a 0 byte buffer
http://bugs.python.org/issue23490  opened by pkt

#23491: PEP 441 - Improving Python Zip Application Support
http://bugs.python.org/issue23491  opened by pmoore

#23492: Argument Clinic: improve generated parser for 1-argument funct
http://bugs.python.org/issue23492  opened by serhiy.storchaka

#23493: optimize sort_keys in json module by using operator.itemgetter
http://bugs.python.org/issue23493  opened by wbolster

#433028: SRE: (?flag:...) is not supported
http://bugs.python.org/issue433028  reopened by serhiy.storchaka



Most recent 15 issues with no replies (15)
==

#23493: optimize sort_keys in json module by using operator.itemgetter
http://bugs.python.org/issue23493

#23492: Argument Clinic: improve generated parser for 1-argument funct
http://bugs.python.org/issue23492

#23487: argparse: add_subparsers 'action' broken
http://bugs.python.org/issue23487

#23485: PEP 475: handle EINTR in the select and selectors module
http://bugs.python.org/issue23485

#23484: SemLock acquire() keyword arg 'blocking' is invalid
http://bugs.python.org/issue23484

#23470: OpenBSD buildbot uses wrong stdlib
http://bugs.python.org/issue23470

#23469: Delete Misc/*.wpr files
http://bugs.python.org/issue23469

#23464: Remove or deprecate JoinableQueue in asyncio docs
http://bugs.python.org/issue23464

#23459: Linux: expose the new execveat() syscall
http://bugs.python.org/issue23459

#23456: asyncio: add missing @coroutine decorators
http://bugs.python.org/issue23456

#23455: file iterator "deemed broken"; can resume after StopIteration
http://bugs.python.org/issue23455

#23444: HCI Bluetooth socket bind error on an arm crosscompiled enviro
http://bugs.python.org/issue23444

#23443: XMLRPCLIB Exception uses str not class or instance
http://bugs.python.org/issue23443

#23436: xml.dom.minidom.Element.ownerDocument is hiden
http://bugs.python.org/issue23436

#23423: XPath Support in ElementTree doc omission
http://bugs.python.org/issue23423



Most recent 15 issues waiting for review (15)
=

#23492: Argument Clinic: improve generated parser for 1-argument funct
http://bugs.python.org/issue23492

#23491: PEP 441 - Improving Python Zip Application Support
http://bugs.python.org/issue23491

#23490: allocation (and overwrite) of a 0 byte buffer
http://bugs.python.org/issue23490

#23488: Random objects twice as big as necessary on 6

[Python-Dev] Fwd: str(IntEnum)

[Demian Brecht]

> On Feb 20, 2015, at 8:54 AM, Brett Cannon  wrote:
> Concrete reason. The string is 'MyEnum.FOO' which is much more readable and 
> obvious where the value came from. The fact that it can be treated as an int 
> is the same as the reason True and False are subclasses of int; it made 
> practical sense for compatibility with what they typically replaced, but 
> where it made more sense to diverge and introduce new behaviour then we did 
> so.

Thanks Brett, that makes sense and was pretty much what I assumed. Reading the 
docs for __str__ does clarify things a bit in that the intention is to be a 
string representation of the object and not the value. That said, 
implementations seem to vary throughout the standard library and builtins:

>>> str(uuid.uuid4())
'd467d97c-fc09-4dc9-bea5-aeebdad8df8d’
>>> str(int())
‘0'
>>> str(datetime.datetime.now())
'2015-02-20 09:31:28.385539’
>>> str(IPv4Address('127.0.0.1'))
'127.0.0.1'

These and other implementations return a string representation of the 
instance’s value, not a string representation of the object itself. Whereas 
elsewhere in the standard library:

>>> str(ProtocolError('url', 42, 'msg', ''))
'’
>>> str(URLError('reason'))
'’
>>> str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '', ''))
''

The specific problem that I encountered was when swapping an IntEnum 
implementation for ints in http.client, which caused a change in logging output 
(from int.__str__ to Enum.__str__), which was a bit of a surprise, especially 
given the value is a builtin type.

I think that a decent rule around the usage of __str__ is that it should be a 
string representation of the value, not of the object. Failing the ability to 
logically coerce the value to a string, it should simply fall back to repr(obj).

Of course, I realize that the chances of this change being made to such a 
fundamental (and largely inconsequential) feature are likely nil, but I thought 
I’d share my thoughts anyways.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Fwd: str(IntEnum)

[Florian Bruhin]

* Demian Brecht  [2015-02-20 10:24:53 -0800]:
> These and other implementations return a string representation of the 
> instance’s value, not a string representation of the object itself. Whereas 
> elsewhere in the standard library:
> 
> >>> str(ProtocolError('url', 42, 'msg', ''))
> '’
> >>> str(URLError('reason'))
> '’
> >>> str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '', ''))
> ''
> 
> The specific problem that I encountered was when swapping an IntEnum 
> implementation for ints in http.client, which caused a change in logging 
> output (from int.__str__ to Enum.__str__), which was a bit of a surprise, 
> especially given the value is a builtin type.
> 
> I think that a decent rule around the usage of __str__ is that it should be a 
> string representation of the value, not of the object. Failing the ability to 
> logically coerce the value to a string, it should simply fall back to 
> repr(obj).
> 
> Of course, I realize that the chances of this change being made to such a 
> fundamental (and largely inconsequential) feature are likely nil, but I 
> thought I’d share my thoughts anyways.

>>> foo = object()
>>> str(foo)
''
>>> repr(foo)
''

This is exactly what you see above. ;)

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
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] Fwd: str(IntEnum)

[Ethan Furman]

On 02/20/2015 10:24 AM, Demian Brecht wrote:

> I think that a decent rule around the usage of __str__ is that it should
> be a string representation of the value, not of the object. Failing the
> ability to logically coerce the value to a string, it should simply fall
> back to repr(obj).

There are two "stringy" methods for objects:  __repr__ and __str__; if __str__ 
has not been defined __repr__ is
automatically used.

One of the motivating forces behind Enum is that often the name is more 
important (for humans) than the actual value, so
__str__ is defined as being the Enum class name plus the Enum member name.  The 
__repr__ has that as well as the
underlying value (occasionally it's useful to know that, too ;) .

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
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] Update to PEP 11 to clarify garnering platform support

[Brett Cannon]

I just realized I actually never committed this change. Assuming no new
objections I'll commit this in the near future (promise this time =).

On Fri May 16 2014 at 1:51:00 PM Brett Cannon  wrote:

> Here is some proposed wording. Since it is more of a clarification of what
> it takes to garner support -- which is just a new section -- rather than a
> complete rewrite I'm including just the diff to make it easier to read the
> changes.
>
>
> *diff -r 49d18bb47ebc pep-0011.txt*
>
> *--- a/pep-0011.txt Wed May 14 11:18:22 2014 -0400*
>
> *+++ b/pep-0011.txt Fri May 16 13:48:30 2014 -0400*
>
> @@ -2,22 +2,21 @@
>
>  Title: Removing support for little used platforms
>
>  Version: $Revision$
>
>  Last-Modified: $Date$
>
> -Author: mar...@v.loewis.de (Martin von Löwis)
>
> +Author: Martin von Löwis ,
>
> +Brett Cannon 
>
>  Status: Active
>
>  Type: Process
>
>  Content-Type: text/x-rst
>
>  Created: 07-Jul-2002
>
>  Post-History: 18-Aug-2007
>
> +  16-May-2014
>
>
>
>
>
>  Abstract
>
>  
>
>
>
> -This PEP documents operating systems (platforms) which are not
>
> -supported in Python anymore.  For some of these systems,
>
> -supporting code might be still part of Python, but will be removed
>
> -in a future release - unless somebody steps forward as a volunteer
>
> -to maintain this code.
>
> +This PEP documents how an operating system (platform) garners
>
> +support in Python as well as documenting past support.
>
>
>
>
>
>  Rationale
>
> @@ -37,16 +36,53 @@
>
>  change to the Python source code will work on all supported
>
>  platforms.
>
>
>
> -To reduce this risk, this PEP proposes a procedure to remove code
>
> -for platforms with no Python users.
>
> +To reduce this risk, this PEP specifies what is required for a
>
> +platform to be considered supported by Python as well as providing a
>
> +procedure to remove code for platforms with little or no Python
>
> +users.
>
>
>
> +Supporting platforms
>
> +
>
> +
>
> +Gaining official platform support requires two things. First, a core
>
> +developer needs to volunteer to maintain platform-specific code. This
>
> +core developer can either already be a member of the Python
>
> +development team or be given contributor rights on the basis of
>
> +maintaining platform support (it is at the discretion of the Python
>
> +development team to decide if a person is ready to have such rights
>
> +even if it is just for supporting a specific platform).
>
> +
>
> +Second, a stable buildbot must be provided [2]_. This guarantees that
>
> +platform support will not be accidentally broken by a Python core
>
> +developer who does not have personal access to the platform. For a
>
> +buildbot to be considered stable it requires that the machine be
>
> +reliably up and functioning (but it is up to the Python core
>
> +developers to decide whether to promote a buildbot to being
>
> +considered stable).
>
> +
>
> +This policy does not disqualify supporting other platforms
>
> +indirectly. Patches which are not platform-specific but still done to
>
> +add platform support will be considered for inclusion. For example,
>
> +if platform-independent changes were necessary in the configure
>
> +script which was motivated to support a specific platform that would
>
> +be accepted. Patches which add platform-specific code such as the
>
> +name of a specific platform to the configure script will generally
>
> +not be accepted without the platform having official support.
>
> +
>
> +CPU architecture and compiler support are viewed in a similar manner
>
> +as platforms. For example, to consider the ARM architecture supported
>
> +a buildbot running on ARM would be required along with support from
>
> +the Python development team. In general it is not required to have
>
> +a CPU architecture run under every possible platform in order to be
>
> +considered supported.
>
>
>
>  Unsupporting platforms
>
>  --
>
>
>
> -If a certain platform that currently has special code in it is
>
> -deemed to be without Python users, a note must be posted in this
>
> -PEP that this platform is no longer actively supported.  This
>
> +If a certain platform that currently has special code in Python is
>
> +deemed to be without Python users or lacks proper support from the
>
> +Python development team and/or a buildbot, a note must be posted in
>
> +this PEP that this platform is no longer actively supported.  This
>
>  note must include:
>
>
>
>  - the name of the system
>
> @@ -69,8 +105,8 @@
>
>  forward and offer maintenance.
>
>
>
>
>
> -Resupporting platforms
>
> ---
>
> +Re-supporting platforms
>
> +---
>
>
>
>  If a user of a platform wants to see this platform supported
>
>  again, he may volunteer to maintain the platform support.  Such an
>
> @@ -101,7 +137,7 @@
>
>  release is made. Developers of extension modules will generally need
>
>  to use the same Visual Studio release; they are concerned 

Re: [Python-Dev] Fwd: str(IntEnum)

[Ian Cordasco]

On Fri, Feb 20, 2015 at 12:36 PM, Florian Bruhin  wrote:
> * Demian Brecht  [2015-02-20 10:24:53 -0800]:
>> These and other implementations return a string representation of the 
>> instance’s value, not a string representation of the object itself. Whereas 
>> elsewhere in the standard library:
>>
>> >>> str(ProtocolError('url', 42, 'msg', ''))
>> '’
>> >>> str(URLError('reason'))
>> '’
>> >>> str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '', 
>> >>> ''))
>> ''
>>
>> The specific problem that I encountered was when swapping an IntEnum 
>> implementation for ints in http.client, which caused a change in logging 
>> output (from int.__str__ to Enum.__str__) , which was a bit of a surprise, 
>> especially given the value is a builtin type.
>>
>> I think that a decent rule around the usage of __str__ is that it should be 
>> a string representation of the value, not of the object. Failing the ability 
>> to logically coerce the value to a string, it should simply fall back to 
>> repr(obj).
>>
>> Of course, I realize that the chances of this change being made to such a 
>> fundamental (and largely inconsequential) feature are likely nil, but I 
>> thought I’d share my thoughts anyways.
>
> >>> foo = object()
> >>> str(foo)
> ''
> >>> repr(foo)
> ''
>
> This is exactly what you see above. ;)
>
> Florian
>
> --
> http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>  I love long mails! | http://email.is-not-s.ms/

There's a semantic difference between an int and an IntEnum (or
subclass thereof). MyEnum.FOO is a MyEnum type. IntEnums just happen
to behave like an int under certain circumstances. That doesn't mean
it needs to act like it in all. Further, it can be turned into an int
if you want to represent it as an int, e.g., str(int(MyEnum.FOO)) ==
str(1). I hope this helps.
___
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] Any volunteers to implement PEP 479?

[Chris Angelico]

On Wed, Jan 7, 2015 at 2:48 PM, Guido van Rossum  wrote:
> There's a proof of concept patch in http://bugs.python.org/issue22906, but
> it doesn't have the __future__ import and probably gets other details wrong.
>
> Reference:
> PEP 479 -- Change StopIteration handling inside generators
>
> --
> --Guido van Rossum (python.org/~guido)

For the benefit of people who haven't been following the tracker
issue: There is now a patch which *does* create the __future__
directive and so on. It applies cleanly to current tip (I just tested
it again today), and the test suite passes on Debian AMD64. Can other
people please try this, on other platforms, and see how it goes?

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

[Python-Dev] [X-POST] GSoC 2015 ideas

[Kushal Das]

Hi all,

In case anyone wants to mentor a student for GSoC 2015, or have an
idea on which students can work on during GSoC, please start putting
them up in [1]. I am yet to get the edit access, I will put up the
initial template text there. You can even send the idea as a reply to
this thread. The template for the ideas is given below:


==  Project name ==
 * '''Project description''':  Make sure you have a high-level
description that any student can understand, as well as deeper details
 * '''Skills''': programming languages? specific domain knowledge?
 * '''Difficulty level''': Easy/Intermediate/Hard classification
(students ask for this info frequently to help them narrow down their
choices)
 * '''Related Readings/Links''':  was there a mailing list discussion
about this topic?  standards you want the students to read first?
bugs/feature requests?
 * '''Potential mentors''': A list of mentors likely to be involved
with this project, so students know who to look for on IRC/mailing
lists if they have questions.  (If you've had trouble with students
overwhelming specific mentors, feel free to re-iterate here if
students should contact the mailing list to reach all mentors.)


[1] https://wiki.python.org/moin/SummerOfCode/2015/python-core

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
Director Python Software Foundation
http://kushaldas.in
___
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