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

[Serhiy Storchaka]

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.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 of small enhancement to Argument Clinic to
>> generate faster code for parsing arguments (see for example issue23492).
>> Every such step will produce large diffs for
>> generated code and will create code churn if it is inlined and mixed up
>> with handwritten code. It would be better when only generated files will
>> be changed. So I suggest to move all inlined generated code in separate
>> file. What are you think?
>
>
> +1 to moving to a separate file for all .c files. Might be painful now but
> the long-terms benefits are worth it.

Yeah, agreed. Originally I was a fan of having everything inline so I
could see them while I was working on the code, but I eventually
changed my mind to favour making it a clearer build step with a
separate generated file. I suspect it was a matter of starting to
trust AC to do the right thing, so having it implicitly asking me to
check its work all the time ultimately become annoying rather than
reassuring :)

I assume some parts, like the header for the implementation function,
will always need to be generated inline in the hand-edited
implementation file, though.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Enum is really serializable using json?

[Nick Coghlan]

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.
>
> Arghhh.. stupid of me. Sorry for the noise, and thanks!

I don't know if we actually clearly explain anywhere why that's the
case, though. As I see it, the core problem is that when mapping an
Enum to JSON, you may either do it by name (so it becomes a string on
the JSON side) or by value (so you lose the fact that it's an enum,
but can work with protocols that use integers rather than strings).

There's no "right" answer in general as to which of those is correct -
the one you want will depend on exactly what protocols you're working
with. By contrast, for IntEnum, we want that to be an
as-close-to-drop-in-as-is-feasible replacement for existing ints, so
there's a clear correct answer: we need to serialise it to JSON as an
integer, and lose the additional enum details.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Rob Cliffe]

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


If we are busy nitpicking, why are we saying "found Y"? Nothing was
*found* by the callee, it just *got* an argument.


Well, it depends on the reason for the message.

If you're passing an argument, then 'found' is the wrong word, but if
you're parsing, say, a regex, then 'got' is the wrong word.


So it should be "expected X, but got Y".

Personally, I think the "but" is superfluous: the contradiction is
already implied, so "expected X, got Y" is terser and conveys the
meaning just as well.


If you wanted a message to cover both argument-passing and parsing,
then "expected Y, not Y" would do.

Assuming you meant "expected Y, not X":
+1
Perhaps better than all other suggestions so far.

___
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

[Rob Cliffe]

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 for me to parse. Compare:

 int expected, but found str
 float expected, but found int

 'int' expected, but found 'str'
 'float' expected, but found 'int'

It's not a big deal to me either way, but I find the version with the
quotes makes me think it is looking for the literal string 'int', but
found the literal string 'str', whereas in the first case it seems
clear it is looking for objects of that type.  Perhaps this is just
because I am used to the existing messages, but I think it goes
beyond that.



+1.  FWIW, I feel the same as David (and Antoine).
Rob Cliffe
___
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

[Rob Cliffe]

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, 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".

If we are busy nitpicking, why are we saying "found Y"? Nothing was
*found* by the callee, it just *got* an argument.

So it should be "expected X, but got Y".

Personally, I think the "but" is superfluous: the contradiction is
already implied, so "expected X, got Y" is terser and conveys the
meaning just as well.

Regards

Antoine.

+1
Rob Cliffe
___
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] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

[Steve Dower]

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

What about time_t_to_FILE_TIME?


___
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%40microsoft.com
___
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] [Python-checkins] cpython: Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on

[Steve Dower]

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
Subject: 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 
mailto:benh...@gmail.com>> 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 _Py_stat_struct", which is fine -- however, the old "struct 
win32_stat" definition is still present (but unused) in posixmodule.c.

So I think the old "struct win32_stat { ... }" definition can simply be removed 
from posixmodule.c now.

I don't think win32_stat is part of the stable ABI so as long as everything 
keeps working then I don't see why it needs to stick around.


Also, unrelated to this commit, I notice the _Py_attribute_data_to_stat 
function (was attribute_data_to_stat) can't fail and always returns 0, and all 
callers ignore its return value anyway. Can it be changed to return void?

Don't see why not since it's a private API.
___
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] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

[Serhiy Storchaka]

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_to_stat


What about time_t_to_FILE_TIME?


___
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] [Python-checkins] cpython: Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on

