Re: [Python-Dev] PEP 575, 576, 579 and 580

eryone actually uses? That's already broken on every minor release, so you shouldn't spend any time worrying about preserving compatibility there. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] On the METH_FASTCALL calling convention

ime on. But kwargs do improve readability, and it's nice when we can make readable code fast, so people aren't tempted to obfuscate things in the name of speed. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python

Re: [Python-Dev] Don't assign to a variable used later in the expression

On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev wrote: > On 04.07.2018 10:10, Nathaniel Smith wrote: >> Right, Python has a *very strong* convention that each line should >> have at most one side-effect, and that if it does have a side-effect >> it should be a

Re: [Python-Dev] Assignment expression and coding style: the while True case

ense to try to define some Official Universal Rule about when := is appropriate and when it isn't. That said, FWIW, my current feeling is that this simplest case is the only one where I would use :=; for your other examples I'd stick with the loop-and-a-half style. -n -- Nathaniel J. Smith -- https://vorpus.o

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 4, 2018, 09:09 Steven D'Aprano wrote: > On Wed, Jul 04, 2018 at 12:10:11AM -0700, Nathaniel Smith wrote: > > > Right, Python has a *very strong* convention that each line should > > have at most one side-effect, > > import math, fractions, decimal > &g

Re: [Python-Dev] Examples for PEP 572

P authors response would be to the issues that bother me :-(. -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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] Examples for PEP 572

in time) as trivial as possible." It's very disheartening that not only is PEP 572 apparently going to be accepted, but as far as I can tell neither the text nor its proponents have even addressed this basic issue. -n -- Nathaniel J. Smith -- https://vorpus.org

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

> On Jun 27, 2018, at 9:49 AM, Steven D'Aprano wrote: > >> On Wed, Jun 27, 2018 at 08:00:20AM -0400, Eric V. Smith wrote: >>> On 6/27/2018 7:08 AM, Chris Angelico wrote: >>> It gets funnier with nested loops. Or scarier. I've lost the ability >>> to d

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/27/2018 7:08 AM, Chris Angelico wrote: It gets funnier with nested loops. Or scarier. I've lost the ability to distinguish those two. def test(): spam = 1 ham = 2 vars = [key1+key2 for key1 in locals() for key2 in locals()] return vars Wanna guess what that's gonna

Re: [Python-Dev] [python-committers] 3.7.0 / 3.6.6 Update: all systems go for final releases!

Congrats, Ned. Thank you for all of your hard work! -- Eric > On Jun 26, 2018, at 2:39 AM, Ned Deily wrote: > > A quick update: after many months we are at the finish line. We are on > track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on > 2018-06-27. Since 3.7.0rc1 shipped 2

Re: [Python-Dev] We now have C code coverage!

service for aggregation and reporting. The coverage information is being gathered while running CPython's regular CI tests, and then uploaded to codecov.io to view. So if you want to run the gui tests -- which seems like a good idea if possible! -- then the way to do that would be to make them run

Re: [Python-Dev] About [].append == [].append

ters whether the 'self' comparison uses == or 'is', but the method object doesn't know whether 'self' is mutable, so it has to either work in general or not work in general. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org h

Re: [Python-Dev] A more flexible task creation

all those Task objects up front, then that front-loads a chunk of work (i.e., allocating all those objects!) that otherwise would be spread throughout the queue processing. So you'll see a noticeable pause up front before the code starts working. -n -- Nathaniel J. Smith -- https://v

Re: [Python-Dev] A more flexible task creation

How about: async def wait_to_run(async_fn, *args): await wait_for_something() return await async_fn(*args) task = loop.create_task(wait_to_run(myfunc, ...)) - Whatever strategy you use, you should also think about what semantics you want if one of these delayed tasks is cancelled

Re: [Python-Dev] Stable ABI

On 6/3/2018 10:55 AM, Christian Tismer wrote: On 03.06.18 13:18, Ronald Oussoren wrote: On 3 Jun 2018, at 12:03, Christian Tismer wrote: ... I have written a script that scans all relevant header files and analyses all sections which are reachable in the limited API context. All macros

Re: [Python-Dev] PyIndex_Check conflicts with PEP 384

