[Python-Dev] Should the dataclass frozen property apply to subclasses?

[Raymond Hettinger]

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

>>> class S(D):
pass

>>> s = S()
>>> s.cached = True
Traceback (most recent call last):
  File "", line 1, in 
s.cached = True
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py",
 line 448, in _frozen_setattr
raise FrozenInstanceError(f'cannot assign to field {name!r}')
dataclasses.FrozenInstanceError: cannot assign to field 'cached'

Other immutable classes in Python don't behave the same way:


>>> class T(tuple):
pass

>>> t = T([10, 20, 30])
>>> t.cached = True

>>> class F(frozenset):
pass

>>> f = F([10, 20, 30])
>>> f.cached = True

>>> class B(bytes):
pass

>>> b = B()
>>> b.cached = True


Raymond
___
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] How is the GitHub workflow working for people?

[Abdur-Rahmaan Janhangeer]

>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, "Guido van Rossum"  wrote:

...
___
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] How is the GitHub workflow working for people?

[Benjamin Peterson]

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 (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
> >> code, and detect trailing whitespace on all lines that a PR modifies.
> >>
> >
> > Guido said "no" to this from the outset.
> >
> 
> I'm willing to reconsider if there's a good enough tool. Ditto for C code
> (or do we already do it for C?).

The C/C++ world has very good tooling for formating in the form of 
clang-format. If someone made a clang-format configuration file close to the 
current PEP 7 guide and existing code, I would support running it over the 
entire codbase and enforcing formatting in CI. Massive reformatings of CPython 
C have actually already uneventfully happened: several years ago Antoine 
removed all tabs from C sources.
___
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] How is the GitHub workflow working for people?

[Yury Selivanov]

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 a per-module basis then.
For instance, I believe that all files in asyncio package pass flake8
with default flags (at least I'm doing my best to keep it that way).
Sometimes it takes an extra review round to fix the code style, having
the CI to enforce it would save time for everybody.

Something similar to "cpython/.github/CODEOWNERS" but for enabling
linters would work.

Yury
___
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] How is the GitHub workflow working for people?

[Nick Coghlan]

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 stdlib, how much code would break (even the most conservative
> formatter sometimes breaks code that wasn't expecting to be reformatted --
> e.g. we used to have tests with significant trailing whitespace), and how
> often the result would be just too ugly to look at.

I believe we still run Tools/scripts/reindent.py and
Tools/scripts/reindent-rst.py as pre-merge checks. (I actually thought
we add a reindent-c.py script as well, since Py3 switched all the C
code over to using spaces for indentation to match the Python
conventions, but it appears not).

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] How is the GitHub workflow working for people?

[Nick Coghlan]

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 code, flake8 --possibly with our own custom plugins— is the way 
>> to go.
>
> Is flake8 that much better than pylint, that pylint wouldn't even be 
> discussed?
>
> pylint does warn about some relatively unimportant things out of the
> box, but it can be configured to ignore (almost?) everything it
> checks.

"pylint -E" is my own preferred IDE-level checker (since it's pretty
good about reserving the "Error" category for things that almost
certainly indicate bugs), but all of these tools share a common
problem when applied to CPython: we routinely break them :)

Part of that is permanent breakage in the test suite where we
deliberately test the compiler and interpreter's reaction to invalid
code, while the other part is transient breakage when we introduce new
syntax and other language level constructs.

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] How is the GitHub workflow working for people?

[Guido van Rossum]

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, and I wouldn't want *any* directives for either
one to appear in stdlib code, ever.

In some ideal future all code would just be reformatted before it's checked
in -- we're very far from that, and I used to be horrified by the very
idea, but in the Go world this is pretty much standard practice, and the
people at work who are using it are loving it. So I'm trying to have an
open mind about this. But there simply isn't a tool that does a good enough
job of this.

What I was thinking of was a much weaker option like tabnanny.py by Tim
Peters (still in the stdlib!), but I don't know whether this is feasible.

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 stdlib, how much code would break (even the most conservative
formatter sometimes breaks code that wasn't expecting to be reformatted --
e.g. we used to have tests with significant trailing whitespace), and how
often the result would be just too ugly to look at. If you're not willing
to work on that, please don't respond to this thread.

