[Python-ideas] Re: XDG Directory Support for PDB

I apologize for the top-post and awkward trimming, my employer just switched to o365 and won't accomodate my existing mail client so I'm stuck with a crappy webmail client on this address. :-p I agree with Barry on both points: seems like a good idea, but the search priority should be ./.pdbr

[Python-ideas] Re: XDG Directory Support for PDB

2023-04-21 00:51 に Gustaf Waldemarson さんは書きました: Oh i see you read all the files. Usually you need to stop looking once you find an rc file. I guess that really depends on the program, but since pdb is modelled on gdb, I figured it made sense to do something similar :) I don't have a proble

[Python-ideas] Re: new PEP: implementation independent native code invocation and data exchange ABI standard (not sure if accurate)

This isn't a PEP yet: it's a set of requirements. A PEP eventually needs to say how to implement the requirements, and even at this "proto-PEP" stage, it needs to be plausible that it's implementable. It's on you to explain how your very ambitious requirements can be satisfied in Python. Nob

[Python-ideas] Possibility to decorate single code line or code block?

Marco Sulla writes: > Maybe it's a crazy idea, but what if we could decorate a single line > of code? > For example: > > @Timer > a = time_consuming_function() As syntax, I don't see the advantage over with ContextManagingTimer(): a = time_consuming_function() I don't underst

[Python-ideas] Re: built in to clear terminal

Eryk Sun writes: > Here are some concerns I have: This is the best argument for a clear_terminal (clear_window?) builtin I've seen. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] h

[Python-ideas] Re: built in to clear terminal

Mike Miller writes: > No offense, but if you're a developer who can't handle hotkeys or > came of age before the "glass tty" and won't learn any new tricks… > well, that's just *"your problem, mayan."* > > The rest of us are capable. :D The thing is, this is a destructive capability. In s

[Python-ideas] Re: Unpack operator "**" and Mapping

Brendan Barnwell writes: > So, to give an example, the iterator protocol should be documented > right where the `for` statement is documented, and it should be > explicitly framed as "this is the definition of what the `for` statement > does", not something separate. But for the stude

[Python-ideas] Re: built in to clear terminal

Mike Miller writes: > Note, I added the word *important* on purpose. ;-) Ie, since you were lucky enough the time you did something like it, it's not important to anybody? > Reminds me of a story. As an teen I learned the lesson of what > happens when you flip the power switch of the comput

[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.

Steven D'Aprano writes: > URLs are also a lot more complicated than file paths, It may be just me, but I would say the opposite: URLs are simpler because they follow unambiguous rules. There is no "realpath" for URLs, they're WYSIWYG. "." and ".." have unambiguous semantics in URLs[1], which a

[Python-ideas] Re: Python with braces formal proposal?

Chris Angelico writes: > On Wed, Jan 6, 2021 at 9:27 PM Steven D'Aprano wrote: > > I'm glad that things like Perl one-liners, obfuscated C, and > > sewerage treatment works exist... > > :) +1 > > Multi-statment anonymous functions are, in my opinion, overrated, and a > > (slight) code s

[Python-ideas] Re: pathlib enhancements

Joseph Martinot-Lagarde writes: > One remark about this : .tar.gz files are the exception rather than > the rule, and AFAIK maybe the only one ? Not really. stem.ext -> stem.ext.zzz where zzz is a compression extension is a pretty common naming convention. For me ext == 'tar' is by far the mo

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Chris Angelico writes: > On Sat, Jan 23, 2021 at 12:37 PM Inada Naoki wrote: > > ## 1. Add `io.open_text()`, builtin `open_text()`, and > > `pathlib.Path.open_text()`. > > > > All functions are same to `io.open()` or `Path.open()`, except: > > > > * Default encoding is "utf-8". I wonder i

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Steven D'Aprano writes: > On Sat, Jan 23, 2021 at 12:40:55AM -0500, Random832 wrote: > > On Fri, Jan 22, 2021, at 20:34, Inada Naoki wrote: > > > * Default encoding is "utf-8". > > > > it might be worthwhile to be a little more sophisticated than this. > > > > Notepad itself uses character

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Guido van Rossum writes: > I have definitely seen BOMs written by Notepad on Windows 10. I'm not clear on what circumstances we care if a UTF-8 file has or doesn't have a UTF-8 signature. Most software doesn't care, it just reads it and spits it back out if it's there and hasn't been edited out

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Cameron Simpson writes: > I thought I'd seen [UTF-16 BOM] on Windows text files within the > last year or so (I don't use Windows often, so this is happenstance > from receiving some data, not an observation of the Windows > ecosystem; my recollection is that it was a UTF16 CSV file.) OK; my

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Matt Wozniski writes: > Rather than introducing a new `open_utf8` function, I'd suggest the > following: > > 1. Deprecate calling `open` for text mode (the default) unless an > `encoding=` is specified, For that, we should have a sentinel for "system default encoding" (as you acknowledge, b

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Chris Angelico writes: > Can anyone give an example of a current in-use system encoding that > would have [ASCII bytes in non-ASCII text]? Shift JIS, Big5. (Both can have bytes < 128 inside multibyte characters.) I don't know if Big5 is still in use as the default encoding anywhere, but Shift

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Chris Angelico writes: > Can anyone give an example of a current system encoding (ie one that > is likely to be the default currently used by open()) that can have > byte values below 128 which do NOT mean what they would mean in ASCII? > In other words, is it possible to read in a section of

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