Indeed, that sounds like a pretty straightforward bug in the stable ABI. You should file an issue on bugs.python.org so it doesn't get lost (and if it's the main new stable ABI break in 3.7 then you should probably mark that bug as a release blocker so that Ned notices it). Unfortunately, very

Re: [Python-Dev] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Wed, May 30, 2018, 14:21 Victor Stinner wrote: > 2018-05-30 18:02 GMT+02:00 Nathaniel Smith : > > On Wed, May 30, 2018, 07:30 Victor Stinner wrote: > >> > >> Does anyone would benefit of MemoryBIO in Python 2.7? Twisted, > >> asyncio, trio, urllib3, a

Re: [Python-Dev] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

On Wed, May 30, 2018, 07:30 Victor Stinner wrote: > Does anyone would benefit of MemoryBIO in Python 2.7? Twisted, > asyncio, trio, urllib3, anyone else? Asyncio and trio are strongly py3-only. Twisted's TLS functionality is built around pyopenssl, so the stdlib ssl module doesn't affect them.

Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

Isn't that what happens if someone enables the check box at Repository Settings -> Branches -> Branch protection rules -> [pick a branch] -> Require branches to be up to date before merging ? On Mon, May 28, 2018, 09:11 Brett Cannon wrote: > Ryan is right that there's no special setting in

Re: [Python-Dev] PEP 574 (pickle 5) implementation and backport available

e inefficient when you're transmitting pickles between two processes on the same system – they still add extra memory copies. And that's a very common use case. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-De

Re: [Python-Dev] My fork lacks a 3.7 branch - can I create it somehow?

are purely a matter of convention. -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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] please help triage VSTS failures

18, 2018 at 5:35 PM Nathaniel Smith <n...@pobox.com> wrote: > On Fri, May 18, 2018 at 1:13 PM, Steve Dower <steve.do...@python.org> > wrote: > > According to the VSTS dev team, an easy “rerun this build” button and > > filtering by changed paths are coming soon, which sho

Re: [Python-Dev] please help triage VSTS failures

uch information to go on besides that build log. -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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] please help triage VSTS failures

These both look like VSTS infrastructure falling over on PRs: https://python.visualstudio.com/cpython/_build?buildId=522 https://python.visualstudio.com/cpython/_build?buildId=523 I don't see anywhere that gives information about the failures. (*) These CI failures on different platforms are

Re: [Python-Dev] [Python-checkins] bpo-33522: Enable CI builds on Visual Studio Team Services (GH-6865) (GH-6925)

Why did this commit modify .py files, unittests, and test.support? That is inappropriate for something claiming to merely enable a CI platform. -gps On Thu, May 17, 2018 at 6:50 AM Steve Dower wrote: > >

Re: [Python-Dev] Why aren't escape sequences in literal strings handled by the tokenizer?

On 5/17/2018 3:01 PM, Larry Hastings wrote: I fed this into tokenize.tokenize(): b''' x = "\u1234" ''' I was a bit surprised to see \U in the output.  Particularly because the output (t.string) was a *string* and not *bytes*. For those (like me) who have no idea how to use

Re: [Python-Dev] What is the rationale behind source only releases?

