On 05.08.2019 7:22, raymond.hettin...@gmail.com wrote:
We should revisit what we want to do (if anything) about invalid escape
sequences.
For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which
is visible by default. The intention is to make it a SyntaxError in Python 3.
On Mon, Aug 5, 2019, at 00:29, raymond.hettin...@gmail.com wrote:
> The warning crops up frequently, often due to
> third-party packages (such as docutils and bottle) that users can't
> easily do anything about. And during live demos and student workshops,
> it is especially distracting.
Maybe
On 05/08/2019 11:16, Inada Naoki wrote:
> https://github.com/python/cpython/blob/1213123005d9f94bb5027c0a5256ea4d3e97b61d/Include/pyport.h#L158-L168
>
> This can be changed to this:
>
> #ifndef PY_FORMAT_SIZE_T
> /* "z" is defined C99 and portable enough. We can use "%zd" instead of
>"%" PY_FO
On 8/5/19, Steve Dower wrote:
>
> though I do also see many people bitten by FileNotFoundError
> because of a '\n' in their filename.
Thankfully the common filesystems used in Windows reserve ASCII
control characters in filenames (except not in stream names or
named-pipe names). So a mistaken str
On 06/08/2019 07:14:35, Michael wrote:
For "filenames" you could, perhaps, make an exception in the calls that
use them. e.g., when they are hard-coded in something such as
open("..\training\new_memo.doc").
Sorry, that won't work. Strings are parsed at compile time, open() is
executed at ru
On Mon, Aug 05, 2019 at 04:22:50AM -, raymond.hettin...@gmail.com wrote:
> This once seemed like a reasonable and innocuous idea to me; however, I've
> been using the 3.8 beta heavily for a month and no longer think it is a good
> idea. The warning crops up frequently, often due to third-party
Making it an error so soon would be mistake, IMHO. That will break
currently working code for small benefit. When Python was a young
language with a few thousand users, it was easier to make these
kinds of changes. Now, we should be much more conservative and give
people a long time and a lot
On 2019-08-06 17:32, Matt Billenstein wrote:
On Mon, Aug 05, 2019 at 04:22:50AM -, raymond.hettin...@gmail.com wrote:
This once seemed like a reasonable and innocuous idea to me; however, I've
been using the 3.8 beta heavily for a month and no longer think it is a good
idea. The warning cro
On 06Aug2019 0959, Neil Schemenauer wrote:
Could PyPI and pip gain the ability to warn and even fix these
issues? Having a warning from pip at install time could be better
than a warning at import time. If linting was built into PyPI, we
could even do a census to see how many packages would be
On Tue, 6 Aug 2019 at 17:39, Matt Billenstein wrote:
>
> On Mon, Aug 05, 2019 at 04:22:50AM -, raymond.hettin...@gmail.com wrote:
> > This once seemed like a reasonable and innocuous idea to me; however, I've
> > been using the 3.8 beta heavily for a month and no longer think it is a good
> >
On Tue, Aug 06, 2019 at 04:32:04PM +, Matt Billenstein wrote:
> Perhaps those packages could be flagged now via pylint and problems raised
> with
> the respective package maintainers before the actual 3.8 release? Checking
> the
> top 100 or top 1000 packages on PyPI?
fwiw, ran pylint on th
Paul Moore wrote:
> On Tue, 6 Aug 2019 at 17:39, Matt Billenstein m...@vazor.com wrote:
> >
> > On Mon, Aug 05, 2019 at 04:22:50AM -,
> > raymond.hettin...@gmail.com wrote:
> > This once seemed like a reasonable and innocuous
> > idea to me; however, I've
> > been using the 3.8 beta heavily for
Rob Cliffe via Python-Dev wrote:
Sorry, that won't work. Strings are parsed at compile time, open() is
executed at run-time.
It could check for control characters, which are probably the result
of a backslash accident. Maybe even auto-correct them...
--
Greg
On Tue, Aug 6, 2019 at 10:06 AM Neil Schemenauer
wrote:
>
> Making it an error so soon would be mistake, IMHO. That will break
> currently working code for small benefit. When Python was a young
> language with a few thousand users, it was easier to make these
> kinds of changes. Now, we shoul
On Wed, Aug 07, 2019 at 10:41:25AM +1200, Greg Ewing wrote:
> Rob Cliffe via Python-Dev wrote:
> >
> >Sorry, that won't work. Strings are parsed at compile time, open() is
> >executed at run-time.
>
> It could check for control characters, which are probably the result
> of a backslash accident.
On Tue, Aug 06, 2019 at 08:14:35AM +0200, Michael wrote:
> For "filenames" you could, perhaps, make an exception in the calls that
> use them. e.g., when they are hard-coded in something such as
> open("..\training\new_memo.doc").
Functions such as open cannot tell whether their argument was prov
I've updated the text of PEP 588 (https://www.python.org/dev/peps/pep-0588/)
with several items under "Migration Plan" section:
- Hire a professional project manager to help ensure the success of the
project.
- Create a playground issue tracker on GitHub to experiment and test the
new workflow
- T
This really is a hairy one.
The current behaviour encourages people to use a single backslash when
they should be using a double, but that works only sometimes. Should you
include an escape or not? Sometimes the backslash stays and sometimes it
disappears:
py> "abc \d \' xyz"
"abc \\d ' xyz"
On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote:
> - Keep the SyntaxWarning silent by default for 3.8. That gives us
> another year or more to gently pressure third-party libraries to fix
> their code, and to find ways to encourage developers to run with
> warnings enabled.
How do you propo
On 07/08/2019 01:14:08, Chris Angelico wrote:
On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote:
- Keep the SyntaxWarning silent by default for 3.8. That gives us
another year or more to gently pressure third-party libraries to fix
their code, and to find ways to encourage developers to r
People distribute code via pypi. if we reject uploads of packages with
these problems and link to fixers (modernize can be taught what to do), we
prevent them from spreading further. A few years after doing that, we can
revisit how much pain and for whom making this a SyntaxWarning or even
Syntax
On 8/6/2019 5:57 PM, Gregory P. Smith wrote:
People distribute code via pypi. if we reject uploads of packages
with these problems and link to fixers (modernize can be taught what
to do), we prevent them from spreading further. A few years after
doing that, we can revisit how much pain and fo
https://github.com/python/cpython/pull/13482
is a simple doc change for difflib, which I approved some months ago.
But I don't know the current workflow well enough to finish it myself.
Like:
- Does something special need to be done for doc changes?
- Since this is a 1st-time contributor, do
On Tue, Aug 6, 2019 at 3:44 PM Brett Cannon wrote:
> I think this is a good example of how the community is not running tests with
> warnings on and making sure that their code is warnings-free. This warning
> has existed for at least one full release and fixing it doesn't require some
> crazy
>
> - Does something special need to be done for doc changes?
Nothing special.
- Since this is a 1st-time contributor, does it need a change to the ACKS
> file?
I think the change is trivial enough, the misc/acks is not necessary.
- Anything else?
1. Does it need to be backported? If so, pl
On Wed, Aug 07, 2019 at 10:14:08AM +1000, Chris Angelico wrote:
> On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote:
> > - Keep the SyntaxWarning silent by default for 3.8. That gives us
> > another year or more to gently pressure third-party libraries to fix
> > their code, and to find ways t
On Tue, Aug 06, 2019 at 07:58:12PM -0700, Nathaniel Smith wrote:
> For example, all my projects run tests with deprecation warnings
> enabled and warnings turned into errors, but I never saw any of these
> warnings. What happens is: the warning is issued when the .py file is
> byte-compiled; but a
On Wed, Aug 7, 2019 at 1:54 PM Steven D'Aprano wrote:
> Don't think of this as a failure. Think of it as an opportunity: we've
> identified a weakness in our deprecation process. Let's fix that
> process, make sure that *developers* will see the warning in 3.8 or 3.9,
> and not raise an exception
[Mariatta ]
- Since this is a 1st-time contributor, does it need a change to the ACKS
file?
>
> I think the change is trivial enough, the misc/acks is not necessary.
>
> - Anything else?
>
>
> 1. Does it need to be backported? If so, please add the "needs backport to
> .." label.
>
> 2. Add the "🤖
06.08.19 20:37, Paul Moore пише:
I don't see issues reported in the bug trackers for docutils and
bottle. Maybe as a start, someone could raise issues there?
The warning in docutils was fixed.
https://sourceforge.net/p/docutils/code/8255/
___
Python-D
07.08.19 01:37, Brett Cannon пише:
I think this is a good example of how the community is not running tests with
warnings on and making sure that their code is warnings-free. This warning has
existed for at least one full release and fixing it doesn't require some crazy
work-around for backwar
07.08.19 03:31, Rob Cliffe via Python-Dev пише:
How about: whenever a third-party library uses a potentially-wrong
escape sequence, it creates a message on the console. Then when
someone sees that message, they can post a bug report against the
package.
Would not it just increase the amount of
07.08.19 03:57, Gregory P. Smith пише:
People distribute code via pypi. if we reject uploads of packages with
these problems and link to fixers (modernize can be taught what to do),
we prevent them from spreading further.
How can we check that there are such problems in the package? Pass all
33 matches
Mail list logo
