On Wed, Mar 6, 2019 at 7:41 AM Brett Cannon wrote:
>
>
>
> On Tue, Mar 5, 2019 at 11:59 AM Jeroen Demeyer wrote:
>>
>> On 2019-03-05 18:14, Steve Dower wrote:
>> > However, if you don't have
>> > *a single* core developer on board from python-ideas, chances are the
>> > whole team is going to rej
On Wed, Mar 20, 2019 at 12:25 AM Antoine Pitrou wrote:
>
>
> -1. Please don't remove tempfile.mktemp(). mktemp() is useful to
> create a temporary *name*. All other tempfile functions create an
> actual file and impose additional burden, for example by making the
> file unaccessible by other pr
895: Spelling fixes (Contributed by Ville Skyttä).
Wat?! Why is 15f44ab043 showing up again?!
What's the git subtlety I'm missing here?
Chris
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/
On 28/04/2019 03:51, Martin Panter wrote:
On Sat, 27 Apr 2019 at 19:07, Chris Withers wrote:
Right, so I've merged up to 15f44ab043, what comes next?
$ git log --oneline --no-merges 15f44ab043.. -- Lib/unittest/mock.py
Lib/unittest/test/testmock/ | tail -n 3
This Git command line means
On 28/04/2019 03:51, Martin Panter wrote:
On Sat, 27 Apr 2019 at 19:07, Chris Withers wrote:
Right, so I've merged up to 15f44ab043, what comes next?
$ git log --oneline --no-merges 15f44ab043.. -- Lib/unittest/mock.py
Lib/unittest/test/testmock/ | tail -n 3
This Git command line
copies of a change. Should be safe to skip those.
Yep, current script I've been using is here, high level highlighted:
https://github.com/cjw296/mock/blob/backporting/backport.py#L102-L125
cheers,
Chris
___
Python-Dev mailing list
Python-Dev@python.
[resending to python-dev in case there are Jython users here...]
Hi All,
If you need Jython support in the mock backport, please shout now:
https://github.com/testing-cabal/mock/issues/453
cheers,
Chris
___
Python-Dev mailing list
Python-Dev
they're
needed now that we have unittest discover, but thought I'd ask.
Chris
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rc are you referring to? There isn't one in the cpython
repo and a current release of coverage.py doesn't appear to exclude
these lines for me:
https://circleci.com/gh/testing-cabal/mock/20
(line 44 in mock/tests/testsentinel.py)
Chris
___
Pyt
On 01/05/2019 07:46, Serhiy Storchaka wrote:
01.05.19 00:24, Chris Withers пише:
I have a crazy idea of getting unittest.mock up to 100% code coverage.
I noticed at the bottom of all of the test files in testmock/, there's a:
if __name__ == '__main__':
unittest.main()
On 01/05/2019 13:21, Victor Stinner wrote:
Le mer. 1 mai 2019 à 03:12, Chris Withers a écrit :
Right, but that's not the documented way of running individual suites in
the devguide.
Maybe, but I'm using that sometimes and it's useful for some specific
issues. Is it pos
are
using the same test runner) could make a difference.
Chris
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
x27;m only taking about the ones in
unittest/mock/testmock - Rob Collins confirmed these where never needed
in a private reply:
They were never needed 😁
Removal is fine with me.
Chris
___
Python-Dev mailing list
[email protected]
https://mail.
these blocks versus the way described in the dev guide, and
stressing about what the differences might be, when there aren't any...
Chris
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
have been, and bisect.py would not have needed renaming
to bisect_cmd.py.
Chris
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t tool getting a
slightly more clumsy name.
Running:
./python -m unittest some.package.test_whatever
...uses exactly the same runner, just without the unfortunate sys.path
addition.
I thought https://www.python.org/dev/peps/pep-0582/ had something
On Sun, May 26, 2019 at 8:38 AM Richard Damon wrote:
>
> On 5/25/19 5:09 PM, Nathaniel Smith wrote:
> > a = locals()
> > b = locals()
> > # now our first "snapshot" has changed
> > assert "a" in a
> >
> To me that is a static snapshot of a dynamic environment, not a dynamic
> snapshot. The snapsho
On Sun, May 26, 2019 at 8:07 PM Steven D'Aprano wrote:
> On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote:
>
> > From my reading of the description, you could also "assert a is b" -
> > is that correct?
>
> Yes, that's already the behavio
On Fri, Jun 7, 2019 at 4:30 PM Stephen J. Turnbull
wrote:
> They could, however be made more friendly than they currently are.
> There's no reason (in principle, of course it requires changing code
> and the DNS) why your message, currently given the Archived-At URL
>
> https://mail.python.org/arc
On Fri, Jun 28, 2019 at 1:02 AM wrote:
>
> Anyone experienced anything like this?
>
> The behavior seems consistent but unexpected.
>
> python 3.6 on both windows (10) and linux (ubuntu 18.04) seem to exhibit the
> same odd behavior.
>
> something about a docker-image looking string seems to trig
On Tue, Jul 2, 2019 at 2:01 AM Steven D'Aprano wrote:
>
> On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote:
> > > You have missed at least one: the minimum technology requirement for
> > > using Github is a lot more stringent than for Roundup. Github's minimum
> > > system requiremen
On Tue, Jul 2, 2019 at 2:28 PM Glenn Linderman wrote:
>
>> A method could raise instead of returning the string as-is if the prefix is
>> not really a prefix. How often is this needed? The most common end
>> deletions are whitespace, which the current .strip handles correctly.
>
> raising woul
On Mon, Aug 5, 2019 at 2:24 PM wrote:
> For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which
> is visible by default. The intention is to make it a SyntaxError in Python
> 3.9.
>
> This once seemed like a reasonable and innocuous idea to me; however, I've
> been using
On Tue, Aug 6, 2019 at 11:48 AM wrote:
>
> End-user experience isn't something that can just be argued away. Steve and
> I are reporting a recurring annoyance. The point of a beta release is to
> elicit these kinds of reports so they can be addressed before it is too late.
> ISTM you are cho
On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote:
> - Keep the SyntaxWarning silent by default for 3.8. That gives us
> another year or more to gently pressure third-party libraries to fix
> their code, and to find ways to encourage developers to run with
> warnings enabled.
How do you propo
On Wed, Aug 7, 2019 at 1:54 PM Steven D'Aprano wrote:
> Don't think of this as a failure. Think of it as an opportunity: we've
> identified a weakness in our deprecation process. Let's fix that
> process, make sure that *developers* will see the warning in 3.8 or 3.9,
> and not raise an exception
On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote:
> What's the rush? Let's be objective here: what benefit are we going to
> get from this change? Is there anyone hanging out desperately for "\d"
> and "\-" to become SyntaxErrors, so they can... do what?
So that problems can start to be detec
On Thu, Aug 8, 2019 at 8:58 AM wrote:
>
> For me, these warnings are continuing to arise almost daily. See two recent
> examples below. In both cases, the code previously had always worked without
> complaint.
>
> - Example from yesterday's class
>
> ''' How old-style formatting works
On Sat, Oct 17, 2020 at 12:30 PM Tim Peters wrote:
>
> I don't plan on making a series of these posts, just this one, to give
> people _some_ insight into why the new algorithm gets systematic
> benefits the current algorithm can't. It splits the needle into two
> pieces, u and v, very carefully
gment = urlparse(url)
instead of this--
scheme, _, _, params, query, fragment = urlparse(url)
So I'd prefer if the scheme would allow including a name (either by
prefixing or some other method), or at least not preclude such an extension
in the future.
--Chris
___
On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
>
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> The overall aim is t
On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano wrote:
> A minor point, and I realise that the costs are all in very round
> figures, but they don't quite match up: $2 million split over five
> stages is $400K per stage, not $500K.
The proposal is for four stages.
ChrisA
___
On Wed, Oct 21, 2020 at 3:31 AM Mark Shannon wrote:
>
> Hi Chris,
>
> On 20/10/2020 4:37 pm, Chris Angelico wrote:
> > On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
> >>
> >> Hi everyone,
> >>
> >> CPython is slow. We all know tha
On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano wrote:
>
> On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote:
>
> > Do you have any details to back this up? You're not just asking for a
> > proposal to be accepted, you're actually asking for
On Wed, Oct 21, 2020 at 8:23 PM Matti Picus wrote:
> Just to set the record straight, PyPy has been available on conda-forge
> [0] since March, and has seen close to 70,000 downloads [1] from that
> channel alone, in addition to the downloads from
> https://downloads.python.org/pypy and the other
On Wed, Oct 21, 2020 at 10:38 PM Matti Picus wrote:
>
> On 10/21/20 20:42:02 +1100 Chris Angelico wrote:
>
> > When I go looking for PyPy performance stats, everything seems to be
> > Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or
> > whichever
On Tue, Oct 27, 2020 at 2:42 AM Matti Picus wrote:
>
>
> On 10/21/20 2:38 PM, Matti Picus wrote:
> > On 10/21/20 20:42:02 +1100 Chris Angelico wrote:
> >
> >> When I go looking for PyPy performance stats, everything seems to be
> >> Python 2.7. Is there anyw
On Tue, Oct 27, 2020 at 10:00 AM Greg Ewing wrote:
>
> On 27/10/20 8:24 am, Victor Stinner wrote:
> > I would
> > rather want to kill the whole concept of "access" time in operating
> > systems (or just configure the OS to not update it anymore). I guess
> > that it's really hard to make it effici
On Sat, Oct 31, 2020 at 5:31 AM Mark Shannon wrote:
> > It's right here that you lose me. Anyone who reduces pattern matching to "a
> > fancy switch statement" probably isn't the right person to be discussing
> > its semantics and usefulness with. It seems that some people just can't
> > separa
On Tue, Nov 3, 2020 at 8:53 AM Glenn Linderman wrote:
>
> On 11/2/2020 1:42 PM, Guido van Rossum wrote:
> > But we feel that `case x, x` can easily be misunderstood as "a tuple
> > of two equal values"
>
> So what _is_ the syntax for "a tuple of two equal values" ?
>
> case x, ?x: # comes to mind
On Tue, Nov 10, 2020 at 3:19 AM Simon Cross
wrote:
>
> I really enjoyed learning from this "user manual with a strong
> narrative component" so I would personally like to see it stay even if
> a new tutorial is created for a different kind of audience.
If that were to happen, what I'd prefer is t
On Tue, Nov 10, 2020 at 3:38 AM Guido van Rossum wrote:
>
> Do you want to join the docs WG? IIUC it’s open to new members. (Carol?)
>
Me personally, or members of this conversation in general?
My life is a bit too chaotic at the moment to take on more
responsibilities, although I might reconsid
On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote:
>
> FWIW, I'd like to add my +1 to usage of "as" for spelling class capture
> patterns. This is by far the clearest and easiest to read form I've seen thus
> far, and I suspect that it would be the easiest to explain to users already
> familia
On Tue, Nov 17, 2020 at 9:44 PM Steven D'Aprano wrote:
> `try...except` is no different.
> ...
> The only wrinkle in the case of `try...except` is that the error
> variable is deleted, even if it wasn't actually used. If you look at the
> byte-code generated, each compound try...except with an exc
On Wed, Nov 18, 2020 at 4:08 AM Richard Damon wrote:
>
> One comment about having the exception handler 'save state' and restore
> it is that frequently the purpose of the exception handler is TO make
> changes to outer variable to fix things up based on the exception.
>
> I could see the desire o
On Wed, Nov 18, 2020 at 8:38 AM Steven D'Aprano wrote:
> To start with, what else are they using "e" for? Surely it would be more
> important to use a better name *there* rather than change the exception
> variable.
2.718281828?
ChrisA
___
Python-Dev m
On Tue, Nov 24, 2020 at 7:00 AM Ethan Furman wrote:
>
> On 11/23/20 11:06 AM, Larry Hastings wrote:
> > On 11/23/20 8:15 AM, Brian Coleman wrote:
> >> def process(root_node: Node):
> >> def process_node(node: Node):
> >> if isinstance(node, StringNode):
> >> return
On Tue, Jan 12, 2021 at 4:22 AM Larry Hastings wrote:
>
>
> I've written a new PEP. Please find it below. Happy reading!
>
Can this get added to the PEPs repo and assigned a number and such?
BTW, the currently preferred wording for the copyright blurb is
slightly different. If you're the sole
On Tue, Jan 12, 2021 at 5:10 AM Larry Hastings wrote:
>
>
> Certainly. I'm just another victim in the copy-and-paste wars.
>
Ah yes, the Battle of the Clipboard. Iconic, epic, such a glorious
engagement! But the casualties were steep. Fortunately we can rebuild.
> I actually have write access t
On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann wrote:
>
>
> On 1/8/21 4:31 PM, Mats Wichmann wrote:
> >
> >
> > Someone reported a testsuite break on stuff I work on (scons) with
> > 3.10a4, and it looks similar to this which appears in the changelog at
> >
> > https://docs.python.org/3.10/whatsnew
On Tue, Jan 12, 2021 at 12:56 PM Larry Hastings wrote:
>
> It was a balancing act. Using an 64-byte empty dict per object with no
> defined annotations seems so wasteful. And anything short of an empty dict,
> you'd have to guard against. Current code already has to guard against
> "__annota
On Wed, Jan 13, 2021 at 4:24 AM Richard Damon wrote:
>
> On 1/12/21 10:53 AM, Mark Shannon wrote:
> > Hi everyone,
> >
> > Should the optimizer eliminate tests that it can prove have no effect
> > on the control flow of the program, even if that may eliminate some
> > side effects in __bool__()?
>
On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote:
>
> On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
>
> > That'd leave open
> > the option for "foo() if x else foo()" to be optimized down to just
> > "foo()", altho
On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
>
> On 1/12/21 10:37 PM, Chris Angelico wrote:
> > On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote:
> >>
> >> On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
> >>
> >>
On Wed, Jan 13, 2021 at 8:02 PM Ethan Furman wrote:
>
> On 1/12/21 11:27 PM, Chris Angelico wrote:
> > On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
>
> >> Optimizations are an implementation detail, and implementation details
> >> should not change the la
On Wed, Jan 13, 2021 at 9:08 PM Emily Bowman wrote:
>
> Even if you define __bool__() as returning a bool, and error/undefined
> behavior otherwise, that doesn't eliminate side effects. Is it even possible
> to nail down a definition to the point that you can say, "Thou shalt not
> mutate or ca
On Fri, Jan 15, 2021 at 10:13 PM Rob Cliffe via Python-Dev
wrote:
>
>
>
> On 12/01/2021 15:53, Mark Shannon wrote:
> > Hi everyone,
> >
> >
> >
> > In master we convert `if x: pass` to `pass` which is equivalent,
> > unless bool(x) has side effects the first time it is called. This is a
> > recent
ot; section could be constructed by
copying the relevant bits from that section in the previous release.
--Chris
On Wed, Jan 20, 2021 at 4:47 PM Kyle Stanley wrote:
> Thanks for bringing attention to this, Victor, and to Ken Jin (GH:
> Fidget-Spinner) for the PR. I've just complete
standard library. Unlike,
the module_names attribute, this function would reflect the reality of the
underlying module, and so not have false positives as with doing a name
check alone.
—Chris
>
> On 25.01.2021 16:03, Victor Stinner wrote:
> > Hi,
> >
> > I just added a ne
On Mon, Jan 25, 2021 at 2:05 PM Victor Stinner wrote:
> On Mon, Jan 25, 2021 at 6:37 PM Chris Jerdonek
> wrote:
> > On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev <
> [email protected]> wrote:
> >>
> >> Just _names_? There's a
On Mon, Jan 25, 2021 at 10:23 PM Random832 wrote:
> On Mon, Jan 25, 2021, at 18:44, Chris Jerdonek wrote:
> > But to issue a warning when a standard module is being overridden like
> > I was suggesting, wouldn’t you also need to know whether the name of
> > the modul
On Sun, Feb 7, 2021 at 8:14 AM Luciano Ramalho wrote:
>
> On Sat, Feb 6, 2021 at 6:04 PM Steve Holden wrote:
> >
> > My suggestion that it be introduced via __future__ due to its contentious
> > nature met immediate resistance. No point going down that road.
>
> This is really unfortunate.
>
> I
On Sun, Feb 7, 2021 at 6:25 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Sat, 6 Feb 2021 23:05:19 -0800
> Guido van Rossum wrote:
>
> > That’s incorrect. __future__ is used when something new and
> > *incompatible* is being introduced (and the old way is being
> > deprecated at the same time). For
On Sun, Feb 7, 2021 at 7:54 PM Paul Sokolovsky wrote:
>
> So, you're saying that, by the benevolence of divine providence,
> most (can you truly vouch for "all" and provide evidence?) features so
> far added to __future__ never were changed (enough).
No, I'm saying that the __future__ directive i
On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg wrote:
> I believe Python needs to become more independent of CPython, for Python's
> long term health.
>
Since 1997, Python has been defined independently of CPython. There
are numerous documents that define the language semantics for the
benefit of
On Sat, Feb 13, 2021 at 10:42 AM Dan Stromberg wrote:
>
>
> On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico wrote:
>>
>> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg wrote:
>> > I believe Python needs to become more independent of CPython, for Python's
>
On Sun, Feb 14, 2021 at 7:38 AM Wes Turner wrote:
>
> https://awesome-safety-critical.readthedocs.io/en/latest/
> https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards
>
> What is and is not constant time in Python could be added to structured data
> elements in (imp
On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw
wrote:
>
> > Does 'master' confuse people?
>
> There's a general movement to replace language from common programming
> practises that derive from, or are associated with, the dehumanization of
> people. Such as master and slave, as well as whitelist
On Wed, Mar 10, 2021 at 12:09 PM Ivan Pozdeev via Python-Dev
wrote:
>
>
> On 10.03.2021 3:53, Chris Angelico wrote:
> > On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw
> > wrote:
> >>> Does 'master' confuse people?
> >> There's a gen
On Thu, Mar 11, 2021 at 12:16 AM Evpok Padding wrote:
>
> Dear all,
>
> Apparently renaming a git branch to follow the general convention is now an
> unbearable outrage.
It is NOT a general convention. It is a push by Microsoft (owners of
GitHub). Outside of GitHub, the git command still uses "m
On Thu, Mar 11, 2021 at 2:48 AM Charalampos Stratakis
wrote:
>
>
>
> - Original Message -
> > From: "Chris Angelico"
> > To: "Python-Dev"
> > Sent: Wednesday, March 10, 2021 4:20:19 PM
> > Subject: [Python-Dev] Re: Steering Counci
On Sun, Mar 21, 2021 at 1:30 PM Yury Selivanov wrote:
> That said I wouldn't mind aiter() supporting the two-arguments mode as it
> could make it easier to convert some sync code bases (that use greenlets, for
> example) to async. And given that async iteration mirrors the sync iteration
> prot
On Sat, Mar 27, 2021 at 3:33 AM Baptiste Carvello
wrote:
>
> Le 25/03/2021 à 15:59, Stefano Borini a écrit :
> > On Tue, 23 Mar 2021 at 21:39, Python Steering Council
> > wrote:
> >> This isn’t just about ‘master’ being rooted in slavery.
> >
> > No it's not and I am shocked that such ignorance w
On Thu, Apr 1, 2021 at 11:54 AM Caleb Donovick wrote:
>
> > Here, `Child` will *not* match as a sequence, even though it probably
> > should,
>
> Strong disagree, if I explicitly set `__match_seq__` to `False` in `Parent`
> I probably have a good reason for it and would absolutely expect `Child
On Sun, Apr 4, 2021 at 6:20 PM Paul Moore wrote:
>
> On Sun, 4 Apr 2021 at 01:37, Brandt Bucher wrote:
> >
> > Mark Shannon said:
> > > I was relying on the "reference" implementation, which is also in the PEP.
> >
> > Can you please stop putting scare quotes around "reference implementation"?
>
f the
later comments there talk about "exception trees" and other types of
annotations.
If that issue were addressed after ExceptionGroups were introduced, does
that mean there would then be two types of exception-related trees layered
over each other (e.g. groups of trees, trees of g
On Wed, Apr 14, 2021 at 9:45 AM Hugh Fisher wrote:
> I don't want Python to be explicitly typed either. I'm happy with dynamic
> typing, and do not want to have to write even
> x : object
You don't. That's not the proposal. The proposals have ALL been about
gradual typing and inferred typing,
On Wed, Apr 14, 2021 at 9:47 AM Hugh Fisher wrote:
>
> > From: Ned Batchelder
> [ munch ]
> > This is very similar to statically typed languages. They also have two
> > steps:
> >
> > * There is the first step that checks the types but does not run the
> > program. In C/C++, this is the com
On Thu, Apr 15, 2021 at 2:36 PM Hugh Fisher wrote:
>
> > Date: Wed, 14 Apr 2021 09:57:49 +1000
> > From: Chris Angelico
> > Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2
>
> >
> > You're advocating an approach that absolutely mandates runn
On Sat, Apr 17, 2021 at 3:20 AM wrote:
>
> The benefits:
>
> 1. You will link with high quality libstdc++ with lots of reusable containers
> without writing your own "buggy" one.
> 2. C++ is much much more maintainable than pure C. It drastically increase
> number of contributors that what like
On Sat, Apr 17, 2021 at 3:32 AM wrote:
>
> Chris Angelico wrote:
> > On Sat, Apr 17, 2021 at 3:20 AM [email protected] wrote:
> > > The benefits:
> > >
> > > You will link with high quality libstdc++ with lots of reusable
> > > containers without
On Wed, Apr 21, 2021 at 1:05 AM Skip Montanaro wrote:
>>
>> Perhaps there's some history in the python-dev archives that would inform
>> you of previous discussions and help you repeating already-considered
>> arguments.
>
>
> This topic has come up a few times over the years. Maybe it would be
On Wed, Apr 21, 2021 at 3:04 AM Mark Shannon wrote:
> Then came type hints. PEP 484 explicitly said that type hints were
> optional and would *always* be optional.
>
> Then came along many typing PEPs that assumed that type hints would only
> used for static typing, making static typing a bit less
On Thu, Apr 22, 2021 at 5:03 PM Ryan Gonzalez wrote:
>
> On Apr 21, 2021, 5:29 PM -0500, Paul Bryan , wrote:
>
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes
On Thu, Apr 22, 2021 at 7:53 PM Paul Moore wrote:
> I wonder whether type checkers could handle a "magic" type (let's call
> it DuckTyped for now :-)) which basically means "infer a protocol
> based on usage in this function". So if I do:
>
> def my_fn(f: DuckTyped):
> with f:
> data =
On Fri, Apr 23, 2021 at 11:22 AM Larry Hastings wrote:
>
>
> On 4/20/21 10:03 AM, Mark Shannon wrote:
>
> If you guarded your code with `isinstance(foo, Sequence)` then I could not
> use it with my `Foo` even if my `Foo` quacked like a sequence. I was forced
> to use nominal typing; inheriting f
On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith wrote:
>
> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compr
On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote:
>
>
>
> On Sat, 24 Apr 2021, 10:02 am Skip Montanaro,
> wrote:
>>
>>
>>> Practically speaking, one issue I have is how easy it is to write
>>> isinstance or issubclass checks. It has historically been much more
>>> difficult to write and mai
On Mon, Apr 26, 2021 at 2:27 PM Nathaniel Smith wrote:
> Yeah, you've understood correctly, and you see why I wrote "both the
> current proposal and the alternative have very complex implications
> and downsides" :-)
>
> [chomp lots of very helpful summarizing]
Gotcha, thanks!
ChrisA
___
On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble wrote:
>
> On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote:
>>
>> On 4/29/21 10:35 AM, Jonathan Goble wrote:
>> > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
>>
>>
>> >> Which raises the question: Do we want to have a standard name for
th no compression
> whatsoever.
>
To know what compression methods might be effective, I’m wondering if it
could be useful to see separate histograms of, say, the start column number
and width over the code base. Or for people that really want to dig in,
maybe access to the set of all pairs co
On Fri, May 7, 2021 at 6:39 PM Steven D'Aprano wrote:
> On Fri, May 07, 2021 at 06:02:51PM -0700, Chris Jerdonek wrote:
>
> > To know what compression methods might be effective, I’m wondering if it
> > could be useful to see separate histograms of, say, the start column
On Thu, May 13, 2021 at 5:37 PM Abdur-Rahmaan Janhangeer
wrote:
>
> Greetings,
>
> One crucial missing piece in the Python world is the focus
> on internals of projects. You have many talks on usage and
> scaling but not enough on internals. Even less workshops.
> For OpenSource to thrive, you nee
ve, open-source
> development model.
>
I was curious what you meant by "is more suitable to a collaborative,
open-source
development model," but I didn't see it elaborated on in the PEP. If this
is indeed a selling point, it might be worth mentioning that and saying why.
--Chris
&
On Fri, May 14, 2021 at 7:31 PM Petr Viktorin wrote:
> Perhaps it would be beneficial to provide a common base class or
> factory, so we get a good repr. But I don't think another common value
> like None and Ellipsis would do much good.
>
Agreed - I think Sentinel would make a great class, from
On Sat, May 15, 2021 at 2:04 AM Barry Warsaw wrote:
>
> On May 14, 2021, at 02:38, Chris Angelico wrote:
> >
> > Do we ever really need the ability to pass a specific sentinel to a
> > function, or are we actually looking for a way to say "and don't pass
On Tue, May 18, 2021 at 8:51 PM Stephen J. Turnbull
wrote:
>
> Steve Holden writes:
> > On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano
> > wrote:
> >
> > > Steve
> > > (one of the other ones)
> > >
> >
> > We are all other Steves!
>
> +1
>
> There were five Steves (and one Stephanie) in
On Fri, May 21, 2021 at 3:51 AM David Mertz wrote:
>
> On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote:
>>
>> On Sat, May 15, 2021 at 2:09 AM David Mertz wrote:
>> > Just add a ._uuid attribute and have object equality follow equality of
>> > that attribute. There's no reason to expose that in
On Mon, May 24, 2021 at 6:40 PM Łukasz Langa wrote:
>
>
> On 20 May 2021, at 07:03, [email protected] wrote:
>
> The Python Developers Guide specifically states to get VS2017 for developing
> or enhancing python on a Windows system.
>
> Is it still correct to specifically use VS2017 , or is
check. That would change the
kind of name you want, though.
Otherwise, some things that occur to me: factorable, factorizable,
factorized, decomposable. The thinking here is that each named member
should be capable of being decomposed / factored into individual v
901 - 1000 of 1918 matches
Mail list logo
