Re: [Python-Dev] Revisiting old enhancement requests

[Terry Reedy]

On 12/20/2017 12:36 AM, Steven D'Aprano wrote:

What is the best practice for revisiting old enhancement requests on the
tracker, if I believe that the time is right to revisit a rejected issue
from many years ago? (Nearly a decade.)


I have been thinking about the opposite: revisit old enhancement 
requests that have been open for a decade that I thing have no change 
ever and should be closed.



Should I raise a new enhancement request and link back to the old one,
or re-open the original?


I think the answer for both is to consider posting on python-ideas.

--
Terry Jan Reedy

___
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] Revisiting old enhancement requests

[Steven D'Aprano]

What is the best practice for revisiting old enhancement requests on the 
tracker, if I believe that the time is right to revisit a rejected issue 
from many years ago? (Nearly a decade.)

Should I raise a new enhancement request and link back to the old one, 
or re-open the original?


Thanks,



-- 
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] Guarantee ordered dict literals in v3.7?

[Glenn Linderman]

On 12/19/2017 5:32 PM, Nathaniel Smith wrote:

On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower  wrote:

On 19Dec2017 1004, Chris Barker wrote:

Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to
return the same dict -- so documented behavior may already be broken.


Two relevant quotes from the pprint module docs:


The pprint module provides a capability to “pretty-print” arbitrary
Python data structures in a form which can be used as input to the
interpreter
Dictionaries are sorted by key before the display is computed.

It says nothing about the resulting dict being the same as the original one,
just that it can be used as input. So these are both still true (until
someone deliberately breaks the latter).

This is a pretty fine hair to be splitting... I'm sure you wouldn't
argue that it would be valid to display the dict {"a": 1} as
'["hello"]', just because '["hello"]' is a valid input to the
interpreter (that happens to produce a different object than the
original one) :-). I think we can assume that pprint's output is
supposed to let you reconstruct the original data structures, at least
in simple cases, even if that isn't explicitly stated.


Any dict object read in from pprint is going to be a different object, 
not the original one. And, unless the original insertion order was 
sorted by the same key as pprint uses to sort, the iteration order will 
be different from the original.


As pointed out below, it will compare equal to the original dict.

pprint has always allowed you to reconstruct the original data 
structures, but not the iteration order of dicts.


With the new insertion order guarantee, nothing has changed, here.

A far more interesting question than what pprint does to dict order is 
what marshal and pickle do (and have done) with the dict order, although 
I can't figure that out from the documentation.





In any case, there are so many ways
to spoil the first point for yourself that it's hardly worth treating as an
important constraint.

I guess the underlying issue here is partly the question of what the
pprint module is for. In my understanding, it's primarily a tool for
debugging/introspecting Python programs, and the reason it talks about
"valid input to the interpreter" isn't because we want anyone to
actually feed the data back into the interpreter, but to emphasize
that it provides an accurate what-you-see-is-what's-really-there view
into how the interpreter understands a given object. It also
emphasizes that this is not intended for display to end users; making
the output format be "Python code" suggests that the main intended
audience is people who know how to read, well, Python code, and
therefore can be expected to care about Python's semantics.


