On Sun, Oct 7, 2018 at 7:55 AM Guido van Rossum wrote:
>
> OK, then maybe someone (not me) can merge
> https://github.com/python/peps/pull/799 for me.
>
Per discussion, merged.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
On Tue, Oct 30, 2018 at 11:10 AM Nathaniel Smith wrote:
> I also wonder if it would be useful to give pdb the ability to break
> when an exception is *raised*, rather than when it's caught?
This is veering into python-ideas territory (or even python-list), but
the first big concern that comes to
On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
wrote:
>
> Considering feedback from Ned, what about building this as an independent
> service? We don't really need to interface with python.org at all, we just
> need some hardware, a domain, some code to interface with github API and
On Mon, Nov 5, 2018 at 2:33 AM Stephane Wirtel wrote:
>
> On 11/05, Chris Angelico wrote:
> >On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev
> > wrote:
> >>
> >> Considering feedback from Ned, what about building this as an independent
> >&g
On Wed, Nov 7, 2018 at 5:11 AM srinivasan wrote:
> As am newbie to python development, I am trying to use the below function to
> get verify the filesystem type of the SD card parition using bash command in
> python using subprocess module, I ma seeing the below Error "SyntaxError:
> can't assi
On Mon, Nov 19, 2018 at 6:01 AM Richard Damon wrote:
> One issue with things like vehicle registration numbers is that the VIN
> of a vehicle is really a UUID, it is globally unique no other vehicle
> will every have that same ID number, and people may not think of the
> fact that some other ID nu
On Thu, Nov 29, 2018 at 5:10 PM Armin Rigo wrote:
> PS: on CPython could use ``typedef struct { PyObject *_obj; }
> PyHandle;``. This works like a pointer, but you can't use ``==`` to
> compare them.
And then you could have a macro or inline function to compare them,
simply by looking at that pr
On Sun, Jan 6, 2019 at 10:12 PM Paul Sokolovsky wrote:
> It's clear that what happens there is that first None is stored to N,
> just to del it as the next step. Indeed, that's what done in the
> compile.c:
>
> https://github.com/python/cpython/blob/master/Python/compile.c#L2905
>
> Storing None l
On Mon, Jan 7, 2019 at 1:21 AM Steven D'Aprano wrote:
> > I would
> > definitely find a behavior of merely clearing an "except" target
> > variable to be more understandable than magic fiddling with namespaces.
>
> I don't understand what this means. What is "clearing an except target"?
> Do you m
On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
> > The "store None" behavior can be traced down to introduction of the
> > "del except target var" behavior back in 2007:
> > https://github.com/python/cpython/commit/b940e113bf90ff71b0ef57414ea2beea9d2a4bc0#diff-cb296cc5109f5640ff3f6d7198a6a
On Mon, Jan 7, 2019 at 2:52 AM Serhiy Storchaka wrote:
>
> 06.01.19 17:35, Chris Angelico пише:
> > On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
> >> Because there is a reason for such code.
> >
> > What reason though??
>
> I added referenc
On Mon, Jan 7, 2019 at 3:13 AM Paul G wrote:
>
> I think Serhiy is saying that if you delete exc before the except body ends,
> when the compiled code goes to delete it it will fail. Binding to None
> guarantees that there is something to delete.
Ahh! Thank you. I interpreted that example as a
On Mon, Jan 7, 2019 at 7:18 AM Brett Cannon wrote:
>
> Maybe someone can propose a code comment to explain this instead? I agree
> that this doesn't need to be explained in the language spec, but I don't see
> any harm in a comment where the opcodes are emitted to explain why it is the
> way it
On Fri, Jan 18, 2019 at 11:50 AM Gregory P. Smith wrote:
>
> I've heard that libraries using ctypes, cffi, or cython code of various sorts
> in the real world wild today does abuse the unfortunate side effect of
> CPython's implementation of id(). I don't have specific instances of this in
> mi
On Sat, Jan 19, 2019 at 9:58 AM Greg Ewing wrote:
>
> Chris Angelico wrote:
> > I would be strongly in favour of ctypes gaining a "get address of
> > object" function, which happens (in current CPythons) to return the
> > same value as id() does, but is specifica
On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote:
> We could say that implementations are allowed to raise errors at compile
> time instead of run time, but aren't required to. Then it becomes a
> matter of "quality of implementation".
>
> For literal ints, strings, None, etc we can tell at c
On Thu, Feb 28, 2019 at 10:58 PM Antoine Pitrou wrote:
> Some of them may be coming from C++, where the respective
> characteristics of set and map (or unordered_set and
> unordered_multimap) are closely related. I'm sure other languages
> show similar analogies.
>
> On a more abstract level, set
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
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
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
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"?
>
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 redrad...@gmail.com 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
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
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, pjfarl...@earthlink.net 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
On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote:
>
> I think it makes sense, and I do see a difference between Provisional and
> Unstable. Is this anything more than a documentation label?
>
Would it be a pipe dream to hope that static checkers could be taught
to recognize them? Not a huge de
On Fri, Jun 4, 2021 at 8:31 AM Guido van Rossum wrote:
>
> On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote:
>>
>> On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote:
>> >
>> > I think it makes sense, and I do see a difference between Provisional and
&
On Wed, Jun 30, 2021 at 2:36 AM wrote:
>
> I just stumbled upon the following issue and subsequent pull request. It is a
> very small bugfix. There is currently a bug in Python and this pull request
> fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it
> doesn't get revi
On Fri, Jul 2, 2021 at 10:06 AM Eric V. Smith wrote:
>
> On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote:
> > "Merging something is also a responsibility to whoever does it" - And it's
> > also a responsibility to fix bugs, no? I don't get why you're so afraid of
> > (maybe!) introducing a ne
On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote:
> Specifically: currently, decorators are called just after the function or
> class object is created, before it's bound to a variable. But we could
> change it so that we first bind the variable to the initial value, then call
> the decor
On Thu, Aug 12, 2021 at 3:01 AM Larry Hastings wrote:
>
> On 8/11/21 5:15 AM, Chris Angelico wrote:
>
> On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote:
>
> This approach shouldn't break reasonable existing code. That said, this
> change would be observable fro
On Mon, Aug 16, 2021 at 12:24 AM Marco Sulla
wrote:
>
> On Thu, 12 Aug 2021 at 12:54, Steven D'Aprano wrote:
> > Are you looking for upvotes on StackOverflow
>
> This is unacceptable. I pretend your immediate excuses.
>
? I don't understand this, what do you mean?
ChrisA
___
601 - 700 of 1000 matches
Mail list logo