[Brett Cannon]

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 _Py_stat_struct", which is fine -- however, the old
> "struct win32_stat" definition is still present (but unused) in
> posixmodule.c.
>
> So I think the old "struct win32_stat { ... }" definition can simply be
> removed from posixmodule.c now.
>

I don't think win32_stat is part of the stable ABI so as long as everything
keeps working then I don't see why it needs to stick around.


>
> Also, unrelated to this commit, I notice the _Py_attribute_data_to_stat
> function (was attribute_data_to_stat) can't fail and always returns 0, and
> all callers ignore its return value anyway. Can it be changed to return
> void?
>

Don't see why not since it's a private API.
___
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

[Antoine Pitrou]

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 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".
> >
> > If we are busy nitpicking, why are we saying "found Y"? Nothing was
> > *found* by the callee, it just *got* an argument.
> >
> Well, it depends on the reason for the message.
> 
> If you're passing an argument, then 'found' is the wrong word, but if
> you're parsing, say, a regex, then 'got' is the wrong word.

I don't think parsing would raise a TypeError, would it?

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

[MRAB]

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


If we are busy nitpicking, why are we saying "found Y"? Nothing was
*found* by the callee, it just *got* an argument.


Well, it depends on the reason for the message.

If you're passing an argument, then 'found' is the wrong word, but if
you're parsing, say, a regex, then 'got' is the wrong word.


So it should be "expected X, but got Y".

Personally, I think the "but" is superfluous: the contradiction is
already implied, so "expected X, got Y" is terser and conveys the
meaning just as well.


If you wanted a message to cover both argument-passing and parsing,
then "expected Y, not Y" would do.

___
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] [Python-checkins] cpython: Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on

[Ben Hoyt]

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_stat" definition is still present (but unused) in
posixmodule.c.

So I think the old "struct win32_stat { ... }" definition can simply be
removed from posixmodule.c now.

Also, unrelated to this commit, I notice the _Py_attribute_data_to_stat
function (was attribute_data_to_stat) can't fail and always returns 0, and
all callers ignore its return value anyway. Can it be changed to return
void?

-Ben
___
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] Generate all Argument Clinic code into separate files

[Brett Cannon]

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 code for parsing arguments (see for example issue23492).
> Every such step will produce large diffs for
> generated code and will create code churn if it is inlined and mixed up
> with handwritten code. It would be better when only generated files will
> be changed. So I suggest to move all inlined generated code in separate
> file. What are you think?
>

+1 to moving to a separate file for all .c files. Might be painful now but
the long-terms benefits are worth it.
___
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 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
> > >  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".
>
> If we are busy nitpicking, why are we saying "found Y"? Nothing was
> *found* by the callee, it just *got* an argument.
>
> So it should be "expected X, but got Y".
>
> Personally, I think the "but" is superfluous: the contradiction is
> already implied, so "expected X, got Y" is terser and conveys the
> meaning just as well.
>

I'm also fine with the terser version.

-Brett
___
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] Prefixes and namespaces

[Antoine Pitrou]

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 example: PROTOCOL_SSLv2, PROTOCOL_SSLv3, PROTOCOL_SSLv23. 
> Python used the same prefixed names when reflect C constants to module 
> level Python globals.

Python still uses the names, and they are still globals. There's no
reason to change that. The enum is simply there to improve debugging
when printing the values.

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] Prefixes and namespaces

[Serhiy Storchaka]

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.PROTOCOL_SSLv2 will continue to work until Python 2.7 and 
3.4 are dead.


___
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] Prefixes and namespaces

[Ethan Furman]

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
> dead and libraries like requests, urllib3, httplib2, etc. no longer
> need to support those versions.

Good idea, and easy enough to do since Enum supports aliases.

--
~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] Prefixes and namespaces

[Ian Cordasco]

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: PROTOCOL_SSLv2, PROTOCOL_SSLv3, PROTOCOL_SSLv23.
> Python used the same prefixed names when reflect C constants to module level
> Python globals. But when convert integer constants to IntEnum, is it needed
> to preserve common prefix? Or may be we can drop it, because enum class name
> plays its role?
>
> class Protocol(IntEnum):
> PROTOCOL_SSLv2 = ...
> PROTOCOL_SSLv3 = ...
> PROTOCOL_SSLv23 = ...
>
> or
>
> class Protocol(IntEnum):
> SSLv2 = ...
> SSLv3 = ...
> SSLv23 = ...
>
> ? 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
dead and libraries like requests, urllib3, httplib2, etc. no longer
need to support those versions.
___
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] Prefixes and namespaces

