Hello,
On Sun, 16 Jan 2022 17:31:48 +0200
Iyad Ahmed wrote:
> Example use cases:
>
>- Loop variables and similar, it is sometimes more comfortable to
> scope it to the loop body only
>- Not having to name variables var1, var2, var3, or makeup
> unnecessarily unique variable names, in so
Hello,
On Sat, 29 May 2021 17:29:26 -0300
André Roberge wrote:
> On Sat, May 29, 2021 at 4:54 PM Irit Katriel
> wrote:
>
> >
> > You can control what the traceback of exceptions you are emitting:
> >
> > "raise e.with_traceback(None)" should clear everything before the
> > current frame.
> >
Hello,
On Tue, 25 May 2021 11:53:20 -
"Shreyan Avigyan" wrote:
> I posted my previous idea regarding this on the mailing list. This
> idea is a little different. This idea suggests introducing constant
> name bindings. This is similar to const pointer in C/C++. Once a name
> has been assigne
[to add another backtrace entry] than just "I
did it on another Python implementation, it was easy". But then I
travelled and switched to other set of projects, which keep me busy for
the foreseeable future. So, if you're interested, feel free to post a
ticket to (hopefully) get this ma
Hello,
On Tue, 20 Apr 2021 18:23:15 -
"Pol Welter" wrote:
> Consider the following snippet:
>
> ```
> def foo(a, b):
> pass
>
> foo(1, 2, 3)
> ```
>
> We all know what will happen.
>
> ```
> File "", line 4, in
> foo(1, 2, 3)
> TypeError: foo() takes 2 positional arguments but
Hello Skip,
On Mon, 22 Mar 2021 17:13:19 -0500
Skip Montanaro wrote:
> Thanks for the response. I will try to address your comments inline.
>
> > I guess it should be a good idea to answer what's the scope of this
> > project - is it research one or "production" one? If it's research
> > one, w
Hello,
On Sat, 20 Mar 2021 10:54:10 -0500
Skip Montanaro wrote:
> Back in the late 90s (!) I worked on a reimagining of the Python
> virtual machine as a register-based VM based on 1.5.2. I got part of
> the way with that, but never completed it. In the early 2010s, Victor
> Stinner got much fur
Hello,
On Tue, 23 Feb 2021 13:09:39 -0500
Ned Batchelder wrote:
> On 2/23/21 12:55 PM, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Tue, 23 Feb 2021 11:52:57 -0500
> > Ned Batchelder wrote:
> >
> >> On 2/23/21 12:56 AM, Paul Sokolovsky wrote:
>
Hello,
On Wed, 24 Feb 2021 05:01:37 +1100
Chris Angelico wrote:
> On Wed, Feb 24, 2021 at 4:59 AM Paul Sokolovsky
> wrote:
> > Without getting to the root cause, there will be only workarounds of
> > different level of ugliness. For example, any reasonable JIT would
&g
Hello,
On Tue, 23 Feb 2021 12:11:00 -0500
Richard Damon wrote:
[]
> them. If we look at 'f-strings' as the example, I beleive f-strings
> are now considered the 'preferred obvious' way to do it, when it is
It's a common mistake. %-formatting was "preferred obvious" 30 years
ago, and is "prefer
Hello,
On Tue, 23 Feb 2021 11:52:57 -0500
Ned Batchelder wrote:
> On 2/23/21 12:56 AM, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Mon, 22 Feb 2021 17:32:23 -0500
> > Ned Batchelder wrote:
> >
> >> On 2/22/21 3:06 PM, Paul Sokolovsky wrote:
>
Hello,
On Tue, 23 Feb 2021 09:35:58 -0500
Richard Damon wrote:
[]
> My first thought to the idea of making an alternate syntax is the line
> from the Zen:
>
> There should be one-- and preferably only one --obvious way to do it.
> Although that way may not be obvious at first unless you're Dut
Hello,
On Tue, 23 Feb 2021 15:07:50 +0100
"M.-A. Lemburg" wrote:
[]
> FWIW: I don't understand why people are so unhappy with lambdas.
I don't think that people are unhappy with lambdas. I think that people
are *so* happy with lambdas, that want even shorter notation for them.
> There isn't
Hello,
On Tue, 23 Feb 2021 13:24:10 +
Stestagg wrote:
> I was quite feeling pretty positive about the 'stab' (thanks Steve
> for this term!) operator idea, until I tried out some examples
> locally, and it just feels a bit too out-of-place in python, for me
> (100% subjective opinion here).
Hello,
On Tue, 23 Feb 2021 23:29:33 +1100
Steven D'Aprano wrote:
> On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote:
>
> > Also: I know there are several modern computer languages that use
> > arrows to represent anonymous functions (JS, Kotlin, Scala...).
>
> Javascript: fi
Hello,
On Tue, 23 Feb 2021 17:52:20 +1100
Chris Angelico wrote:
[]
> That's why I dispute that this is an "astonishing oversight". It would
> be nice to have the extra information, but given that Python and
> Python programmers have survived for thirty years without it, I don't
> think it's nea
Hello,
On Tue, 23 Feb 2021 17:52:20 +1100
Chris Angelico wrote:
> On Tue, Feb 23, 2021 at 5:33 PM Paul Sokolovsky
> wrote:
> > Because that's the right analogy of what happens with a function -
> > in the function "prolog", there's a series of assignm
Hello,
On Tue, 23 Feb 2021 12:31:37 +1100
Chris Angelico wrote:
> On Tue, Feb 23, 2021 at 10:10 AM Stestagg wrote:
> > So Python has identified that a function 'do_thing' is being called
> > incorrectly, but /where/ is do_thing defined? This problem gets
> > much harder if there are multiple
Hello,
On Mon, 22 Feb 2021 17:32:23 -0500
Ned Batchelder wrote:
> On 2/22/21 3:06 PM, Paul Sokolovsky wrote:
> >
> > No, I'm proposing to stop faking lack of the last stack frame due to
> > CPython's implementation details. See the original message for more
Hello,
On Mon, 22 Feb 2021 19:47:04 +
Barry Scott wrote:
> > On 22 Feb 2021, at 10:15, Paul Sokolovsky wrote:
> >
> > It looks like:
> >
> > Traceback (most recent call last):
> > File "pseudoc_tool.py", line 91, in
> > File "..
Hello,
On Mon, 22 Feb 2021 10:44:19 +0100
Peter Otten <__pete...@web.de> wrote:
> On 21/02/2021 23:06, Terry Reedy wrote:
> > On 2/21/2021 12:04 PM, Paul Sokolovsky wrote:
> >
> >> Traceback (most recent call last):
> >>
Hello,
On Mon, 22 Feb 2021 18:26:28 +1100
Chris Angelico wrote:
> On Mon, Feb 22, 2021 at 6:08 PM Paul Sokolovsky
> wrote:
> > One explanation why SimpleNamespace is not in "collections" is
> > because ... it's not a collection. One of the basic traits
Hello,
On Mon, 22 Feb 2021 15:51:37 +1100
Chris Angelico wrote:
[]
> In my mind, the current front-runners are:
>
> * namespace
> * ns
> * thing
> * mobject
> * bunch
Such short generic names shouldn't be used for types added so late in
the language evolution. Those are names for variables.
Hello,
On Sun, 21 Feb 2021 16:51:37 -0800
Brendan Barnwell wrote:
> On 2021-02-17 11:21, Chris Angelico wrote:
> > Okay. Let's start bikeshedding. If SimpleNamespace were to become a
> > builtin, what should its name be? It needs to be short (obviously),
> > but not TOO short, and it needs to be
Hello,
Here's example:
Traceback (most recent call last):
File "pseudoc_tool.py", line 91, in
first_class_function_value(func, **pass_params)
TypeError: print() got an unexpected keyword argument 'noann'
Ok, which "print" do you mean, dear CPython? I have a dozen of print
functions (most
Hello,
On Sat, 20 Feb 2021 00:23:13 +0900
"Stephen J. Turnbull" wrote:
> Abdulla Al Kathiri writes:
>
> Condensing to the parts which are in question,
>
> > def test(self, func: t.Callable[..., bool], *args, **kwargs) ->
> > Predicate: return self._build_predicate(
> >lamb
Hello,
On Thu, 18 Feb 2021 21:27:18 +1100
Steven D'Aprano wrote:
[]
> Or we could just use a one-liner:
>
> >>> from types import SimpleNamespace
>
> and get all of that for free. And if it were a builtin, it would be a
> zero-liner.
Right. If the whole CPython stdlib were builtin, it
Hello,
On Wed, 17 Feb 2021 18:43:09 -0300
"Joao S. O. Bueno" wrote:
> On Wed, 17 Feb 2021 at 18:15, Abdulla Al Kathiri <
> alkathiri.abdu...@gmail.com> wrote:
>
> > How is this not pythonic?
> >
> > series.apply(x -> x**2)
> > Compared to..
> > series.apply(lambda x: x**2)
> >
> >
> > (x, y)
Hello,
On Mon, 15 Feb 2021 13:00:50 -0500
Ricky Teachey wrote:
> On Mon, Feb 15, 2021 at 12:55 PM David Mertz wrote:
>
> > On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey
> >
> >> f(x,y)=>x,y->str
> >>>
> >>
> > I read this as "my cat walked across my keyboard, and I'm very
> > proud she wa
Hello,
On Sat, 13 Feb 2021 14:33:43 -0800
Christopher Barker wrote:
> There seems to be a frequent objection to the word "lambda" --
> personally, I found it cryptic, but it's not hard to remember, and it
> IS easy to look up.
There seems to be a bit too many posts downputting the "lambda"
keyw
Hello,
On Sun, 14 Feb 2021 13:57:14 +1100
Steven D'Aprano wrote:
> On Sun, Feb 14, 2021 at 12:47:30AM +0300, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Sat, 13 Feb 2021 16:25:24 -0500
> > Cade Brown wrote:
> >
> > > In my humble opi
Hello,
On Sun, 14 Feb 2021 18:36:14 +1100
Steven D'Aprano wrote:
> On Thu, Feb 11, 2021 at 09:36:25PM -0800, Guido van Rossum wrote:
>
> > Agreed. I'd prefer the JavaScript solution, since -> already has a
> > different meaning in Python return *type*. We could use -> to
> > simplify typing.Cal
he bright side of it -
"=>" is more visible, because otherwise, arrow functions are really
skinny and can be easily missed at all).
>
> On Sat, Feb 13, 2021, 14:52 Paul Sokolovsky wrote:
>
> > Hello,
> >
> > On Sat, 13 Feb 2021 09:24:51 -0800
> > Mat
Hello,
On Sat, 13 Feb 2021 09:24:51 -0800
Matthias Bussonnier wrote:
> Works well with 0 parameters and currying, read almost like a haskell
> function definition.
>
> f = () => ((b) => b)
> g = (a) => (b) => b+a
> h = (a) => (b) => (b, a)
> i = (a,b) => a
>
> print(f()(2))
> print(g(1)(2))
Hello,
On Fri, 12 Feb 2021 18:26:53 +1100
Chris Angelico wrote:
> On Fri, Feb 12, 2021 Paul Sokolovsky wrote:
> > ... And on the 2nd thought, that won't work. The reason it works in
> > JS is that it doesn't have tuples. In Python, "(a, b) => (1, 2)"
>
Hello,
Some time ago I posted a query regarding how the simplest possible
(while still practical to use) import hooking might look like. Since
then, I've coded up my try: https://github.com/pfalcon/python-imphook .
I'd be interested in hearing any criticism, in particular in regard to
the claims
Hello,
On Fri, 12 Feb 2021 18:26:53 +1100
Chris Angelico wrote:
> On Fri, Feb 12, 2021 at 6:24 PM Paul Sokolovsky
> wrote:
> > ... And on the 2nd thought, that won't work. The reason it works in
> > JS is that it doesn't have tuples. In Python, "(a, b) => (1
Hello,
On Fri, 12 Feb 2021 09:55:16 +0300
Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 11 Feb 2021 21:36:25 -0800
> Guido van Rossum wrote:
>
> > > but I think it'd probably be
> > > better to use similar syntax to C#, Java, and Javascript instead
Hello,
On Thu, 11 Feb 2021 21:36:25 -0800
Guido van Rossum wrote:
> > but I think it'd probably be
> > better to use similar syntax to C#, Java, and Javascript instead,
> > and use () -> [12] or () => 12...
> >
>
> Agreed. I'd prefer the JavaScript solution, since -> already has a
> different
Hello,
On Thu, 11 Feb 2021 23:57:16 -0500
Random832 wrote:
[]
> > > I'd like to propose the following:
> > >
> > > w = (): [12]
> >
> > What will be the meaning of {(): [12]} ? Hint: it will be a
> > dictionary of empty tuple mapping to a list, where do you see
> > lambda here?
>
> This
Hello,
On Fri, 12 Feb 2021 01:37:35 +1100
Steven D'Aprano wrote:
> I think it is probably pointless now, but you might get
> more response if you post actual examples of the syntax and
> semantics, explaining how your proposal differs from the (now
> accepted) alternative, and why you made
Hello,
On Thu, 11 Feb 2021 12:24:55 +0100
"J. Pic" wrote:
> Hi all,
>
> Lambdas can be defined as such:
>
> w = lambda: [12]
> x = lambda y: len(y)
>
> I'd like to propose the following:
>
> w = (): [12]
What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
of empty tuple m
Hello,
On Tue, 09 Feb 2021 10:13:06 -
"Jonatan " wrote:
> Someone?
Sure. You might be using this mailing list with a web interface or
something, where you see a message, hit reply button, type a few words
and think people will see just what you had before your eyes.
That's not how email in
" on the language level is
still first on my list, and I'm pretty far from a PEP for it either ;-).
>
> On Sun, Feb 7, 2021 at 23:58 Paul Sokolovsky
> wrote:
>
> > Hello,
> >
> > On Sun, 7 Feb 2021 13:10:55 -0800
> > Guido van Rossum wrote:
> >
ing within index expression useful, up to reporting it, and
then other people ack it and fix it, then why not fix parallel
assignment case? Implementation-wise they *seem* to be of the
similar effort/complexity - just a one-term grammar change. (I still
need to run the testsuite, yeah).
>
Hello,
On Sat, 6 Feb 2021 19:57:33 -0500
Jonathan Crall wrote:
> I ran into another case where I wish I had some sort of conditional
> if.
Right, conditional "if" is exactly what we miss in Python.
Yes, it's a typo, but it's proverbial Freudian slip, shows what stays
behind such proposals - un
Hello,
On Sat, 6 Feb 2021 17:26:00 +1100
Chris Angelico wrote:
> On Sat, Feb 6, 2021 at 5:21 PM Random832
> wrote:
> >
> > While we're on the subject of assignment expression limitations,
> > I've occasionally wanted to write something like
> >
> > try:
> > return a_dict[key]
> > except Key
Hello,
On Sat, 6 Feb 2021 10:46:54 +0200
Serhiy Storchaka wrote:
> 05.02.21 09:51, Paul Sokolovsky пише:
> > a0 = 0
> > b0 = 10
> > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > a2 = a1 + 1
> > b2 = b1 + 1
>
> Such code quickly beco
Hello,
On Sat, 6 Feb 2021 06:17:08 +1100
Chris Angelico wrote:
> On Sat, Feb 6, 2021 at 6:08 AM Paul Sokolovsky
> wrote:
> > And looking back now, that seems like intentionally added accidental
> > gap in the language (https://en.wikipedia.org/wiki/Accidental_gap).
> >
Hello,
Thanks for the reply.
On Fri, 5 Feb 2021 13:32:25 -0500
Terry Reedy wrote:
> On 2/5/2021 2:51 AM, Paul Sokolovsky wrote:
>
> > https://www.python.org/dev/peps/pep-0572/
> ...
>
> >>>> ((a, b) := (1, 2))
> >File "", line 1
&
Hello,
Everyone knows how hard to find a compelling usecase for the assignment
expression operator (":=", colloquially "walrus operator").
https://www.python.org/dev/peps/pep-0572/ examples never felt
compelling and we all remember the split it caused.
I finally found a usecase where *not* using
Hello,
On Sat, 23 Jan 2021 19:04:08 +0900
Inada Naoki wrote:
> On Sat, Jan 23, 2021 at 10:47 AM Chris Angelico
> wrote:
> >
> >
> > Highly dubious. I'd rather focus on just moving to UTF-8 as the
> > default, rather than bringing in a new function - especially with
> > such a confusing name.
>
Hello,
On Tue, 19 Jan 2021 08:54:33 +0900
Inada Naoki wrote:
> Hi, all.
>
> I want to write type hints without worrying about runtime overhead.
> Current best practice is:
>
> ```
> from __future__ import annotations
>
> import typing
>
> if typing.TYPE_CHECKING:
> import xxx # modules u
Hello,
On Thu, 14 Jan 2021 22:19:06 +1100
Steven D'Aprano wrote:
> On Thu, Jan 14, 2021 at 02:05:50PM +0300, Paul Sokolovsky wrote:
>
> [...]
> > Semantically, Python can achieve the same with "imperative" syntax
> > like:
> >
> > def mixin_meth
Hello,
On Thu, 14 Jan 2021 22:14:17 +1100
Chris Angelico wrote:
> On Thu, Jan 14, 2021 at 10:07 PM Paul Sokolovsky
> wrote:
> > The question then: what are the best practices in *declarative*
> > syntax to achieve the same effect in Python? (but of course, unlike
> &g
Hello,
Ruby has following feature. Suppose the existing class "Cls" is scope
(either defined before or imported from some module), then the code
like:
class Cls
def mixin_method(args)
...
end
end
Will "reopen" (Ruby term) that class and will add a new method
"mixin_method" to it.
Hello,
On Thu, 7 Jan 2021 12:32:11 +
Paul Moore wrote:
> On Thu, 7 Jan 2021 at 12:18, Paul Sokolovsky
> wrote:
> > On Thu, 7 Jan 2021 22:59:41 +1100
> > Chris Angelico wrote:
> >
> > > On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky
> > > wr
Hello,
On Thu, 7 Jan 2021 22:59:41 +1100
Chris Angelico wrote:
> On Thu, Jan 7, 2021 at 9:12 PM Paul Sokolovsky
> wrote:
> > In that regard, as of 3.9, CPython, has absolutely atrocious REPL
> > support for its own syntax. It's just barely possible at all to type
> &
Hello,
On Wed, 6 Jan 2021 22:12:53 +1100
Chris Angelico wrote:
[]
> But Paul's recent track record of proposals isn't like that. They're
> not part of the language.
Everything was not part of the language, until it became. And "a
language" is multi-level structure in the first place. For exam
Hello,
On Wed, 6 Jan 2021 21:24:28 +1100
Steven D'Aprano wrote:
[]
> > > > In this regard, braces aren't worse than average other stuff
> > > > posted here. Actually, it might be a bit more interesting, as
> > > > it clearly moved people throughout the years.
> > >
> > > That’s questionabl
Hello,
On Wed, 6 Jan 2021 11:47:08 +1100
Steven D'Aprano wrote:
[]
> You know Paul, as an advocate for braces, you're doing a great job of
> convincing me that they aren't necessary.
I'm an advocate for braces in as much as I'm an advocate for 2+2=4.
Braces exist, and used by people who need
Hello,
On Tue, 5 Jan 2021 14:29:03 +0100
Ronald Oussoren wrote:
[]
> > In this regard, braces aren't worse than average other stuff posted
> > here. Actually, it might be a bit more interesting, as it clearly
> > moved people throughout the years.
>
> That’s questionable. The primary reason
Hello,
On Tue, 5 Jan 2021 23:22:03 +1100
Chris Angelico wrote:
> On Tue, Jan 5, 2021 at 9:38 PM Paul Sokolovsky
> wrote:
> > There were good reasons to not have string interpolation in the core
> > language for decades then - KABOOM - there's string interpolation.
> &
Hello,
On Tue, 5 Jan 2021 21:03:06 +1100
Chris Angelico wrote:
> On Tue, Jan 5, 2021 at 8:32 PM Paul Sokolovsky
> wrote:
> > And you seem to have 2nd level miss about this miss. I'm not the 1st
> > asking about braces in Python, hundreds of people embraced braces
>
Hello,
On Tue, 5 Jan 2021 10:07:45 +0100
Ronald Oussoren wrote:
> > On 4 Jan 2021, at 12:29, Paul Sokolovsky wrote:
> >
> > Hello,
> >
> > On Mon, 4 Jan 2021 21:47:26 +1100
> > Chris Angelico mailto:ros...@gmail.com>> wrote:
> >
>
Hello,
On Tue, 5 Jan 2021 08:52:54 +1100
Steven D'Aprano wrote:
> On Mon, Jan 04, 2021 at 01:38:23PM +0300, Paul Sokolovsky wrote:
> > Hello,
> >
> > There're tons of projects which introduce alternative braces
> > (i.e. C-like) syntax for Python.
&g
Hello,
On Mon, 4 Jan 2021 14:09:30 +0200
Alex Hall wrote:
> On Mon, Jan 4, 2021 at 1:30 PM Paul Sokolovsky
> wrote:
>
> >
> > Which leads us back to the question - did anyone of those who did
> > that over decades ever bothered to post some kind of "spec&
Hello,
On Mon, 4 Jan 2021 21:47:26 +1100
Chris Angelico wrote:
> On Mon, Jan 4, 2021 at 9:41 PM Paul Sokolovsky
> wrote:
> >
> > Hello,
> >
> > There're tons of projects which introduce alternative braces
> > (i.e. C-like) syntax for Python. Most of the
Hello,
There're tons of projects which introduce alternative braces
(i.e. C-like) syntax for Python. Most of them are however not properly
documented, and definitely not spec'ed for what they do.
I wonder, does anyone here remember more or less formal proposal for
braces syntax? A "minimum viable
Hello,
Some time ago we discussed with Steven D'Aprano how "const" annotation
would be combined with other annotations:
https://mail.python.org/archives/list/python-...@python.org/message/SQTOWJ6U5SGNXOOXZB53KBTK7O5MKMMZ/
I mentioned that while current way is to use `typing.Annotated`:
spam: Ann
Hello,
On Sat, 19 Dec 2020 21:24:40 +0300
Paul Sokolovsky wrote:
> Hello,
>
> On Sat, 19 Dec 2020 03:52:46 +0100
> Marco Sulla wrote:
>
> > Maybe it's a crazy idea, but what if we could decorate a single line
> > of code?
>
> > For example:
> &
Hello,
On Mon, 21 Dec 2020 12:43:39 -0800
Christopher Barker wrote:
> Jonathan, did you notice:
>
> python3 -m imphook -i mod_stmt_deco -m example_stmt_deco
>
> I suspect mod_stmt_deco is some code that Paul wrote.
>
> Guessing now, you can implement with with an import_hook, and I'm also
> g
Hello,
On Tue, 22 Dec 2020 18:27:01 +1100
Steven D'Aprano wrote:
> On Mon, Dec 21, 2020 at 04:36:21PM +0300, Paul Sokolovsky wrote:
> > Hello,
> >
> > I posted on python-dev a question regarding builtin vars()
> > vs .__dict__ attribute dichotomy:
> >
Hello,
On Sat, 19 Dec 2020 21:24:40 +0300
Paul Sokolovsky wrote:
> Hello,
>
> On Sat, 19 Dec 2020 03:52:46 +0100
> Marco Sulla wrote:
>
> > Maybe it's a crazy idea, but what if we could decorate a single line
> > of code?
>
[]
>
> Bottom l
Hello,
I posted on python-dev a question regarding builtin vars() vs .__dict__
attribute dichotomy:
https://mail.python.org/archives/list/python-...@python.org/thread/JAFIBBUU5UE7VMX3SFYXQOHNK6TDZBV3/
It could as well be one among the earliest cases of the violation of
"There should be one-- and
Hello,
On Sat, 19 Dec 2020 03:52:46 +0100
Marco Sulla wrote:
> Maybe it's a crazy idea, but what if we could decorate a single line
> of code?
That's definitely useful, as a generic programming language concept. My
favorite example is from (embedded) C, where I'd like to have
per-callsite cont
Hello,
On Fri, 18 Dec 2020 17:42:26 +1300
Greg Ewing wrote:
> On 18/12/20 1:48 pm, Paul Sokolovsky wrote:
> > So, it's already clear that mod.func() syntax will continue to work
> > as before. I don't foresee any problems with implementing that, do
> > you?
&g
Hello,
On Fri, 18 Dec 2020 12:29:10 +1300
Greg Ewing wrote:
> On 18/12/20 7:01 am, Paul Sokolovsky wrote:
> > Now, what if you have an object attribute which stores a callable
> > (no matter is it's bound method, a function, a class, or whatever)?
> >
>
Hello,
On Thu, 17 Dec 2020 15:28:47 -0500
Alexandre Brault wrote:
> On 2020-12-15 5:16 a.m., Paul Sokolovsky wrote:
> >> The compiler applies it when it
> >> can see the only use of the attribute is an immediately following
> >> call.
> > You're no
Hello,
On Fri, 18 Dec 2020 06:09:56 +1100
Chris Angelico wrote:
> On Fri, Dec 18, 2020 at 5:02 AM Paul Sokolovsky
> wrote:
> > This is not some completely new restriction. For example, following
> > already doesn't work in Python:
> >
> > class A:
> &g
Hello,
On Thu, 17 Dec 2020 10:03:14 +
Stestagg wrote:
[]
> > > > But still, are there Python implementations which compile
> > > > "(a.b)()" faithfully, with its baseline semantic meaning? Of
> > > > course there're.
> > >
> > > OK, Paul, why don't you propose a PR and a bug report about
Hello,
On Fri, 18 Dec 2020 03:05:02 +1300
Greg Ewing wrote:
> On 18/12/20 1:52 am, Paul Sokolovsky wrote:
> > On Fri, 18 Dec 2020 01:23:34 +1300
> > Greg Ewing wrote:
> >> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> >>> a) (a.b)() syntax
> >>
Hello,
On Fri, 18 Dec 2020 01:23:34 +1300
Greg Ewing wrote:
> On 17/12/20 11:25 pm, Paul Sokolovsky wrote:
> > CPython compiles "(a.b)()" using LOAD_METHOD not because it
> > consciously "optimizes" it, but simply because it's *unable* to
> > repr
Hello,
On Thu, 17 Dec 2020 12:46:17 +1300
Greg Ewing wrote:
> On 17/12/20 8:16 am, Paul Sokolovsky wrote:
> > With all the above in mind, Python3.7, in a strange twist of fate,
> > and without much ado, has acquired a new operator: the method call,
> > ".()".
Hello,
On Thu, 17 Dec 2020 00:03:51 +0100
Marco Sulla wrote:
> On Wed, 16 Dec 2020 at 20:18, Paul Sokolovsky
> wrote:
> > But still, are there Python implementations which compile "(a.b)()"
> > faithfully, with its baseline semantic meaning? Of course
> > th
Hello,
On Wed, 16 Dec 2020 00:50:27 +1300
Greg Ewing wrote:
> On 16/12/20 12:24 am, Paul Sokolovsky wrote:
>
> > That's good answer, thanks. But... it doesn't correspond to the
> > implementation reality.
>
> Why are we talking about implementation? Yo
Hello,
On Tue, 15 Dec 2020 23:28:53 +1100
Steven D'Aprano wrote:
> On Tue, Dec 15, 2020 at 01:16:21PM +0300, Paul Sokolovsky wrote:
>
> > You're now just a step away from the "right answer". Will you make
> > it? I did.
>
> Sorry Paul, but you d
Hello,
On Tue, 15 Dec 2020 23:37:59 +1300
Greg Ewing wrote:
> On 15/12/20 10:04 pm, Paul Sokolovsky wrote:
> > Example 1:
> >
> > a + b + c vs a + (b + c)
> >
> > Question 1:
> > Do you agree that there's a clear difference between left and r
Hello,
On Tue, 15 Dec 2020 20:18:11 +1100
Chris Angelico wrote:
> On Tue, Dec 15, 2020 at 8:08 PM Paul Sokolovsky
> wrote:
> >
> > Hello,
> >
> > On Mon, 14 Dec 2020 02:17:52 -0500
> > David Mertz wrote:
> >
> > > On Sun, Dec 13, 2020,
Hello,
On Tue, 15 Dec 2020 20:17:37 +1100
Chris Angelico wrote:
> On Tue, Dec 15, 2020 at 8:04 PM Paul Sokolovsky
> wrote:
> > So, let's try simple yes/no questions:
> >
> > Example 1:
> >
> > a + b + c vs a + (b + c)
> >
> > Questio
Hello,
On Tue, 15 Dec 2020 08:25:25 +
Jeff Allen wrote:
> On 13/12/2020 22:09, Paul Sokolovsky wrote:
> > Thanks for hanging with me so far, we're getting to the crux of the
> > question:
> >
> > Do you think there can be difference between t
Hello,
On Mon, 14 Dec 2020 19:39:27 +1100
Steven D'Aprano wrote:
> On Mon, Dec 14, 2020 at 01:09:56AM +0300, Paul Sokolovsky wrote:
>
> > Do you think there can be difference between the following two
> > expressions:
> >
> > obj.meth()
> > (obj.
Hello,
On Mon, 14 Dec 2020 02:17:52 -0500
David Mertz wrote:
> On Sun, Dec 13, 2020, 5:11 PM Paul Sokolovsky d
>
> > a + b + c vs a + (b + c)
> >
> > Here, there's even no guarantee of the same result, if we have user
> > objects with weirdly overloa
Hello,
On Mon, 14 Dec 2020 18:05:07 +1100
Chris Angelico wrote:
> On Mon, Dec 14, 2020 at 5:57 PM Paul Sokolovsky
> wrote:
> >
> > But that's what the question was about, and why there was the intro!
> > Let's please go over it again. Do you agree with
Hello,
On Mon, 14 Dec 2020 09:37:42 +1100
Chris Angelico wrote:
> > 2 8 LOAD_NAME0 (obj)
> > 10 LOAD_METHOD 1 (meth)
...
> >
> > 3 16 LOAD_NAME0 (obj)
> > 18 LOAD_ATTR1 (meth)
...
> Cre
Hello,
How would you feel if explicit parens were used to convey additional
semantic meaning? That seems like a pretty dumb question, because,
well, parens *are* used to convey additional semantic meaning. E.g.:
1 + 2 + 3 vs 1 + (2 + 3)
The result is the same, but somehow I wanted to emphasi
Hello,
On Sun, 6 Dec 2020 00:37:15 -0500
Ricky Teachey wrote:
[]
> From another who like CHB is just random person on this list (but
> probably even more "random"), interested enough to have read the
> entire thread and the other thread, but not knowledgeable or
> competent enough to offer deta
Hello,
On Sat, 5 Dec 2020 12:02:52 -0800
Christopher Barker wrote:
> just one more note:
>
> > > things like you are proposing with an eye to performance is not
> > > really where the Python community wants to go.
> >
> > I never met a Python user who said something like "I want Python to
> >
Hello,
On Wed, 9 Dec 2020 02:01:58 +1100
Chris Angelico wrote:
> On Tue, Dec 8, 2020 at 11:05 PM Paul Sokolovsky
> wrote:
> > > It'd be best to
> > > just write what you want directly, using the tools in importlib.
> >
> > Of course, the impleme
Hello,
On Tue, 08 Dec 2020 11:46:59 -
"Mathew Elman" wrote:
> I am not sure if this has been suggested before, so my apologies if
> it has.
>
> I would like to propose adding lazy types for casting builtins in a
> lazy fashion. e.g. `lazy_tuple` which creates a reference to the
> source ite
1 - 100 of 209 matches
Mail list logo
