You have to consider that for the reader of the code that's one line containing a function call versus six lines containing that comprehension. An advantage of functions is that you can hide the implementation but a comprehension always contains all the code. If the function name is clear abou
1. At least in my editor (PyCharm), I can collapse (fold) list comprehensions
just as easily as functions.
2. In this example the list comprehension already has a name - `clean_lines`.
Using a function actually forces me to come up with a second pointless name.
3. On the note of coming up with na
I also use PyCharm but I don't fold comprehensions; ideally I don't have to since comprehensions are meant to be simple and concise. Folding a comprehension takes away all the information, including the input to the operation.Regarding names, the example function you presented, `clean`, isn't
22.02.20 09:43, David Mertz пише:
Comprehension are very much based on the idea of *declarative* data
collections. That's their entire reason for being. In general, one
expects comprehension to be side-effect free and just build a collection
according to declared rules. Obviously I know many wa
Hello,
Just a quick correction, in case a begginer sees this thread.
You can use raw strings for Windows paths, except when they end with a
backslash.
This works:
path = r'somewhere\some\folder'
filepath = r'somewhere\some\folder\file.txt'
This also works:
from os import sep
path = r'somewher
PyCharm (I think only the paid edition) does recognise SQL in plain string
literals just because it looks like SQL, and it offers various features from
there including syntax highlighting. It also recognises that the first argument
to functions like `re.match` is a regex and has features for tha
Steve Jorgensen wrote:
> Currently, if I know that I want an array.array object with
> itemsize of 4 there is no way to do that without first determining what the
> item sizes are for 'i'/'I' and
> 'l'/'L' on the current platform. Presumably, things could get
> even more hairy with future platform
> One of the points of using a function is to not define it in the local
scope, but in some other namespace, so it can be reused and tested.
I consider the "tested" part to be of particular importance. Especially if
it were to become multiple layers deep, this can become a real issue.
This might
>From reading many of the suggestions in this list (including some of my own,
>of course) there seem to be a lot of us in the Python coder community who find
>the current behavior of strings being iterable collections of single-character
>strings to be somewhat problematic. At the same time, try
On Sun, Feb 23, 2020 at 11:26 AM Steve Jorgensen wrote:
>
> From reading many of the suggestions in this list (including some of my own,
> of course) there seem to be a lot of us in the Python coder community who
> find the current behavior of strings being iterable collections of
> single-char
I don't know if core devs believe it is wrong, but many of the suggestions for
change here seem to express that opinion.
I try to stay away from "wrong" & "right", but one of the reasons I dislike the
current behavior is that it's an issue when trying to traverse a nested graph
of collections.
On 02/22/2020 04:37 PM, Chris Angelico wrote:
Do any of the core devs agree with those two assertions?
If posts to -Ideas required core dev agreement this would be an empty list
indeed.
--
~Ethan~
___
Python-ideas mailing list -- python-ideas@pytho
Hello,
I just noticed that calling `str(x)` is actually doing (in CPython
`PyObject_Str`) `type(x).__str__(x)` rather than `x.__str__()`.
Context: I wanted to override __str__ for certain objects in order to
“see them better”.
I'm wondering why not do `x.__str__()`
Best regards,
--
Jérôme
_
On Sat, Feb 22, 2020, 5:29 PM Steve Jorgensen wrote:
> ... Currently, it is necessary to specifically test whether a node is an
> instance of `str` and stop drilling down in that case. One could say that's
> a minor issue, but it's a minor issue that affects a lot of development
> efforts and has
This is explained in "Special Method Lookup":
https://docs.python.org/3/reference/datamodel.html#special-method-lookup
Short version: For both correctness and performance, special methods (those
that begin and end with double underscores) are typically looked up on the
class, not the instance. If
On Sun, Feb 23, 2020 at 1:15 PM Ethan Furman wrote:
>
> On 02/22/2020 04:37 PM, Chris Angelico wrote:
>
> > Do any of the core devs agree with those two assertions?
>
> If posts to -Ideas required core dev agreement this would be an empty list
> indeed.
>
Heh true. Still, there's not a lot of p
In order for this proposal to be seriously considered, I think it's
necessary to cite many realistic examples where the current behavior is
problematic enough to justify changing the current behavior, and that
adding a str.chars() and eventually removing the ability to iterate over
strings would pr
On Sun, Feb 23, 2020 at 01:28:35AM -, Steve Jorgensen wrote:
> Another issue is one of consistency. A string is not a sequence of
> length-1 strings.
Isn't it? It sure looks like a sequence of length-1 (sub)strings to me.
Of course, strings can also be views as a sequence of paragraphs, li
Thanks Josh for your prompt reply. All clear.
Regards,
--
Jérôme
PS: Somehow I had never encountered a situation exacerbating the
subtleties of implicit invocations of special methods, and hadn't read
or integrated that section of the documentation, then when encountering
the “problem” I didn'
It's always been in the back of my mind that directly iterable strings are
very often more trouble than they are worth. But I also agree that changing
it would probably be extremely disruptive (and also might be more trouble
than it's worth).
I've only been at it for about 3 years, but because of
On Sun, Feb 23, 2020 at 12:10:24AM -0500, Ricky Teachey wrote:
> I've only been at it for about 3 years, but because of iterable strings I
> always seem to regret not using a function like this in many contexts:
>
> def iter_nostr(iterable):
> if isinstance(iterable, str):
> raise Ty
On Sun, Feb 23, 2020 at 05:01:22PM +1100, Steven D'Aprano wrote:
> Why is that a f-string? It's a static message. That's kind of like
> writing `x += eval('1')`.
Oh, I just checked in 3.8 with `dis`, and static f-strings are compiled
to a static string. Nice!
--
Steven
__
Better yet:
Provide type codes for the “new” C exact width integer types:
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
(and any number of tother references)
I've always thought is was unfortunate that Python inherited C's
compiler-specific type definitions. But it's n
I think that the "strings are an iterable of strings", i.e. an iterable of
iterables onto infinity... is the last remaining common dynamic type issue
with Python.
However, I'd like to see the "solution" be a character type, rather than
making strings not iterable, so iterating a string would yield
24 matches
Mail list logo