(though I assume order is still ignored when comparing dicts, so:
eval(pprint(a_dict)) == a_dict will still hold.


Order had better be ignored when comparing dicts, or plenty of code will
break. For example:


{'a': 1, 'b': 2} == {'b': 2, 'a': 1}

True

Yes, this is never going to change -- I expect that in the long run,
the only semantic difference between dict and OrderedDict will be in
their __eq__ methods.


Saying that "iter(dict)" will produce keys in the same order as they were
inserted is not the same as saying that "dict" is an ordered mapping. As far
as I understand, we've only said the first part.

(And the "nerve" here is that I disagreed with even the first part, but
didn't fight it too strongly because I never relied on the iteration order
of dict. However, I *do* rely on nobody else relying on the iteration order
of dict either, and so proposals to change existing semantics that were
previously independent of insertion order to make them rely on insertion
order will affect me. So now I'm pushing back.)

I mean, I don't want to be a jerk about this, and we still need to
examine things on a case-by-case basis but... Guido has pronounced
that Python dict preserves order. If your code "rel[ies] on nobody
else relying on the iteration order", then starting in 3.7 your code
is no longer Python.

Obviously I like that change more than you, but to some extent it's
just something we have to live with, and even if I disagreed with the
new semantics I'd still rather the standard library handle them
consistently rather than being half-one-thing-and-half-another.

-n



___
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] Guarantee ordered dict literals in v3.7?

[Barry Warsaw]

On Dec 19, 2017, at 20:32, Nathaniel Smith  wrote:

> I guess the underlying issue here is partly the question of what the
> pprint module is for. In my understanding, it's primarily a tool for
> debugging/introspecting Python programs, and the reason it talks about
> "valid input to the interpreter" isn't because we want anyone to
> actually feed the data back into the interpreter, but to emphasize
> that it provides an accurate what-you-see-is-what's-really-there view
> into how the interpreter understands a given object. It also
> emphasizes that this is not intended for display to end users; making
> the output format be "Python code" suggests that the main intended
> audience is people who know how to read, well, Python code, and
> therefore can be expected to care about Python's semantics.

pprint.pprint() is indeed mostly for debugging, but not always.  As an example 
of what will break if you change the sorting guarantee: in Mailman 3 the REST 
etag is calculated from the pprint.pformat() of the result dictionary before 
it’s JSON-ified.  If the order is changed, then it’s possible a client will 
have an incorrect etag for a structure that is effectively the same.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Guarantee ordered dict literals in v3.7?

[Nathaniel Smith]

On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower  wrote:
> On 19Dec2017 1004, Chris Barker wrote:
>>
>> Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to
>> return the same dict -- so documented behavior may already be broken.
>
>
> Two relevant quotes from the pprint module docs:
>
 The pprint module provides a capability to “pretty-print” arbitrary
 Python data structures in a form which can be used as input to the
 interpreter
>
 Dictionaries are sorted by key before the display is computed.
>
> It says nothing about the resulting dict being the same as the original one,
> just that it can be used as input. So these are both still true (until
> someone deliberately breaks the latter).

This is a pretty fine hair to be splitting... I'm sure you wouldn't
argue that it would be valid to display the dict {"a": 1} as
'["hello"]', just because '["hello"]' is a valid input to the
interpreter (that happens to produce a different object than the
original one) :-). I think we can assume that pprint's output is
supposed to let you reconstruct the original data structures, at least
in simple cases, even if that isn't explicitly stated.

> In any case, there are so many ways
> to spoil the first point for yourself that it's hardly worth treating as an
> important constraint.

I guess the underlying issue here is partly the question of what the
pprint module is for. In my understanding, it's primarily a tool for
debugging/introspecting Python programs, and the reason it talks about
"valid input to the interpreter" isn't because we want anyone to
actually feed the data back into the interpreter, but to emphasize
that it provides an accurate what-you-see-is-what's-really-there view
into how the interpreter understands a given object. It also
emphasizes that this is not intended for display to end users; making
the output format be "Python code" suggests that the main intended
audience is people who know how to read, well, Python code, and
therefore can be expected to care about Python's semantics.

