Re: [Python-Dev] Make stacklevel=2 by default in warnings.warn()

2015-09-20 Thread Nathaniel Smith 
On Sat, Sep 19, 2015 at 11:44 PM, Serhiy Storchaka  wrote:
> For now the default value of the stacklevel parameter in warnings.warn() is
> 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't
> know cases that need stacklevel=1. I propose to make the default value of
> stacklevel to be 2. I think that unlikely this will break existing code. But
> rather can fix existing bugs. If stacklevel=1 is required (I don't know
> cases), it can be explicitly specified.

+1

I don't have enough fingers to count how many times I've had to
explain how stacklevel= works to maintainers of widely-used packages
-- they had no idea that this was even a thing they were getting
wrong.

OTOH I guess if there is anyone out there who's intentionally using
stacklevel=1 they might be reasonably surprised at this change. I
guess for some kinds of warnings stacklevel=2 is not obviously correct
-- the one that comes to mind is "warning: the computer on the other
end of this network connection did something weird, continuing
anyway". OTOOH in this case I'm not sure stacklevel=1 is any better
either, since the thing being warned about has nothing to do with the
current call stack at all.

-n

-- 
Nathaniel J. Smith -- http://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] Make stacklevel=2 by default in warnings.warn()

2015-09-20 Thread Gustavo Carneiro 
On 20 September 2015 at 07:55, Nathaniel Smith  wrote:

> On Sat, Sep 19, 2015 at 11:44 PM, Serhiy Storchaka 
> wrote:
> > For now the default value of the stacklevel parameter in warnings.warn()
> is
> > 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't
> > know cases that need stacklevel=1. I propose to make the default value of
> > stacklevel to be 2. I think that unlikely this will break existing code.
> But
> > rather can fix existing bugs. If stacklevel=1 is required (I don't know
> > cases), it can be explicitly specified.
>
> +1
>
> I don't have enough fingers to count how many times I've had to
> explain how stacklevel= works to maintainers of widely-used packages
> -- they had no idea that this was even a thing they were getting
> wrong.
>
> OTOH I guess if there is anyone out there who's intentionally using
> stacklevel=1 they might be reasonably surprised at this change. I
> guess for some kinds of warnings stacklevel=2 is not obviously correct
> -- the one that comes to mind is "warning: the computer on the other
> end of this network connection did something weird, continuing
> anyway". OTOOH in this case I'm not sure stacklevel=1 is any better
> either, since the thing being warned about has nothing to do with the
> current call stack at all.
>

In this case you should use the logging module instead.

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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] Make stacklevel=2 by default in warnings.warn()

2015-09-20 Thread Serhiy Storchaka 
For now the default value of the stacklevel parameter in warnings.warn() 
is 1. But in most cases stacklevel=2 is required, sometimes >2, and I 
don't know cases that need stacklevel=1. I propose to make the default 
value of stacklevel to be 2. I think that unlikely this will break 
existing code. But rather can fix existing bugs. If stacklevel=1 is 
required (I don't know cases), it can be explicitly specified.


___
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] My collection of Python 3.5.0 regressions

2015-09-20 Thread Mark Lawrence 

On 19/09/2015 06:38, Stephen J. Turnbull wrote:

Mark Lawrence writes:

  > I agree very strongly with your point here.  Raising umpteen issues
  > over installation failures when a full release comes out strikes me
  > as below the belt when there have been multiple previous releases
  > without a squeak.

Raising issues is always useful and appropriate.  It's up to Larry
Hastings to decide whether he personally needs to do more work.


My point is that issues were raised after the full release was made, but 
no attempt was made to test for these problems in any of the previous 
releases, whether alpha, beta or release candidate.  There was advance 
warning here http://stevedower.id.au/blog/the-python-3-5-installer/, 
which was flagged up here 
http://www.gossamer-threads.com/lists/python/dev/1175080. Larry doesn't 
need to do anything that I'm aware of, except perhaps be guided by our 
windows gurus.




I suspect he probably will, though.  I knew these changes were risky
on the lead time given, even though I don't do Windows, and I'm not a
core Python developer.  I would hope that Steve Dower and Larry were
at least as well aware of what they were getting into, and there are a
lot of Windows users we *want* to support well.  (*Not* "have to", and
YMMV.  But the Python developer community clearly has a working
consensus on supporting Windows well.)



I'm certain that Steve was well aware of what he was getting into, 
Larry, at least with respect to Windows, I'm not so sure about.  Not 
that it really matters to me.  All I know is that the build procedures 
have been made easier on Windows, thanks mostly to Steve and Zach Ware 
in recent years, building on work done by Tim Golden, Martin v. Löwis 
and Mark Hammond amongst others.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] Make stacklevel=2 by default in warnings.warn()