--Guido

On Wed, Feb 21, 2018 at 7:03 PM, 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 code, flake8 --possibly with our own custom plugins— is the
> way to go.
>
> Is flake8 that much better than pylint, that pylint wouldn't even be
> discussed?
>
> pylint does warn about some relatively unimportant things out of the
> box, but it can be configured to ignore (almost?) everything it
> checks.
>
> I've been editing Python code in vim with syntastic.  I have syntastic
> set up to run pyflakes, pycodestyle and pydocstyle.  And I have a
> macro that saves the buffer, shells out and runs "make" with the
> default rule - and that default rule almost always does a
> whole-program pylint.
>
> It's possible to make pylint check just one file from syntastic, but I
> don't do that because it's too slow on large files.
>
> I've gotten the impression that pylint can detect some errors that
> pyflakes misses.  Not sure about flake8.
>
> I do like it that flake8 has a mccabe check.  pylint doesn't appear to
> have that, and instead relies on things like "too many statements",
> "too many branches" and "too many variables".
> ___
> 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] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

[Ethan Furman]

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 migration, but it's now more
about the general ergonmics of the bytes type, and I don't do enough
low level protocol work these days to have a strong opinion on that.

That new champion could be Elias, or else perhaps Ethan Furman (who
drove the last round of proposed updates to the PEP, which
unfortunately don't appear to have been submitted to the PEPs repo:
https://mail.python.org/pipermail/python-dev/2016-September/146043.html)


The changes were still sitting in my ancient mercurial repo.  Copied into the 
git repo and pushed.

--
~Ethan~

___
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] How is the GitHub workflow working for people?

[Nick Coghlan]

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’s motivated to spearhead a move to GH issues, but I also 
> don’t think that can be taken up lightly.

There are also several additional challenges with migrating the issue
tracker that didn't impact the code migration (at least, not as
badly):

* Issue number preservation: because the previous issue tracker
migration was from SourceForge to self-hosted, the SourceForge issue
numbers could be injected directly into Roundup. As far as I know, we
wouldn't be able to do that for a migration into GitHub - all existing
issues would be arbitrarily renumbered. (The most viable solution to
this would probably be to continue running a redirector on
bugs.python.org that translated existing issue links to their GitHub
counterparts)
* External links to issues are far more common than external links
directly into source control, so a migration strategy for preserving
those would be highly desirable (the redirector above would also help
handle that)
* One of the requirements for the GitHub migration was to continue to
offer contribution workflows that don't require creation of an account
with a proprietary American service provider. That workflow is to post
a patch on Roundup and ask someone else to convert it into a GitHub
PR. As a result, migrating the issue tracker would also mean saying
we're dropping that workflow requirement, and deliberately excluding
everyone without a GitHub account entirely from the core development
process (they won't even be able to file issues any more).
* The Roundup tracker is the database-of-record for CLA signatures. We
don't have the ability to add arbitrary user metadata on GitHub, so if
the issue tracker migrates to GitHub, we'll need a different solution
for CLA tracking.
* Roundup's nosy list is integrated with the experts index in the
developer guide, so an equivalent for that would need to be worked out
for GitHub in order to help out triagers

Personally, the only things I really miss on Roundup vs GitHub issues
are usability tweaks like Markdown support in the comment editor, and
inline dropdowns for @-mentions of other users and #-mentions of other
issues, so if someone is motivated to work on issue tracking
enhancements, that seems like a more fruitful endeavour than trying to
migrate wholesale to a proprietary third party service.

Cheers,
Nick.

P.S. That said, one tracker that I think absolutely *would* be worth
migrating to GitHub is the meta-tracker at
http://psf.upfronthosting.co.za/roundup/meta. We haven't customised
that instance the way we have bugs.python.org, and consolidating it
and the source repo at http://hg.python.org/tracker/roundup/ into a
single https://github.com/python/bugs.python.org repo would better
align tracker development with development on other parts of the
infrastructure.

-- 
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] How is the GitHub workflow working for people?

[Mariatta Wijaya]