>> (though I assume order is still ignored when comparing dicts, so:
>> eval(pprint(a_dict)) == a_dict will still hold.
>
>
> Order had better be ignored when comparing dicts, or plenty of code will
> break. For example:
>
 {'a': 1, 'b': 2} == {'b': 2, 'a': 1}
> True

Yes, this is never going to change -- I expect that in the long run,
the only semantic difference between dict and OrderedDict will be in
their __eq__ methods.

> Saying that "iter(dict)" will produce keys in the same order as they were
> inserted is not the same as saying that "dict" is an ordered mapping. As far
> as I understand, we've only said the first part.
>
> (And the "nerve" here is that I disagreed with even the first part, but
> didn't fight it too strongly because I never relied on the iteration order
> of dict. However, I *do* rely on nobody else relying on the iteration order
> of dict either, and so proposals to change existing semantics that were
> previously independent of insertion order to make them rely on insertion
> order will affect me. So now I'm pushing back.)

I mean, I don't want to be a jerk about this, and we still need to
examine things on a case-by-case basis but... Guido has pronounced
that Python dict preserves order. If your code "rel[ies] on nobody
else relying on the iteration order", then starting in 3.7 your code
is no longer Python.

Obviously I like that change more than you, but to some extent it's
just something we have to live with, and even if I disagreed with the
new semantics I'd still rather the standard library handle them
consistently rather than being half-one-thing-and-half-another.

-n

-- 
Nathaniel J. Smith -- https://vorpus.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] Guarantee ordered dict literals in v3.7?

[Steve Dower]

On 19Dec2017 1004, Chris Barker wrote:
Nathaniel Smith has pointed out that eval(pprint(a_dict)) is supposed to 
return the same dict -- so documented behavior may already be broken.


Two relevant quotes from the pprint module docs:

>>> The pprint module provides a capability to “pretty-print” arbitrary 
Python data structures in a form which can be used as input to the 
interpreter


>>> Dictionaries are sorted by key before the display is computed.

It says nothing about the resulting dict being the same as the original 
one, just that it can be used as input. So these are both still true 
(until someone deliberately breaks the latter). In any case, there are 
so many ways to spoil the first point for yourself that it's hardly 
worth treating as an important constraint.


(though I assume order is still ignored when comparing dicts, so: 
eval(pprint(a_dict)) == a_dict will still hold.


Order had better be ignored when comparing dicts, or plenty of code will 
break. For example:


>>> {'a': 1, 'b': 2} == {'b': 2, 'a': 1}
True

Saying that "iter(dict)" will produce keys in the same order as they 
were inserted is not the same as saying that "dict" is an ordered 
mapping. As far as I understand, we've only said the first part.


(And the "nerve" here is that I disagreed with even the first part, but 
didn't fight it too strongly because I never relied on the iteration 
order of dict. However, I *do* rely on nobody else relying on the 
iteration order of dict either, and so proposals to change existing 
semantics that were previously independent of insertion order to make 
them rely on insertion order will affect me. So now I'm pushing back.)


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] Is static typing still optional?

[Rob Cliffe]

On 19/12/2017 20:11, Chris Barker wrote:
There are a number of us that are uncomfortable with static typing in 
general,

+1
and the python-dev community has been criticised for doing too much, 
moving too fast, and complicating the language unnecessarily.


___
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] f-strings

[Eric Fahlgren]

On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> If I were Bach, I'd compose a more-itertools-like module to be named
> Variations_on_the_F_String. :-)
>

​Would that be P.D.Q. Bach to whom you are referring?​
___
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] f-strings

[Chris Barker]

