[Python-ideas] Re: Namespaces!

@Paul Bryan, I'll try to address your questions one-by-one 1. It seems that I could get close to what you're aiming for by just using > underscores in names, and grouping them together in the class definition. > Is there any advantage to declaring methods in a namespace beyond > indentation and

[Python-ideas] Re: String comprehension

On Tue, May 4, 2021 at 5:16 AM Caleb Donovick wrote: > > For the record I am definitely a -1 on this. The arguments against are > overwhelming and the arguments for are pretty weak. However I felt the need > to rebut: > > > Tests don't really count, so there's a small handful here. > > Tests

[Python-ideas] Re: String comprehension

For the record I am definitely a -1 on this. The arguments against are overwhelming and the arguments for are pretty weak. However I felt the need to rebut: > Tests don't really count, so there's a small handful here. Tests 100% count as real use cases. If this is a pattern that would be

[Python-ideas] Re: String comprehension

On Fri, Apr 30, 2021 at 9:06 AM David Álvarez Lombardi < alvarezd...@gmail.com> wrote: > I propose a syntax for constructing/filtering strings analogous to the one > available for all other builtin iterables. It could look something like > this. > > >>> dirty = "f8sjGe7" > >>> clean = c"char for

[Python-ideas] Re: Namespaces!

Correction: 4. What would you expect getattr(A.B, "C") to yield? Paul On Mon, 2021-05-03 at 12:10 -0700, Paul Bryan wrote: > I've read the proposal, and this thread. > > Questions: > > 1. It seems that I could get close to what you're aiming for by just > using underscores in names, and

[Python-ideas] Re: Namespaces!

I've read the proposal, and this thread. Questions: 1. It seems that I could get close to what you're aiming for by just using underscores in names, and grouping them together in the class definition. Is there any advantage to declaring methods in a namespace beyond indentation and the dot

[Python-ideas] Re: Namespaces!

On Mon, May 3, 2021 at 6:49 PM Stestagg wrote: > class A: > Namespace B: > C = 1 > > A.__dict__ == {‘B.C’: 1, ‘B’: } OK, that is a difference. I don't really understand why it's desirable, but I see the difference. I can make that happen with a metaclass that would allow: class

[Python-ideas] Re: Comprehensions within f-strings

On Mon, May 3, 2021 at 5:37 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > f'{row!X:>8.3f} | {sum(row):>8.3f}' > hmm -- this is making me think that maybe we should re-enable sum() for strings -- with an optimized path, rather than an TypeError. I understand the

[Python-ideas] Re: Namespaces!

The first example in the doc lays out the difference: Assignments within the namespace block have this special behaviour whereby the assigned-to name is changed to be: ‘.’ And the assignment is made in the ‘parent scope’ of the namespace. I.e. (again, as described in the doc): class A:

[Python-ideas] Re: String comprehension

To be clear, I'm -1 as well -- we just don't need it. but a few thoughts: On Mon, May 3, 2021 at 6:32 AM Steven D'Aprano wrote: > If we have str comprehensions, we'd need at least two prefixes: one for > raw strings, one for regular (cooked) strings. would we? I don't think so -- because of

[Python-ideas] Re: Namespaces!

On Mon, May 3, 2021 at 6:37 PM Stestagg wrote: > On Mon, 3 May 2021 at 19:24, David Mertz wrote: > >> So yes... as I thought, SimpleNamespace does EVERYTHING described by the >> proposal, just without needing more keywords: >> > > Except that the code and description of the proposal explicitly

[Python-ideas] Re: Namespaces!

On Mon, 3 May 2021 at 19:24, David Mertz wrote: > So yes... as I thought, SimpleNamespace does EVERYTHING described by the > proposal, just without needing more keywords: > Except that the code and description of the proposal explicitly outline behaviours that SimpleNamespace does not provide

[Python-ideas] Re: Changing The Theme of Python Docs Site

Greetings list, Julien Palard responded with the following: *Hi Abdur,> However, I feel that the style is a bit bland and off putting> for newcomers. I suggest we consider changing the theme> to a crisper and cleaner look. I find docs such as Masonite> really enjoyable to read:

[Python-ideas] Re: Namespaces!

So yes... as I thought, SimpleNamespace does EVERYTHING described by the proposal, just without needing more keywords: >>> from types import SimpleNamespace >>> class A(SimpleNamespace): ... class B(SimpleNamespace): ... foo = 'bar' ... >>> A.B.foo 'bar' >>> A.B >>> import sys >>>

[Python-ideas] Re: String comprehension

On Mon, May 3, 2021 at 9:04 AM Paul Moore wrote: > On Mon, 3 May 2021 at 04:00, David Álvarez Lombardi > > This is the mindset that I had. I understand there are other ways to do > what I am asking. (I provided one in my initial post.) I am saying it > relies on what I believe to be a

[Python-ideas] Re: Changing The Theme of Python Docs Site

I think improving the online documentation is a good idea. How can this effort avoid merely addressing subjective preferences? Beauty in the eye of the beholder, and all that. This appears to be the current style guide: https://devguide.python.org/documenting/ It largely focuses on content.

[Python-ideas] Re: Namespaces!

So for simplicity let's assume that the content of 'bar' is 3, and let's assume that the module is __main__ Then: >>> vars(sys.modules[__name__])["A.B.foo"] 3 And it can be accessed in the usual way like: >>>A.B.foo 3 Likewise for the namespace objects that are created during the namespace