>
> 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 case CPython ever migrates away from
> > GitHub; I remember that concern being raised when the original
> > migration was discussed.
> There are tools for it (e.g., I wrote
> https://github.com/mcepl/github-issues-export to move issues to
> Bugzilla, yes I am weird) and it is not that difficult to write
> something just to get data from GitHub’s all embracing arms. Of
> course, I am not sure how it would work on really large number
> of bugs, and it would be necessary to do some postprocessing
> (changing issue numbers etc.).


It's really more complicated than just copying over text from the bpo to
GitHub. Can we preserve the history and the existing discussions?
What about existing patches currently attached to issues? Can the issue
number be preserved?
Everywhere in our commit message we reference bpo-. What will happen to
those?
We'll need to come up with new workflow. How do we want to triage the
issues? And what does it mean to current bug tracker triage permission?

The recent
> improvements to @miss-islington (kudos to Mariatta!) allowing her to
> auto-backport PRs and commit them is a big time saver.


Thanks! I can't take all credit. The bots are easy to build and maintain
mainly because of Brett Cannon's gidgethub [1] library. Thanks Brett!
Also... is this a good time to advertise my PyCon tutorial [2] about
building GitHub bots?

 I still miss my “commit when CI completes” button, but oh well.


It is in my todo list, to at least notify when all CI completed so we can
go back and merge it.
I'll have time to think about this after PyCon US.

if there is a particular sticking point to please bring it up


This has been brought up several times in different mailing lists: Please
clean up the commit message before merging.

1. Ensure bpo-N is included.
If the bpo-N is not included, the commit doesn't get linked to the
issue in the b.p.o.

2. Ensure that the GitHub PR number is replaced, from (#12345) to (GH-12345)
In the b.p.o,  (#12345) links to bugs.python.org/issue12345 instead of
linking to GitHub PR number 12345.

3. Don't reference bpo-N as #N in the commit message.
tl;dr it breaks the bots. See [3] and [4]

One improvement I've been thinking about is related to the way we add news
entry using "blurb add" on the command line.
I wish there's a web UI for doing it. A place where I can type in the news
entry, give it the GitHub PR number, the bpo number, and with a button
click the News.d file magically created and added to the PR. Any thoughts
about this?


Mariatta Wijaya

[1] https://gidgethub.readthedocs.io/en/stable/
[2] https://us.pycon.org/2018/schedule/presentation/41/
[3] https://github.com/python/bedevere/issues/95#issuecomment-366570410
[4] https://github.com/python/bedevere/issues/97



ᐧ
___
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] How is the GitHub workflow working for people?

[Dan Stromberg]

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 way to 
> go.

Is flake8 that much better than pylint, that pylint wouldn't even be discussed?

pylint does warn about some relatively unimportant things out of the
box, but it can be configured to ignore (almost?) everything it
checks.

I've been editing Python code in vim with syntastic.  I have syntastic
set up to run pyflakes, pycodestyle and pydocstyle.  And I have a
macro that saves the buffer, shells out and runs "make" with the
default rule - and that default rule almost always does a
whole-program pylint.

It's possible to make pylint check just one file from syntastic, but I
don't do that because it's too slow on large files.

I've gotten the impression that pylint can detect some errors that
pyflakes misses.  Not sure about flake8.

I do like it that flake8 has a mccabe check.  pylint doesn't appear to
have that, and instead relies on things like "too many statements",
"too many branches" and "too many variables".
___
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 467 (Minor API improvements for binary sequences) - any thoughts?

[Nick Coghlan]

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 ergonmics of the bytes type, and I don't do enough
low level protocol work these days to have a strong opinion on that.

That new champion could be Elias, or else perhaps Ethan Furman (who
drove the last round of proposed updates to the PEP, which
unfortunately don't appear to have been submitted to the PEPs repo:
https://mail.python.org/pipermail/python-dev/2016-September/146043.html)

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] How is the GitHub workflow working for people?

[Brett Cannon]

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 way
> to go.  It would probably take some kind of ratchet or transition period
> before all of the stdlib were compliant.  We’d have to be careful of the
> inevitable raft of PRs to fix things, which may distract from actual bug
> fixes and improvements.  OTOH, that would be another external dependency
> pulled in for core Python development.
>

As long as we pin the version and upgrade only consciously I don't think
it's a massive issue to have an external dependency.

As for C, maybe clang-format?


>
> > FWIW I'm personally hugely happy with the new workflow -- my only regret
> is that we're not using GitHub for issue tracking yet.
>
> I’m very happy with the workflow too, and Mariatta’s and others work has
> been hugely important in making things work so well.  I still miss my
> “commit when CI completes” button, but oh well.
>
> 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’s motivated to spearhead a move to GH issues, but
> I also don’t think that can be taken up lightly.  Just look at the vast
> amount of work Brett and others had to do to migrate code hosting.  It
> would be nice to have integrated reviews and issues (e.g. for auto-closing
> perhaps), but I also honestly don’t miss much with the current suite of
> tools.
>

All I will say is I don't plan on doing this one myself :) .
___
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] Backfilling 'awaiting' labels