On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> I don't see any reason not to document tips and tricks with f-strings,
> and this is a nice and useful example.  But it looks like TOOWTDI to
> me.  The syntax is documented (6.1.3.1 in the Library Reference),
> along with a specific relevant example ("Aligning the text and
> specifying a width" in 6.1.3.2).
>
> So -1 on putting the recipe in the reference docs.  I really don't
> think this kind of information belongs in a PEP for sure, and probably
> not even in the Library Reference.


The docs (and I think PEP) have been updated to clearly state that
f-strings use the same formatting specifiers as .format(), and have links
to those docs.

So I think we're good.


> The Tutorial might be a good place
> for it, though.
>

yup.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Is static typing still optional?

[Chris Barker]

On Mon, Dec 18, 2017 at 11:49 PM, Eric V. Smith  wrote:

> I also don't think it's surprising that you can put misleading information
> (including non-types) in type annotations. All of the documentation and
> discussions are quite clear that type information is ignored at runtime.
>

Sure -- but that's documentation of type annotations -- someone
uninterested in typing, or completely unaware of it, will not be reading
those docs.


> Data Classes is also not the first use of type annotations in the stdlib:
> https://docs.python.org/3/library/typing.html#typing.NamedTuple


That's in the typing package, yes? collections.namedtuple is unchanged. So
yes, obviously the entire typing package is about typing. This is something
that has nothing to do with typing, but does use the typing syntax. It
really is different.

I haven't started teaching typing to newbies yet -- but I imagine I will
have to some day -- and when I do, it will be in the context of: here is an
optional feature that you can use along with a static type checker. And I
can make it clear that the annotations only apply to the static type
checker, and not run-time behavior.

But using type annotations for something other than providing information
to a static type checker, in an stdlib module, changes that introduction.
And people don't read all the docs -- they read to the first example of how
to use it, and away they go. And if that example is something like:

@dataclass
class C:
a: int
b: float = 0.0

There WILL be confusion.

Paul Moore wrote:

> Also, the fact that no-one raised this issue during the whole time the
> PEP was being discussed (at least as far as I recollect) and that
> Guido (who of all of us should be most aware of what is and isn't
> acceptable use of annotations in the stdlib) approved the PEP,
> suggests to me that this isn't that big a deal.


That suggests to me that the people involved in discussing the PEP may not
be representative of the bulk of Python users. There are a number of us
that are uncomfortable with static typing in general, and the python-dev
community has been criticised for doing too much, moving too fast, and
complicating the language unnecessarily.

The PEP's been accepted, so let's move forward, but please be aware of
these issues with the documentation and examples.

I'll try to contribute to that discussion as well.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Guarantee ordered dict literals in v3.7?

[Paul Moore]

On 19 December 2017 at 17:57, Steve Holden  wrote:
> On Tue, Dec 19, 2017 at 4:49 PM, Stephen J. Turnbull
>  wrote:
>>
>> Nathaniel Smith writes:
>>
>>  > To make sure I understand, do you actually have a script like this, or
>>  > is this hypothetical?
>>
>> I have a couple of doctests that assume that pprint will sort by key,
>> yes.  It makes the tests look quite a bit nicer by pprinting the
>> output, and I get sorting (which matters for some older Pythons) for
>> free.  (I admit I don't actually use those tests with older Pythons,
>> but the principle stands.)
>>
>> I don't see why we don't do the obvious, namely add the option to use
>> "native" order to the PrettyPrinter class, with the default being
>> backward compatible.
>
>
> Perhaps now key ordering has been pronounced we could either add a "sorted"
> method to dicts equivalent to the following code.
>
> def sorted(self):
> return {self[k] for k in sorted(self.keys())}
>
> Alternatively the sorted built-in could be modified to handle dicts in this
> way.

I don't think there's any need for this.

> Though I still find the assumption of any ordering at all a bit weird I
> suppose I'll grow used to it.

As far as I'm concerned, dictionaries are still exactly as they were
before - key-value mappings with no inherent order. None of my code
makes any assumption about the ordering of dictionaries, so it'll be
100% unaffected by this change. I find this whole debate about the
"consequences" of mandating insertion order to be completely out of
proportion. As far as I'm concerned, the only practical impact is that
when you iterate over things like dictionary displays, **kw arguments,
etc, you get the "obvious" order, and it's not a lucky accident that
you do so.

Certainly, with the order guaranteed, people who currently use
OrderedDict will be able to simply use a dict in future - although I'd
expect very few people will take advantage of this in the immediate
future, as by doing so they'll be restricting their code to Python
3.7+ only, for no significant benefit. And let's not forget that
OrderedDict is used far less frequently than plain dictionaries, so
we're talking about a small percentage of a tiny percentage of uses of
mapping objects in the wild that will in *any* way be affected by this
change.

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] Guarantee ordered dict literals in v3.7?

[Chris Barker]