[Python-ideas] Re: String comprehension

On Sun, May 02, 2021 at 10:57:59PM -0400, David Álvarez Lombardi wrote: > I really appreciate all the feedback and all of the thought put into this > idea. I wanted to make a couple of comments on some of the responses and > provide my current thoughts on the idea. > > --- Responses to comments

[Python-ideas] Re: String comprehension

On Mon, May 3, 2021 at 10:08 PM Steven D'Aprano wrote: > > On Mon, May 03, 2021 at 09:04:51PM +1000, Chris Angelico wrote: > > > > My understanding of the situation is that the list comprehension [ > > > x*x for x in range(5) ] is a shorthand for list( x*x for x in > > > range(5) ). > > > >

[Python-ideas] Re: Comprehensions within f-strings

Eric V. Smith writes: > I don't think you'd want f-strings to hijack that expression because it > starts with "X". Better to do something like: > > f'{row!X:>8.3f} | {sum(row):>8.3f}' I wondered, is that even possible? OK, I guess you could do it with a Row(Any) class something like

[Python-ideas] Re: Namespaces!

OK, tell me what this does. namespace A: namespace B: foo = bar On Sat, May 1, 2021 at 7:55 PM Matt del Valle wrote: > Hi all! > > So this is a proposal for a new soft language keyword: > > namespace > > I started writing this up a few hours ago and then realized as it was >

[Python-ideas] Re: Comprehensions within f-strings

I didn't even realize f'{n for n in row}' was already valid syntax. Since generator expressions can usually only appear within parentheses, I assumed the syntax wouldn't conflict with anything because you would need to parenthesize the generator to make it work. Anyway, now I see that the

[Python-ideas] Re: String comprehension

On Mon, May 03, 2021 at 09:04:51PM +1000, Chris Angelico wrote: > > My understanding of the situation is that the list comprehension [ > > x*x for x in range(5) ] is a shorthand for list( x*x for x in > > range(5) ). > > Sorta-kinda. It's not a shorthand in the sense that you can't simply >

[Python-ideas] Re: String comprehension

On Mon, May 3, 2021 at 8:03 PM Jonathan Fine wrote: > Difference. > >>> tmp = (x*x for x in range(5)) ; list(tmp) > [0, 1, 4, 9, 16] > >>> tmp = (x*x for x in range(5)) ; [ tmp ] > [ at 0x7fec02319678>] Closer parallel: >>> tmp = (x*x for x in range(5)) ; [ *tmp ] [0, 1, 4, 9,

[Python-ideas] Re: String comprehension

Summary: The argument in list(arg) must be iterable. The argument in str(arg) can be anything. Further, in [ a, b, c, d ] the content of the literal must be read by the Python parser as a Python expression. But in "this and that" the content need not be a Python expression. Hi David I find your

[Python-ideas] Re: Changing The Theme of Python Docs Site

Time from someone clever with CSS in Sphinx may be all it takes. Yes, agree , i am not suggesting other docs systems but just reconsidering the style. @Marc indeed raised the question of overall consistency which i guess will be addressed one day or the other. As for the wiki besides, look

[Python-ideas] Re: Changing The Theme of Python Docs Site

On 30/04/2021 14:29, Rob Cliffe via Python-ideas wrote: On 30/04/2021 07:06, Abdur-Rahmaan Janhangeer wrote: The Masonite docs for example is quite nice: https://docs.masoniteproject.com/ I read as far as the 4th sentence:     "Use it for your next SaaS!"

[Python-ideas] Re: Changing The Theme of Python Docs Site

Yeah, the HOWTOs on the docs include the best explanations of Regex and bitwise operators (and probably other arcane concepts) that I've found anywhere on the Internet, and it would be great if they were themed in a way that felt equal to other great resources on the Internet. On Mon, 3 May 2021

[Python-ideas] Re: String comprehension

On Mon, 3 May 2021 at 04:00, David Álvarez Lombardi wrote: > This is the mindset that I had. I understand there are other ways to do what > I am asking. (I provided one in my initial post.) I am saying it relies on > what I believe to be a notoriously unintuitive method (str.join) and an even

[Python-ideas] Re: Changing The Theme of Python Docs Site

I can well imagine someone turning away from a language because the docs felt old or badly styled. One practical effect of it is people preferring to read articles on other sites rather than consult the docs first. One piece of docs that is greatly explained is the sockets section. The part i

[Python-ideas] Re: Changing The Theme of Python Docs Site

As someone who does both Web design and Python regularly, I'd love to contribute to reworking/changing the Python docs theme. They are not terrible currently, there are certainly areas for improvement, both in overall layout and text styling. Bringing it closer to other Python branding may also

[Python-ideas] Re: Changing The Theme of Python Docs Site

Found the link i was referring to: https://psg.com/r.clue.html quote: <> @Rob Cliffe I was saying that if you don't know the flashy terms it's an indication that you come from a great time. Me myself i find myself no longer wanting to go deep into networking or the Linux kernel maybe because i

[Python-ideas] Re: Changing The Theme of Python Docs Site

Woops i present my excuses list, it seems english jokes in my country don't play well overall. I never intend to insult people nor insinuate insults. @Rob Cliffe normally when i have old friends, i like to joke about how ancient they are. A dinosaur in tech deserves respect. Like i was reading