Chris Angelico writes: > Isn't that what file objects have attributes for? You're absolutely right. Not sure what I was thinking. (Note: not an excuse for my brain bubble, but Path.read_text and Path.read_binary do have this problem because they return str and bytes respectively.) > Do you g

[Python-ideas] Re: Conditional with statements

Oscar Benjamin writes: > On Sun, 7 Feb 2021 at 23:55, Greg Ewing wrote: > > On 8/02/21 6:59 am, Christopher Barker wrote: > > > I find myself > > I often write > My preferred option is There's ALWAYS more than one way to do it! :-) I'm not a fan of the proposed new syntax. A big issue for

[Python-ideas] Re: Conditional with statements

Brendan Barnwell writes: > let the editor (as configured by the reader) choose how to map that > [long logical line] onto a visual display. I think your editor must be the first example of true intelligence in a machine. I don't know any editors that reliably do this readably, let alone to my

[Python-ideas] Re: Arrow functions polyfill

Steven D'Aprano writes: > lambda a, b, c: a+b*c > (a, b, c) -> a+b*c Of course, the mathematicians' spelling would be (a, b, c) |-> a+b*c (Don't bother throwing things, I'm already a 5km down the road.) ___ Python-ideas mailing list -- p

[Python-ideas] Re: Alternate lambda syntax

