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

[Victor Stinner]

Would it be too verbose to display two frames or more by default?
Maybe depending on the action (ex: only if the warning is emitted only
once).

Victor

2015-09-20 8:44 GMT+02:00 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/victor.stinner%40gmail.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] Make stacklevel=2 by default in warnings.warn()

[Victor Stinner]

2015-09-20 8:44 GMT+02:00 Serhiy Storchaka :
> I propose to make the default value of stacklevel to be 2.
> I think that unlikely this will break existing code.

Consider this simple script:
---
import warnings
warnings.warn("here")
---

Currrent output:
---
x.py:3: UserWarning: here
  warnings.warn("here")
---

=> it shows the script name (x.py), the line number and the line, as expected.

Now try stacklevel=2:
---
import warnings
warnings.warn("here", stacklevel=2)
---

New output:
---
sys:1: UserWarning: here
---

"sys:1" is not really useful :-/

I would describe this as a regression, not an enhancement.

It's hard to find a "good" default value. It's better to always
specify stacklevel :-)

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

[Nathaniel Smith]

On Sep 21, 2015 12:15 AM, "Victor Stinner"  wrote:
>
> Would it be too verbose to display two frames or more by default?
> Maybe depending on the action (ex: only if the warning is emitted only
> once).

It's not just about how it gets displayed -- the frame that it gets
"attributed" to is also used when comparing against the warnings filters to
determine what action to take. What if stacklevel=1 makes it match a filter
with action "ignore", and stacklevel=2 makes it match a filter with action
"raise"?

(This is a common example I've encountered in the context of wanting to set
up CI tests so that if *my* code uses deprecated functionality then I want
to fail the test so I notice, but if some library I'm using uses deprecated
functionality internally then that's not my problem. This breaks down when
the library makes the common error of issuing DeprecationWarnings with
stacklevel=1, because that makes python think that they are deprecating
themselves, not warning that I did something deprecated.)

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

[Nick Coghlan]

On 21 September 2015 at 05:22, Eric V. Smith  wrote:
>
>> 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.

It's certainly a similar idea, although PEP 501 just proposed storing
strings and tuples on the code object, with the interpolation template
itself still being a mutable object constructed at runtime. Serhiy's
suggestion goes a step further to suggest making the template itself
immutable, and passing in all the potentially mutable data as method
arguments.

I think there's a simpler approach available though, which is to go
the way we went in introducing first the __import__ builtin and later
the __build_class__ builtin to encapsulate some of the complexity of
their respective statements without requiring a raft of new opcodes.

The last draft of PEP 501 before I deferred it proposed the following
for interpolation templates, since it was able to rely on having
f-strings available as a primitive and wanted to offer more
flexibility than string formatting needs:

_raw_template = "Substitute {names} and {expressions()} at runtime"
_parsed_template = (
("Substitute ", "names"),
(" and ", "expressions()"),
(" at runtime", None),
)
_field_values = (names, expressions())
_format_specifiers = (f"", f"")
template = types.InterpolationTemplate(_raw_template,
  _parsed_template,
  _field_values,
  _format_specifiers)

A __format__ builtin (or a dedicated opcode) could use a simpler data
model that consisted of the following constant and variable elements:

Compile time constant: tuple of (,
) pairs
Runtime variable: tuple of (,
) pairs

If the format string didn't end with a substitution field, then the
runtime variable tuple would be 1 element shorter than the constant
tuple.

With that approach, then __format__ (or an opcode that popped these
two tuples directly off the stack) could be defined as something like:

