On Oct 1, 2019, at 12:17, Ben Rudiak-Gould wrote:
>
>> On Tue, Oct 1, 2019 at 9:26 AM Andrew Barnert wrote:
>>> On Sep 30, 2019, at 23:46, Ben Rudiak-Gould wrote:
>>> ABC membership is a subtype relationship in some sense, and ordinary Python
>>> subclassi
e stop
debating irrelevant stuff about whether the whole design of Python needs to be
redone from scratch and asks him for those answers…
Conceptually, all of these things make sense:
* Subscriptable, which can be implicitly checked.
* Indexable and Keyable, which cannot be implicitly c
t languages solve part of that balance by having a lot of decorators,
or mixin classes, or macros, or magic flags to the implementation. (Or you even
could go Smalltalk style, and different environments will add different methods
to Object.) Python does some of that too—functools.total_order, and some
at most of the complexity is due to the
existing complicated interface of __getitem__ and keywords don’t make it much
different. But I’m not sure that would be true. And I think many of the
objections are from people who suspect the opposite.___
Python-ide
bly want to go back to that, come up with answers to the
objections and open questions, and start over
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.pytho
sue won’t
be a problem in practice, but just showing methods that deal with it and remain
perfectly readable makes the case a lot better.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Hi.
I'm a newbie and Python ideas was recommended to me as a place to go to.
I think this is a good idea that have port parameter in "urlunparse" method.
(refer to: https://bugs.python.org/issue38408)
One way is to add keyword parameters to urlunparse, like:
def urlunp
On Oct 9, 2019, at 20:56, Chris Angelico wrote:
>
> What you may want to consider is backporting the exact argparse.py
> from Python 3.7. It's a fairly straight-forward module and will
> probably work fine on 3.6. That way, once you upgrade to 3.7, it'll
> keep working
be
> something for Python 4.x, not 3.x.
I’m pretty sure almost nobody wants a 3.0-like break again, so this will
probably never happen.
>
> Instead of those objects _being_ sequences, have them provide views that are
> sequences using a method named something like `members` or `item
what you want for the other examples is to add an `__rcontains__`
method, so instead of `x in y` meaning `y.__contains__(x)`, it means either
`y.__contains__(x)` or `x.__rcontains__(y)` depending on some rule that you
have to define. Should it be the same rules as `__radd__`? You probably wan
might be better than explicit type-switching code. Or, if you
have a lot of your own classes that you can modify that aren’t quite sequences
but want to be pushable, you can even add your own protocol method that it
checks for first.
_______
Pytho
se')` or `x.endswith(*suffixes)` instead of
`x.endswith(('spam', 'eggs', 'cheese'))` or `x.endswith(tuple(suffixes))`? That
makes it consistent with everything else in Python, instead of requiring you to
learn that string methods are special and have `_any` vari
Jorgensen seem to be proposing a bunch of
things that already exist. It’s worth taking the time to figure out what’s
already there before suggesting changes.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to pyth
r overloads for will use those overloads; any other types
will use the `push` method protocol if it exists, and it’ll raise whatever
exception you want otherwise.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to
’m at least +0 if you can think of any examples
that would work, and should be implemented this way, but I don’t think either
of these qualifies. Maybe it would help to come up with something concrete
rather than an abstract toy example?
___
Python-
than just wanting to use it. Now that
I read it more carefully… I agree 100%. :)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.p
complex (and some complexes to
a unique real), and you can loosely multiply a real by a complex and so on. But
when you’re working on the actual algebras or the sets/types beneath them, you
can’t do that. `R` is not a subset of `C`, and `1 in C` is just not true. In
other words, the distinctio
to you).
Ideally your mail client lets you quote properly. If not, at least you can
top-post your reply above (part of) the message you’re replying to; they all
can do that.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an em
ty, you probably
wouldn’t want the same thing I do.
_______
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 a
te).
>
> That, of course, is simply a coding pattern and doesn't require any changes
> to the standard lib.
I like the way C++ handles this, actually. The C++ notion of “Iterator” is a
lot more complicated than the Python notion of “Iterator”, and usually, this is
a huge pain, but o
t I’ve never thought of a need
for it until this thread.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
M
real number,
But “equivalent to” doesn’t mean “same as”. It’s sort of like the difference
between `==` and `is` in Python: `1.0 == 1.0+0.0j` is true, but that doesn’t
mean `1.0 is 1.0+0.0j`, and therefore, the fact that `isinstance(1.0=0.0j,
complex)` doesn’t mean that `isinstance(1.0, comp
y don’t have the same subtype relations.
If you’re asking which set of relations is “mathematically correct”, then it
depends on the context. Obviously the set of all Python `int` objects is a
subset of the set of all possible things that meet the `Complex` interface, but
that doesn’t mean they’re
y bridge types like
objc.NSString or js.String—a lot more often than I build strings out of
UserString.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/ma
>> that every number besides 0 has a multiplicative inverse, which obviously
>> isn’t true for the set of integers. Or for the set of Python `int` values.
>> But that’s not what the ABC is testing for, so that’s fine.
>>
>
> Hmm, but every nonzero integer DOES have a
On Oct 14, 2019, at 06:07, Steven D'Aprano wrote:
>
>> On Mon, Oct 14, 2019 at 12:54:13AM -0700, Andrew Barnert via Python-ideas
>> wrote:
>>> On Oct 13, 2019, at 22:54, Chris Angelico wrote:
>>>
>>> Mathematically, what's the differenc
al subclass of str?
>>> None of the concrete classes register virtual subclasses, so this would be a
>> unique exception.
>
> See the final lines in
> https://github.com/python/cpython/blob/3.7/Lib/_collections_abc.py
>
>MutableSequence.register(list)
>Mutab
overloads and even custom
__getattribute__. And of course you can just as easily define a regular old
class and then use it as a plain-old-data struct. So, would this even be useful
as a hint, much less a guarantee, of anything?
_______
Python-ideas mailing
ues. That’s if anything less
direct than a normal class, where you just have to access the instance’s
__dict__.
Finally, why are we even bikeshedding this? As Steven already explained,
there’s no point in trying to nail down details for something when it’s not
even remotely clear what it’s meant to be,
Dict and ChainMap? (And
are there any other types that need that question?)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.pyt
archives.
_______
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@p
have variables
named a and b they’re going to be numbers (or maybe numpy arrays), because
those are good names for two triangle side lengths but they’re very bad names
for a list of strings and an integer Unix timestamp (to give an example which
would allow * but it would be a logical error in your
ings that tells you even make sense in Python.___
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
our code better?
___
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@pyt
ding +
in analogy with list concatenation, then obviously we want += as well; if we
add |, add |= as well; it we add a merge method, we’ve already got an update
method so nothing changes there; etc
Anyway, it sounds like the only arguments against it are arguments that Python
shouldn
different.
Set union had analogies to two different operations that pre-existed it:
concatenation, and bitwise or. Especially since bitwise or is often used
(especially by people who’d rather by writing C than Python) as set union on
integers used as bit sets.
Set union also needs an intersection
C&scope=set%3Astackage) for
all the meanings in the stdlib, but programs and third-party libs might define
even more.
But I think this all serves as more an argument for you than for the other
side. :)
___
Python-ideas mailing list -- python-i
t unless the
result is something like “the constructor segfaults”, it seems like probably
it’s fine to keep doing it, and if not it’s probably a separate bug from the
one you’re fixing.
___
Python-ideas mailing list -- [email protected]
To unsub
plementation
of it anyway if you want it.
It’s also worth looking at the implementation of the various alternative enum
implementations on PyPI (both the ones that pre-existed 3.4, and the ones that
build on it).
___
Python-ideas mailing list --
PyPI and the PoC code from the PEP and the section in Nick’s blog
post all do (in a couple different ways), or maybe it’s insufficiently magic
for your purposes, but without knowing how and why it’s different or
insufficient it’s impossible to know whether there’s an actual limitation to
.__or__ exists, but Sequence.__add__ does not. I think if you end up using
__or__ I’d argue for it to be added to Mapping, but if you end up using
__add__… well, I don’t know why Sequence.__add__ wasn’t included, so I don’t
know whether the same rationale applies to Mapping.__add__ or not
On Oct 20, 2019, at 18:26, Steven D'Aprano wrote:
>> but i'm -0 because i am very concerned it will not be obvious to new
>> learners, without constantly looking it up, whether adding two mappings
>> together would either:
>
> When Python first added the dict.
it to be spelled | if it has to be added. But people who
are dying for it mostly want + (except for the ones who want all the set
operators). I’m not sure what that means…
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an emai
m doing the same thing indirectly.
___________
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.pyth
syntaxes, and separate protocols
for it.
I realize that in JavaScript that’s not true; collections are just objects with
their items as attributes, so `a.b` means the same thing as `a['b']`. But
that’s confusing more often than it’s helpful, and I don’t think anyone wants
to bring i
that I could pass to sum and use it efficiently as
a generic fold function against its will, it was pretty obvious that’s not what
it was for.)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python
parser
ambiguity. What future worthwhile suggestions to that existing syntax are you
imagining that might break that?
Even if you’re imagining that people might want @ to be a unary prefix operator
as well as a binary operator (like + and -), how does restricting decorator
syntax help ambiguity t
On Oct 22, 2019, at 11:39, Mike Miller wrote:
>
> Had an idea, why not choose the more accurate syntax: |, |= after all? Then,
> to help newcomers and forgetful pros a custom error message is implemented
> for +, +=. In pseudo C/Python, something like this:
>
On Oct 22, 2019, at 15:06, Steve Jorgensen wrote:
>
> Actually, in Ruby, the surrounding character pair can be pretty much anything
> `, and in practice, curly braces are often used.
This seems like a prime example of “Ruby is Perl done right, Python is not
d
sing import hook. Then
people could experiment with it and if someone finds real-life performance
benefits, file a bug to add it to CPython (which should be a lot easier
nowadays than it was a few versions ago).
_______
Python-ideas mailing list -- pyt
l be efficient whatever version or
> implementation of Python you are using.
The advantage of just optimizing split on a literal is that split becomes the
One Obvious Way, and you know it will work and be correct in whatever version
of implementation of Python you are using, back to 0.9; it’ll
u were adding onto that argument is that you said people
should be able to write something and know it’ll be _efficient_ on every Python
implementation. Why does efficient matter if this code will only show up in
places where you are, as you say below, already not concerned with performance?
That’s
On Oct 23, 2019, at 13:10, Steven D'Aprano wrote:
>
> David, you literally wrote the book on text processing in Python. I
> think you are being disingenious here, and below when you describe a
> standard string hex-escape \x20 that has been in Python forever and in
> j
On Oct 23, 2019, at 16:00, Christopher Barker wrote:
>
>> On Sun, Oct 13, 2019 at 12:52 PM Andrew Barnert via Python-ideas
>> wrote:
>
>> The main problem is that a str is a sequence of single-character str, each
>> of which is a one-element sequence of itself,
the str class. You can’t
document something as a method of Unicode strings that splits on “whitespace”
using anything other than a Unicode definition of whitespace is without a good
reason.
_______
Python-ideas mailing list -- [email protected]
To un
ey can be Z but not
Zs.
Anyway, some of the answers the Unicode committee came up with are odd, but
they’re the right answers by definition. Plus, even if I had a time machine and
an unlimited life span, I’m pretty sure I wouldn’t want to participate in those
arguments.
_______
On Oct 23, 2019, at 22:45, Greg Ewing wrote:
>
> Andrew Barnert via Python-ideas wrote:
>> Someone earlier in this thread said we could optimize calling split on a
>> string literal, just as we can and do optimize iterating over a list literal
>> in a for statement.
>&
fore I tested this! I rest my case.
or
body = f'{prefix}{text}{suffix}'
or
[suggestions invited]
I would not wish to see either feature removed from Python.
I'm sure I have sometimes added a number to a string. But the TypeError
message soon puts me right.
Rob Cliffe.
A
live with either.
_______
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
ected to optimize everything well enough
that you can just any arbitrary sequence of chars as a string with reasonable
efficiency, so strings being a thin convenience wrapper above that makes
intuitive sense. In Python, that isn’t true; a function that loops character by
character would often be to
On Oct 25, 2019, at 01:34, Paul Moore wrote:
>
> On Thu, 24 Oct 2019 at 23:47, Andrew Barnert via Python-ideas
> wrote:
>> But again, I don’t think either of these is the reason Python strings being
>> iterable is a problem; I think it really is primarily about them b
On Oct 25, 2019, at 06:26, Serhiy Storchaka wrote:
>
> 25.10.19 15:53, Andrew Barnert via Python-ideas пише:
>> If you were designing a new Python-like language today, or if you had a time
>> machine back to the 90s, it would be a different story.
>
> Interesting, how f
at look
> similar to ints from C code, but that have no extractable integer
> value in Python code, so that they're independent of the underlying
> string representation.
You certainly can design a more complicated iteration/indexing protocol that
handles this—C++, Swift, and Rust have exa
On 24/10/2019 18:19:27, Andrew Barnert via Python-ideas wrote:
On Oct 23, 2019, at 23:47, Inada Naoki wrote:
But if we use + for dict merging, I think we should add + to set too.
Then the set has `.union()`, `|` and `+` for the same behavior.
I don’t think we really need that. If set and
On Oct 26, 2019, at 16:28, Steven D'Aprano wrote:
>
>> On Sun, Oct 13, 2019 at 12:41:55PM -0700, Andrew Barnert via Python-ideas
>> wrote:
>> On Oct 13, 2019, at 12:02, Steve Jorgensen wrote:
> [...]
>>> This proposal is a serious breakage of backward com
. (Unless you can statically look ahead at the
code and prove that a string will never be indexed—which a Haskell compiler can
do, but I don’t think it’s remotely feasible for a language like Python.)
If you redesign your find, re.search, etc. APIs to not return character
indexes, then I think you ca
On Oct 26, 2019, at 21:33, Steven D'Aprano wrote:
>
> IronPython and Jython use whatever .Net and Java use.
Which makes them sequences of UTF-16 code units, not code points. Which is
allowed for the Python 2.x unicode type, but would violate the rules for 3.x
str, but neither on
> On Oct 27, 2019, at 05:38, Steven D'Aprano wrote:
>
>> On Sun, Oct 27, 2019 at 12:10:22AM -0700, Andrew Barnert via Python-ideas
>> wrote:
>>
>> If you redesign your find, re.search, etc. APIs to not return
>> character indexes, then I think you c
;/home/rosuav/tmp/demo.py", line 1
>print("Hello, world!')
> ^
> SyntaxError: EOL while scanning string literal
So if those 12 glyphs take 14 code units because you’re using Stephen’s string
and it’s in NFKD, getting 14 and then indenting two spac
On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>
> throw is an expression, not a statement, in C++. I see no reason raise
> couldn't be an expression in Python. It doesn't even need a special
> rule in the grammar:
>
>from __future__ import raise_function
hat,
and we really do need to change the language to allow raise in expressions, it
should be done like yield, not like print.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
ht
On Oct 27, 2019, at 18:00, Steven D'Aprano wrote:
>
> On Sun, Oct 27, 2019 at 10:07:41AM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>>> File "/home/rosuav/tmp/demo.py", line 1
>>> print("Hello, world!')
>>>
On Oct 28, 2019, at 04:44, Richard Vogel wrote:
>
> Current state:
> Python will search for the first TOP-LEVEL hit when resolving an import
> statement and search inside there for the remainder part of the import. If it
> cannot find the symbols it will fail. (Teste
On Oct 27, 2019, at 17:27, Chris Angelico wrote:
>
> and the fact that
> throw() isn't in everyone's toolkits already suggests that this really
> isn't a major problem to be solved.
Searching on “python raise expression”, the first hit is a StackOverflow
question whe
On Oct 28, 2019, at 14:23, Serhiy Storchaka wrote:
>
> 28.10.19 20:38, Andrew Barnert via Python-ideas пише:
>> Many of them are abusing throw(StopIteration) to fake a “takewhile clause”
>> in comprehensions
>
> Well, so actually you needed the break expre
ur sys.path, only put the
directory containing the package on it.
What happens if you break this rule is exactly what you’re seeing. The way
Python ensures that doing `import spam` twice results in the same spam module
object (so your globals don’t all get duplicated) is by storing modules by
qualif
on’t know as much about PHP, but most of its design
is intended to feel familiar to C and C++ developers even if it doesn’t quite
make sense, so I’m guessing that’s why it has a similar feature.
Anyway, in Python, a “namespace package” is a package that’s _just_ a
namespace—it contains modules a
except FileExistsError:
pass
___________
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@pyth
d to rather than replaced. So, the OP’s first implementation
would be the right one, not his second.
Hopefully that doesn’t contradict what you’d want from the OP’s use case. :)
___________
Python-ideas mailing list -- [email protected]
To unsub
On Oct 29, 2019, at 11:45, Richard Vogel wrote:
>> What happens if you break this rule is exactly what you’re seeing. The way
>> Python ensures that doing `import spam` twice results in the same spam
>> module object (so your globals don’t all get duplicated) is by stor
On Oct 29, 2019, at 15:05, Richard Vogel wrote:
>
> Nevertheless, could Python cache that spec and cache also a checksum of whats
> coming out after resolveing the loader ?
>
Sure. In addition to sys.modules mapping names to modules you could have a
similar dict mapping specs to
, you can already shadow any stdlib
or other module completely.
_______
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 a
I agree, it's a bad idea. It'd have to be Python 4, like
> print_function was Python 3.
>
>>def throw(e): raise e
>
> The problem with this is that it adds an extra line to the traceback,
> so you have to choose between the convenience of using it and the
> con
over 100%.
Also, there are many places in the Python data model where you have to raise an
exception, such as StopIteration; there are no places where you need to print.
And if you need output and print is too slow, you can always go below; there’s
no way to raise an exception without raise.
exception, and
>> returning) is far more than twice as long.
>
> I don't recall seeing your test code, but I don't follow your reasoning
> here.
You replied to a message from Ben that was a reply to my message with the
performance test in it, which Ben was referring to in
t as well as being able
to search for your “https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/VIKWLWLDX3JKQOUGEUZ3EOX5T5JL7YBJ/
Code of Conduct: http://python.org/psf/codeofconduct/
On Nov 2, 2019, at 21:02, Random832 wrote:
>
>> On Sun, Oct 27, 2019, at 19:17, Andrew Barnert via Python-ideas wrote:
>>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>>>
>>> throw is an expression, not a statement, in C++. I see no reason raise
>
>> read/recv/mmap/result of a C library/whatever and use it as a string
>> without doing linear work on it first.
>
> constructing a string already takes linear time because you have to copy it
> into memory managed by the python garbage collector.
Not necessarily. There
orse, something that looks like a repr. That would be confusing.
>> Objects that have a better representation for normal humans, even if it may
>> be ambiguous or incomplete for programmers, use that for str, otherwise they
>> just fall back to the repr.
>
> Sure. But the
than they are helpful,
they’ll complain, and the next version of Python will change assignment
statements to handle raise_expr just like they handle yield_expr. (Or, if
someone can make that case even without waiting for experience, it’ll come up
while bikesheddi
languages mean I often don’t refactor functions as much
(even when it’s easy to prove that the call and moves will get inlined and
optimized out, because it’s not easy in C++ I don’t instinctively go there). So
for me, that doesn’t transfer into wanting to do the same thing in Python. But
again, I
n),
> which - needless to say - is impossible in CPython. In a hypothetical
> implementation that would allow such a thing, having the raise return a value
> in such a scenario might not be unreasonable.
That’s not just a CPython limitation, it’s a limitation of the defined Python
semantics. Pyt
On Nov 6, 2019, at 01:46, martin_05--- via Python-ideas
wrote:
>
>
> Still, the idea of two assignment operators just didn't sit well with me.
> That's when I realized I had seen this kind of a problem nearly thirty years
> ago, with the introduction of "J&
pression simple enough to be a target and a double-negated expression can
only be written by putting a space after the < symbol, but that probably
affects not a single line of code ever written.
But (even assuming I’m right about that), it would mean a new and unique rule
that you have to in
Thanks for your feedback. A few comments:
> I do not consider these two things conceptually equivalent. In Python the
>identifier ('a' in this case) is just label to the value
I used APL professionally for about ten years. None of your objections ring
true. A simple exa
> I don't think you understood the point about APL's arrow assignment operator
>being counterintuitive in Python.
I understood this just fine. I happen to think your argument in this regard is
neither sound nor valid.
Question: Where did APL's "←" operato
On Nov 6, 2019, at 19:52, Mike Miller wrote:
>
>> On 2019-11-06 05:40, Andrew Barnert via Python-ideas wrote:
>> While we’re at it, when you replace both = and := with an arrow, what do you
>> do with += and the other augmented assignments? I can’t think of a
>> s
out it. Anything else is
a pointer to a relevant data structure somewhere in memory. I think I can say
this it true of the vast majority of languages. Exceptions are cases like
Python and, say, Objective-C, or, in general, where the philosophy is that
everything is an object. Nobody is filling
On Nov 6, 2019, at 21:53, Martin Euredjian via Python-ideas
wrote:
>
> I've had this kind of a conversation with many people in the 30+ years since
> I learned APL and 20+ years since I stopped using it professionally. It has
> been my experience that people who have not h
> Really? Because I’ve been using ABC notation for music for decades
Try writing an orchestral suite in ASCII and see how well it goes. C'mon. I
know people use tablature and similar ideas. Sure. So what?
> The fact that I can enter Python code as plain text is even more useful th
601 - 700 of 1690 matches
Mail list logo