Ned Batchelder writes: > "lambda" is unnecessarily obscure. And it should be. It's really only useful as an argument. There's no advantage to foo = (x) -> 1 vs. def foo(x): return 1 except a couple of characters. So what currently looks like some_list.sort(key=lambda e: e[3].

[Python-ideas] Re: Alternate lambda syntax

Abdulla Al Kathiri writes: > How is this not pythonic? > > series.apply(x -> x**2) > Compared to.. > series.apply(lambda x: x**2) The main problem is that the second already exists, and the first doesn't, while the first adds no new power to the language, and isn't enough more readable (a

[Python-ideas] Re: SimpleNamespace vs object

Chris Angelico writes: > On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote: > > I would personally love for SimpleNamespace to get a shorter name > > and become a built-in. > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > builtin, what should its name be? It need

[Python-ideas] Re: Alternate lambda syntax

[email protected] writes: > On 2021-02-18 at 18:10:16 +0400, > Abdulla Al Kathiri wrote: > > > I will be very happy if those versions of Callable and anonymous > > functions exist in Python right now. See how elegant that would look > > like.. > > > > def func(x: int, y:

[Python-ideas] Re: Alternate lambda syntax

Abdulla Al Kathiri writes: Condensing to the parts which are in question, > def test(self, func: t.Callable[..., bool], *args, **kwargs) -> Predicate: > return self._build_predicate( >lambda lhs, value: func(lhs, *args, **kwargs), > Operation.TEST, >

[Python-ideas] Re: argparse: mutually inclusive arguments

David Mertz writes: > On Wed, Feb 24, 2021 at 1:38 PM Paul Korir wrote: > > > I've been using the argparse library for a long time and one use case that > > repeatedly shows us is the need to have two arguments appear together i.e > > either both appear or none of them appear. I'll refer to

[Python-ideas] Re: argparse: mutually inclusive arguments

Oscar Benjamin writes: > On Fri, 26 Feb 2021 at 02:49, Stephen J. Turnbull > wrote: > > Thing is, this "mutual inclusion" condition isn't really about parsing > > (ie, syntax)[1]; this is about semantics -- like all input validation. > > I don'

[Python-ideas] Integer concatenation to byte string

[email protected] writes: > I propose an array-type string like the, or for the bytearray. It > would work as a mutable b-string, as > > foo = a"\x00\x01\x02abcÿ" # a-string, a mutable bytes object. I don't work with bytes much, so I won't comment on the proposal itself. But as some

[Python-ideas] OT: Make list.reverse() more flexible

Vincent Cheong writes: > Sorry for not explaining the background of my idea. I'm involved in > the research area of sorting algorithms. Reversals are part of > sorting I'm curious: Many of the sorting algorithms I know use swap pairs of elements, but what sorting algorithm reverses segments l

[Python-ideas] Re: Looking for people interested in a Python register virtual machine project

Skip Montanaro writes: > So, neither "research" nor "production" seems to be a correct > descriptor. Not even government funding agencies distinguish between "research" and "itch-scratching" as long as you self-promote enough! :-) I agree with Paul, feel free to call it "research"! Steve __

[Python-ideas] Clarification to PEP 394

Moving to Python Dev, reply-to set. Please reply to Python-Dev only. Full message appended at end for context. Adam Hendry writes: > Although PEP 394 is geared towards Linux users, those unfamiliar > with Linux don't know what env is or what it does. env(1) is not Linux-specific. It a POSIX

[Python-ideas] Re: Reverse polish notation

Greg Ewing writes: > To get by with just one "+" you would need some way to bracket > the arguments, then you have something more like backwards Lisp > with at least as many parens as infix. You can't invoke Lisp here: (+) 0 (+ 1) 1 (+ 1 1) 2 (+ 1 1 1) 3 and so on. My recollection is the sa

[Python-ideas] Re: Reverse polish notation

Alexandre Brault writes: > On 2021-04-03 12:07 a.m., John wrote: > >> Visually this means I can identify each particular operation and its > >> relationship with the next term, then ignore it (visually track parts > >> that no longer matter for understanding the equation) and look at the > >>

[Python-ideas] Re: Reverse polish notation

John writes: > Here's a question: is it possible to implement this with a Python > module, or is that absolutely not a thing that can be done? Yes, it can, or at least you could use MacroPy (not sure if that's pure Python, if it is then you could implement in a module using the same techniques)

[Python-ideas] Re: Adding syntax for the empty set

Chris Angelico writes: > Not to mention everyone's keyboards. Python != APL. Err, I mean, > Python ≠ APL. I am really tired of this argument. set() is not going to go away. And it's easy enough to install input methods (aka "keyboards") on any modern system that allow you to enter these if yo

[Python-ideas] Re: Python Idea - extension of 'with'

Serhiy Storchaka writes: > A year or two ago I proposed the same syntax with different semantic: to > catch only exceptions in the context manager, not in the with > block. FWIW, this is the semantics I would expect, for the reason you give: > Exceptions in the with block you can catch by ad

[Python-ideas] Iterable scalar values returning itself ones?

Hans Ginzel writes: > Are there any reasons not to make scalar types iterable returning > the value ones? Yes. Scalars aren't containers. Except strs, which are containers all the way down. :-þ If we must iterate scalars, then at the very least we should conform to existing mathematical inte

[Python-ideas] : str() vs format(): trivia question

@serhiy Moving my speculative discussion to python-ideas. CC as courtesy, comment from you is welcome but not necessarily expected. Serhiy Storchaka writes: > format() without format specifier and str() should return the same > value in general, otherwise it will confuse users. I think this i

[Python-ideas] Support more conversions in format string

Serhiy Storchaka writes: > Currently format strings (and f-string expressions) support three > conversions: !s -- str, !r -- repr and !a for ascii. It's not clear to me what these are good for, to be honest. Why not just have s, r, and a format codes? The !conversions don't compose with forma

[Python-ideas] Re: Support more conversions in format string

Cameron Simpson writes: > I would _frequently_ like to be able to provide custom > conversions. At present I'm using elaborate hacks based on > __getattr__ etc to recognise things like this: > > '{x} is {x_lc} in lowercase' > > where the _lc suffix is caught and a value computed from

[Python-ideas] Re: Support more conversions in format string

Cameron Simpson writes: > On 23Apr2021 18:25, Stephen J. Turnbull > wrote: > >I don't understand how this is supposed to work. It looks to me like > >!code is a preprocessor: [...] > >If so, > > > >'{x} is {x!lc:foo} in lowercase'

[Python-ideas] Re: Support more conversions in format string

Serhiy Storchaka writes: > Because it converts value to string, and string formatting does not > support "g". Converters !s, !r and !a are separated from format > specifier, and it is old and widely used feature. And poorly documented, IMO. I'll see if I can do better. > but if we are going

[Python-ideas] Re: Support more conversions in format string

Cameron Simpson writes: > First up, I have somehow missed this (":format_name") in the > semirecursive mess which is the python format-and-friends descriptions. > (object.__format__? str.format? str.formap_map? f''? the format > mini-language? all in separate places, for reasonable rea

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

Abdur-Rahmaan Janhangeer writes: > I have been reading the Python docs since long. > I have enjoyed it, it has great pieces of information. > You have how-tos, faqs etc. Really awesome to read. Thank you! ;-) > However, I feel that the style is a bit bland and off putting > for newcomers. I

[Python-ideas] TACE16 text encoding for Tamil language

You wrote: > I want to use this encoding > > for Tamil language text As written, it sounds like you just want help. If so, this list is for proposals to change Python itself (including the standard library), and this

[Python-ideas] Re: TACE16 text encoding for Tamil language

Jonathan Goble writes: > I assume the "cpython" part of these paths here is your local clone of the > CPython GitHub repo? (Otherwise these local filepaths from your computer > don't make sense.) Thanks for catching that! Sorry, I was concentrating on stifling irrelevant Unicode politics. :-)

[Python-ideas] Re: Adding str.remove()

David Mertz writes: > Lots of things "should be" :-). Sadly, I deal with "actually existing data." What I would do to experience your kind of sadness! I spend most of my time working around (or doing theory instead of working on) "actually nonexisting data". ;-) Steve _

[Python-ideas] Re: String comprehension

Valentin Berlier writes: > f""" > Guest list ({len(people)} people): > {person.name + '\n' for person in people} > """ That's nice! It's already (almost[1]) legal syntax, but it prints the repr of the generator function. This could work, though: f"""

[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 class

[Python-ideas] Re: String comprehension

Bruce Leban writes: > where *!j* means join. It could optionally take a separator string as in > this example: Converters *could* take arguments but they currently don't: it's a simple switch on a str argument. We already have one complex minilanguage inside {}, do we really want another? May

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

Paul Bryan writes: > It largely focuses on content. Would it be worth codifying additional > aesthetic and usability objectives, and build consensus around > them? We're literally talking about painting a bikeshed! Just do it, and if people don't like it enough it gets rolled back. My two se

[Python-ideas] Re: division of integers should result in fractions not floats

David Mertz writes: > On Fri, May 14, 2021, 4:31 PM Jonathan Fine wrote: > > > >>> 1/2 + 1/3 > >> 5/6 > >> 1 / 2 + 1 / 3 > >> 0.83 > >> > > > > I'm sighted. I can see the difference. I suspect a blind person using a > > screen reader would struggle a lot to spot

[Python-ideas] Re: division of integers should result in fractions not floats

Christopher Barker writes: > Python assumes, and converts to, floats all over the place. So users need > to understand and accommodate the limitations of floats anyway. Having > exact fractions in seemingly arbitrary places will not result in more > accurate (or precise) results in most cases

[Python-ideas] Re: division of integers should result in fractions not floats

Rob Cliffe via Python-ideas writes: > So what's the big deal about having to write Fraction(1,2) or F(1,2) ? Writing that is never a big deal. Forgetting to write that when you need to incurs immediate loss of precision, which is a big deal in applications where it matters at all. Knuth (Semin

[Python-ideas] Re: division of integers should result in fractions not floats

Christopher Barker writes: > sure -- but the error analysis is harder for computations that use a > mixture of Fraction and float, and it's not obvious where which is > used. I don't understand what the problem is. Fractions are just a field of computer numbers where all the computations give

[Python-ideas] Re: Fractions vs. floats - let's have the cake and eat it

Martin Teichmann writes: > Also in this case my proposal would give SymPy the chance to > understand what the user actually entered, and act accordingly. But *only* in this case. It seems to me that what SymPy would really like is for arithmetic expressions in certain contexts to be returned a

[Python-ideas] Re: Fractions vs. floats - let's have the cake and eat it

Matt del Valle writes: > Fully agreed on the sentiment that we shouldn't treat compile-time > literals differently from runtime operations. But as you just pointed out, we do. Literals are evaluated at compile time, operations at runtime. "This" and f"This" generate very different code! Ther

[Python-ideas] Re: Add support for private variables, methods and functions in Python

Abdur-Rahmaan Janhangeer writes: > This whole thread reminds me of a comment of > Miguel Grinberg i remember somewhere when discussing > secrets. Some go for .env some for env variables but he suggested > focusing the attention on not letting people getting access to the > server instead of t

[Python-ideas] Re: Decorators on variables

Ricky Teachey writes: > Continuing on with Steven's counter proposal and the motivating example of > symbolic math, for multiple symbols it would be this: > > # x, y, z = symbols( 'x,y,z' ) > x, y, z = symbols(@@) > > However, even though it works for the symbols example, this meaning loo

[Python-ideas] Re: Add support for private variables, methods and functions in Python

Steven D'Aprano writes: > On Tue, May 25, 2021 at 04:24:39PM +0900, Stephen J. Turnbull wrote: > It's not really purely cooperative. API consumers always want more than > the API designers are willing or able to give. True enough as stated, but "purely coopera

[Python-ideas] Re: Introduce constants in Python (constant name binding)

Shreyan Avigyan writes: > I've already given one. Since Python is dynamically typed changing > a critical variable can cause huge instability. Want a > demonstration? Here we go, > > import sys > sys.stdout = None > > Now what? > Now how can we print anything? With print(). Even in yo

[Python-ideas] Re: Introduce constants in Python (constant name binding)

Christopher Barker writes: > i really hate lists that don't have the the list as the default reply > setting :-( This is something that lists should *not* do, because your MUA can and should do it for you (and not for me). If you want the feature, get a decent MUA (unfortunately, that probably

[Python-ideas] Re: dict.sort()?

Jonathan Fine writes: > tmp = list(sorted(d.items())) The list() call is redundant. sorted() always returns a new list. Ditto, reversed(). The method versions are in-place. Steve ___ Python-ideas mailing list -- [email protected] To unsubscrib

[Python-ideas] Re: dict.sort()?

Chris Angelico writes: > > Ditto, reversed(). The method versions are in-place. > > Not correct - reversed() is a parallel to iter() and returns a > reversed iterator. Opps, I knew that too -- once upon a time. Thanks for the correction! ___ Pyt

[Python-ideas] Re: Add "try: stmt except: stmt" syntax to Python

Shreyan Avigyan writes: > My Browser showed "No results" and a windows error sound could be > heard. I couldn't find the PEP. If I did I would have studied a > lot. I didn't have any idea this idea was proposed before and also > had a PEP (unfortunately rejected) You're very close to the lead

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

Thomas Güttler writes: > This really helps developers to avoid cross-site-scripting attacks > by enabling a secure escaping of all strings which are not > explicitly marked as safe. Frameworks can already do this by unconditionally applying a function like conditional_escape to all evaluated t

[Python-ideas] Define functions without parentheses (if no parameters given)

Boštjan Mejak writes: > *** > What if we could define functions (that don't have any parameters) like this: > > def my_function: > pass > > *** > Is that a possible scenario at this point, or even desirable? I'm sure it's possible, but the argument lists are very different in nature

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

Thomas Güttler writes: > Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer : > > Unevaluated f-strings is a nice way to think about this > > functionality. But they're not "unevaluated" in a lot of important ways. A better term might be "pre-assembled". :-) > > Another use-case that

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

Thomas Güttler writes: > I don't understand what you mean with "pragma > %conditional_escape_everything". > Could you please elaborate? "Pragma" just means it's a way to switch on conditional_escape for all template variable accesses for the rest of the file. The main point is that Django alr

[Python-ideas] Re: Introduce constant variables in Python

tabeb qena writes: > Great Idea, I have joined the mailing list to write the same idea. > > As I can't find the great difference between Final and Constant, > So, I will use the name Final. > > I suggest one the following syntax: The syntaxes proposed already are fine. The problem is mo

[Python-ideas] Re: Deprecate sum of lists

Chris Angelico writes: > Insufficiently trolly - lacks walrus operator. :) > > >>> l = [[1,2],[3,4],[5,6],[7,8],[9]] > >>> any(map((x:=[]).extend, l)) or x > [1, 2, 3, 4, 5, 6, 7, 8, 9] > > ChrisA This you? https://mobile.twitter.com/Tr0llyTr0llFace/photo :-)

[Python-ideas] Re: "except;" - semicolon after except, to get rid of indentation when doing error recovery

Chris Angelico writes: > But logically, there is a significant difference between putting code > inside the except block, and having "except X: pass" and then putting > code after. Code should be written the way it's meant to be, not the > way that happens to work. Technical point: doesn't th

[Python-ideas] Re: Deprecate sum of lists

David Mertz writes: > On Thu, Jun 17, 2021, 5:24 PM Ben Rudiak-Gould > > > Okay, slightly off-topic, but can we *please* allow > > > > [*chunk for chunk in list_of_lists] > > > > It is completely non-obvious to me what that would even MEAN. I cannot > derive anything obvious from oth

[Python-ideas] Re: Extension methods in Python

Soni L. writes: > The trick to extension methods is that they're only available when you > explicitly use them. What does "explicitly use them" mean? How does this help avoid the kinds of problems we know that monkey-patching causes? ___ Python-ideas

[Python-ideas] Re: Extension methods in Python

Chris Angelico writes: > if it's a fallback after default behaviour fails (like __getattr__) > [...] it's likely to impact performance a lot less. I guess the effect on performance is that it takes one more check to get to AttributeError? ___ Python-

[Python-ideas] Re: Extension methods in Python

David Mertz writes: > That said, one crucial difference is once an extension method is > "used" we are stuck with it for the entire module. While you get it for all objects of type(foo) in the whole module, presumably whatever syntax you used to "use" it, you can use to get rid of it, or at lea

[Python-ideas] Deprecation APIs and language tooling

Sergei Lebedev writes: > The proliferation of deprecation APIs itself is not a problem, but it does > make it difficult (if not impossible) for language tooling to consume that > deprecation information and help users of these libraries write better > code. We don't know that it's not a probl

[Python-ideas] Re: builtins for running context managers

Ethan Furman writes: > Isn't that javascript? Javascript idioms are not (necessarily) > Python idioms. True, but unless there is (preferably) a Python idiom or one from another language we borrow from at least somewhat frequently, why not adopt the Javascript idiom? Note: I don't think you we

[Python-ideas] Re: builtins for running context managers

Thomas Grainger writes: > Another example, is a cash point (ATM) won't give you your money > until you take your card That ATM is effective in enforcing the desired behavior. In Python you would usually use an exception to force handling. Returning status codes, or couples of status codes and

[Python-ideas] Re: builtins for running context managers

Thomas Grainger writes: > Right but it's not a status code - it's a callback that you *must* > call OK. Thing is, Serhiy was just saying "hey I did almost exactly that (but minor technical detail)". In your idiomatic usage, 'exit' is almost invisible outside of the wrapped context manager. I

[Python-ideas] Possibility to specify port in __init__ of ftplib.FTP

Marty writes: > If there is possible to connect and login to ftp server within > __init__, I think it would make sense to add parameter **port** in > ftplib.FTP. It could look like this: > ``` > def __init__(self, host='', port=0, user='', passwd='', acct='', > timeout=

[Python-ideas] Re: Proposal: Python Native bindings for OpenAPI

Vaideeswaran Ganesan writes: > I actually want to avoid get, post, put, 2xx, 4xx codes in the > client portions of the code. I think this goal is too high-level for the standard library. I don't know what you expect on the other side, but in an application I work on it matters whether you're u

[Python-ideas] Re: Proposal: Python Native bindings for OpenAPI

Vaideeswaran Ganesan writes: > Intent is to make a web interaction as if you're working with local > function. This is very well known design pattern called Proxy. Sure, but the stdlib is fairly low-level. The question is not whether this module is useful. I'm sure for some purposes it is ver

[Python-ideas] C API for converting Python integers to/from bytes sequences

Serhiy Storchaka writes: > Python integers have arbitrary precision. For serialization and > interpolation with other programs and libraries we need to > represent them [...]. [In the case of non-standard precisions,] > [t]here are private C API functions _PyLong_AsByteArray and > _PyLong_Fr

[Python-ideas] Re: Pattern matching in python function headers

Abdulla Al Kathiri writes: > case def fib(0): > return 0 This syntax (1) is a new, slightly shorter version of something we can already do as you point out yourself, and (2) plausibly is something of a bug magnet if someone does case def fib(1): case def fib(2): def fib(n): Plausible !=

[Python-ideas] Re: Notation for subscripts.

Matsuoka Takuo writes: > Let me clarify the issue. An optional starred expression (denoted > "[starred_expression]" in the specification of the syntax) is a > natural generalization of an expression list (which is not necessarily > an expression in the Python sense) in the sense that use of th

[Python-ideas] Re: Pattern matching in python function headers

Abdulla Al Kathiri writes: > You have a point, but the mathematical approach of Haskell of > different function cases is quite readable and straight forward. You seem to have quite missed that point, though. The point is that although borrowing tech from Haskell for Python is a *great* idea (a

[Python-ideas] Re: Notation for subscripts.

Matsuoka Takuo writes: > I don't see any parenthesis nor bracket around "1,2,". Parentheses are not part of tuple display syntax, with the exception of "()", the empty tuple. Parenthesis are needed for tuple displays only to group the display in the context of a larger expression. This is my

[Python-ideas] Re: multiprocessing: hybrid CPUs

Christopher Barker writes: > The worker pool approach is probably the way to go, but there is a fair bit > of overhead to creating a multiprocessing job. So fewer, larger jobs are > faster than many small jobs. True, but processing those rows would have to be awfully fast for the increase in o

[Python-ideas] Re: multiprocessing: hybrid CPUs

Thomas Grainger writes: > Would a work stealing approach work better for you here? Then the only > signalling overhead would be when a core runs out of work Not sure what you're talking about with "work stealing". It sounds conceptually more complex than the queue + worker pool approach, which

[Python-ideas] Re: Notation for subscripts.

Matsuoka Takuo writes: > >>> *(1,2), > (1, 2) Yes, this works, and now that I see you just want that to work in "a[*(1,2),]", I agree, I don't know why that is a syntax error. This works, of course: t = *(1,2), a[t] (in the sense that if a is a sequence you get a TypeError because th

[Python-ideas] Add .cache and compile_commands.json to .gitignote

Jack DeVries writes: > What does everyone think? Can we add these two items to the .gitignore: > > - `.cache` > - `compile_commands.json` I don't see any cost to this -- .cache is uncomfortably generic, but given the semantics of "cache" gitignoring it seems a good idea. ISTM rather than ha

[Python-ideas] Re: PEP8 mandatory-is rule

Michael Lee writes: > None is primarily useful for representing the absence of some > value, and I'm not sure if that's something beginners actually need > to write interesting and useful code. In Python, we generally think of writing code as a subordinate skill. :-) In reading code, beginner

[Python-ideas] Re: PEP8 mandatory-is rule

Steven D'Aprano writes: > On Thu, Sep 02, 2021 at 04:04:40PM +0900, Stephen J. Turnbull wrote: > > > You may not need to teach them about singletons, though. > > It's hard to teach why `is` works with None, For definitions of "works" that comes down to

[Python-ideas] Re: PEP8 mandatory-is rule

Steven D'Aprano writes: > Ah, but that's because you're a Python programmer who has been seeped in > the language for many, many years :-) No, it's because I'm a Lisp programmer for twice as long, and know the differences among #'=, #'string=, #'equal, #'eql, and #'eq (the last is `is'`. > T

[Python-ideas] Re: PEP8 mandatory-is rule

Andr$(D+1(B Roberge writes: > > In theory, there is edu-sig ( > https://www.python.org/community/sigs/current/edu-sig/) but it is > essentially dead. Don't they still have a summit at PyCon every year? Surely they're discussing somewhere! Steve _

[Python-ideas] Re: Different exceptions for assert

Juancarlo A$(D+P(Bez writes: > assert cond: > # Write some debugging info to a log. > ... > raise ExtType(args) > > I like the idea of preparing the arguments for the assertion message in a > context that gets executed only when the assertion fails. The mor

[Python-ideas] Re: A better math.factorial

Steven D'Aprano writes: > But I don't think it would be a big problem unless the caller was mixing > calls to gamma with int and float arguments. You mean `factorial` here, right? `gamma` coerces int to float before evaluating, doesn't it? > If you stick to one or the other, it wouldn't mat

  1   2   3   4   5   6   7   8   9   >