def __format__(constant_parts, variable_parts):
num_fields = len(variable_parts)
segments = []
for idx, (leading_text, specifier_constants) in constant_parts:
segments.append(leading_text)
if idx < num_fields:
field_value, specifier_variables = variable_parts[idx]
if specifier_variables:
specifier = __format__(specifier_constants,
specifier_variables)
else:
assert len(specifier_constants) == 1
specifier = specifier_constants[0]
if specifier.startswith("!"):
# Handle "!a", "!r", "!s" by modifying field_value
*and* specifier
if specifier:
segments.append(format(field_value, specifier)
return "".join(segments)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev maili

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

[Nick Coghlan]

On 21 September 2015 at 17:21, Nathaniel Smith  wrote:
> On Sep 21, 2015 12:15 AM, "Victor Stinner"  wrote:
>>
>> Would it be too verbose to display two frames or more by default?
>> Maybe depending on the action (ex: only if the warning is emitted only
>> once).
>
> It's not just about how it gets displayed -- the frame that it gets
> "attributed" to is also used when comparing against the warnings filters to
> determine what action to take. What if stacklevel=1 makes it match a filter
> with action "ignore", and stacklevel=2 makes it match a filter with action
> "raise"?
>
> (This is a common example I've encountered in the context of wanting to set
> up CI tests so that if *my* code uses deprecated functionality then I want
> to fail the test so I notice, but if some library I'm using uses deprecated
> functionality internally then that's not my problem. This breaks down when
> the library makes the common error of issuing DeprecationWarnings with
> stacklevel=1, because that makes python think that they are deprecating
> themselves, not warning that I did something deprecated.)

As Victor notes, though, that's not the right default for *scripts*
that are issuing deprecation warnings to end users - there, they
really are deprecating themselves. It's also not the right default for
pretty much any warning other than DeprecationWarning - for those,
you're generally wanting to say "we hit this problematic code path",
not report anything about your caller.

Passing "stacklevel=2" for API deprecations is by no means obvious
though, so perhaps it makes sense to add a
"warnings.warn_deprecated(message)" function that's implemented as:

def warn_deprecated(message, stacklevel=1):
return warnings.warn(message, DeprecationWarning,
stacklevel=(2+stacklevel)).

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

[Guido van Rossum]

I think it's been conclusively shown that we should not change the default.
Instead I recommend updating the docs with an example showing when
stacklevel=2 is appropriate.

On Mon, Sep 21, 2015 at 2:05 AM, Nick Coghlan  wrote:

> On 21 September 2015 at 17:21, Nathaniel Smith  wrote:
> > On Sep 21, 2015 12:15 AM, "Victor Stinner" 
> wrote:
> >>
> >> Would it be too verbose to display two frames or more by default?
> >> Maybe depending on the action (ex: only if the warning is emitted only
> >> once).
> >
> > It's not just about how it gets displayed -- the frame that it gets
> > "attributed" to is also used when comparing against the warnings filters
> to
> > determine what action to take. What if stacklevel=1 makes it match a
> filter
> > with action "ignore", and stacklevel=2 makes it match a filter with
> action
> > "raise"?
> >
> > (This is a common example I've encountered in the context of wanting to
> set
> > up CI tests so that if *my* code uses deprecated functionality then I
> want
> > to fail the test so I notice, but if some library I'm using uses
> deprecated
> > functionality internally then that's not my problem. This breaks down
> when
> > the library makes the common error of issuing DeprecationWarnings with
> > stacklevel=1, because that makes python think that they are deprecating
> > themselves, not warning that I did something deprecated.)
>
> As Victor notes, though, that's not the right default for *scripts*
> that are issuing deprecation warnings to end users - there, they
> really are deprecating themselves. It's also not the right default for
> pretty much any warning other than DeprecationWarning - for those,
> you're generally wanting to say "we hit this problematic code path",
> not report anything about your caller.
>
> Passing "stacklevel=2" for API deprecations is by no means obvious
> though, so perhaps it makes sense to add a
> "warnings.warn_deprecated(message)" function that's implemented as:
>
> def warn_deprecated(message, stacklevel=1):
> return warnings.warn(message, DeprecationWarning,
> stacklevel=(2+stacklevel)).
>
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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()

[Walter Dörwald]

On 21 Sep 2015, at 9:18, Victor Stinner wrote:


2015-09-20 8:44 GMT+02:00 Serhiy Storchaka :

I propose to make the default value of stacklevel to be 2.
I think that unlikely this will break existing code.


Consider this simple script:
---
import warnings
warnings.warn("here")
---

Currrent output:
---
x.py:3: UserWarning: here
warnings.warn("here")
---

=> it shows the script name (x.py), the line number and the line, as 
expected.


Now try stacklevel=2:
---
import warnings
warnings.warn("here", stacklevel=2)
---

New output:
---
sys:1: UserWarning: here
---

"sys:1" is not really useful :-/

I would describe this as a regression, not an enhancement.

It's hard to find a "good" default value. It's better to always
specify stacklevel :-)


