On Jul 23, 2018 8:43 PM, "Chris Barker - NOAA Federal via Python-ideas" <
python-ideas@python.org> wrote:
> Procedures return None
> ==
a = [3,1,2]
b = a.sort()
a, b
> ([1, 2, 3], None)
This is less about None than about the convention that mutating
methods return
On Mon, Jul 23, 2018 at 7:46 AM, Grégory Lielens
wrote:
> Paul Moore wrote:
>>
>> This is my impression, as well. It seems like something that's helpful
>> in dealing with unstructured object hierarchies with lots of optional
>> attributes - which is where JSON tends to be used.
>>
>> But given
let[x](EXPR)
x == EXPR
let[x](a=1)
x == 1
let[x](a=1, EXPR)
x == EXPR
let[x, y](a=1, EXPR)
x == 1
y == EXPR
let[x, y](a=1, b=2, EXPR)
x == 2
y == EXPR
z = let[x, y](a=1, EXPR)
x == 1
y == EXPR
z == (1, EXPR)
Anybody seeing how the above might be useful, and address some of the
concerns I've
On Thu, Jan 25, 2018 at 5:09 PM, Nick Timkovich
wrote:
> I think part of the reason that logging appears complicated is because
> logging actually is complicated. In the myriad different contexts a Python
> program runs (daemon, command line tool, interactively), the
On Nov 29, 2017 10:09 PM, "Steven D'Aprano" wrote:
> On Thu, Nov 30, 2017 at 11:21:48AM +1300, Greg Ewing wrote:
>
> > It seems that many people think about unpacking rather
> > differently from the way I do. I think the difference
> > is procedural vs. declarative.
> >
> >
On Mon, Nov 27, 2017 at 3:49 PM, Greg Ewing <greg.ew...@canterbury.ac.nz>
wrote:
> C Anthony Risinger wrote:
>
>> * Perhaps existence of `__len__` should influence unpacking? There is a
>> semantic difference (and typically a visual one too) between 1-to-1
>> m
On Nov 28, 2017 12:32 AM, "Steven D'Aprano" wrote:
On Tue, Nov 28, 2017 at 06:15:47PM +1300, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >How does "stop iterating here" equate to a wildcard?
>
> The * means "I don't care what else the sequence has in it".
>
> Because I
This proposal resonates with me. I've definitely wanted to use unpacking to
crank an iterator a couple times and move on without exhausting the
iterator. It's a very natural and intuitive meaning for unpacking as it
relates to iterators.
In my mind, this ask is aligned with, and has similar
On Thu, Sep 14, 2017 at 8:07 AM, Steven D'Aprano
wrote:
> On Wed, Sep 13, 2017 at 12:24:31PM +0900, INADA Naoki wrote:
> > I'm worring about performance much.
> >
> > Dict has ma_version from Python 3.6 to be used for future optimization
> > including global caching.
> >
On Mon, Sep 11, 2017 at 1:09 PM, Neil Schemenauer <
nas-python-id...@arctrix.com> wrote:
> On 2017-09-11, C Anthony Risinger wrote:
> > I'm not sure I follow the `exec(code, module)` part from the other
> thread.
> > `exec` needs a dict to exec code into [..]
> [..]
On Fri, Sep 8, 2017 at 11:36 AM, Neil Schemenauer <
nas-python-id...@arctrix.com> wrote:
> On 2017-09-09, Chris Angelico wrote:
> > Laziness has to be complete - or, looking the other way, eager
> > importing is infectious. For foo to be lazy, bar also has to be lazy;
>
> Not with the approach
I'd really love to find a way to enable lazy loading by default, maybe with
a way to opt-out old/problem/legacy modules instead of opt-in via
__future__ or anything else. IME easily 95%+ of modules in the wild, today,
will not even notice (I wrote an application bundler in past that enabled
it
On Sun, Jul 23, 2017 at 8:54 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> C Anthony Risinger writes:
>
> > A tuple is a tuple is a tuple. No types. Just convenient accessors.
>
> That's not possible, though. A *tuple* is an immuta
On Jul 23, 2017 1:56 PM, "MRAB" wrote:
On 2017-07-23 17:08, Todd wrote:
> On Jul 20, 2017 1:13 AM, "David Mertz" > wrote:
>
> I'm concerned in the proposal about losing access to type
> information (i.e. name) in this
On Jun 8, 2017 1:35 AM, "Greg Ewing" <greg.ew...@canterbury.ac.nz> wrote:
C Anthony Risinger wrote:
> Incredibly useful and intuitive, and for me again, way more generally
> applicable than iterable unpacking. Maps are ubiquitous.
>
Maps with a known, fixed set of key
On Jun 7, 2017 5:54 PM, "Erik" <pyt...@lucidity.plus.com> wrote:
On 07/06/17 23:42, C Anthony Risinger wrote:
> Neither of these are really comparable to destructuring.
>
No, but they are comparable to the OP's suggested new built-in method
(without requiring each mapping
On Jun 7, 2017 5:42 PM, "C Anthony Risinger" <c...@anthonyrisinger.com> wrote:
On Jun 7, 2017 5:15 PM, "Matt Gilson" <m...@getpattern.com> wrote:
On Wed, Jun 7, 2017 at 3:11 PM, Erik <pyt...@lucidity.plus.com> wrote:
> On 07/06/17 19:14, Nick Hu
I occasionally want to do something like this:
import .. as parent
or:
import . as self
The pattern is a little less useful for namespace packages (which I've been
trying to use almost exclusively, along with relative imports) than it is
for __init__.py based packages, but there is still some
On Wed, Feb 15, 2017 at 10:45 AM, C Anthony Risinger <anth...@xtfx.me>
wrote:
> On Tue, Feb 14, 2017 at 3:55 PM, Barry <ba...@barrys-emacs.org> wrote:
>>
>>
>> The point is that the cost of creating the msg argument can be very high.
>>
>> At
On Tue, Feb 14, 2017 at 3:55 PM, Barry wrote:
>
>
> The point is that the cost of creating the msg argument can be very high.
>
> At the point that logging decides to skip output it is to late to save the
> cost of creating the arg tuple.
>
Awhile back I was playing with
On Sat, Jan 28, 2017 at 5:26 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 28 January 2017 at 02:11, C Anthony Risinger <anth...@xtfx.me> wrote:
> > I can't articulate it we'll, or even fully isolate the reasons for it.
> All I
> > really know is how I feel
On Fri, Jan 27, 2017 at 3:28 PM, Ethan Furman wrote:
> On 01/27/2017 01:07 PM, Brent Brinkley wrote:
>
>> Suggested structure:
>>
>> print() <| some_func() <| another_func("Hello")
>>
>
> My first question is what does this look like when print() and some_func()
> have
On Jan 27, 2017 4:51 PM, "Random832" <random...@fastmail.com> wrote:
On Fri, Jan 27, 2017, at 12:54, C Anthony Risinger wrote:
> I know the scientific community is a big and important part of the
> Python ecosystem, but I honestly believe other parts of Python are
> su
So I realize this is subjective and just a personal experience, but over
the last 3-5 years I've really watched Python usage and popularity decline
in the "hearts and minds" of my peers, across a few different companies I
work with. At my current gig we don't even use Python anymore for tools
that
On Oct 22, 2016 2:51 AM, "Alexander Heger" wrote:
>>>
>>>
For me the current behaviour does not seem unreasonable as it
resembles the order in which you write out loops outside a comprehension
>>>
>>>
>>> That's true, but the main reason for having comprehensions
>>> syntax
On Oct 3, 2016 7:09 PM, "Stephen J. Turnbull" <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> Rene Nejsum writes:
>
> > I believe that you should be able to code concurrent code, without
> > being to explicit about it, but let the runtime handle low-level
> > timing, as long as you know your
On Sep 11, 2016 7:11 AM, "Chris Angelico" wrote:
>
> That said, though, filtered iteration isn't common enough to demand
> its own syntax IMO. I do it fairly often,
I do it often enough to want this. When I first started writing Python this
struck me as an inconsistency... if
27 matches
Mail list logo