08.08.19 07:55, Toshio Kuratomi пише:
Like the Ansible feature, though, the problem is that over time we've
discovered that it is hard to educate users about the exact
characteristic of the feature (\k == k but \n == newline;
No, \k == \\k. This differs from most other programming languages.
On Mon, Aug 5, 2019 at 6:47 PM wrote:
>
> I wish people with more product management experience would chime in;
> otherwise, 3.8 is going to ship with an intentional hard-to-ignore annoyance
> on the premise that we don't like the way people have been programming and
> that they need to change
Alas, we didn't think of struct sequences when we designed PEP 484. It
seems they are a hybrid of Tuple and NamedTuple; both of these are
currently special-cased in mypy in ways that cannot easily be combined.
Do you really need anonymous fields?
I see an example in
This isn't about me. As a heavy user of the 3.8 beta, I'm just the canary in
the coal mine.
After many encounters with these warnings, I'm starting to believe that
Python's long-standing behavior was convenient for users. Effectively, "\-"
wasn't an error, it was just a way of writing "\-".
On 2019-08-07 23:43, Steve Holden wrote:
This whole thread would be an excellent justification for following 3.9
with 4.0. It's as near as we ever want to get to a breaking change, and
a major version number would indicate the need to review. If increasing
strictness of escape code
On Thu, Aug 8, 2019 at 8:58 AM wrote:
>
> For me, these warnings are continuing to arise almost daily. See two recent
> examples below. In both cases, the code previously had always worked without
> complaint.
>
> - Example from yesterday's class
>
> ''' How old-style formatting
For me, these warnings are continuing to arise almost daily. See two recent
examples below. In both cases, the code previously had always worked without
complaint.
- Example from yesterday's class
''' How old-style formatting works with positional placeholders
print('The answer is
This whole thread would be an excellent justification for following 3.9
with 4.0. It's as near as we ever want to get to a breaking change, and a
major version number would indicate the need to review. If increasing
strictness of escape code interpretation in string literals is the only
> I think this might work:
>
> $ hg diff -r fb80df16c4ff -r tip
>
> Not sure fb80df16c4ff is the correct base revision. It seems to be
> the base of Victor's work. I put the resulting patch file here:
>
> http://python.ca/nas/python/registervm-victor.txt
Thanks, Neil. I barely
On 8/7/19, Steve Dower wrote:
>
> * change the PyErr_SetExcFromWindowsErrWithFilenameObjects function to
> append (or chain) an extra message when either of the filenames contains c
> control characters (or change OSError to do it, or the default
> sys.excepthook)
On a related note for Windows,
[Brett Cannon ]
> We probably need to update https://devguide.python.org/committing/ to
> have a step-by-step list of how to make a merge works and how to
> handle backports instead of the wall of text that we have. (It's already
> outdated anyway, e.g. `Misc/ACKS` really isn't important as git
We probably need to update https://devguide.python.org/committing/ to have a
step-by-step list of how to make a merge works and how to handle backports
instead of the wall of text that we have. (It's already outdated anyway, e.g.
`Misc/ACKS` really isn't important as git itself records the
On 2019-08-07, Skip Montanaro wrote:
> Victor's experiments into a register-based virtual machine live here:
>
> https://hg.python.org/sandbox/registervm
>
> I'd like to revive them, if for no other reason to understand what he
> did. I see no obvious way to collect them all as a massive diff.
Steven D'Aprano wrote:
> Because our processes don't work the way we assumed, it turns out that
> in practice we haven't given developers the deprecation period we
> thought we had. Read Nathaniel's post, if you haven't already done so:
>
On 07Aug2019 0247, Chris Angelico wrote:
On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote:
What's the rush? Let's be objective here: what benefit are we going to
get from this change? Is there anyone hanging out desperately for "\d"
and "\-" to become SyntaxErrors, so they can... do what?
For what I can see, the majority of new users in an interactive environment
seeing the warning will do so because the incorrect string will be
in _their_ code. The benefits are immediate, as people change to either
using raw-strings or using forward-slashes for file paths.
The examples in the
Victor's experiments into a register-based virtual machine live here:
https://hg.python.org/sandbox/registervm
I'd like to revive them, if for no other reason to understand what he
did. I see no obvious way to collect them all as a massive diff. For
the moment, I downloaded each commit and am
On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote:
> What's the rush? Let's be objective here: what benefit are we going to
> get from this change? Is there anyone hanging out desperately for "\d"
> and "\-" to become SyntaxErrors, so they can... do what?
So that problems can start to be
On Wed, 7 Aug 2019 at 10:32, Steven D'Aprano wrote:
> No, I'm saying we don't have to rush this into 3.8. Let's keep the
> warning silent and push everything back a release.
>
> Now is better than never.
> Although never is often better than *right* now.
>
> Right now, we're looking at a
On Wed, Aug 07, 2019 at 02:33:51PM +1000, Chris Angelico wrote:
> 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
Hi all,
Ok, I am about to implement generation of such structures
automatically using the struct sequence concept.
One more question:
--
Struct sequences are not yet members of the typing types.
I would like to add that, because a major use case is also to
show nice .pyi files
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
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 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
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/
___
25 matches
Mail list logo