A "dynamic" stacklevel might help. Normally when you implement a call to 
warning.warn() inside a module, you want to report the innermost 
stacklevel that is outside of your module, because that's the spot where 
the error likely is. This could be done automatically (report the first 
module that is different from the one where the call to warning.warn() 
is), or by specifying a base package name or regular expression, i.e. 
report the innermost stackframe that is not from 
"mypackage.mysubpackage").


See http://bugs.python.org/issue850482

Bye,
   Walter Dörwald
___
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()

[Serhiy Storchaka]

On 21.09.15 10:18, Victor Stinner wrote:

2015-09-20 8:44 GMT+02:00 Serhiy Storchaka :

I propose to make the default value of stacklevel to be 2.
I think that unlikely this will break existing code.


Consider this simple script:
---
import warnings
warnings.warn("here")
---

Currrent output:
---
x.py:3: UserWarning: here
   warnings.warn("here")
---

=> it shows the script name (x.py), the line number and the line, as expected.

Now try stacklevel=2:
---
import warnings
warnings.warn("here", stacklevel=2)
---

New output:
---
sys:1: UserWarning: here
---

"sys:1" is not really useful :-/


This is not new. The same output we get when run a module that correctly 
emits a warning at module level (with explicit stacklevel=2).


$ ./python -Wa Lib/imp.py
sys:1: PendingDeprecationWarning: the imp module is deprecated in favour 
of importlib; see the module's documentation for alternative uses


If this message looks confusing for you, we can avoid it if stop 
skipping frames further if frame.f_back is None. This will got rid of 
"sys:1:" in both cases, explicit and implicit stacklevel=2.



___
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()

[Serhiy Storchaka]

On 21.09.15 12:05, Nick Coghlan wrote:

As Victor notes, though, that's not the right default for *scripts*
that are issuing deprecation warnings to end users - there, they
really are deprecating themselves. It's also not the right default for
pretty much any warning other than DeprecationWarning - for those,
you're generally wanting to say "we hit this problematic code path",
not report anything about your caller.


If a warning is emitted in library function, user can't do anything with 
function's code and should change his code that calls the function. In 
this case the warning should point to the line where the function is used.


If a warning is emitted in user's code, he is able to add explicit 
stacklevel=1 if needed.


stacklevel=2 is correct argument for module level warnings, but as 
Nathaniel noted not all packages use it. When your run correctly written 
module as script you get the same "sys:1:". And this issue can be solved 
in general case.


not allecause the user wants to get a warning at the place where the 
module is imported.



Passing "stacklevel=2" for API deprecations is by no means obvious
though, so perhaps it makes sense to add a
"warnings.warn_deprecated(message)" function that's implemented as:

 def warn_deprecated(message, stacklevel=1):
 return warnings.warn(message, DeprecationWarning,
stacklevel=(2+stacklevel)).


This will not fix tons of modules that are not aware of correct stacklevel.

___
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()

[Brett Cannon]

On Mon, 21 Sep 2015 at 10:15 Serhiy Storchaka  wrote:

> On 21.09.15 12:05, Nick Coghlan wrote:
> > As Victor notes, though, that's not the right default for *scripts*
> > that are issuing deprecation warnings to end users - there, they
> > really are deprecating themselves. It's also not the right default for
> > pretty much any warning other than DeprecationWarning - for those,
> > you're generally wanting to say "we hit this problematic code path",
> > not report anything about your caller.
>
> If a warning is emitted in library function, user can't do anything with
> function's code and should change his code that calls the function. In
> this case the warning should point to the line where the function is used.
>
> If a warning is emitted in user's code, he is able to add explicit
> stacklevel=1 if needed.
>
> stacklevel=2 is correct argument for module level warnings, but as
> Nathaniel noted not all packages use it. When your run correctly written
> module as script you get the same "sys:1:". And this issue can be solved
> in general case.
>
> not allecause the user wants to get a warning at the place where the
> module is imported.
>
> > Passing "stacklevel=2" for API deprecations is by no means obvious
> > though, so perhaps it makes sense to add a
> > "warnings.warn_deprecated(message)" function that's implemented as:
> >
> >  def warn_deprecated(message, stacklevel=1):
> >  return warnings.warn(message, DeprecationWarning,
> > stacklevel=(2+stacklevel)).
>
> This will not fix tons of modules that are not aware of correct stacklevel.
>