[Brett Cannon]

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 is set explaining
> that we're backfilling and if you're ready for a change review then leave
> the magical comment to trigger Bedevere.
>
> My plan is to limit this to only 20 total comments within a day so at to
> not overwhelm any single person with notifications. I will also run this
> script manually so there's no guarantee this will even occur every day.
>
> Assuming that 20 comment/day limit seems reasonable to people I will
> probably do the inaugural run tomorrow which will add an 'awaiting label'
> to 158 issues (which should be more than half of the issues lacking an
> 'awaiting' label).
>
___
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] How is the GitHub workflow working for people?

[Matěj Cepl]

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 it (e.g., I wrote 
https://github.com/mcepl/github-issues-export to move issues to 
Bugzilla, yes I am weird) and it is not that difficult to write 
something just to get data from GitHub’s all embracing arms. Of 
course, I am not sure how it would work on really large number 
of bugs, and it would be necessary to do some postprocessing 
(changing issue numbers etc.).

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
God is not worried about my financial situation.

___
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] How is the GitHub workflow working for people?

[Antoine Pitrou]

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-workflow mailing list so we can potentially address it.

It works great for me.

Regards

Antoine.


___
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] Making "Provisional" an explicit PEP state

[Barry Warsaw]

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



signature.asc
Description: Message signed with OpenPGP
___
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 467 (Minor API improvements for binary sequences) - any thoughts?

[Chris Barker]

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 simply subclass, too (overriding __new__ and a couple
methods). But that would do exactly no good, unless you used your own
custom string and bytes objects, too. The whole point is that iterating
over a string (Or bytes) always returns an also-iterable object,
ad-infinitum.

This is the cause of the major remaining common "type error" in Python.
(the old integer division used to be the big one)


> The fact that characters are single-byte strings is responsible for
> certain anomalies with (e.g.) the __contains__ operator (list elements
> aren't lists, but string element are strings), but overall the choices made
> lead to sensible, comprehensible code.
>

I'm pretty convinced that the choice not to have a character type has had
basically zero benefits to sensible, comprehensible code, though it's not a
very big deal, either. not a big enough deal for the churn it would cause
to introduce it now, that's for sure.

so +1 for this PEP as is.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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 467 (Minor API improvements for binary sequences) - any thoughts?

[Guido van Rossum]

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 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.
>>
>
> well, it was originally targeted for 3.5, so it did need kick to get going.
>
> Probably too late for 3.7.0, but no reason not to get it moving if there
> is support, and aren't objections.
>
> Anyone know if it paused to controversy or just lack of momentum? From a
> quick search, it looks like discussion simply petered out in Sept 2016.
>
> -CHB
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

[Chris Barker]

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.
>

well, it was originally targeted for 3.5, so it did need kick to get going.

Probably too late for 3.7.0, but no reason not to get it moving if there is
support, and aren't objections.

Anyone know if it paused to controversy or just lack of momentum? From a
quick search, it looks like discussion simply petered out in Sept 2016.

-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] How is the GitHub workflow working for people?

[Barry Warsaw]

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 transition period before 
all of the stdlib were compliant.  We’d have to be careful of the inevitable 
raft of PRs to fix things, which may distract from actual bug fixes and 
improvements.  OTOH, that would be another external dependency pulled in for 
core Python development.

