Re: [Python-Dev] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

On 22.02.15 01:26, Steve Dower wrote: Thanks! Fixed now. Clinic removes the declaration of _Py_time_t_to_FILE_TIME. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.pyth

Re: [Python-Dev] Generate all Argument Clinic code into separate files

On 22 February 2015 at 06:58, Brett Cannon wrote: > > > On Sat Feb 21 2015 at 1:50:32 PM Serhiy Storchaka > wrote: >> >> Currently for some files converted to use Argument Clinic the generated >> code is written into a separate file, for other files it is inlined. >> >> I'm going to make a number

Re: [Python-Dev] Enum is really serializable using json?

On 22 February 2015 at 05:10, Facundo Batista wrote: > On Sat, Feb 21, 2015 at 3:50 PM, Benjamin Peterson > wrote: > >>> Am I failing to understand the bug tracker saying the patch was >>> applied for Py3.4? >> >> As the issue title suggests, IntEnum but not Enum supports JSON >> serialization.

Re: [Python-Dev] TypeError messages

On 21/02/2015 21:39, MRAB wrote: On 2015-02-21 17:14, Antoine Pitrou wrote: On Fri, 20 Feb 2015 14:05:11 + Brett Cannon wrote: 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 >

Re: [Python-Dev] TypeError messages

On 21/02/2015 15:57, R. David Murray wrote: On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan wrote: On 21 February 2015 at 00:05, Brett Cannon wrote: I agree that type names don't need to be quoted. As a user, I actually appreciate the quotes, because they make the error pattern easier fo

Re: [Python-Dev] TypeError messages

On 21/02/2015 17:14, Antoine Pitrou wrote: On Fri, 20 Feb 2015 14:05:11 + Brett Cannon wrote: 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,

Re: [Python-Dev] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

Thanks! Fixed now. Cheers, Steve Top-posted from my Windows Phone From: Serhiy Storchaka Sent: ‎2/‎21/‎2015 14:14 To: python-dev@python.org Subject: Re: [Python-Dev] cpython: Issue #23152: Renames attribute

Re: [Python-Dev] [Python-checkins] cpython: Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on

Agreed. I've made both of these changes. Thanks for the suggestions Cheers, Steve Top-posted from my Windows Phone From: Brett Cannon Sent: ‎2/‎21/‎2015 14:13 To: Ben Hoyt; Python-Dev

Re: [Python-Dev] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

On 21.02.15 20:04, steve.dower wrote: https://hg.python.org/cpython/rev/307713759a62 changeset: 94720:307713759a62 parent: 94718:4f6f4aa0d80f user:Steve Dower date:Sat Feb 21 10:04:10 2015 -0800 summary: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data

Re: [Python-Dev] [Python-checkins] cpython: Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on

On Sat Feb 21 2015 at 4:23:16 PM Ben Hoyt wrote: > When merging some changes while working on scandir, I noticed a minor > issue with this commit: > > https://hg.python.org/cpython/rev/4f6f4aa0d80f > > The definition of "struct win32_stat" has been moved to fileutils.h and > renamed to "struct _P

Re: [Python-Dev] TypeError messages

On Sat, 21 Feb 2015 21:39:32 + MRAB wrote: > On 2015-02-21 17:14, Antoine Pitrou wrote: > > On Fri, 20 Feb 2015 14:05:11 + > > Brett Cannon wrote: > >> On Thu Feb 19 2015 at 5:52:07 PM Serhiy Storchaka > >> wrote: > >> > >> > Different patterns for TypeError messages are used in the std

Re: [Python-Dev] TypeError messages

On 2015-02-21 17:14, Antoine Pitrou wrote: On Fri, 20 Feb 2015 14:05:11 + Brett Cannon wrote: 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 > expecte

[Python-Dev] [Python-checkins] cpython: Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on

When merging some changes while working on scandir, I noticed a minor issue with this commit: https://hg.python.org/cpython/rev/4f6f4aa0d80f The definition of "struct win32_stat" has been moved to fileutils.h and renamed to "struct _Py_stat_struct", which is fine -- however, the old "struct win32