On Tue, Dec 19, 2017 at 8:14 AM, Barry Warsaw  wrote:

> On Dec 18, 2017, at 22:37, Nathaniel Smith  wrote:
>
> > Wait, what? Why would changing pprint (so that it accurately reflects
> > dict's new underlying semantics!) be a breaking change? Are you
> > suggesting it shouldn't be changed in 3.7?
>
> As others have pointed out, exactly because the current behavior is
> documented.  And we all know that if it’s documented (and often even if
> it’s not, but that’s besides the point here) it will be relied upon.
>

Nathaniel Smith has pointed out that  eval(pprint(a_dict)) is supposed to
return the same dict -- so documented behavior may already be broken.

(though I assume order is still ignored when comparing dicts, so:
eval(pprint(a_dict))
== a_dict will still hold.

But practicality beats purity, and a number of folks have already posted
use-cases where they rely on sorted order, so there you go.


> So we can’t change the default behavior.  But I have no problems
> conceptually with giving users options.  The devil is in the details
> though, e.g. should we special case dictionary sorting only?



> Should we use a sort `key` to mirror sorted() and list.sort()?
>

That would be a nice feature! If anything is done, I think we should allow
a key function.

and maybe have key=None as "unsorted"

-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Guarantee ordered dict literals in v3.7?

[Steve Holden]

On Tue, Dec 19, 2017 at 4:49 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Nathaniel Smith writes:
>
>  > To make sure I understand, do you actually have a script like this, or
>  > is this hypothetical?
>
> I have a couple of doctests that assume that pprint will sort by key,
> yes.  It makes the tests look quite a bit nicer by pprinting the
> output, and I get sorting (which matters for some older Pythons) for
> free.  (I admit I don't actually use those tests with older Pythons,
> but the principle stands.)
>
> I don't see why we don't do the obvious, namely add the option to use
> "native" order to the PrettyPrinter class, with the default being
> backward compatible.
>

​Perhaps now key ordering has been pronounced we could either add a
"sorted" method to dicts equivalent to the following code.

def sorted(self):​
return {self[k] for k in sorted(self.keys())}

Alternatively the sorted built-in could be modified to handle dicts in this
way. Though I still find the assumption of any ordering at all a bit weird
I suppose I'll grow used to it.

regards
 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] Is static typing still optional?

[Steve Holden]

On Tue, Dec 19, 2017 at 10:53 AM, Paul Moore  wrote:

> On 19 December 2017 at 07:49, Eric V. Smith  wrote:
> > Data Classes is also not the first use of type annotations in the stdlib:
> > https://docs.python.org/3/library/typing.html#typing.NamedTuple
> >
>
> Also, the fact that no-one raised this issue during the whole time the
> PEP was being discussed (at least as far as I recollect) and that
> Guido (who of all of us should be most aware of what is and isn't
> acceptable use of annotations in the stdlib) approved the PEP,
> suggests to me that this isn't that big a deal.
>
> The only thing that has surprised me in this discussion is that the
> actual type used in the annotation makes no difference. And once
> someone reminded me that types are never enforced at runtime (you can
> call f(x: int) with f('haha')) that seemed fine.
>

​If anything, this makes things more difficult for the learner.​ The fact
that annotations are formally undefined as to anything but syntax is
sensible but can be misleading (as the example above clearly shows).

In the typing module it's logical to see annotations, I guess. But I really
hope they aren't sprinkled around willy-nilly. Sooner or later there will
be significant demand for annotated libraries, even though CPython will
perform exactly as it does with non-annotated code. I can see the value of
annotations in other environments and for different purposes, but it would
be a pity if this were to unnecessarily complicate the stdlib.

regards
 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] f-strings

[Stephen J. Turnbull]

Mariatta Wijaya writes:
 > I agree it's useful info :)
 > 
 > I went ahead and made a PR [1].
 > In my PR, I simply linked to the Format Specification Mini Language[2] from
 > f-strings documentation[3].
 > 
 > Not sure about updating PEP 498 at this point..