On 5/16/18 4:34 AM, Serhiy Storchaka wrote: 16.05.18 07:35, Alex Walters пише: [1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence And I wish that every author who suggested the idea for Python was familiar with the Chesterton's fence principle. Indeed! It's refreshing.

Re: [Python-Dev] PEP 572 and f-strings

> On May 12, 2018, at 9:03 AM, Chris Angelico <ros...@gmail.com> wrote: > >> On Sat, May 12, 2018 at 9:11 PM, Eric V. Smith <e...@trueblade.com> wrote: >> I don't think it matters to its acceptance, but PEP 572 should at least >> mention that the := syntax

[Python-Dev] PEP 572 and f-strings

I don't think it matters to its acceptance, but PEP 572 should at least mention that the := syntax means that you cannot use assignment expressions in f-strings. As I wrote in a python-ideas email, f'{x:=4}' already has a defined meaning (even if no one is using it). Eric

Re: [Python-Dev] Slow down...

> On May 8, 2018, at 11:48 AM, Brett Cannon wrote: > > > >> On Tue, 8 May 2018 at 08:26 Craig Rodrigues wrote: >>> On Mon, May 7, 2018 at 2:24 PM Barry Warsaw wrote: >>> On May 7, 2018, at 11:49, Craig Rodrigues

Re: [Python-Dev] A fast startup patch (was: Python startup time)

On Sat, May 5, 2018, 11:34 Toshio Kuratomi <a.bad...@gmail.com> wrote: > > > On Sat, May 5, 2018, 10:40 AM Eric Fahlgren <ericfahlg...@gmail.com> > wrote: > >> On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi <a.bad...@gmail.com> >> wrote: >>

Re: [Python-Dev] A fast startup patch (was: Python startup time)

What are the obstacles to including "preloaded" objects in regular .pyc files, so that everyone can take advantage of this without rebuilding the interpreter? Off the top of my head: We'd be making the in-memory layout of those objects part of the .pyc format, so we couldn't change that within a

Re: [Python-Dev] Process to remove a Python feature

On Fri, May 4, 2018, 11:50 Serhiy Storchaka wrote: > > Ideally any deprecated feature should have a replacement, and this > replacement should be available in at least one version before adding > the deprecation warning. > > X.Y: added a replacement > > X.Y+1: added a

Re: [Python-Dev] Python startup time

On Thu, May 3, 2018 at 5:22 PM, Lukasz Langa wrote: > > > On May 2, 2018, at 8:57 PM, INADA Naoki wrote: > > > > Recently, I reported how stdlib slows down `import requests`. > > https://github.com/requests/requests/issues/4315#issuecomment-385584974 > >

Re: [Python-Dev] A fast startup patch (was: Python startup time)

+1 to the concept! On Thu, May 3, 2018 at 1:13 PM, Carl Shapiro wrote: > Hello, > > Yesterday Neil Schemenauer mentioned some work that a colleague of mine > (CCed) and I have done to improve CPython start-up time. Given the recent > discussion, it seems timely to

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018 at 2:13 PM, Barry Warsaw wrote: > Thanks for bringing this topic up again. At $day_job, this is a highly > visible and important topic, since the majority of our command line tools > are written in Python (of varying versions from 2.7 to 3.6). Some of

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, 20:59 INADA Naoki wrote: > Recently, I reported how stdlib slows down `import requests`. > https://github.com/requests/requests/issues/4315#issuecomment-385584974 [...] > * Add faster and simpler http.parser (maybe, based on h11 [1]) and avoid >

Re: [Python-Dev] PEP 575: Unifying function/method classes

On 5/3/2018 6:22 AM, Jeroen Demeyer wrote: On 2018-05-03 11:30, Victor Stinner wrote: Please don't queue backward incompatible changes for Python 4.0. You should use the regular deprecation process. I don't really see how that can be done here. As Stefan said The problem is that this change

Re: [Python-Dev] [RELEASE] Python 2.7.15

I would guess that the folks who end up supporting python 2 past 2020 (either as distributors or as library authors) will have an easier time of it if python 2's ssl module gets resynced with python 3 before the eol. But I suppose it's up to them to do the work... and probably other changes like

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, 09:51 Gregory Szorc wrote: > Correct me if I'm wrong, but aren't there downsides with regards to C > extension compatibility to not having a shared libpython? Or does all the > packaging tooling "just work" without a libpython? (It's possible I have

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

On 4/27/2018 8:28 AM, Steven D'Aprano wrote: On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote: Now we got standard library features requiring type annotation We do? Did I miss them? Which std lib features are you referring to? (That's not a rhetorical question -- maybe I have

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

essions. Expecting new users to realize that this is possible, and a good idea, and to implement it, and get it right, while they're in the middle of being confused about basic python things, is not terribly reasonable, so it's probably underused. But there are ways we could address that. -n --

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

ossible use-cases, but interestingly, the fraction it covers includes: - two of the three real examples given in the rationale section - exactly the cases that *don't* force you to twist your brain in pretzels thinking about sequential side-effecting control flow in the middle of expressions

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

dn't change anything about how the code worked (apart > from possibly clobbering a local name). I thought this was what q was for :-) https://pypi.org/project/q/ -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] PEP 572: Assignment Expressions

On Wed, Apr 18, 2018 at 11:04 AM Barry Warsaw wrote: > On Apr 18, 2018, at 10:43, MRAB wrote: > > > Some languages use '=' for assignment, others for equality, but do you > know of a language that uses ':=' for equality' or '==' for assignment? > >

[Python-Dev] PEP 561 implemented and minor clarification

, the PEP text is replicated below. Cheers! Ethan == PEP: 561 Title: Distributing and Packaging Type Information Author: Ethan Smith <et...@ethanhs.me> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 09-Sep-2017 Python-Version: 3.7 Post-History: 10-Sep-2017,

Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)

der the hood... -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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] Timeline for Pull request reviews in 3.8