The long-term solution to this is to add a warnings.deprecate_module()
function which does the right thing and simply not expose the stacklevel
argument to users. We can then consider warnings.warn() more of a power
user function and make the stacklevel a keyword-only argument with no
default value (although I can already hear Raymond saying "but the Python 2
users" for that part of the idea =).
___
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()

[Serhiy Storchaka]

On 21.09.15 20:00, Serhiy Storchaka wrote:

On 21.09.15 10:18, Victor Stinner wrote:

---
sys:1: UserWarning: here
---

"sys:1" is not really useful :-/


This is not new. The same output we get when run a module that correctly
emits a warning at module level (with explicit stacklevel=2).

$ ./python -Wa Lib/imp.py
sys:1: PendingDeprecationWarning: the imp module is deprecated in favour
of importlib; see the module's documentation for alternative uses

If this message looks confusing for you, we can avoid it if stop
skipping frames further if frame.f_back is None. This will got rid of
"sys:1:" in both cases, explicit and implicit stacklevel=2.


The patch is provided in http://bugs.python.org/issue25204.

___
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()

[Serhiy Storchaka]

On 21.09.15 20:32, Brett Cannon wrote:



On Mon, 21 Sep 2015 at 10:15 Serhiy Storchaka mailto:storch...@gmail.com>> wrote:

On 21.09.15 12:05, Nick Coghlan wrote:
 > Passing "stacklevel=2" for API deprecations is by no means obvious
 > though, so perhaps it makes sense to add a
 > "warnings.warn_deprecated(message)" function that's implemented as:
 >
 >  def warn_deprecated(message, stacklevel=1):
 >  return warnings.warn(message, DeprecationWarning,
 > stacklevel=(2+stacklevel)).

This will not fix tons of modules that are not aware of correct
stacklevel.


The long-term solution to this is to add a warnings.deprecate_module()
function which does the right thing and simply not expose the stacklevel
argument to users. We can then consider warnings.warn() more of a power
user function and make the stacklevel a keyword-only argument with no
default value (although I can already hear Raymond saying "but the
Python 2 users" for that part of the idea =).


warnings.deprecate_module() will do the right thing only for deprecated 
modules, but most deprecations refer to separate functions.



___
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()

[Brett Cannon]

On Mon, 21 Sep 2015 at 11:29 Serhiy Storchaka  wrote:

> On 21.09.15 20:32, Brett Cannon wrote:
> >
> >
> > On Mon, 21 Sep 2015 at 10:15 Serhiy Storchaka  > > wrote:
> >
> > On 21.09.15 12:05, Nick Coghlan wrote:
> >  > Passing "stacklevel=2" for API deprecations is by no means obvious
> >  > though, so perhaps it makes sense to add a
> >  > "warnings.warn_deprecated(message)" function that's implemented
> as:
> >  >
> >  >  def warn_deprecated(message, stacklevel=1):
> >  >  return warnings.warn(message, DeprecationWarning,
> >  > stacklevel=(2+stacklevel)).
> >
> > This will not fix tons of modules that are not aware of correct
> > stacklevel.
> >
> >
> > The long-term solution to this is to add a warnings.deprecate_module()
> > function which does the right thing and simply not expose the stacklevel
> > argument to users. We can then consider warnings.warn() more of a power
> > user function and make the stacklevel a keyword-only argument with no
> > default value (although I can already hear Raymond saying "but the
> > Python 2 users" for that part of the idea =).
>
> warnings.deprecate_module() will do the right thing only for deprecated
> modules, but most deprecations refer to separate functions.
>

And we can add one for functions as well. My point is that people seem to
not fully comprehend how to properly use the stacklevel argument and so I'm
suggesting we have functions for the common cases (modules, functions,
methods, classes).
___
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] PEP 495 accepted

[Guido van Rossum]

Just so people know, over at the datetime-sig I've accepted PEP 495, which
adds a fold flag to datetime objects to distinguish ambiguous times. This
enables roundripping of conversions for those times where the local clock
is moved backward (creating ambiguous times that could not be distinguished
before).

I would like to thank Alexander and Tim for their unrelenting work on this.
The idea seems simple, but the details were excruciatingly hard to get
right, given the strict backwards compatibility requirements.

There may well be additional beneficial changes to the datetime module. The
datetime-sig is now open for their discussion. However, proposals that
break backwards compatibility are a waste of everybody's time, so be
prepared to explain how your proposal does not break existing code that
works under Python 3.5.

-- 
--Guido van Rossum (python.org/~guido)
___
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()

[Nathaniel Smith]

On Mon, Sep 21, 2015 at 10:14 AM, Serhiy Storchaka  wrote:
> stacklevel=2 is correct argument for module level warnings, but as Nathaniel
> noted not all packages use it. When your run correctly written module as
> script you get the same "sys:1:". And this issue can be solved in general
> case.

Point of information: for module deprecations, stacklevel=2 is correct
in 2.7 and 3.5, but in 3.4 the correct value is stacklevel=8 (see
https://bugs.python.org/issue24305#msg249981). I'm inclined to think
that this is a bug that should be fixed in 3.4.4, but Larry disagrees
and I don't really care enough to argue about it either way :-).

-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] PEP 495 accepted

[Victor Stinner]

More context ;-)

PEP 0495 -- Local Time Disambiguation

Abstract

This PEP adds a new attribute fold to instances of the datetime.time
and datetime.datetime classes that can be used to differentiate
between two moments in time for which local times are the same. The
allowed values for the fold attribute will be 0 and 1 with 0
corresponding to the earlier and 1 to the later of the two possible
readings of an ambiguous local time.

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

Victor

2015-09-22 0:03 GMT+02:00 Guido van Rossum :
> Just so people know, over at the datetime-sig I've accepted PEP 495, which
> adds a fold flag to datetime objects to distinguish ambiguous times. This
> enables roundripping of conversions for those times where the local clock is
> moved backward (creating ambiguous times that could not be distinguished
> before).
>
> I would like to thank Alexander and Tim for their unrelenting work on this.
> The idea seems simple, but the details were excruciatingly hard to get
> right, given the strict backwards compatibility requirements.
>
> There may well be additional beneficial changes to the datetime module. The
> datetime-sig is now open for their discussion. However, proposals that break
> backwards compatibility are a waste of everybody's time, so be prepared to
> explain how your proposal does not break existing code that works under
> Python 3.5.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> 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/victor.stinner%40gmail.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] Make stacklevel=2 by default in warnings.warn()