I don't see any reason not to document tips and tricks with f-strings,
and this is a nice and useful example.  But it looks like TOOWTDI to
me.  The syntax is documented (6.1.3.1 in the Library Reference),
along with a specific relevant example ("Aligning the text and
specifying a width" in 6.1.3.2).

So -1 on putting the recipe in the reference docs.  I really don't
think this kind of information belongs in a PEP for sure, and probably
not even in the Library Reference.  The Tutorial might be a good place
for it, though.

If I were Bach, I'd compose a more-itertools-like module to be named
Variations_on_the_F_String. :-)

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] Guarantee ordered dict literals in v3.7?

[Stephen J. Turnbull]

Nathaniel Smith writes:

 > To make sure I understand, do you actually have a script like this, or
 > is this hypothetical?

I have a couple of doctests that assume that pprint will sort by key,
yes.  It makes the tests look quite a bit nicer by pprinting the
output, and I get sorting (which matters for some older Pythons) for
free.  (I admit I don't actually use those tests with older Pythons,
but the principle stands.)

I don't see why we don't do the obvious, namely add the option to use
"native" order to the PrettyPrinter class, with the default being
backward compatible.


-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
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] Guarantee ordered dict literals in v3.7?

[Barry Warsaw]

On Dec 18, 2017, at 22:37, Nathaniel Smith  wrote:

> Wait, what? Why would changing pprint (so that it accurately reflects
> dict's new underlying semantics!) be a breaking change? Are you
> suggesting it shouldn't be changed in 3.7?

As others have pointed out, exactly because the current behavior is documented. 
 And we all know that if it’s documented (and often even if it’s not, but 
that’s besides the point here) it will be relied upon.

So we can’t change the default behavior.  But I have no problems conceptually 
with giving users options.  The devil is in the details though, e.g. should we 
special case dictionary sorting only?  Should we use a sort `key` to mirror 
sorted() and list.sort()?

We can figure those things out and whether it’s even worth doing.  I don’t 
think that’s PEP-worthy, so if someone is sufficiently motivated, please open 
an issue on bpo.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] [RELEASE] Python 3.6.4 is now available

[Ned Deily]

On behalf of the Python development community and the Python 3.6
release team, I am happy to announce the availability of Python 3.6.4,
the fourth maintenance release of Python 3.6.  Detailed information
about the changes made in 3.6.4 can be found in the change log here:

https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-4-final

Please see "What’s New In Python 3.6" for more information about the
new features in Python 3.6:

https://docs.python.org/3.6/whatsnew/3.6.html

You can download Python 3.6.4 here:

https://www.python.org/downloads/release/python-364/

The next maintenance release of Python 3.6 is expected to follow in
about 3 months, around the end of 2018-03.  More information about the
3.6 release schedule can be found here:

https://www.python.org/dev/peps/pep-0494/

Enjoy!

--
  Ned Deily
  n...@python.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] PEP 489: module m_traverse called with NULL module state

[Petr Viktorin]

On 12/19/2017 04:19 PM, Antoine Pitrou wrote:

On Tue, 19 Dec 2017 16:10:06 +0100
Petr Viktorin  wrote:


Speaking of which, the doc is not very clear: is PEP 489 required for
multi-interpreter support or is PyModule_GetState() sufficient?


Yes, it is possible to have proper subinterpreter support without
multi-phase init.


Thanks.  I guess the C API docs need a user-friendly section laying out
the various methods for initializing a module, and their various
advantages :-)


That, or eventually remove multi-phase init's disadvantages, and have 
just one way to do 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] PEP 489: module m_traverse called with NULL module state

[Antoine Pitrou]

On Tue, 19 Dec 2017 16:10:06 +0100
Petr Viktorin  wrote:
> >
> > Speaking of which, the doc is not very clear: is PEP 489 required for
> > multi-interpreter support or is PyModule_GetState() sufficient?  
> 
> Yes, it is possible to have proper subinterpreter support without
> multi-phase init.