Hi, Anthony. On 4/5/2018 10:57 PM, Anthony Flury via Python-Dev wrote: Can anyone enlighten me on what the expected time-line is for reviewing pull requests made on 3.8. I can give you the timeline for releases. Unfortunately, volunteer time is short for reviews. I made a few simple fixes

Re: [Python-Dev] Python version numbers

that I doubt there's much appetite for fiddling with it... -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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] Why is pickle.DEFAULT_PROTOCOL still 3?

On Mon, Apr 2, 2018 at 3:57 PM Lukasz Langa wrote: > > > On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote: > > > > On Mon, 2 Apr 2018 13:48:46 -0700 > > Lukasz Langa wrote: > >> Pickle protocol version 4.0 was originally defined back in

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

Given that, go ahead and change in master (3.8). On Mon, Apr 2, 2018 at 3:13 PM Christian Heimes wrote: > On 2018-04-02 22:48, Lukasz Langa wrote: > > Pickle protocol version 4.0 was originally defined back in PEP 3154 and > shipped as part of Python 3.4 back in 2011. Yet

Re: [Python-Dev] Subtle difference between f-strings and str.format()

s* distinguishable by user code, at least in principle. If we want to change the language spec, I guess it would be with text like: "if bool(obj) would be called twice in immediate succession, with no other code in between, then the interpret

Re: [Python-Dev] Subtle difference between f-strings and str.format()

On 3/29/2018 12:13 PM, Nick Coghlan wrote: On 29 March 2018 at 21:50, Eric V. Smith <e...@trueblade.com> wrote: #1 seems so complex as to not be worth it, given the likely small overall impact of the optimization to a large program. If the speedup really is sufficiently imp

Re: [Python-Dev] Subtle difference between f-strings and str.format()

On 3/29/2018 6:17 AM, Jeff Allen wrote: My credentials for this are that I re-worked str.format in Jython quite extensively, and I followed the design of f-strings a bit when they were introduced, but I haven't used them to write anything. Thanks for your work on Jython. And hop on the

Re: [Python-Dev] PEP 574 -- Pickle protocol 5 with out-of-band data

On Thu, Mar 29, 2018, 02:02 Chris Angelico <ros...@gmail.com> wrote: > On Thu, Mar 29, 2018 at 7:56 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 29 March 2018 at 09:49, Chris Angelico <ros...@gmail.com> wrote: > >> On Thu, Mar 29, 2018 at 7:18 PM, Na

Re: [Python-Dev] PEP 574 -- Pickle protocol 5 with out-of-band data

On Thu, Mar 29, 2018 at 12:56 AM, Chris Jerdonek <chris.jerdo...@gmail.com> wrote: > On Wed, Mar 28, 2018 at 6:15 PM, Nathaniel Smith <n...@pobox.com> wrote: >> On Wed, Mar 28, 2018 at 1:03 PM, Serhiy Storchaka <storch...@gmail.com> >> wrote: >>> 28.03.18

Re: [Python-Dev] PEP 574 -- Pickle protocol 5 with out-of-band data

