reemptively answer all of those questions
and turn this into a proposal that covers everything but the implementation
details (with maybe a few narrow open questions).
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an ema
for normal .py imports on a stock CPython on Windows or Mac
installation, can a non-sophisticated user (or automated software) reliably
distinguish system, site, added-by-old-school-egg, user, venv, script-dir, and
custom based on the pathname?
_______
Python-
is std but nothing else”), but if that’s what we want,
I think it’s doable without an implementation nightmare.
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailm
tarts using try from std import except from local import instead of screwing
with sys.path, that’s not a problem, it’s a good thing). But it’s something to
keep in mind._______
Python-ideas mailing list -- [email protected]
To unsubscribe send an
to Python itself, just
define the one-liner wherever you want to use it, and you can use it.
_______________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists
On Nov 10, 2019, at 08:00, Stephen J. Turnbull
wrote:
>
> Andrew Barnert via Python-ideas writes:
>>> On Nov 7, 2019, at 19:59, Chris Angelico wrote:
>>>
>>> And I do the same with the operators that you disparagingly call
>>> "ASCII soup".
On Nov 10, 2019, at 08:23, Stephen J. Turnbull
wrote:
>
> Martin Euredjian via Python-ideas writes:
>
>> Another interesting example is had in some of my work with real
>> time embedded systems. There are plenty of cases where you are
>> doing things that are v
e case that someone is actually
going to get out of that box and comprehend what you are saying.
BTW, there are some interesting efforts out there, like this:
https://www.youtube.com/watch?v=1iTPLgfmFdI
Once you dig into these truly interesting examples you end-up discovering that
notat
On Nov 10, 2019, at 20:50, Martin Euredjian via Python-ideas
wrote:
>
> > This has nothing to do with representation or input via text
>
> It does, it's an extension of the reality that, after so many decades, we are
> still typing words on a text editor.
And how
far as the grammar) a kind of
display.
On the other hand, except for dtype example, you can already do all of this
exactly the same without changing Python just by using A(...) instead of
a[...], and I don’t think it looks that much worse.
______
ank you,
-Martin
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@py
t hook that runs your macros as AST
transforms, so you only have to focus on what the macros should look like and
do. It can’t always do everything you need, but when it can, it’s amazing.
_______
Python-ideas mailing list -- [email protected]
o be useful, they’d all have to be changed to return
NotImplemented instead.
I think __lcontains__ (following the same rules as __radd__, and with the
change to every existing __contains__, and probably at least two versions’
worth of __future__) could be useful, and if I were designing a new P
out
at that point.
But this all based on my memory, which is probably wrong or fuzzy on at least
some points, so you really should dig up all of the old threads.
_______________
Python-ideas mailing list -- [email protected]
To unsubscribe send an
expressions, what gets dumped with the SyntaxError isn’t always the
most relevant part of the expression. (Everyone remembers the first time they
left off a close paren and got a baffling error complaining about the perfectly
good next line…)
___
Pytho
On Nov 14, 2019, at 09:53, Andrew Barnert via Python-ideas
wrote:
>
> Yeah, it seems like this should be doable in basically the same way bracketed
> multiline expressions are. I’m not sure how much of a change that would
> require. But it seems like it’s worth fiddling with
enize.py have enough info to handle that
properly? I don’t know, and the answer to that might be a good proxy to the
question of whether it can be done in the real compiler without making parsing
complicated, even if it won’t prove the answer either way.
_______
seemed potentially more
promising than the original (and frequent) suggestion to add parens here.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.pytho
On Nov 14, 2019, at 13:23, MRAB wrote:
>
>> On 2019-11-14 19:51, Andrew Barnert via Python-ideas wrote:
>> On Nov 14, 2019, at 11:21, Random832 wrote:
>>>> On Thu, Nov 14, 2019, at 13:12, Andrew Barnert wrote:
>>>> And then you can run it on a whole
r cases. But it seems like
it’s at least worth building for your personal toolbox and keeping track of how
often it comes up (and how much nicer it makes things), and maybe publishing it
to PyPI or submitting it to contextlib2 so more people will do the same.
_________
thon
has—e.g., if you have a raw fd passed to you by a C API or over a Unix socket,
the way to wrap it in a file object is just to call open and use it as the
first argument; it seems like it would be weird to have a “file ready to be
opened” that’s actually an open file but the wrap
doesn’t
give you any benefits except in special cases (s.g., it could be useful for an
auto-curry decorator that accumulates args into a partial until the entire
signature is bound, and then calls the function).
Maybe those special cases are common enough to put a helper in functools or
so
that only cleans up if the generator is cleaned up…)
Or breaking file objects up into as many orthogonal pieces as possible to see
if there’s a better way to reassemble them?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an
tax? I don’t think so.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/py
good use. It seems like your argument is
that even though it makes code harder to read as plain text, and to write, it
helps IDEs so much that the readability is a net win? Maybe some examples would
help, but it seems implausible.
___________
Python-i
= 18
> print (x + y + z + str(a))
> and thats not much difference to worry about. Problem comes when there are
> more different data types need to be added and combined together.
Why? Every data type is converted to string in the same way: the str function.
Every data type is also automatically
context
manager.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.pytho
On Nov 18, 2019, at 10:27, Random832 wrote:
>
> On Mon, Nov 18, 2019, at 13:00, Andrew Barnert via Python-ideas wrote:
>>def f(a, b): return a**(b+1)
>>g = partial(f, b==2)
>>h = lambda x: f(x, 2)
>>
>> Python can’t tell the difference between f,
g the closing cm on it in a different lexical context that
you end up passing the released cm to).
(I think C++ smart pointers might be relevant here, or maybe something from
Rust, although I haven’t thought it through in much detail.)
___
Python-ideas mailing list -- pyth
ts__, or even replace their
__code__.
In fact, there aren’t very many _immutable_ callables (by comparison to the
huge number of functions).
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-le...@python.
claring that it’s definitely not a
problem. But I _think_ it’s not a problem.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Messa
atever in the first place?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python
by default and every ownership is scoped by default” model that Rust has
and C++ vaguely approximates, but with Python you’d need… I’m not sure, but I
suspect it would be ugly.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe s
On Nov 18, 2019, at 16:35, Soni L. wrote:
>
>
>> On 2019-11-18 5:22 p.m., Soni L. wrote:
>>
>>
>>> On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote:
>>>> On Nov 18, 2019, at 10:51, Random832 wrote:
>>> > > On Mo
behaves that way into the stdlib. Or just mention
how to do (and that helpers are readily available) in the docs on decorators.
(I don’t think it means we need to add a whole new decorator syntax that just
does that for you magically but is otherwise the same as the existing one.)
_____
ested functions and you’re done.
But if we’re really going to rethink resource management from scratch, I don’t
think we’re talking about Python anymore anyway.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to p
ile would probably work.
But is that better than an opening function that takes a Path (or any of the
other valid arguments to open) as its first argument?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python
he problem;
no matter how you write things, fn2 will never be entered, so no file will be
created or truncated and no fd will get leaked.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-
no doubt others) am less likely to engage with a thread if I have
to spend more time than necessary trying to understand it.
Thanks
Rob Cliffe
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
On Nov 19, 2019, at 14:30, Greg Ewing wrote:
>
> On 20/11/19 6:51 am, Andrew Barnert via Python-ideas wrote:
>> A class can bind attributes in __new__ and return a fully initialized
>> object. If that’s perfectly ok, why doesn’t every class do everything
>> in __new__,
g but not an error, if you break the rules. But you
don’t have to use ARC, and you can go around the conventions rather than
breaking them, so I think “just a convention” is close enough.)
_______
Python-ideas mailing list -- [email protected]
To u
rials and
blog posts and python-list and StackOverflow answers to favor creating and
using lazy context managers whenever possible (“because they work with the
tuple syntax” seems like a good argument…).
And you can do all of this without needing to change the protocol.
____
t rely on eager context manager behavior. So we’re still
not talking about an idea for Python here. The idea in my other email,
providing a wrapper to turn eager context managers lazy and an ABC to
distinguish them and so on, may not be nearly as clean, but it seems a lot more
feasibl
On 06/11/2019 17:05:21, Martin Euredjian via Python-ideas wrote:
One has to use APL for real work and for at least a year or two in
order for your brain to make the mental switch necessary to understand
it. Just messing with it casually isn't good enough. Lots of
inquisitive people
take "a year or two" to become familiar.
In a nutshell: APL is a dinosaur; the world has moved on.
Python is always alive to adopting ideas from other programming languages.
But in this case "We've heard what you say. No thank you".
Rob Cliffe
____
.
+1.
Rob Cliffe
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org
experiment within the rules of PEP 484.
The question is whether that’s still true, or whether PEP 484 usage is explored
well enough by now to start offering guides rather than an invitation to
experiment further.
_______
Python-ideas mailing list -- pytho
ryear) vs. prmonth?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/pytho
ing contents.
That’s a lot more confusing. I frequently accidentally try to parse a pathname
as an XML document, or to open a file using an XML document as a pathname, but
I never make that mistake with JSON.
___
Python-ideas mailing list -- python-ideas@p
(much like dis), not a function you’d use to convert an object to a
pickle and save in a file.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman
everything from scripts to
servers. That’s why we usually get names like `get_current_loop` today instead
of names like `getcwd`. (But not always—e.g., new additions to `math` that wrap
or emulate `math.h` functions still get C-style names.)
_______
Python-id
r new users would clamor first += but not ++, or be able to learn each
when they see it, but knowing that C programmers would find them both intuitive
but that their intuition for ++ doesn’t make sense for Python while their
intuition for += does.
_________
e aliases (because they’re just functions),
but what about bound methods (and classmethods and custom method-y decorators)?
For example, if `mine = MyClass()`, does `mine.process_file.__alias__` also
work? How? Do method objects have a @property for the dunder that delegates to
the underlying `__func__`? If not, I
On Nov 30, 2019, at 10:25, MRAB wrote:
>
> On 2019-11-30 05:28, Andrew Barnert via Python-ideas wrote:
>>> On Nov 29, 2019, at 02:42, Steven D'Aprano wrote:
>>> Programming uses lots of initialisms, abbreviations and hybrid words, such
>>> as:
>>
so I don’t think it would have the desired result of pushing the
whole ecosystem to change in 4.5 years; people would have to keep using [0] and
[1] for many years to come if they wanted to work with all mapping types.
_______
Python-ideas mailing
On Nov 30, 2019, at 16:15, Steven D'Aprano wrote:
> On Sat, Nov 30, 2019 at 11:54:35AM -0800, Andrew Barnert via Python-ideas
> wrote:
>
>> To an experienced C programmer, both += and ++ are intuitive. But to a
>> novice who’s never programmed, neither one is int
for value, key in d.items()` it will appear correct but
then do the wrong thing inside the loop. (And if I’m trying to fix your code, I
might not even notice that you got it backward until after a couple hours
banging my head on the debugger.) With a namedtuple, there’s no way to mix up
the n
On Nov 30, 2019, at 20:13, Steven D'Aprano wrote:
>
> On Sat, Nov 30, 2019 at 05:31:01PM -0800, Andrew Barnert wrote:
>>> On Nov 30, 2019, at 16:15, Steven D'Aprano wrote:
>>> On Sat, Nov 30, 2019 at 11:54:35AM -0800, Andrew Barnert via Python-ideas
>&g
les would in any way
affect any of the code you wrote.
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archiv
u need a closing brace because the dedent could
be a lie, in Python it syntactically means the very thing you hope it means.)_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://
up to the start. But does a ruler
help any better? And would an “end for”?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org
ld 2.3 sets module, change the underlying dict from mapping each key
to None to instead map it to itself, and then the method is just return
self._dict[key].)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to pytho
constructor returns a zero?)
I’m pretty sure I have run into a handful of more useful uses for this method
over the years, but I can’t remember any. Maybe something to do with Unicode
normalization?
___
Python-ideas mailing list -- python-ideas@p
> On Dec 3, 2019, at 03:41, Steven D'Aprano wrote:
> On Tue, Dec 03, 2019 at 01:54:44AM -0800, Andrew Barnert via Python-ideas
> wrote:
>>>>> On Dec 2, 2019, at 16:27, Soni L. wrote:
>>>> Even use-cases where you have different objects whose dif
ight that there would be similar convenience uses for
findfirst, if not even more of them. And it makes more sense to build that
findfirst around findall or finditer than around search.
But, given how easy it is to build this on finditer, and that it uses a general
pattern that works for every si
s. For example, should dict.__or__ and __ior__
handle all the same values as update, or some more restricted set of types? The
same as set.__or__ and __ior__ vs. union, and list.__add__ and __iadd__ vs
extend, and so on. If they’re all consistent, and there’s no compelling reason
to add an i
can, and already do.
And if someone like Serhiy or even Guido is away for a week, does that mean
every thread started during that week should get resolved without their
frequently crucial input?
_______
Python-ideas mailing list -- [email protected]
To
On Dec 3, 2019, at 15:45, Greg Ewing wrote:
>
> On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote:
>> If you’re using interning for functionality, to distinguish two equal
>> strings that came from different inputs or processes, your code is probably
>> brok
xt that raises a
> different exception when the result isn't found.
If you need that, it’s pretty trivial to write yourself.
If you think other people need it and don’t know how to write it, why not
submit it to more-itertools and/or tools? If it gets enough uptake, you can
always su
deas, where you can
directly respond to objections and refine your positive case, a frozen document
is probably less likely to convince people. Plus, once it’s rejected, that’s …
not quite final (I think ideas from rejected PEPs have been revived; I think
the @ operator is an example?), but at l
overcome that.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/li
ne even worse, so that’s not a serious proposal, just a blue-sky wish.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Me
if the type is a builtin).
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python
think about whether start==stop is safe, it will obviously safely give you an
empty range.
(You can extend this to be more flexible (take just stop, or start and stop, or
start and stop and abs(step) arguments) if you need it.)
_______
Python-ideas mailing
t test it.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]
bout once/year for them? That
sounds about right to me, too.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message arc
ed
like when they last ran into it, and how much their workaround bothered them).
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Me
’s likely that you could find that much.)
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mai
example of a logic error that a compiler could catch without
early return but can’t catch with it?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3
ey don’t.
So maybe it’s worth at least adding first as a recipe, even if people don’t
think it’s worth adding to the module itself?
(Personally, I use first if I’ve already imported more-itertools for something
else, but otherwise I just next Iter.)________
st even more, because novices shouldn’t learn that bad idea.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Messa
dules in the stdlib) has come up before, but either there’s
never a good enough use case, or just nobody volunteers to do it. And first
might well be the candidate that’s worth it.
Then again, maybe it is worth optimizing. Or maybe it’s fine to just list it as
a recipe (the recipes docs already
, but sometimes
people do, and sometimes we all have to deal with their code. I don’t think
this is a huge objection, but it is worth figuring out how often and how badly
people would be affected.
_______
Python-ideas mailing list -- [email protected]
want the basic peek.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-idea
next(finditer()).group(1), which return a
tuple vs. just the first one?
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.pytho
ot really an argument against making a special case for one that isn’t
made for unique or consume.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/
rently, but because its target audience is more
novice-y), or what?
You need some argument for that to overcome the status quo, and expanding
itertools making it harder to find the stuff that really is necessary to have
there, and the fact that you’d either have to implement it in C or con
with
a little edited-in footnote or comment saying “if you’re using the upcoming
3.9, you can use first instead of next and leave out the call to iter”.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-l
e’s
ever been willing to do each time it comes up (and you’re right, it comes up
every time a new potentially useful itertools tool is proposed…). If someone
cares about first enough to finally do that, I’m +1 on the proposal instead of
0.
___________
s, I found some that were clearly updated for 3.x but still explicitly
checked for StopIteration anyway.
If adding first causes some people to re-evaluate old code like that in
tutorials and improve a few of them, maybe that’s enough to be worth it on its
own.
Also, the new docs on first its
;__iter__') check
No there isn’t. It’s almost always true, because the only things that normally
have __next__ are iterators, and they always have __iter__ as well. But there’s
no need to check for that. If you create a type that has __next__ but not
__iter__ for some reason, you expect that it
take and then curry that. So you can just follow the convention everywhere
without worrying about whether this is one of the rare cases where the other
way around might actually be useful more often.
___
Python-ideas mailing list -- [email protected]
iple places in more_itertools) makes more sense. Trying to get the first
value out of an empty Iterable is a lot like trying to use tuple unpacking on
an empty Iterable; it’s not much like trying to look up a key in an empty dict.
_______
Python-
istinct from:
>
>first = next
Because first works with any Iterable; next works only with iterators.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pyth
understand the subtleties of leaking StopIteration, or whatever).
That’s a pretty different argument. (Not that there can’t be something to both
arguments, of course.)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to
at way)? But I think by this
point, we already have at least two answers (yours and Guido’s), it’s just a
question of working out whether either one is sufficient for someone to go try
to convince Raymond with it.
___
Python-ideas mailing list -- [email protected]
T
if it were called "one" instead of "first"?
I’d expect one to be “like first, but raise if there are two or more elements”,
because that’s what it means in a number of functional languages and database
libraries, and more-itertools.
__________
ypeError. Take it away, and the standard idioms for at least two
common things are no longer valid._______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lis
o, what else could you do? Make __setattr__ check the stack and see if it’s
being called from type(self).__post_init__? Add an extra hidden attribute to
every instance just to track whether you’re inside __post_init__ so __setattr__
can check it?
___
e your fullname just by assigning to the always-mutable but private
_fullname attribute, and have a readonly fullname property that uses that cache._______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-i
701 - 800 of 1693 matches
Mail list logo