[Serhiy Storchaka]

/* 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 the same prefixed names when reflect C constants to module 
level Python globals. But when convert integer constants to IntEnum, is 
it needed to preserve common prefix? Or may be we can drop it, because 
enum class name plays its role?


class Protocol(IntEnum):
PROTOCOL_SSLv2 = ...
PROTOCOL_SSLv3 = ...
PROTOCOL_SSLv23 = ...

or

class Protocol(IntEnum):
SSLv2 = ...
SSLv3 = ...
SSLv23 = ...

? Protocol.PROTOCOL_SSLv2 or Protocol.SSLv2?

___
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] Enum is really serializable using json?

[Facundo Batista]

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!

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
___
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] Enum is really serializable using json?

[Benjamin Peterson]

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 Py3.4.
> 
> However, this is still failing:
> 
> Python 3.4.2 (default, Oct  8 2014, 13:18:07)
> [GCC 4.9.1] on linux
> >>> import enum, json
> >>> Foo = enum.Enum('Foo', 'bar baz')
> >>> json.dumps(Foo.bar)
> Traceback (most recent call last):
> ...
> TypeError:  is not JSON serializable
> 
> 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.
___
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] Generate all Argument Clinic code into separate files

[Serhiy Storchaka]

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 step will produce large diffs for
generated code and will create code churn if it is inlined and mixed up 
with handwritten code. It would be better when only generated files will 
be changed. So I suggest to move all inlined generated code in separate 
file. What are you think?


___
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] Enum is really serializable using json?

[Facundo Batista]

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 2014, 13:18:07)
[GCC 4.9.1] on linux
>>> import enum, json
>>> Foo = enum.Enum('Foo', 'bar baz')
>>> json.dumps(Foo.bar)
Traceback (most recent call last):
...
TypeError:  is not JSON serializable

Am I failing to understand the bug tracker saying the patch was
applied for Py3.4?

(thought it was more polite to ask here than to reopen the whole
thread in the issue tracker)

Thanks!

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
___
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

[Victor Stinner]

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.

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

[Antoine Pitrou]

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

If we are busy nitpicking, why are we saying "found Y"? Nothing was
*found* by the callee, it just *got* an argument.

So it should be "expected X, but got Y".

Personally, I think the "but" is superfluous: the contradiction is
already implied, so "expected X, got Y" is terser and conveys the
meaning just as well.

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

[Antoine Pitrou]

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 make the
> > error pattern easier for me to parse. Compare:
> > 
> > int expected, but found str
> > float expected, but found int
> > 
> > 'int' expected, but found 'str'
> > 'float' expected, but found 'int'
> 
> It's not a big deal to me either way, but I find the version with the
> quotes makes me think it is looking for the literal string 'int', but
> found the literal string 'str', whereas in the first case it seems
> clear it is looking for objects of that type.  Perhaps this is just
> because I am used to the existing messages, but I think it goes
> beyond that.

Agreed.

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

[Demian Brecht]

> 
> 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. Personally I’d still prefer it to be consistent with int (and 
other types as shown above) and if I wanted to know where it came from, I could 
use repr(), but I understand that this /was/ previously thought out and is 
contrary to the decision made. I’m fine with being in the minority (or on my 
own as it seems in this case) and leaving it alone (with the only caveat being 
the next point).

2. Consistency of __str__ semantics across the standard library and builtins. I 
believe that the value of __str__ is something that I, as a user, should be 
able to infer when using disparate types. Unfortunately, some represent the 
values while other represent the object themselves, nearly the same problem 
that __repr__ solves minus the requirement of being a valid Python expression 
where possible. In my mind, a clear separation between __str__ representing the 
value of an instance and __repr__ representing the object, or where the value 
came from (and perhaps /not/ having the auto-fallback) makes sense, but would 
only be one potential solution to promoting consistency.

In any event, there are many larger problems to be solved (that is, if anyone 
else /does/ consider this a problem) and I very well may be on my own with this 
thinking.


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

[Stefan Behnel]

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


___
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

[R. David Murray]

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 expected, but found str
> float expected, but found int
> 
> 'int' expected, but found 'str'
> 'float' expected, but found 'int'

It's not a big deal to me either way, but I find the version with the
quotes makes me think it is looking for the literal string 'int', but
found the literal string 'str', whereas in the first case it seems
clear it is looking for objects of that type.  Perhaps this is just
because I am used to the existing messages, but I think it goes
beyond that.

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

[Serhiy Storchaka]

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 issue where having a recommended way to do it can
save a fair bit of time considering the exact phrasing of error
messages, as well as improving the developer experience by providing
more consistent feedback on error details.


It would be great. I'm going to change standard messages in PyArg_Parse* 
and common converting functions (as PyLong_AsLong and 
PyObject_GetBuffer) to make them uniform.



___
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

[Serhiy Storchaka]

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/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TypeError messages

[Serhiy Storchaka]

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 pointing to reused memory it
could be useful.


Thank you. This makes sense and explains why type names are not 
truncated in Python code.


___
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

[Serhiy Storchaka]

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

[Nick Coghlan]

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

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.

Perhaps this should be a recommendation in both PEP 7 & 8? It's
exactly the kind of issue where having a recommended way to do it can
save a fair bit of time considering the exact phrasing of error
messages, as well as improving the developer experience by providing
more consistent feedback on error details.

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

This is C, assuming strings are correctly NULL terminated is almost
always a recipe for future disaster :)

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

Assuming the "newer" was intended to be "never", yes, that's due to
the main concern being with not blowing up in the face of missing
terminating NULLs in purported C strings. That concern doesn't exist
at the Python level.

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

As a user, I actually appreciate the quotes, because they make the
error pattern easier for me to parse. Compare:

int expected, but found str
float expected, but found int

'int' expected, but found 'str'
'float' expected, but found 'int'

The variable information in this pattern (i.e. the types) gets
highlighted visually in the second version, as it's in the sections
surrounded by single quotes. For me, that helps the structural
scaffolding (the "expected, but found" part) to fade more readily into
the background as a familiar piece of text that primes my pattern
recognition, but doesn't change much across different error messages.

Regards,
Nick.

>
> ___
> 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/ncoghlan%40gmail.com
>



-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Nick Coghlan]

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, Australia
___
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] Idea: __length_hint__ wrapper in itertools

[Nick Coghlan]

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

Seamless wrappers for arbitrary types are actually fairly tricky to
implement, but Graham Dumpleton's wrapt library hides most of those
messy details: https://pypi.python.org/pypi/wrapt

A pure iterator-only wrapper would be a fair bit easier to implement,
but it's not clear it's worth it for cases like this where data
processing and memory reallocation time dominates your runtime costs
sufficiently for __length_hint__ to make a big difference. Writing
your own wrapper using a generic wrapper library like wrapt may be a
better choice (and has the advantage of working today rather than only
in 3.5+)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] PEP 441 - Improving Python ZIP Application Support

[Nick Coghlan]

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 think we want to get as official support for .pyz files on *nix as
 possible.
>>
>> Paul Moore wrote:
>>> I'll add a note to the PEP, but I have no idea how we would even go
>>> about that, so that's all I can do, unfortunately.
>>
>> Are you just looking for
>>
>> http://www.iana.org/assignments/media-types/media-types.xhtml
>>
>> and its references, including the registration procedures
>>
>> http://tools.ietf.org/html/rfc6838#section-4.2.5
>>
>> and the application form at
>>
>> http://www.iana.org/form/media-types
>>
>> ?
>
> That covers mime types, but not file extensions, so it's not really
> what *I* thought Barry was talking about.

FWIW, registering the vnd.python MIME prefix with IANA has been
vaguely kicking around on my todo list since we switched the PyPA
metadata PEPs over to using JSON. If anyone did decide to follow up on
that idea, the PSF Infrastructure working group mailing list would
likely be a suitable contact address to use (Infra already handles
relationships with other internet registries for DNS et al, and I
can't think of another group better suited to the task).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Request for Pronouncement: PEP 486 - Make the Python Launcher aware of virtual environments

[Paul Moore]

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.

So, I think this is ready for pronouncement.

Thanks,
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] TypeError messages

[Guido van Rossum]

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 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/guido%40python.org
>


-- 
--Guido van Rossum (on iPad)
___
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