Re: [Python-Dev] Generate all Argument Clinic code into separate files

On Sat Feb 21 2015 at 1:50:32 PM Serhiy Storchaka wrote: > Currently for some files converted to use Argument Clinic the generated > code is written into a separate file, for other files it is inlined. > > I'm going to make a number of small enhancement to Argument Clinic to > generate faster cod

Re: [Python-Dev] TypeError messages

On Sat Feb 21 2015 at 12:15:25 PM Antoine Pitrou wrote: > On Fri, 20 Feb 2015 14:05:11 + > Brett Cannon wrote: > > 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 >

Re: [Python-Dev] Prefixes and namespaces

On Sat, 21 Feb 2015 21:28:21 +0200 Serhiy Storchaka wrote: > /* Namespaces are one honking great idea -- let's do more of those! */ > > There are two ways to avoid name conflicts: prefixes and namespaces. > Programming languages that lacks namespaces (such as C) need to use > prefixes. For exa

Re: [Python-Dev] Prefixes and namespaces

On 21.02.15 21:49, Ian Cordasco wrote: So I like the latter (Protocol.SSLv2) but would qualify that with the request that ssl.PROTOCOL_SSLv2 continue to work until Python 2 is dead and libraries like requests, urllib3, httplib2, etc. no longer need to support those versions. Of course, ssl.PROT

Re: [Python-Dev] Prefixes and namespaces

On 02/21/2015 11:49 AM, Ian Cordasco wrote: > On Sat, Feb 21, 2015 at 1:28 PM, Serhiy Storchaka wrote: >> ? Protocol.PROTOCOL_SSLv2 or Protocol.SSLv2 ? > > So I like the latter (Protocol.SSLv2) but would qualify that with the > request that ssl.PROTOCOL_SSLv2 continue to work until Python 2 is >

Re: [Python-Dev] Prefixes and namespaces

On Sat, Feb 21, 2015 at 1:28 PM, Serhiy Storchaka wrote: > /* Namespaces are one honking great idea -- let's do more of those! */ > > There are two ways to avoid name conflicts: prefixes and namespaces. > Programming languages that lacks namespaces (such as C) need to use > prefixes. For example:

[Python-Dev] Prefixes and namespaces

/* Namespaces are one honking great idea -- let's do more of those! */ There are two ways to avoid name conflicts: prefixes and namespaces. Programming languages that lacks namespaces (such as C) need to use prefixes. For example: PROTOCOL_SSLv2, PROTOCOL_SSLv3, PROTOCOL_SSLv23. Python used th

Re: [Python-Dev] Enum is really serializable using json?

On Sat, Feb 21, 2015 at 3:50 PM, Benjamin Peterson wrote: >> Am I failing to understand the bug tracker saying the patch was >> applied for Py3.4? > > As the issue title suggests, IntEnum but not Enum supports JSON > serialization. Arghhh.. stupid of me. Sorry for the noise, and thanks! -- .

Re: [Python-Dev] Enum is really serializable using json?

On Sat, Feb 21, 2015, at 13:48, Facundo Batista wrote: > We have this issue closed as resolved: > > http://bugs.python.org/issue18264 > > It's called "enum.IntEnum is not compatible with JSON serialisation", > and it looks that after a long conversation they added proper support > for it in P

[Python-Dev] Generate all Argument Clinic code into separate files

Currently for some files converted to use Argument Clinic the generated code is written into a separate file, for other files it is inlined. I'm going to make a number of small enhancement to Argument Clinic to generate faster code for parsing arguments (see for example issue23492). Every such

[Python-Dev] Enum is really serializable using json?

We have this issue closed as resolved: http://bugs.python.org/issue18264 It's called "enum.IntEnum is not compatible with JSON serialisation", and it looks that after a long conversation they added proper support for it in Py3.4. However, this is still failing: Python 3.4.2 (default, Oct 8 2

Re: [Python-Dev] TypeError messages

Le 21 févr. 2015 15:27, "Nick Coghlan" a écrit : > int expected, but found str > float expected, but found int > > 'int' expected, but found 'str' > 'float' expected, but found 'int' I would prefer quotes with the word type: 'float' type expected, but got 'int' type Or no quotes