Thanks.  I guess the C API docs need a user-friendly section laying out
the various methods for initializing a module, and their various
advantages :-)

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] PEP 489: module m_traverse called with NULL module state

[Petr Viktorin]

On Thu, Dec 14, 2017 at 12:00 PM, Antoine Pitrou  wrote:
> On Thu, 14 Dec 2017 17:00:10 +1000
> Nick Coghlan  wrote:
>> On 14 Dec. 2017 9:19 am, "Antoine Pitrou"  wrote:
>>
>>
>> Hello,
>>
>> After debugging a crash on AppVeyor for a submitter's PR
>> (see https://github.com/python/cpython/pull/4611 ), I came to the
>> following diagnosis: converting the "atexit" module (which is a
>> built-in C extension) to PEP 489 multiphase initialization can lead to
>> its m_traverse function (and presumably also m_clear and m_free) to be
>> called while not module state is yet registered: that is,
>> `PyModule_GetState(self)` when called from m_traverse returns NULL!
>>
>> Is that an expected or known subtlety?
>>
>>
>> Not that I'm aware of, so I'd be inclined to classify it as a bug in the
>> way we're handling multi-phase initialisation unless/until we determine
>> there's no way to preserve the existing invariant from the single phase
>> case.
>
> Speaking of which, the doc is not very clear: is PEP 489 required for
> multi-interpreter support or is PyModule_GetState() sufficient?

Yes, it is possible to have proper subinterpreter support without
multi-phase init.
___
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] Question on a seemingly useless doctest

[Erik Bray]

Sorry, completely fat-fingered my autocomplete and sent to to wrong list.

On Tue, Dec 19, 2017 at 12:12 PM, Erik Bray  wrote:
> Hi all,
>
> I have a ticket [1] that's hung up on a failure in one doctest in the
> form of sage.doctest.sources.FileDocTestSource._test_enough_doctests.
>
> This test has been there since, it seems, as long as the current
> doctest framework has been in place and nobody seems to have
> questioned it.  Its expected output is generated from the Sage sources
> themselves, and can change when tests are added or removed to any
> module (if any of those tests should be "skipped").  Over the years
> the expected output to this test has just been updated as necessary.
>
> But in taking a closer look at the test--and I could be mistaken--but
> it's not even a useful test.  It's *attempting* to validate that the
> doctest parser skips tests when it's supposed to.  But it performs
> this validation by...implementing its own, less robust doctest parser,
> and comparing the results of that to the results of the real doctest
> parser.  Sometimes--in fact often--the comparison is wrong (as the
> test itself acknowledges).
>
> This doesn't seem to me a correct or useful way to validate the
> doctest parser.  If there are cases that the real doctest parser
> should be tested against, then unit tests/regression tests should be
> written that simply test the real doctest parser against those cases
> and check the results.  Having essentially a real doctest parser, and
> a "fake" one that's incorrect doesn't make sense to me, unless there's
> something about this I'm misunderstanding.
>
> I would propose to just remove the test.  If there are any actual
> regressions it's responsible for catching then more focused regression
> tests should be written for those cases.
>
> Erik
>
>
> [1] https://trac.sagemath.org/ticket/24261#comment:24
___
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] Question on a seemingly useless doctest

[Erik Bray]

Hi all,

I have a ticket [1] that's hung up on a failure in one doctest in the
form of sage.doctest.sources.FileDocTestSource._test_enough_doctests.

This test has been there since, it seems, as long as the current
doctest framework has been in place and nobody seems to have
questioned it.  Its expected output is generated from the Sage sources
themselves, and can change when tests are added or removed to any
module (if any of those tests should be "skipped").  Over the years
the expected output to this test has just been updated as necessary.

But in taking a closer look at the test--and I could be mistaken--but
it's not even a useful test.  It's *attempting* to validate that the
doctest parser skips tests when it's supposed to.  But it performs
this validation by...implementing its own, less robust doctest parser,
and comparing the results of that to the results of the real doctest
parser.  Sometimes--in fact often--the comparison is wrong (as the
test itself acknowledges).

