(Replying to multiple posts in this thread)
Guido van Rossum:
> Another problem is PEP 505 -- it
> is full of discussion but its specification is unreadable due to the
> author's idea to defer the actual choice of operators and use a
> strange sequence of unicode characters instead.
Hi, I wrote
On Fri, Oct 14, 2016 at 9:37 AM, Gustavo Carneiro
wrote:
>
> I see. short-circuiting is nice to have, sure.
>
> But even without it, it's still useful IMHO.
>
It's worth mentioning that SQL's COALESCE is usually (always?) short
circuiting:
https://www.postgresql.org/docs/9.5/static/functions-
On Fri, Oct 14, 2016 at 12:10 PM, Guido van Rossum wrote:
> I propose that the next phase of the process should be to pick the
> best operator for each sub-proposal. Then we can decide which of the
> sub-proposals we actually want in the language, based on a combination
> of how important the fun
On Fri, Oct 14, 2016 at 11:36 PM, Guido van Rossum wrote:
> I'm not usually swayed by surveys -- Python is not a democracy. Maybe
> a bunch of longer examples would help all of us see the advantages of
> the proposals.
I understand. You said the next phase should be to pick the best operator
fo
Stephen J. Turnbull wrote:
> I gather you think you have a deadlock here. The way to break it is
> to just do it. Pick a syntax and do the rewriting. My memory of some
> past instances is that many of the senior devs (especially Guido) will
> "see through the syntax" to evaluate the benefits of
ribute of None. Therefore, if "foo?.bar"
evaluates to None, then ".baz" is short circuited — that attribute is not
looked up.
[1] https://en.wikipedia.org/wiki/Null_coalescing_operator#SQL
On Mon, Oct 31, 2016 at 12:33 PM, Paul Moore wrote:
> On 31 October 2016 at 15:51, Ma
Zero Piraeus writes:
> If I write something like obj.attr, the failure mode I care about is that
> obj has no attribute attr, rather than that obj is specifically None (or
> one of a defined group of somewhat Nonelike objects).
>
> Clearly, in such a circumstance, obj is not what I expected it to
, the definition of conditional expressions
> could be updated to also make the ``else`` clause optional::
>
> test: else_test ['if' or_test ['else' test]] | lambdef
> else_test: or_test ['else' test]
>
> (We would avoid the apparent simplification to ``
I don't think an informational PEP would make threads like Python Review
shorter and/or more productive. The OP clearly didn't do much research, so
it seems unlikely he would read an informational PEP. Moreover, the
bikeshedding about what goes into this PEP will inevitably lead to a troll
who isn'
On Sun, Feb 12, 2017 at 11:51 AM, Markus Meskanen
wrote:
>
> 2. To register callbacks to objects, i.e. plain out set an attribute for
> an instance. I've used the menu example above:
>
> class Menu:
> def __init__(self, items=None, select_callback=None):
> self.items = items if i
In the debug logging thread, somebody suggested the "%r" format specifier
and a custom __repr__. This is a neat solution because Python logging
already includes a "delayed" evaluation of sorts: it formats the logging
string *after* it determines that the message's log level is greater than
or equal
On Fri, Feb 17, 2017 at 1:55 PM, Joshua Morton
wrote:
> but I'm wondering how common async and await were when that was proposed
> and accepted?
Actually, "async" and "await" are backwards compatible due to a clever
tokenizer hack. The "async" keyword may only appear in a few places (e.g.
async
This could be solved with a null-coalescing operator, e.g. PEP-505.
>>> val = conf.get('setting_name') ?? load_from_db('setting_name')
The right side isn't evaluated unless the left side is None. It's similar
to this:
>>> val = conf.get('setting_name') or load_from_db('setting_name')
Exce
>
> -Joseph
>
> On Feb 28, 2017, at 10:21 AM, Mark E. Haase wrote:
>
> This could be solved with a null-coalescing operator, e.g. PEP-505.
>
>>>> val = conf.get('setting_name') ?? load_from_db('setting_name')
>
> The right side is
Hi Pavel,
This is a really impressive body of work. I had looked at this project in
the past but it is great to get back up to speed and see all the progress
made.
I use Python + databases almost every day, and the major unanswered
question is what benefit does dedicated language syntax have over
Your example is really repeating two things:
d = [ [0 for _ in range(5)] for _ in range(10) ]
But since list() uses * for repetition, you could write it more concisely
as:
d = [[0] * 5] * 10]
I'm not picking on your specific example. I am only pointing out that
Python gives you the tools you ne
On Thu, Jun 8, 2017 at 4:27 PM, Abe Dillon wrote:
> >>> a, *b = 1, 2, 3, 4, 5 # NOTE: Most itterables unpack starred
> variables as a list
> >>> type(b)
>
>
> >>> a, *b = "except strings"
> >>> type(b)
>
>
I was just playing around with this, and on Python 3.5.3, I see strings
unpacked as li
On Wed, Jul 5, 2017 at 9:22 PM, Chris Angelico wrote:
> For what it's worth, I'm in favour of Steven's "too negative" approach
> - or rather, I don't think his style is too negative. Yes, it's a bit
> rough and uncomfortable to be on the receiving end of it, but it's
> exactly correct. All three
On Thu, Jul 6, 2017 at 5:58 AM, Paul Moore wrote:
> To use the (already
>
over-used) NameError example, Ken's proposal doesn't include any
> change to how NameError exceptions are raised to store the name
> separately on the exception.
>
Maybe I'm misunderstanding you, but the proposal has a cle
On Thu, Jul 6, 2017 at 2:56 PM, Steven D'Aprano wrote:
> > Maybe I'm misunderstanding you, but the proposal has a clear example of
> > raising NameError and getting the name attribute from the exception
> > instance:
> >
> > try:
> > raise NameError(name=name, template="name '{name}'
On Wed, Jul 19, 2017 at 2:37 AM, Pau Freixes wrote:
> Not at all, the idea is taking into advantage the Event principle,
> having a set of Futures waiting to be awakened and returning either a
> value or exception.
That's not the principle of Event. You are describing a Future.
Regarding the p
On Wed, Sep 13, 2017 at 5:05 PM, Jason H wrote:
> Python is weird in that there are these special magical globals that
> operate on many things.
Jason, that weirdness is actually a deep part of Python's philsophy. The
language is very protocol driven. It's not just the built-in functions that
u
Explicit yield points makes reasoning about multitasking much easier. The
author of Twisted wrote an excellent post about this.[1] I agree that the
Python documentation doesn't do justice to the question, "when should I use
asyncio instead of threads?"
[1] https://glyph.twistedmatrix.com/2014/02/
asyncio.coroutine and async def are slightly different—not synonyms. The
former defines a generator function and the latter defines a coroutine
function. Generators and coroutines are very similar in Python (they share
lots of code in the CPython implementation) but coroutines are preferred
for asy
On Thu, Jul 19, 2018 at 2:36 PM Brendan Barnwell
wrote:
> People keep saying that this null-coalescing behavior is so common
> and
> useful, etc., but that hasn't been my experience at all. In my
> experience, the desire to shortcut this kind of logic is more often a
> sign of corner-cut
On Mon, Jul 23, 2018 at 2:23 AM Nicholas Cole
wrote:
> One issue for me is that the trivial case is already a one-liner:
>
> if a is None: a = 10
>
Yes, if you have no indentation and a 1-character name, then it fits on a
single line. If you have a longer expression and/or side effects, then it'
On Mon, Jul 23, 2018 at 11:34 AM Robert Vanden Eynde
wrote:
> The default could be at the end with an argument to unboxing :
>
> favorite = NoneAware(cfg).user.profile.food.unbox("Spam")
>
That's what PyMaybe does:
https://pymaybe.readthedocs.io/en/latest/readme.html#examples-use-cases
PyMaybe
On Mon, Jul 23, 2018 at 2:12 PM Rhodri James wrote:
>
> How are you supposed to do method calling, the equivalent of
> "foo?.bar()" ? "NoneAware(foo).bar.unbox()()" looks downright weird.
> Is there more magic in NoneAware to cover this case? (Not that I think
> we should be encouraging people
Hey Wes, the checksec() function in PEDA that you cited has a standalone
version as well:
https://github.com/slimm609/checksec.sh
Running this on my Python (installed from Ubuntu package):
$ checksec --output json -f /usr/bin/python3.6 | python3 -m json.tool
{
"file": {
"relro": "par
On Thu, Sep 13, 2018 at 10:49 AM Rhodri James wrote:
More importantly, this whole idea of banning and/or changing terminology is
> psychologically and sociologically wrong-headed. The moment you say "You
> may not use that word" you create a taboo, and give the word a power that
> it did not hav
On Thu, Sep 20, 2018 at 8:09 AM Oleg Broytman wrote:
> On Thu, Sep 20, 2018 at 01:46:10PM +0400, Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> wrote:
> > i miss a +1 button
>
>It's absence is a big advantage. We're not a social network with
> "likes". We don't need a bunch of argumentles
On Thu, Sep 20, 2018 at 10:33 AM Ethan Furman wrote:
> On 09/20/2018 07:23 AM, Oleg Broytman wrote:
> > We're proposing and *discussing* things here not "likes" each other.
> > Write your arguments or be silent.
>
> The number of people who have the same argument is also a factor. I would
>
On Tue, Sep 25, 2018 at 8:47 PM Mikhail V wrote:
> As for statistics - IIRC someone gave statistics once, but the only
> thing I can remember -
> "while 1/True" is used quite a lot in the std lib, so the numbers
> exceeded my expectation
> (because I expected that it's used mostly in algorithms).
Python's coroutines are designed to make suspension points visible, which
enhances "local reasoning" about code. This concept has been written up
very well over here: https://glyph.twistedmatrix.com/2014/02/unyielding.html
On Tue, Oct 30, 2018 at 8:37 AM Ron Reiter wrote:
> You are right that th
34 matches
Mail list logo