into, that only promises compatibility within a given 3.X release cycle? Like version=-2 or version=pickle.NONPORTABLE or something? (This is orthogonal to Antoine's PEP.) -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Pyth

Re: [Python-Dev] Subtle difference between f-strings and str.format()

I’d vote #3 as well. -- Eric > On Mar 28, 2018, at 11:27 AM, Serhiy Storchaka wrote: > > There is a subtle semantic difference between str.format() and "equivalent" > f-string. > >'{}{}'.format(a, b) >f'{a}{b}' > > In the former case b is evaluated before

Re: [Python-Dev] descriptor __set_name__ and dataclasses

On 3/26/18 11:10 AM, Eric V. Smith wrote: On 3/26/18 11:08 AM, Nick Coghlan wrote: On 27 March 2018 at 00:40, Eric V. Smith <e...@trueblade.com> wrote: Would it be feasible to define `Field.__set_name__`, and have that call `default.__set_name__` when the latter exists, and be a

Re: [Python-Dev] descriptor __set_name__ and dataclasses

On 3/26/18 11:08 AM, Nick Coghlan wrote: On 27 March 2018 at 00:40, Eric V. Smith <e...@trueblade.com> wrote: https://bugs.python.org/issue33141 points out an interesting issue with dataclasses and descriptors. Given this code: from dataclasses import * class D: ""&qu

[Python-Dev] descriptor __set_name__ and dataclasses

https://bugs.python.org/issue33141 points out an interesting issue with dataclasses and descriptors. Given this code: from dataclasses import * class D: """A descriptor class that knows its name.""" def __set_name__(self, owner, name): self.name = name def __get__(self,

Re: [Python-Dev] Symmetry arguments for API expansion

On Mar 21, 2018 05:40, "Steven D'Aprano" wrote: I don't want to change the behaviour of pow(), but we shouldn't dismiss the possibility of some other numeric function wanting to treat values N.0 and N the same. Let's say, an is_prime(x) function that supports floats as well

Re: [Python-Dev] Symmetry arguments for API expansion

On Mon, Mar 12, 2018 at 9:51 AM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > There is a feature request and patch to propagate the float.is_integer() > API through rest of the numeric types ( https://bugs.python.org/issue26680 > ). > > While I don't think it is a good idea, the OP

Re: [Python-Dev] Fix strncpy warning with gcc 8 (#5840)

obscure comment. What are your thoughts @warsaw and @ericvsmith? Py_UNREACHABLE was added in issue31338 by Barry. The original code was added in issue1580 by Eric Smith (maybe it was copied from other place). Mark Dickinson and/or I wrote that. I agree that leaving the two commented o

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

On 3/1/2018 1:02 AM, Nick Coghlan wrote: I'm assuming you meant "3.7.0b2" here (and similarly alpha->beta for the other version numbers below) Oops, yes. Thanks. So going back to original questions above, my suggestions are: 1. What happens when a frozen dataclass inherits from a

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

On 2/22/2018 1:56 AM, Raymond Hettinger wrote: 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: >>>

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

On 2/22/18 9:43 PM, Nick Coghlan wrote: On 22 February 2018 at 20:55, Eric V. Smith <e...@trueblade.com> wrote: On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characte

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

I've opened https://bugs.python.org/issue32953 to track this. On 2/22/18 5:55 AM, Eric V. Smith wrote: On 2/22/2018 1:56 AM, Raymond Hettinger wrote: When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic

Re: [Python-Dev] [Python-checkins] Exhaustively test dataclass hashing when no hash= value is provided. This is in anticipation of changing how non-default hashing is handled. (GH-5834) (GH-5889)

Thanks. Do you know if this gets backported to 3.7? Eric. On 2/25/2018 1:36 PM, Terry Reedy wrote: On 2/25/2018 11:56 AM, Eric V. Smith wrote: +    # specify any value in the deecorator). I fixed this through the web interface.  The CI now knows that a comment change does not need

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

On 2/22/18 9:43 PM, Nick Coghlan wrote: On 22 February 2018 at 20:55, Eric V. Smith <e...@trueblade.com> wrote: A related issue is that dataclasses derived from frozen dataclasses are automatically "promoted" to being frozen. @dataclass(frozen=True) ... class A

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

On Tue, Feb 20, 2018 at 6:50 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

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

How often do we find ourselves grumbling over .py file style in PRs on github? If the answer to that isn't very often, the rest of my response below seems moot. :) On Wed, Feb 21, 2018 at 7:30 PM Guido van Rossum wrote: > Where I work we have some teams using flake8 and some

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

On 2/22/2018 1:56 AM, Raymond Hettinger wrote: 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: >>>

Re: [Python-Dev] Dataclasses, frozen and __post_init__

> On Feb 20, 2018, at 5:38 PM, Guido van Rossum <gu...@python.org> wrote: > >> On Tue, Feb 20, 2018 at 1:37 PM, Eric V. Smith <e...@trueblade.com> wrote: >>> On 2/17/2018 2:35 PM, Guido van Rossum wrote: >>> PS. I have to ponder why frozen dataclass

Re: [Python-Dev] Dataclasses, frozen and __post_init__

On 2/17/2018 2:35 PM, Guido van Rossum wrote: PS. I have to ponder why frozen dataclasses don't use `__new__`. As I'm sure everyone is now aware after the rest of this discussion: it's because the returned object isn't really immutable. That said, I have threatened to create a decorator

Re: [Python-Dev] Dataclasses and correct hashability

Sorry for the late reply. Still recovering from a computer failure. My only concern with this approach is: what if you don’t want any __hash__ added? Say you want to use your base class’s hashing. I guess you could always “del cls.__hash__” after the class is created, but it’s not elegant.

Re: [Python-Dev] Dataclasses and correct hashability

On 2/6/18 2:40 PM, Ethan Furman wrote: On a different note, should the PEP be updated with the current signature? It still talks about hash=None being the default. Once we've reached an agreement, I'll update the PEP. I don't think we're there quite yet. Eric

Re: [Python-Dev] libxml2 installation/binding issue

This list is for the discussion of development *of* Python. For discussion of development *with* Python, you want python-list. On Mon, Feb 5, 2018 at 2:41 PM, Priest, Matt wrote: > Hello, > > > > I am not sure if this is the correct place to post an issue/question like >

Re: [Python-Dev] Dataclasses and correct hashability

sh, foo) # This method is automatically generated for classes with freezable=True foo.freeze() # Now object is immutable, and hash(foo) is allowed assertRaises(foo.__setattr__, "blah", 2) hash(foo) I don't know if it's worth the complexity, but I guess it would cover at least some of the

Re: [Python-Dev] Dataclasses and correct hashability

+1 using unsafe_hash as a name addresses my concern. It's a good signal that there are caveats worth considering. -gps On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum wrote: > Looks like this is turning into a major flamewar regardless of what I say. > :-( > > I really don't

Re: [Python-Dev] Dataclasses and correct hashability

On Fri, Feb 2, 2018 at 10:25 PM Nick Coghlan <ncogh...@gmail.com> wrote: > > > On 3 Feb. 2018 1:09 am, "Eric V. Smith" <e...@trueblade.com> wrote: > > > The problem with dropping hash=True is: how would you write __hash__ > yourself? It seems like a bug

Re: [Python-Dev] "threading.Lock().locked()" is not documented

On Wed, Jan 31, 2018 at 4:46 PM Jesus Cea wrote: > https://docs.python.org/3.6/library/threading.html doesn't document > "threading.Lock().locked()", and it is something quite useful. > > In fact, it is used in "threading.py" itself. For instance, lines 109, > 985, 1289. > > Is

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On Feb 2, 2018 7:24 AM, "Christian Heimes" wrote: Shortly after the PR has landed, I was made aware that glibc has deprecated crypt(3) API [2] and favor of an external library called libxcrypt [3] from OpenWall Linux. I have patched Python 3.7 [4] to support libxcrypt. In

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:56 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:51:11 AM EST Eric V. Smith wrote: I was specifically talking about the case of a non-frozen, hashable class. If you want to make a class frozen and hashable, then: @dataclass(frozen=True) will do just

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 10:38 AM, Elvis Pranskevichus wrote: On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote: However, I don't feel very strongly about this. As I've said, I expect the use cases for hash=True to be very, very rare. Why do you think that the requirement to make a dataclass

Re: [Python-Dev] Dataclasses and correct hashability

On 2/2/2018 12:33 AM, Nick Coghlan wrote: For 3.7, I think we should seriously considered just straight up disallowing the "hash=True, frozen=False" combination, and instead require folks to provide their own hash function in that case. "Accidentally hashable" (whether by identity or field

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 8:29 PM, Elvis Pranskevichus wrote: On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote: I should add: This is why you shouldn't override the default (hash=None) unless you know what the consequences are. Can I ask why you want to specify hash=True? hash=None

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 8:17 PM, Eric V. Smith wrote: On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote: There appears to be a critical omission from the current dataclass implementation: it does not make hash=True fields immutable. Per Python spec: "the implementation of hashable collections req

Re: [Python-Dev] Dataclasses and correct hashability

On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote: There appears to be a critical omission from the current dataclass implementation: it does not make hash=True fields immutable. Per Python spec: "the implementation of hashable collections requires that a key’s hash value is immutable (if the

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

TL;DR of Steve's post - MSVC is the compiler of choice for most serious software on Windows. So we use it to best integrate with the world. There is no compelling reason to change that. The free-as-in-beer MSVC community edition is finally non-sucky (their earlier efforts were crippled, they seem

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

I'm curious if changing the obmalloc.c ALIGNMENT and ALIGNMENT_SHIFT defines is sufficient to avoid ABI breakage. -gps On Tue, Jan 30, 2018 at 1:20 PM Gregory P. Smith <g...@krypto.org> wrote: > The proper fix for this in the code would likely break ABI compatibility > (ie:

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

The proper fix for this in the code would likely break ABI compatibility (ie: not possible in python 2.7 or any other stable release). Clang's UBSAN (undefined behavior sanitizer) has been flagging this one for a long time. In Python 3 a double is used instead of long double since 2012 as I did

Re: [Python-Dev] Is static typing still optional?

On 1/29/2018 4:01 AM, Raymond Hettinger wrote: On Jan 28, 2018, at 11:52 PM, Eric V. Smith <e...@trueblade.com> wrote: I think it would be a bad design to have to opt-in to hashability if using frozen=True. I respect that you see it that way, but it doesn't make sense to me. You can

Re: [Python-Dev] Is static typing still optional?

On 1/29/2018 3:42 AM, Ethan Furman wrote: On 01/28/2018 07:45 AM, Eric V. Smith wrote: On 1/6/2018 5:13 PM, Eric V. Smith wrote: On 12/10/2017 5:00 PM, Raymond Hettinger wrote: 2) Change the default value for "hash" from "None" to "False".  This migh

Re: [Python-Dev] Is static typing still optional?

On 1/29/2018 1:55 AM, Yury Selivanov wrote: On Mon, Jan 29, 2018 at 1:36 AM Nick Coghlan > wrote: [...] Currently the answers are: - A: not hashable - B: hashable (by identity) # Wat? - C: hashable (by field hash) - D:

Re: [Python-Dev] Is static typing still optional?

On 1/6/2018 5:13 PM, Eric V. Smith wrote: On 12/10/2017 5:00 PM, Raymond Hettinger wrote: ... 2) Change the default value for "hash" from "None" to "False".  This might take a little effort because there is currently an oddity where setting hash=False causes

Re: [Python-Dev] [python-committers] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

That's awesome! A great choice. Congrats, Łukasz. Eric. On 1/27/2018 4:02 PM, Barry Warsaw wrote: As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus feature freeze. I think we can all give Ned a huge round of applause for his amazing work as Release Manager for Python

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

On 1/26/2018 12:22 PM, Mariatta Wijaya wrote: I believe https://github.com/python/bedevere/pull/82  will add a comment, which will get emailed to everyone nosy on the PR. Yes, and I've just updated my PR description: If a PR was merged

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

On 1/25/2018 8:13 PM, Terry Reedy wrote: On 1/25/2018 7:47 PM, Mariatta Wijaya wrote: I think we're starting to deviate from the original topic here which is: please replace # with GH- when you click Squash & Merge button. I will try to remember to do this, although it seems pointless if most

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

it should still be able to keep things moving. Anyway, I don't know if it's exactly what cpython wants, but it's at the least got some really interesting ideas. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@pyth

<    1   2   3   4   5   6   7   8   9   10   >