2015-09-20 Thread Serhiy Storchaka 
субота, 19-вер-2015 23:55:44 Nathaniel Smith написано:
> OTOH I guess if there is anyone out there who's intentionally using
> stacklevel=1 they might be reasonably surprised at this change.

That is why I ask on Python-Dev instead of just open an issue.

But I doubt that there is such case.
 
___
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 there an official order for Misc/NEWS sections?

2015-09-20 Thread Brett Cannon 
There is no official order to the NEWS file. I know I have always just
referred to the last release when trying to decide whether to stick a
section.

On Sun, Sep 20, 2015, 14:27 Larry Hastings  wrote:

>
>
> What is the official order for sections in Misc/NEWS?  I'm sure that "Core
> and Builtins" is first, and "Library" is second, but after that... I'm not
> sure.
>
> This seems about right, though I'm not certain we're 100% consistent about
> it:
> Core and Builtins
> Library
> IDLE
> Documentation
> Tests
> Build
> Windows
> Tools/Demos
> C API
>
> Is it documented anywhere?  I didn't see it in the Dev Guide.
>
>
> */arry*
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

2015-09-20 Thread Eric V. Smith 
On 9/20/2015 8:37 AM, Nick Coghlan wrote:
> On 19 September 2015 at 21:03, Eric V. Smith  wrote:
>> Instead of calling __format__, I've changed the code generator to call
>> format(expr1, spec1). As an optimization, I might add special opcodes to
>> deal with this and string concatenation, but that's for another day (if
>> ever).
> 
> Does this mean overriding format at the module level or in builtins
> will affect the way f-strings are evaluated at runtime? (I don't have
> a strong preference one way or the other, but I think the PEP should
> be explicit as to the expected behaviour rather than leaving it as
> implementation defined).

Yes, in the current implementation, if you mess with format(), str(),
repr(), or ascii() you can break f-strings. The latter 3 are used to
implement !s, !r, and !a.

I have a plan to change this, by adding one or more opcodes to implement
the formatting and string joining. I'll defer a decision on updating the
PEP until I can establish the feasibility (and desirability) of that
approach.

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

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

2015-09-20 Thread Serhiy Storchaka 

On 20.09.15 16:51, Eric V. Smith wrote:

On 9/20/2015 8:37 AM, Nick Coghlan wrote:

On 19 September 2015 at 21:03, Eric V. Smith  wrote:

Instead of calling __format__, I've changed the code generator to call
format(expr1, spec1). As an optimization, I might add special opcodes to
deal with this and string concatenation, but that's for another day (if
ever).


Does this mean overriding format at the module level or in builtins
will affect the way f-strings are evaluated at runtime? (I don't have
a strong preference one way or the other, but I think the PEP should
be explicit as to the expected behaviour rather than leaving it as
implementation defined).


Yes, in the current implementation, if you mess with format(), str(),
repr(), or ascii() you can break f-strings. The latter 3 are used to
implement !s, !r, and !a.

I have a plan to change this, by adding one or more opcodes to implement
the formatting and string joining. I'll defer a decision on updating the
PEP until I can establish the feasibility (and desirability) of that
approach.


I propose to add internal builting formatter type. Instances should be 
marshallable and callable. The code generated for f-strings should just 
load formatter constant and call it with arguments. The formatter builds 
resulting string by concatenating literal strings and results of 
formatting arguments with specified specifications.


Later we could change compiler (just peephole optimizer?) to replace 
literal_string.format(*args) and literal_string % args with calling 
precompiled formatter.


Later we could rewrite str.format, str.__mod__ and re.sub to create 
temporary formatter object and call it.


Later we could expose public API for creating formatter object. It can 
be used by third-party template engines.



___
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 498 (interpolated f-string) tweak

2015-09-20 Thread Nick Coghlan 
On 19 September 2015 at 21:03, Eric V. Smith  wrote:
> While finishing up the implementation of PEP 498, I realized that the
> PEP has an error. It says that this code:
>
> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
>
> Is equivalent to:
>
> 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
> + str(expr3).__format__('') + 'ghi'
>
> But that's not correct. The right way to call __format__ is:
>
> type(expr1).__format__(expr1, spec1)
>
> That is, the lookup of __format__ is done on the type, not the instance.
>
> Instead of calling __format__, I've changed the code generator to call
> format(expr1, spec1). As an optimization, I might add special opcodes to
> deal with this and string concatenation, but that's for another day (if
> ever).

Does this mean overriding format at the module level or in builtins
will affect the way f-strings are evaluated at runtime? (I don't have
a strong preference one way or the other, but I think the PEP should
be explicit as to the expected behaviour rather than leaving it as
implementation defined).

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] My collection of Python 3.5.0 regressions