This doesn't seem to me a correct or useful way to validate the
doctest parser.  If there are cases that the real doctest parser
should be tested against, then unit tests/regression tests should be
written that simply test the real doctest parser against those cases
and check the results.  Having essentially a real doctest parser, and
a "fake" one that's incorrect doesn't make sense to me, unless there's
something about this I'm misunderstanding.

I would propose to just remove the test.  If there are any actual
regressions it's responsible for catching then more focused regression
tests should be written for those cases.

Erik


[1] https://trac.sagemath.org/ticket/24261#comment:24
___
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] Guarantee ordered dict literals in v3.7?

[Paul Moore]

On 19 December 2017 at 08:27, Nathaniel Smith  wrote:
> On Mon, Dec 18, 2017 at 11:38 PM, Steve Dower  wrote:
>> On 18Dec2017 2309, Steven D'Aprano wrote:
>>> [A LOT OF THINGS I AGREE WITH]
>> I agree completely with Steven's reasoning here, and it bothers me that
>> what is an irrelevant change to many users (dict becoming ordered) seems
>> to imply that all users of dict have to be updated.
>
> Can we all take a deep breath and lay off the hyperbole? The only
> point under discussion in this subthread is whether pprint -- our
> module for producing nicely-formatted-reprs -- should continue to sort
> keys, or should continue to provide an accurate repr. There are
> reasonable arguments for both positions, but no-one's suggesting
> anything in the same solar system as "all users of dict have to be
> updated".
>
> Am I missing some underlying nerve that this is hitting for some reason?

IMO, the key thing is that people appear to be talking as if changing
documented behaviour without deprecation is acceptable. Or even if
they are OK with a deprecation period, they are still talking about
changing documented behaviour for a trivial reason (as Steve Dower
said, most people will still use dict for its dict behaviour, not for
its orderedness). People (including me) are getting irritated because
backward compatibility, which is normally a key principle, is being
treated so lightly here. (It happened in another thread as well -
changing the output of csv.DictReader from OrderedDict to dict - again
suggesting that breaking a documented behaviour was OK, just because
dicts are now ordered).

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] Is static typing still optional?

[Paul Moore]

On 19 December 2017 at 07:49, Eric V. Smith  wrote:
> Data Classes is also not the first use of type annotations in the stdlib:
> https://docs.python.org/3/library/typing.html#typing.NamedTuple
>

Also, the fact that no-one raised this issue during the whole time the
PEP was being discussed (at least as far as I recollect) and that
Guido (who of all of us should be most aware of what is and isn't
acceptable use of annotations in the stdlib) approved the PEP,
suggests to me that this isn't that big a deal.

The only thing that has surprised me in this discussion is that the
actual type used in the annotation makes no difference. And once
someone reminded me that types are never enforced at runtime (you can
call f(x: int) with f('haha')) that seemed fine.

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] Guarantee ordered dict literals in v3.7?

[Nathaniel Smith]

On Mon, Dec 18, 2017 at 11:38 PM, Steve Dower  wrote:
> On 18Dec2017 2309, Steven D'Aprano wrote:
>> [A LOT OF THINGS I AGREE WITH]
> I agree completely with Steven's reasoning here, and it bothers me that
> what is an irrelevant change to many users (dict becoming ordered) seems
> to imply that all users of dict have to be updated.

Can we all take a deep breath and lay off the hyperbole? The only
point under discussion in this subthread is whether pprint -- our
module for producing nicely-formatted-reprs -- should continue to sort
keys, or should continue to provide an accurate repr. There are
reasonable arguments for both positions, but no-one's suggesting
anything in the same solar system as "all users of dict have to be
updated".

Am I missing some underlying nerve that this is hitting for some reason?

-n

-- 
Nathaniel J. Smith -- https://vorpus.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