When working on the docs for dataclasses, something unexpected came up. If a
dataclass is specified to be frozen, that characteristic is inherited by
subclasses which prevents them from assigning additional attributes:
>>> @dataclass(frozen=True)
class D:
x: int = 10
>>
>FWIW I'm personally hugely happy with
>the new workflow -- my only regret is
>that we're not using GitHub for issue
>tracking yet.
Btw you can create your own issue labels. some pythonic names can be
considered
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
On 22 Feb 2018 01:23, "Gu
On Wed, Feb 21, 2018, at 13:22, Guido van Rossum wrote:
> On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon wrote:
>
> >
> >
> > On Wed, 21 Feb 2018 at 09:30 Yury Selivanov
> > wrote:
> >
> >> FWIW I'm extremely happy with the current workflow. The recent
> >> improvements to @miss-islington (kudo
On Wed, Feb 21, 2018 at 10:27 PM, Guido van Rossum wrote:
[..]
> I honestly expect that running either with close-to-default flags on stdlib
> code would be a nightmare, and I wouldn't want *any* directives for either
> one to appear in stdlib code, ever.
It would be great to enable the linter on
On 22 February 2018 at 13:27, Guido van Rossum wrote:
> What we need now is not more opinions on which formatter or linter is best.
> We need someone to actually do some work and estimate how much code would be
> changed if we ran e.g. tabnanny.py (or something more advanced!) over the
> entire st
On 22 February 2018 at 13:03, Dan Stromberg wrote:
> On Wed, Feb 21, 2018 at 2:19 PM, Barry Warsaw wrote:
>> On Feb 21, 2018, at 13:22, Guido van Rossum wrote:
>>>
>>> I'm willing to reconsider if there's a good enough tool. Ditto for C code
>>> (or do we already do it for C?).
>>
>> For Python
Where I work we have some teams using flake8 and some teams that use
pylint, and while pylint is more thorough, it is also slower and pickier,
and the general sense is to strongly prefer flake8.
I honestly expect that running either with close-to-default flags on stdlib
code would be a nightmare,
On 02/21/2018 06:52 PM, Nick Coghlan wrote:
On 22 February 2018 at 08:35, Guido van Rossum wrote:
It's too late for 3.7 period, but there's no reason it can't be considered
for 3.8.
Something else the PEP needs is a new champion - my original interest
was to help lower barriers to Python 3 mi
On 22 February 2018 at 08:19, Barry Warsaw wrote:
> As for the bug tracker, I still do like Roundup, and we have a huge
> investment in it, not just in resources expended to make it rock, but also in
> all the history in it and everything that integrates with it. I wouldn’t
> stop anybody who’
>
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow
It's been great! Thanks!
> Said PEP may also need to mention the possibility of exporting
> > the history of GitHub issues, in cas
On Wed, Feb 21, 2018 at 2:19 PM, Barry Warsaw wrote:
> On Feb 21, 2018, at 13:22, Guido van Rossum wrote:
>>
>> I'm willing to reconsider if there's a good enough tool. Ditto for C code
>> (or do we already do it for C?).
>
> For Python code, flake8 --possibly with our own custom plugins— is the
On 22 February 2018 at 08:35, Guido van Rossum wrote:
> It's too late for 3.7 period, but there's no reason it can't be considered
> for 3.8.
Something else the PEP needs is a new champion - my original interest
was to help lower barriers to Python 3 migration, but it's now more
about the general
On Wed, 21 Feb 2018 at 14:21 Barry Warsaw wrote:
> On Feb 21, 2018, at 13:22, Guido van Rossum wrote:
> >
> > I'm willing to reconsider if there's a good enough tool. Ditto for C
> code (or do we already do it for C?).
>
> For Python code, flake8 --possibly with our own custom plugins— is the wa
FYI I am now done backfilling issues.
On Tue, 30 Jan 2018 at 19:35 Brett Cannon wrote:
> I have written a script that will go through and backfill the 'awaiting'
> label on older pull requests based on the review state as it stands today.
> A comment will be left if an "awaiting changes" label i
On 2018-02-21, 21:49 GMT, Chris Angelico wrote:
> Said PEP may also need to mention the possibility of exporting
> the history of GitHub issues, in case CPython ever migrates away from
> GitHub; I remember that concern being raised when the original
> migration was discussed.
There are tools for
On Wed, 21 Feb 2018 01:58:15 +
Brett Cannon wrote:
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow and if there is a particular sticking point to please bring it up
> on the core-
On Feb 20, 2018, at 22:42, Nick Coghlan wrote:
>
> In the current PEP workflow, provisionally accepted PEPs are marked as
> "Accepted", and remain in that state until they're declared stable and
> moved to Final.
I left a review on the PR, but the substance of the changes LGTM!
-Barry
signat
On Wed, Feb 21, 2018 at 12:39 PM, Steve Holden wrote:
> I think the chances of a "byte" object are about as good as the chances of
> a character object
>
probably right.
> (though one can always implement such in C extensions, that wouldn't build
> them into the syntax).
>
I think you could s
It's too late for 3.7 period, but there's no reason it can't be considered
for 3.8.
On Wed, Feb 21, 2018 at 2:30 PM, Chris Barker wrote:
> On Wed, Feb 21, 2018 at 12:21 PM, Ethan Furman wrote:
>
>> At this point the PEP itself has not been approved, and is undergoing
>> changes. I don't see an
On Wed, Feb 21, 2018 at 12:21 PM, Ethan Furman wrote:
> At this point the PEP itself has not been approved, and is undergoing
> changes. I don't see anything happening with it right now while 3.7 is
> going through it's final stages to release. Once 3.7.0 is published we can
> come back to this
On Feb 21, 2018, at 13:22, Guido van Rossum wrote:
>
> I'm willing to reconsider if there's a good enough tool. Ditto for C code (or
> do we already do it for C?).
For Python code, flake8 --possibly with our own custom plugins— is the way to
go. It would probably take some kind of ratchet or
On Thu, Feb 22, 2018 at 8:38 AM, Guido van Rossum wrote:
> On Wed, Feb 21, 2018 at 1:28 PM, Bernát Gábor
> wrote:
>>
>> Any reason in particular for not using github issues (or blockers in
>> achieving this)?
>
>
> Many core devs did not want to change their workflow, and Brett did not want
> to
On 2/20/2018 8:58 PM, Brett Cannon wrote:
It's been a year and 10 days since we moved to GitHub, so I figured now
is as good a time as any to ask people if they are generally happy with
the workflow
***The nearly automatic backporting!!! A responsible human *should*
check backport PRs, as it
On Wed, Feb 21, 2018 at 1:28 PM, Bernát Gábor
wrote:
> Any reason in particular for not using github issues (or blockers in
> achieving this)?
>
Many core devs did not want to change their workflow, and Brett did not
want to have to handle two migrations at once.
When a new serious volunteer st
> I'm personally hugely happy with the new workflow -- my only regret is
that we're not using GitHub for issue tracking yet.
I have the same feelings. I like the GitHub issue tracker, and it would be
great to migrate there (if possible).
--
Ivan
On 21 February 2018 at 21:22, Guido van Rossum
On 2/21/2018 5:22 AM, Serhiy Storchaka wrote:
21.02.18 12:12, Terry Reedy пише:
3.7.0b1 Windows installer installs tcl/tk 8.6.6, which is a couple of
years old. Same for Windows repository builds. I believe the MacOS
installer shipped with something later. Can we update Windows to the
curre
Any reason in particular for not using github issues (or blockers in
achieving this)?
On 21 Feb 2018 21:25, "Guido van Rossum" wrote:
> On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon wrote:
>
>>
>>
>> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov
>> wrote:
>>
>>> FWIW I'm extremely happy with the
On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon wrote:
>
>
> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov
> wrote:
>
>> FWIW I'm extremely happy with the current workflow. The recent
>> improvements to @miss-islington (kudos to Mariatta!) allowing her to
>> auto-backport PRs and commit them is a bi
This is about some minor changes to the bytes, bytearray, and memoryview
classes. Here is the PEP: https://www.python.org/dev/peps/pep-0467/
The page in the bug tracker can be seen at
https://bugs.python.org/issue27923 and the pull request can be seen at
https://github.com/python/cpython/pull/3237
I think the chances of a "byte" object are about as good as the chances of
a character object (though one can always implement such in C extensions,
that wouldn't build them into the syntax). The fact that characters are
single-byte strings is responsible for certain anomalies with (e.g.) the
__con
On Wed, Feb 21, 2018 at 11:55 AM, Elias Zamaria wrote:
> This is about some minor changes to the bytes, bytearray, and memoryview
> classes. Here is the PEP: https://www.python.org/dev/peps/pep-0467/
>
> I am waiting for this to be merged, or approved, or whatever is the next
> step. Someone on
On 02/21/2018 11:55 AM, Elias Zamaria wrote:
This is about some minor changes to the bytes, bytearray, and memoryview
classes. Here is the PEP:
https://www.python.org/dev/peps/pep-0467/
The page in the bug tracker can be seen at https://bugs.python.org/issue27923
and the pull request can be s
On Wed, Feb 21, 2018 at 5:53 PM, Brett Cannon wrote:
>
>
> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov
> wrote:
>
>>
>
>
>> Huge thanks to the core-workflow team!
>>
>>
Hear, hear!
regards
Steve
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Wed, 21 Feb 2018 at 09:30 Yury Selivanov wrote:
> FWIW I'm extremely happy with the current workflow. The recent
> improvements to @miss-islington (kudos to Mariatta!) allowing her to
> auto-backport PRs and commit them is a big time saver.
>
> I can only suggest a couple improvements:
>
> 1.
FWIW I'm extremely happy with the current workflow. The recent
improvements to @miss-islington (kudos to Mariatta!) allowing her to
auto-backport PRs and commit them is a big time saver.
I can only suggest a couple improvements:
1. Make our bots check the code style—fully enforce PEP 8, lint the
21.02.18 12:12, Terry Reedy пише:
3.7.0b1 Windows installer installs tcl/tk 8.6.6, which is a couple of
years old. Same for Windows repository builds. I believe the MacOS
installer shipped with something later. Can we update Windows to the
current 8.6.8?
Yes, please open an issue for this.
3.7.0b1 Windows installer installs tcl/tk 8.6.6, which is a couple of
years old. Same for Windows repository builds. I believe the MacOS
installer shipped with something later. Can we update Windows to the
current 8.6.8?
--
Terry Jan Reedy
___
Py
37 matches
Mail list logo