> FWIW I'm personally hugely happy with the new workflow -- my only regret is 
> that we're not using GitHub for issue tracking yet.

I’m very happy with the workflow too, and Mariatta’s and others work has been 
hugely important in making things work so well.  I still miss my “commit when 
CI completes” button, but oh well.

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’s motivated to spearhead a move to GH issues, but I also don’t think that 
can be taken up lightly.  Just look at the vast amount of work Brett and others 
had to do to migrate code hosting.  It would be nice to have integrated reviews 
and issues (e.g. for auto-closing perhaps), but I also honestly don’t miss much 
with the current suite of tools.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] How is the GitHub workflow working for people?

[Chris Angelico]

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 have to handle two migrations at once.
>
> When a new serious volunteer steps up we might consider it (a PEP would have
> to be written).
>

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.

ChrisA
___
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] How is the GitHub workflow working for people?

[Terry Reedy]

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 is possible for a merge to 'work', but be 
wrong, but that is all that a human *needs* to do.


and if there is a particular sticking point to please bring 
it up on the core-workflow mailing list so we can potentially address it.


Neither Travis not *nix or Mac buildbots test tkinter code.  I will post 
on the c-w list, but I don't know if that covers buildbots.


--
Terry Jan Reedy

___
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] How is the GitHub workflow working for people?

[Guido van Rossum]

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 steps up we might consider it (a PEP would
have to be written).

-- 
--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] How is the GitHub workflow working for people?

[Ivan Levkivskyi]

> 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  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 (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
>>> code, and detect trailing whitespace on all lines that a PR modifies.
>>>
>>
>> Guido said "no" to this from the outset.
>>
>
> I'm willing to reconsider if there's a good enough tool. Ditto for C code
> (or do we already do it for C?).
>
> FWIW I'm personally hugely happy with the new workflow -- my only regret
> is that we're not using GitHub for issue tracking yet.
>
> --
> --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/
> levkivskyi%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] Update tcl/tk to 8.6.latest on Windows?

[Terry Reedy]

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 
current 8.6.8?


Yes, please open an issue for this. See also 
https://bugs.python.org/issue27647 and https://bugs.python.org/issue15663.


https://bugs.python.org/issue32901

--
Terry Jan Reedy


___
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] How is the GitHub workflow working for people?

[Bernát Gábor]

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 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
>>> code, and detect trailing whitespace on all lines that a PR modifies.
>>>
>>
>> Guido said "no" to this from the outset.
>>
>
> I'm willing to reconsider if there's a good enough tool. Ditto for C code
> (or do we already do it for C?).
>
> FWIW I'm personally hugely happy with the new workflow -- my only regret
> is that we're not using GitHub for issue tracking yet.
>
> --
> --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/
> jokerjokerer%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] How is the GitHub workflow working for people?

[Guido van Rossum]

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 big time saver.
>>
>> I can only suggest a couple improvements:
>>
>> 1. Make our bots check the code style—fully enforce PEP 8, lint the
>> code, and detect trailing whitespace on all lines that a PR modifies.
>>
>
> Guido said "no" to this from the outset.
>

I'm willing to reconsider if there's a good enough tool. Ditto for C code
(or do we already do it for C?).

FWIW I'm personally hugely happy with the new workflow -- my only regret is
that we're not using GitHub for issue tracking yet.

-- 
--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

[Python-Dev] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

[Elias Zamaria]

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 am waiting for this to be merged, or approved, or whatever is the next
step. Someone on the bug tracker mentioned restarting the discussion on the
mailing list, so that is what I'm trying to do here. Does anyone have any
thoughts?
___
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 467 (Minor API improvements for binary sequences) - any thoughts?

[Steve Holden]

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
__contains__ operator (list elements aren't lists, but string element are
strings), but overall the choices made lead to sensible, comprehensible
code.

regards
 Steve

Steve Holden

On Wed, Feb 21, 2018 at 8:26 PM, Chris Barker  wrote:

