[Python-ideas] Re: Multiple arguments to str.partition and bytes.partition
You can get almost the same result using pattern matching. For example, your
"foo:bar;baz".partition(":", ";")
can be done by a well-known matching idiom:
re.match(r'([^:]*):([^;]*);(.*)', 'foo:bar;baz').groups()
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TVGHFAVNQU4BTLCAPK34DBU5ESN464Z3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should Python enforce Type-checking in the future?
Steven D'Aprano wrote:
> > That seems to be close to the opinion of Robert C Martin:
> http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html
> He also has some comments on languages like Koitlin and Swift that have
> gone down that path of mandatory static typing:
> http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html
Yet another example of "Uncle Bob" writing stuff that's "not even wrong". Of
course, typing doesn't catch all bugs; but neither does Uncle Bob's
testing-testing-testing. And never will. Programmers need all the help they can
in catching bugs and also in understanding other people's code - and types are
really helpful for that ... I can't count the number of hours I've spent at
Google, figuring out how something works so that I can add some functionality -
often by adding stuff like logging.info("Type of qqsv: %s", qqsv.__class_).
(On Mondays, Wednesdays, and Fridays, I think that mandatory typing would be
fabulous (to paraphrase Brian Reid: "most people won't use types even when you
threaten them"). On Tuesdays, Thursdays, and Saturdays, I meditate on how
difficult it is to write types in Haskell, which is far easier for typing than
Python. On Sundays, I go for a head-clearing walk in the park.)
PS: For another example of "Uncle Bob" nonsense:
https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/L6FPYNFJKFJPD4Z4NHVP2E5BXERDDPT4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extending ast.parse with some lib2to3.pytree features
Neil Girdhar wrote: > I wish this had gotten more attention! :) I wonder what the various projects are doing to handle the latest version of Python, if they need a parse tree with whitespace information. (The projects I know of are yapf, black, mypy, pytype, kythe -- are there others?) ast.parse() has an option `type_comments`, so certain kinds of comments are handled -- I wonder how much work it would be to extend this to handle all whitespace? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/747HHPVSNK6TCSOZHJHUEUDX2GKQROKN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing additional string operators
MRAB wrote:
> From a mathematical point of view, x-y is equivalent to x+(-y).
>From a mathematical point of view, x+y is equivalent to y+x, but I suppose
>that ship has sailed a long long time ago. ("++", "--", etc. would have been
>better choices for operators)[*]
Anyway, if you're going to add these operators for strings, I suggest also
adding them for lists. And also make them work with the new match syntax.
[*] Floating point x+y isn't always y+x, but floating point is its own
problematic world.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/L54PEC35IQ7SLZANDQQEEGARXRININS5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding syntax for the empty set
David Mertz wrote:
> The pattern of "Create an empty collection, then add stuff in a loop" is
> quite common, ...
Or you can use comprehensions, in which case there's no need for creating an
empty collection.
s = {f(x) for x in some_list}
vs
s = set()
for x in some_list:
s.add(f(x))
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3ZEFFBQMMEG3BHE45SOHB2P4G73C7DC3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
Chris Angelico wrote:
> On Sat, Mar 13, 2021 at 1:46 PM Peter Ludemann peter.ludem...@gmail.com wrote:
> > It's not clear to me what surprising behaviors there would be. Javascript
> > seems to do OK with optional semicolons - presumably its algorithm is
> > similar to what BCPL used. (Or perhaps the surprising behaviors are trivial
> > compared to the other surprises that Javascript springs on people.)
> > Yes, right up until you try to do something like:
> function foo() {
> return
> thing.goes.here()
> }
> which becomes extremely common with frameworks like React.js. There's
> an implicit semicolon and a big block of dead code.
> ChrisA
def foo():
return
thing.goes.here()
is illegal Python; and wouldn't result in a line-join by my proposal.
However:
def foo():
return "A long piece of text (Lorem ipsum dolor sit amet, consectetur
adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna
aliqua.)" +
thing.goes.here()
would work by my proposal and avoid the extra parentheses that are currently
needed.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GUVXVBLWVCCST6NTGSDICZO73QPD7BPV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
On Fri, 12 Mar 2021 at 18:27, Guido van Rossum wrote: > On Fri, Mar 12, 2021 at 6:23 PM Peter Ludemann > wrote: > >> [I wonder why C didn't adopt BCPL's convention for eliding semi-colons? >> ...] >> > > [Presumably because it caused too many surprising behaviors...] > My guess is that it would have been more work in the parser, and therefore didn't fit with Unix "minimalism". ;) It's not clear to me what surprising behaviors there would be. Javascript seems to do OK with optional semicolons - presumably its algorithm is similar to what BCPL used. (Or perhaps the surprising behaviors are trivial compared to the other surprises that Javascript springs on people.) > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MJK7MMCZ2NVZM6OL3IWD3BXXAFYIYLMX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
Guido van Rossum wrote:
> Can we skip ahead to considering how to implement this? I can think of two
> approaches: either hack the lexer to special-case a newline followed by a
> period (which currently can never start a line), or redesign the syntax to
> allow NEWLINE INDENT ‘.’ . NEWLINE ‘.’ DEDENT at the
> end of an expression. Both have pros and cons.
> Discuss how this allows for certain typos to pass as valid syntax.
IIRC, BCPL's compiler would continue and expression on the next line if a line
ended with an operator. E.g.:
x = a +
b
would parse like
x = (a +
b);
(I think this was a bit more general - if a line didn't end with ";", the
parser would try adding a ";" and if that failed to parse, it would continue to
the next line.)
This leads result in a different style for method-chaining:
y = x.rstrip("\n").
split(":")[0].
lower()
... and if you don't like ending lines with a ".", you could always add a
parenthesis:
y = (x.rstrip("\n")
.split(":")[0]
.lower())
[I wonder why C didn't adopt BCPL's convention for eliding semi-colons? ...]
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/A344DHD4YD25DQFM2OYBNKU63HTHO4FN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generic NamedTuples
Ben Avrahami wrote 9 Feb 2021, 03:30: > That's the current alternative, but namedtuples (unlike dataclasses) are > slotted, which makes them more space-efficient and (slightly) faster. When I use @dataclass(frozen=True), I manually add a __slots__ attribute. I presume this makes the resulting objects similar in size to NamedTuples, but I haven't done any measurements (and not sure how to measure this anyway). I wonder: is it possible for @dataclass to have an option slots=True? And perhaps frozen=True should imply slots=True (would this cause any backwards compatibility problems?). ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OBFNLB363DQM5YELR46M3OI3BNKIKSPB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generic NamedTuples
I use dataclass (with frozen=True) instead of NamedTuple - and I can do mixins. https://docs.python.org/3/library/dataclasses.html ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CGJTA7NHHWJJZZ775RAX3FLC3VRXMEB7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Standard tool for iterating over recursive data structures?
A variant of the problem is the "occurs check", used in theorem proving: https://en.wikipedia.org/wiki/Occurs_check Removing the occurs check reduces the cost of unifying two terms (t1, t2) from *O(size(t1) + size(t2))* to *O(min(size(t1), size(t2)))*, which is why Prolog implementations don't do the occurs check by default (but provide unify_with_occurs_check and acyclic_term predicates for when the check is needed). One use for cyclic terms is in representing grammars. Of course, the loops can be avoided by changing the representation from a graph to a BNF-style set of clauses - that is, by naming the nodes. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EY7K2T2S6DNG3JPTWEJVKNC6TQVLYEGF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] extending ast.parse with some lib2to3.pytree features
With lib2to3 going away (https://bugs.python.org/issue40360), it seems to
me that some of its functionality for handling "whitespace" can be fairly
easily added to the ast module. (By "whitespace", I mean things like
indent, dedent, comments, backslash; and also the ability to manipulate the
encoded bytes in the original source.)
Off the top of my head, I know of the following projects that use lib2to3
or similar to access the "whitespace" in the parse tree and will need a new
solution:
yapf, black, mypy, pytype, kythe.
(If they don't use lib2to3, they need to maintain a custom parser that
changes with each release of Python, so my proposal would potentially help
them.)
Are there other projects that need access to the parse tree and
"whitespace"?
I propose implementing an optional pass over the parse tree that records
lib2to3's "prefix" with each leaf node. The interface would be something
like:
def detect_encoding(source: bytes) -> str
def parse_with_whitespace(source: bytes, encoding: str, filename: str) ->
ast.Module
def unparse_bytes(tree: ast.Module) -> bytes
def unparse_str(tree: ast.Module) -> str
# Various convenience functions/properties, similar to
pytree.next_sibling etc.
parse_with_whitespace() calls ast.parse(), then does a pass over the parse
tree, adding to the leaf nodes:
prefix: str # whitespace and comments preceding token in the input
pieces: List # see below
col_byte_offset: int # start byte offset within line
src_byte_offset: int # start byte offset within source
The "pieces" field is intended to handle things like:
x = 'abc' \
"def"
y = (f'abc{x}' # comment
"def")
Each "piece" would include:
- byte offset from the beginning of the token (negative for a prefix
piece)
- detailed type (single-quote string, double-quote string, format-string,
int, float, etc.)
- source bytes
- decoded value (Unicode str)
The ast.Module class would also be extended with additional attributes that
apply to the entire source, such as the encoding.
All of this is quite fiddly, but I already have some code for dealing with
the conversions between byte and string offsets, so I don't anticipate a
huge amount of work. (The design is also inherently a bit inefficient; but
I don't want to get involved with the internals of compile().)
A related item: "Parser module in the stdlib":
https://mail.python.org/archives/list/python-...@python.org/thread/RHZ6JOEXJSQUPLJECCBEIYWWWSB3IG3O/#UJ5YEMSPSUGQFDKCIEMVALVB4WP6NYI5
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/X2HJ6I6XLIGRZDB27HRHIVQC3RXNZAY4/
Code of Conduct: http://python.org/psf/codeofconduct/