2015-09-20 Thread Nick Coghlan 
On 20 September 2015 at 18:03, Mark Lawrence  wrote:
> I'm certain that Steve was well aware of what he was getting into, Larry, at
> least with respect to Windows, I'm not so sure about.  Not that it really
> matters to me.  All I know is that the build procedures have been made
> easier on Windows, thanks mostly to Steve and Zach Ware in recent years,
> building on work done by Tim Golden, Martin v. Löwis and Mark Hammond
> amongst others.

From a process perspective, the release manager is responsible for
wrangling the release process, tagging the source tree, and creating
and publishing the source tarball, but the binary installers are in
the hands of the platform specialists listed in the release PEP
(https://www.python.org/dev/peps/pep-0478/ in the case of 3.5).

The full release process is at
https://www.python.org/dev/peps/pep-0101/, which has details of the
unfortunately manual Windows installation testing process at the end.
It might be interesting to see if running the installs at least in
quiet mode could be automated on Appveyor to reduce the manual testing
requirements.

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 495 (Local Time Disambiguation) is ready for pronouncement

2015-09-20 Thread Alexander Belopolsky 
On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> PEP 495 [1] is a deliberately minimalistic proposal to remove an
> ambiguity in representing some local times as datetime.datetime
> objects.

A major issue has come up since my announcement above.  Tim Peters have
noticed that PEP 495 would violate the "hash invariant" unless the fold
attribute is accounted for in inter-zone comparisons.
See [2] for details.  This issue has been resolved by modifying the
definition [3] of the "==" operator for aware datetimes with post-PEP
tzinfo.  Note that no program will be affected by this change unless it
uses a post-PEP tzinfo implementation.

I made some smaller changes [4] to the PEP as well and it should finally be
ready for pronouncement.

[1]: https://www.python.org/dev/peps/pep-0495
[2]:
https://mail.python.org/pipermail/datetime-sig/2015-September/000625.html
[3]:
https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison
[4]: https://hg.python.org/peps/log/39b7c1da05a2/pep-0495.txt
___
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] Is there an official order for Misc/NEWS sections?

2015-09-20 Thread Larry Hastings 



What is the official order for sections in Misc/NEWS?  I'm sure that 
"Core and Builtins" is first, and "Library" is second, but after that... 
I'm not sure.


This seems about right, though I'm not certain we're 100% consistent 
about it:

Core and Builtins
Library
IDLE
Documentation
Tests
Build
Windows
Tools/Demos
C API

Is it documented anywhere?  I didn't see it in the Dev Guide.


//arry/
___
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 498 (interpolated f-string) tweak

2015-09-20 Thread Eric V. Smith 

> On Sep 20, 2015, at 11:15 AM, Serhiy Storchaka  wrote:
> 
>> On 20.09.15 16:51, Eric V. Smith wrote:
>>> On 9/20/2015 8:37 AM, Nick Coghlan wrote:
 On 19 September 2015 at 21:03, Eric V. Smith  wrote:
 Instead of calling __format__, I've changed the code generator to call
 format(expr1, spec1). As an optimization, I might add special opcodes to
 deal with this and string concatenation, but that's for another day (if
 ever).
>>> 
>>> Does this mean overriding format at the module level or in builtins
>>> will affect the way f-strings are evaluated at runtime? (I don't have
>>> a strong preference one way or the other, but I think the PEP should
>>> be explicit as to the expected behaviour rather than leaving it as
>>> implementation defined).
>> 
>> Yes, in the current implementation, if you mess with format(), str(),
>> repr(), or ascii() you can break f-strings. The latter 3 are used to
>> implement !s, !r, and !a.
>> 
>> I have a plan to change this, by adding one or more opcodes to implement
>> the formatting and string joining. I'll defer a decision on updating the
>> PEP until I can establish the feasibility (and desirability) of that
>> approach.
> 
> I propose to add internal builting formatter type. Instances should be 
> marshallable and callable. The code generated for f-strings should just load 
> formatter constant and call it with arguments. The formatter builds resulting 
> string by concatenating literal strings and results of formatting arguments 
> with specified specifications.
> 
> Later we could change compiler (just peephole optimizer?) to replace 
> literal_string.format(*args) and literal_string % args with calling 
> precompiled formatter.
> 
> Later we could rewrite str.format, str.__mod__ and re.sub to create temporary 
> formatter object and call it.
> 
> Later we could expose public API for creating formatter object. It can be 
> used by third-party template engines.
> 

I think this is InterpolationTemplate from PEP 501.

Eric. 

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