> 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 the bug tracker mentioned restarting the discussion on the
>> mailing list, so that is what I'm trying to do here. Does anyone have any
>> thoughts?
>>
>
> +1 all around.
>
> One other thought:
>
> : Addition of optimised iterator methods that produce bytes objects
>
> Maybe it would make sense to have a "byte" type that holds a single byte.
> It would be an integer that could only hold values from 0-255. Then the
> regular iterator could simply return a bunch of single byte objects.
>
> I can't say I've thought it through, but if a byte is a int with
> restricted range, then it could act like an int in (almost?) every context,
> so there would be no need for a separate iterator.
>
> I also haven't thought through whether there is any real advantage to
> having such a type -- but off the top of my head, making a distinction
> between a bytes object that happens to be length-one and a single byte
> could be handy. I sure do often wish for a character object.
>
> -CHB
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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/
> steve%40holdenweb.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] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

[Chris Barker]

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 the bug tracker mentioned restarting the discussion on the
> mailing list, so that is what I'm trying to do here. Does anyone have any
> thoughts?
>

+1 all around.

One other thought:

: Addition of optimised iterator methods that produce bytes objects

Maybe it would make sense to have a "byte" type that holds a single byte.
It would be an integer that could only hold values from 0-255. Then the
regular iterator could simply return a bunch of single byte objects.

I can't say I've thought it through, but if a byte is a int with restricted
range, then it could act like an int in (almost?) every context, so there
would be no need for a separate iterator.

I also haven't thought through whether there is any real advantage to
having such a type -- but off the top of my head, making a distinction
between a bytes object that happens to be length-one and a single byte
could be handy. I sure do often wish for a character object.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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 467 (Minor API improvements for binary sequences) - any thoughts?

[Ethan Furman]

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 seen at
https://github.com/python/cpython/pull/3237.

I am waiting for this to be merged, or approved, or whatever is the next step. 
Someone on the bug tracker mentioned
restarting the discussion on the mailing list, so that is what I'm trying to do 
here. Does anyone have any thoughts?


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.


--
~Ethan~

___
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] How is the GitHub workflow working for people?

[Steve Holden]

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
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Brett Cannon]

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. Make our bots check the code style—fully enforce PEP 8, lint the
> code, and detect trailing whitespace on all lines that a PR modifies.
>

Guido said "no" to this from the outset.


>
> 2. AppVeyor and Travis are a bit slow at times.  Maybe it's possible
> to ask them to slightly increase our quotas (again).  Although usually
> this isn't a problem and CI is fast enough.
>

We already have a huge amount of quota from Travis and AppVeyor is no
special quota (we're just like any other open source project). Our contact
at Circle CI left the company so that option has walked away.

IOW we either have to find another CI provider who happens to be faster or
we are going to have to build our own.


>
> 3. It would be great if our buildbots could update the PR at blame
> when they detect a regression (I understand that this is a hard to
> implement feature...)
>

Possibly. This is starting to dive into Bors/Zuul-level regression
management which is more infrastructure to run, so we would have to decide
we seriously want this maintenance overhead.

-Brett


>
> Huge thanks to the core-workflow team!
>
> Yury
>
> On Tue, Feb 20, 2018 at 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 and if there is a particular sticking point to please bring it
> up
> > on the core-workflow mailing list so we can potentially address it.
> >
> > ___
> > 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/yselivanov.ml%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] How is the GitHub workflow working for people?

[Yury Selivanov]

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
code, and detect trailing whitespace on all lines that a PR modifies.

2. AppVeyor and Travis are a bit slow at times.  Maybe it's possible
to ask them to slightly increase our quotas (again).  Although usually
this isn't a problem and CI is fast enough.

3. It would be great if our buildbots could update the PR at blame
when they detect a regression (I understand that this is a hard to
implement feature...)

Huge thanks to the core-workflow team!

Yury

On Tue, Feb 20, 2018 at 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 and if there is a particular sticking point to please bring it up
> on the core-workflow mailing list so we can potentially address it.
>
> ___
> 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/yselivanov.ml%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] Update tcl/tk to 8.6.latest on Windows?

[Serhiy Storchaka]

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. See also 
https://bugs.python.org/issue27647 and https://bugs.python.org/issue15663.


___
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] Update tcl/tk to 8.6.latest on Windows?

[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?


--
Terry Jan Reedy

___
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