[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
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
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
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
>
> - 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,
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
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,
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
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
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
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
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"
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
-
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
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
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
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
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
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
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 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 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
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 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
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
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
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
>"%"
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.
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
On 05/08/2019 06:22, raymond.hettin...@gmail.com wrote:
I have read through (most) of the thread, and visited the issue referenced.
> We should revisit what we want to do (if anything) about invalid escape
> sequences.
IMHO - revisit is okay, generally - but that was actually done a long
time
30 matches
Mail list logo