Re: [Python-Dev] TypeError messages

On Fri, 20 Feb 2015 14:05:11 + Brett Cannon wrote: > 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 > > expe

Re: [Python-Dev] TypeError messages

On Sat, 21 Feb 2015 10:57:49 -0500 "R. David Murray" wrote: > On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan wrote: > > On 21 February 2015 at 00:05, Brett Cannon wrote: > > > I agree that type names don't need to be quoted. > > > > As a user, I actually appreciate the quotes, because they m

Re: [Python-Dev] str(IntEnum)

> > On Feb 20, 2015, at 7:03 PM, Ian Cordasco wrote: > I hope this helps. It does, as do the other replies, thanks all. To be clear, my first gripe has stemmed into two related (but very minor) problems: 1. IntEnum.__str__. I understand the reasoning behind the current implementation. Persona

Re: [Python-Dev] TypeError messages

Serhiy Storchaka schrieb am 21.02.2015 um 16:35: > I'm going to change standard messages in PyArg_Parse* > and common converting functions (as PyLong_AsLong and PyObject_GetBuffer) > to make them uniform. *sigh* - and along came another heap of doctest adaptations... Stefan

Re: [Python-Dev] TypeError messages

On Sun, 22 Feb 2015 00:26:23 +1000, Nick Coghlan wrote: > On 21 February 2015 at 00:05, Brett Cannon wrote: > > I agree that type names don't need to be quoted. > > As a user, I actually appreciate the quotes, because they make the > error pattern easier for me to parse. Compare: > > int e

Re: [Python-Dev] TypeError messages

On 21.02.15 16:26, Nick Coghlan wrote: Likewise, although as Rob noted, it's sometimes to desirable to use the "Z should be X, not Y" form if the shorter form would be ambiguous. Z is not always available. Perhaps this should be a recommendation in both PEP 7 & 8? It's exactly the kind of iss

Re: [Python-Dev] TypeError messages

On 21.02.15 10:03, Guido van Rossum wrote: IIRC there's a limited buffer used for the formatting. For now formatting buffer is not limited. But other arguments are valid. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailm

Re: [Python-Dev] TypeError messages

On 20.02.15 18:11, Eric V. Smith wrote: 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 po

Re: [Python-Dev] TypeError messages

On 20.02.15 01:57, MRAB wrote: Messages tend not to be complete sentences anyway, so I think that it would be fitting to omit articles. Thanks. This post was aroused by your note about articles on the tracker. ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] TypeError messages

On 21 February 2015 at 00:05, Brett Cannon wrote: > > > 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

Re: [Python-Dev] Update to PEP 11 to clarify garnering platform support

On 21 February 2015 at 04:47, Brett Cannon wrote: > I just realized I actually never committed this change. Assuming no new > objections I'll commit this in the near future (promise this time =). Looks good to me :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Austra

Re: [Python-Dev] Idea: __length_hint__ wrapper in itertools

On 20 February 2015 at 03:15, Carlos Pita wrote: > 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, b

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On 19 February 2015 at 07:16, Paul Moore wrote: > On 18 February 2015 at 20:48, Jim J. Jewett wrote: >> Barry Warsaw wrote: I don't know exactly what the procedure would be to claim .pyz for *nix, e.g. updating /etc/mime.types, but I think the PEP should at least mention this. I t

[Python-Dev] Request for Pronouncement: PEP 486 - Make the Python Launcher aware of virtual environments

The discussion on PEP 486 (started at https://mail.python.org/pipermail/python-dev/2015-February/138171.html, following from the thread at https://mail.python.org/pipermail/python-dev/2015-February/138160.html) seems to have died down. There's an implementation at http://bugs.python.org/issue23465.

Re: [Python-Dev] TypeError messages

IIRC there's a limited buffer used for the formatting. Also, if a dynamically created type name is 100 characters long I'd rather see it truncated than blow up my shell window. On Friday, February 20, 2015, Eric V. Smith wrote: > On 02/20/2015 09:05 AM, Brett Cannon wrote: > > Some messa