[Nick Coghlan]

On 22 Sep 2015 03:16, "Serhiy Storchaka"  wrote:
>
> On 21.09.15 12:05, Nick Coghlan wrote:
>>
>> As Victor notes, though, that's not the right default for *scripts*
>> that are issuing deprecation warnings to end users - there, they
>> really are deprecating themselves. It's also not the right default for
>> pretty much any warning other than DeprecationWarning - for those,
>> you're generally wanting to say "we hit this problematic code path",
>> not report anything about your caller.
>
>
> If a warning is emitted in library function, user can't do anything with
function's code and should change his code that calls the function. In this
case the warning should point to the line where the function is used.
>
> If a warning is emitted in user's code, he is able to add explicit
stacklevel=1 if needed.
>
> stacklevel=2 is correct argument for module level warnings, but as
Nathaniel noted not all packages use it. When your run correctly written
module as script you get the same "sys:1:". And this issue can be solved in
general case.

Aye, combined with your suggestion of not going beyond the top of the stack
when issuing warnings, I've been persuaded that changing the default stack
level to 2 makes sense.

The other relevant thing I recalled is the guidance in
https://docs.python.org/3/howto/logging.html#logging-basic-tutorial, which
suggests using warnings.warn if you want the caller to change their code,
logging.warn otherwise.

Cheers,
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/archive%40mail-archive.com

Re: [Python-Dev] PEP 495 accepted

[Nick Coghlan]

On 22 September 2015 at 08:03, Guido van Rossum  wrote:
> Just so people know, over at the datetime-sig I've accepted PEP 495, which
> adds a fold flag to datetime objects to distinguish ambiguous times. This
> enables roundripping of conversions for those times where the local clock is
> moved backward (creating ambiguous times that could not be distinguished
> before).

Hurrah, and congratulations in particular on finding a name for the
flag which is memorable, meaningful and succinct.

> I would like to thank Alexander and Tim for their unrelenting work on this.
> The idea seems simple, but the details were excruciatingly hard to get
> right, given the strict backwards compatibility requirements.

I don't think I've seen a collision between mathematical and language
level invariants that complex since the first time I had to figure out
the conflict between container membership invariants and floating
point NaN values (and this one is even more subtle).

I'm reading through the full PEP now, and really appreciating the
thorough write up. Thanks to Alexander and Tim, and to all the folks
involved in the extensive discussions!

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