Re: [Python-ideas] Fix default encodings on Windows

On 11 August 2016 at 01:41, Chris Angelico wrote: > I've almost never seen files stored in UTF-32 (even UTF-16 isn't all > that common compared to UTF-8), so I wouldn't stress too much about > that. Recognizing FE FF or FF FE and decoding as UTF-16 might be worth > doing, but it

Re: [Python-ideas] Fix default encodings on Windows

On 11 August 2016 at 00:30, Random832 wrote: >> Python could copy how >> configure_text_mode() handles the BOM, except it shouldn't write a BOM >> for new UTF-8 files. > > I disagree. I think that *on windows* it should, just like *on windows* > it should write CR-LF for

Re: [Python-ideas] New function to add into the "random" module

On 2 February 2017 at 12:01, wrote: > P.P.S.: The function is tested, it’s working  > First of all, thanks for your suggestion, and for taking the time to help improve Python. As noted, random.uniform probably does what you want, so we don't really need this function.

Re: [Python-ideas] Using Python for end user applications

On 8 February 2017 at 00:49, eryk sun wrote: >> LoadLibrary might work (I'm only calling Py_Main). I seem to recall >> trying this before and having issues but that might have been an >> earlier iteration which made more complex use of the C API. Also, I >> want to load

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 22 January 2017 at 22:45, Soni L. wrote: > I've been thinking of an Immutable Builder pattern and an operator to go > with it. Since the builder would be immutable, this wouldn't work: > > long_name = mkbuilder() > long_name.seta(a) > long_name.setb(b) > y =

Re: [Python-ideas] Immutable Builder" Pattern and Operator

On 23 January 2017 at 13:47, Hervé "Kyle" MUTOMBO <hervinhiosl...@gmail.com> wrote: > Paul Moore is clearly right when He says that this "a .= 1+1" doesn't make > sense. It means nothing understandable although in "a .= s(e)" can mean > someth

[Python-ideas] Using Python for end user applications

On 28 January 2017 at 02:11, C Anthony Risinger wrote: > I can't articulate it we'll, or even fully isolate the reasons for it. All I > really know is how I feel when peers ask me about Python or the reading I > get when others speak about their experience using it. Python is

Re: [Python-ideas] pathlib suggestions

On 25 January 2017 at 16:04, Thomas Kluyver wrote: > On Wed, Jan 25, 2017, at 03:54 PM, Todd wrote: > > Those [.tar.foo] are just examples that I encounter a lot, there can be > other cases where multiple extensions are used. > > > The real issue is that there's no

Re: [Python-ideas] Ideas for improving the struct module

On 20 January 2017 at 18:18, Guido van Rossum wrote: > I'd be wary of making a grab-bag of small improvements, it encourages > bikeshedding. Agreed. Plus the bikeshedding and debating risks draining Elizabeth's motivation. Paul

Re: [Python-ideas] Ideas for improving the struct module

On 20 January 2017 at 20:47, Elizabeth Myers wrote: > Two things: > > 1) struct.unpack and struct.unpack_from should remain > backwards-compatible. I don't want to return extra values from it like > (length unpacked, (data...)) for that reason. If the calcsize solution >

Re: [Python-ideas] Is it Python 3 yet?

Resending because Google Groups handling of mailing lists is broken :-( Sorry to anyone who gets double posts. On 27 January 2017 at 08:39, Paul Moore <p.f.mo...@gmail.com> wrote: > On 27 January 2017 at 06:22, Denis Akhiyarov <denis.akhiya...@gmail.com> > wrote: >> The

Re: [Python-ideas] List indexing multiple elements

On 20 February 2017 at 20:54, Ryan Gonzalez wrote: > Apologies if this has already been covered! > > Right now, if you want to get multiple elements in a list, you have to do: > > elements = [mylist[a], mylist[b]] > > My proposal is two-folded: > > - Right now, a[b,c] is already

Re: [Python-ideas] if in for-loop statement

On 23 February 2017 at 13:37, Henk-Jaap Wagenaar wrote: > Note that this has been suggested before at least once > (https://mail.python.org/pipermail/python-dev/2007-November/075257.html), > and that thread itself suggests it has been suggested before and shutdown by >

Re: [Python-ideas] if in for-loop statement

On 23 February 2017 at 14:20, Henk-Jaap Wagenaar wrote: > > In a straw poll at the company I work at everyone was in favour, though they > obviously are not in charge of implementing or changing documentation so > that is easy for them to say, they've got no skin in

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

On 12 February 2017 at 04:37, Steven D'Aprano wrote: >> Making a dedicated syntax or decorator for patching is saying that we >> (the language) think you should do it. > > We already have that syntax: > > anything.name = thing And the point here is that we don't need to

Re: [Python-ideas] Fwd: Define a method or function attributeoutside of a class with the dot operator

On 10 February 2017 at 16:09, Markus Meskanen wrote: > But if people are gonna do it anyways with the tools provided (monkey > patching), why not provide them with better tools? Because encouraging and making it easier for people to make mistakes is the wrong thing to

Re: [Python-ideas] Python package index: query and rating

On 15 February 2017 at 11:07, Steven D'Aprano wrote: >> I have two ides to improve the package index: > > Thank you for your ideas, but I don't think this is the right place for > suggesting improvements to PyPI. You could try looking through the list > of other Python

Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

On 10 February 2017 at 11:16, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Feb 10, 2017 at 10:13 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> Furthermore, once we open up this possibility, I would expect requests >> for things like >> >>

Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

On 10 February 2017 at 10:45, Markus Meskanen wrote: > Keep in mind that the extra syntax is *very* minor, and goes hand-to-hand > with the existing attribute access syntax. Basically it's taking the > existing syntax to one more place, where it in my opinion should have

Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

On 10 February 2017 at 13:55, Stephan Houben wrote: > My point would be that the new syntax *also* requires one to figure out what > the new syntax does. This is an extremely good point. It is mentioned when new syntax is proposed (the term often used is "discoverability")

Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

On 10 February 2017 at 14:00, Markus Meskanen wrote: >> > I've started working on a PEP for this since most people seem to be for >> > it. >> >> I don't know how you get "most people" -- there's only been a handful of >> responses in the few hours since the original

Re: [Python-ideas] Let’s make escaping in f-literals impossible

On 19 August 2016 at 21:50, C Anthony Risinger wrote: > The only real point I'm trying to make is that expressions within an > f-string are an *escape*. They escape the normal semantics of a string > literal and instead do something else for a while. Therefore, the escaped >

Re: [Python-ideas] Let’s make escaping in f-literals impossible

On 20 August 2016 at 04:57, C Anthony Risinger wrote: > The two string parts are string-colored and the x.partition bits would look > like > any other code in the file. It won't look like concatenation at that point. That's entirely subjective and theoretical (unless you've

Re: [Python-ideas] suggestion about the sort() function of the list instance

On 1 March 2017 at 01:31, qhlonline wrote: > My code example is not proper, Yes, may be this is better: > list.sort().revers( We can already do this - reversed(sorted(lst)) This is a long-established design decision in Python. It would need a *very* compelling use case to

Re: [Python-ideas] __repr__: to support pprint

On 1 March 2017 at 13:50, Steven D'Aprano wrote: > It is possible that we could come up with a pretty-printing protocol, > but that wouldn't be a trivial job. I'd be inclined to do this via simplegeneric. Let pprint do what it currently does, but allow users to register

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 13:11, Serhiy Storchaka <storch...@gmail.com> wrote: > On 02.03.17 14:20, Paul Moore wrote: >> >> So I guess I'm +0.5 on the proposed "positional only parameters" >> syntax, and -1 on any form of new language-defined sentinel value. > >

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 14:24, Steven D'Aprano wrote: > I like this! If the caller doesn't provide a value, the parameter > remains unbound and any attempt to look it up will give a NameError or > UnboundLocalError. Hmm. But those exceptions currently indicate with almost 100%

Re: [Python-ideas] SI scale factors in Python

On 25 August 2016 at 09:54, Ken Kundert wrote: > 1G -> 1e+09 > 1M -> 1e+06 > 1k -> 1e+03 While these suffixes are suitable for a scientific context, in a computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make just as much, if not more, sense

Re: [Python-ideas] Shuffled

On 8 September 2016 at 10:34, Arek Bulski wrote: > That wont work because I would have to type the expression that is used as > argument twice in a test. I need shuffled. Enough said. You've probably spent way more time debating shuffled here than you would have needed to

Re: [Python-ideas] Typecheckers: there can be only one

On 7 September 2016 at 22:31, Hugh Fisher wrote: > The average programmer such as myself will expect that if I write code > specifying the type of a variable or whatever it should *do > something*. It's code, I wrote it, it should be interpreted. Reading the documentation

Re: [Python-ideas] Naming convention for Enums

On 14 September 2016 at 12:51, Chris Angelico wrote: > Perhaps the advice needs to be along the lines of: Decide what the > purpose of the enum is, and follow a naming convention accordingly. > Uppercase if you're basically making constants; lowercase if you're > not; etcetera.

Re: [Python-ideas] Null coalescing operator

On 10 September 2016 at 18:26, Guido van Rossum wrote: > IMO the key syntax is > simply one for accessing attributes returning None instead of raising > AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to > `foo.bar.baz if (foo is not None and foo.bar is not

Re: [Python-ideas] Fwd: Null coalescing operator

On 12 September 2016 at 21:47, Eric Snow wrote: > Note that there's a subtle difference here when multiple lookups are > involved. Given: > > def f(spam): > return spam().eggs().ham > > With null-coalescing: > > def f(spam): > return

Re: [Python-ideas] if-statement in for-loop

On 11 September 2016 at 10:36, Dominik Gresch wrote: > I've recently found myself writing code similar to this: > > for i in range(10): > if i == 5: > continue > "body" > > which I find a bit ugly. I write code like this quite frequently. However, unlike you I

Re: [Python-ideas] if-statement in for-loop

On 5 October 2016 at 05:09, Ken Kundert wrote: > On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote: >> >> Extra newlines are cheap. Writing >> > > The cost is paid in newlines *and* extra levels of indentation. No extra indentation if you ise "if not

Re: [Python-ideas] Add "equal" builtin function

On 6 October 2016 at 14:45, Filipp Bakanov wrote: > For now there are many usefull builtin functions like "any", "all", etc. I'd > like to propose a new builtin function "equal". It should accept iterable, > and return True if all items in iterable are the same or iterable is

Re: [Python-ideas] if-statement in for-loop

On 4 October 2016 at 08:56, Stephen J. Turnbull wrote: > These are my opinions; I don't claim any authority for them. I just > don't find the proposed syntax as obvious and unambiguous as you do, > and would like to explain why that is so. > > Ken Kundert

Re: [Python-ideas] if-statement in for-loop

On 5 October 2016 at 17:26, Nick Coghlan wrote: > Compared to those, locally modifying the token stream to inject ": > INDENT" pairs when the if and for keywords are encountered between an > opening "for" keyword and a closing ":" keyword would be a relatively >

Re: [Python-ideas] Improve error message when missing 'self' in method definition

On 5 October 2016 at 18:17, Lisa Roach wrote: > +1 > > I've definitely seen a lot of new users make this error, an improved message > could go a long way. I'm not a new user by any means, and I still regularly make this mistake. Because I've got the experience, I recognise

Re: [Python-ideas] async objects

On 5 October 2016 at 21:28, Rene Nejsum wrote: > But, are the runtimes for Python and Erlang that fundamentally different? Is > it Python’s tight integration with C that is the big difference? I don't know *that* much about Erlang, but Python's model is that of a single

Re: [Python-ideas] PEP8 dictionary indenting addition

On 9 October 2016 at 01:25, Steven D'Aprano wrote: > On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote: >> I have an idea to improve indenting guidelines for dictionaries for better >> readability: If a value in a dictionary literal is placed on a new line, it >>

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 13:10, Paul Moore <p.f.mo...@gmail.com> wrote: > > For this particular suggestion, though, I don't think that's the case. > I think it's going to either be something that's accepted into the > stdlib, or something that's rejected as too platform

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 12:56, Steven D'Aprano wrote: > > For relatively small pieces of functionality, if it is useful enough, we > should just add it to the std lib, and if it isn't, we should just say > it isn't useful enough. We shouldn't condemn supporters of the idea to

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 18:20, אלעזר wrote: > Obviously > > from __pip__ import "run-lambda>=0.1.0" If we were going to go down this route (which I'm not at all convinced we should) it should be "from __pypi__ import" not "from __pip__ import" (as PyPI is where the code is

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 17:59, Joonas Liik wrote: > using pip from within python is not that difficult already. > as can be seen with a glance to: > http://stackoverflow.com/questions/12332975/installing-python-module-within-code Note that pip does not officially support

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 11:46, אלעזר wrote: > So it should be something like > > from unsafe.__pip__ import benchmark > > Where unsafe is the hypothetical namespace in which exec(), eval() and > subprocess.run() would have reside given your concerns. In my opinion, it should

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 23:46, אלעזר wrote: >> import pip >> pip.install('attrs') >> import attr > > Please forgive me for my ignorance, but it doesn't work as written - what's > the actual method? As David Mertz said, pip.main(['install', 'attrs']) works right now, but it is

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 00:28, אלעזר wrote: > On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull > wrote: >> >> אלעזר writes: >> >> > Another use case, though I admit not the top priority of anyone here, >> is >> > that of assignment

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 12:12, אלעזר wrote: > Moreover, being able to do it programmatically is a security risk, since it > requires elevated privileges that I don't know how to drop, and most people > will not think about doing, but a library implementation will. > > So if

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 19:52, אלעזר wrote: > Of course it doesn't address the issues - for example, running a python > script from the file manager will result in a failed execution, unexplained. What you're talking about here is deployment of Python "applications" (where in

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 21:34, אלעזר wrote: > Paul, I understand what you say, except the part of compatibility with > Python3.5. Of course such a change is targeting future version more than the > current and previous versions. If we have this syntax for Python3.6, users > of

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 03:40, Chris Angelico wrote: > On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano wrote: >> (The fallback if all else fails is easy: get the height of the terminal, >> in lines, and print that many blank lines.) > > Assuming you can

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 13:58, Random832 wrote: > On Tue, Sep 20, 2016, at 07:12, אלעזר wrote: >> Moreover, being able to do it programmatically is a security risk, >> since it requires elevated privileges that I don't know how to drop, >> and most people will not think

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 21:35, João Matos wrote: > Hello, > > I don't see why creating a clear command would interfere with dict.clear() > which is a function/method. > > Although my first idea was a clear command, I have no problem if it is a > clear() function from site.py.

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

On 27 August 2016 at 23:39, Arek Bulski wrote: > They can be used simply out of convenience, like 4K is a shorthand for 4000. > And 9G is definitely easier to write and *therefore less prone to error* > than a full literal. I dispute "less prone to error". Like it or not,

Re: [Python-ideas] SI scale factors in Python

On 25 August 2016 at 19:02, Ken Kundert wrote: > This proposal basically has two parts. One part is that Python should > naturally support printing real numbers with SI scale factors. Currently > there > are three formats for printing real number: %f, %d, %g.

Re: [Python-ideas] Delay evaluation of annotations

On 27 September 2016 at 13:46, Neil Girdhar wrote: > Yes, I understand that, but I don't see how that would help at all with > annotations. Aren't annotations also evaluated at "compile time"? Yes, but a string whose value is a class name is treated as being the same

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 29 September 2016 at 08:08, Stephan Houben wrote: > I just tried with this official Python binary: > Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit > (Intel)] on win32 > > and CTRL-L for sure does clear the window. It just doesn't then move

Re: [Python-ideas] if-statement in for-loop

On 27 September 2016 at 16:54, Erik Bray wrote: > Then following my own logic it > would be desirable to also allow the nested for loop syntax of list > comprehensions outside them as well. I'd say that it's a case where we should either allow arbitrary concatenation

Re: [Python-ideas] async objects

On 3 October 2016 at 15:52, Giampaolo Rodola' wrote: > Independently from what the proposed solution is, I think you raised a very > valid concern: the DRY principle. > Right now the stdlib has tons of client network libraries which do not > support the new async model. > As

Re: [Python-ideas] Conditional context manager

Resending, because Google Groups messes up replying to the list :-( On 1 October 2016 at 21:09, Paul Moore <p.f.mo...@gmail.com> wrote: > On 1 October 2016 at 19:07, Neil Girdhar <mistersh...@gmail.com> wrote: >> Sometimes, I want to conditionally enter a context manager. Th

Re: [Python-ideas] f-string, for dictionaries

On 25 October 2016 at 20:11, Michel Desmoulin wrote: > Similarly, I'd like to suggest a similar feature for building dictionaries: > foo = 1 bar = 2 {:bar, :foo} > {'bar': 1, 'foo', 2} I don't see a huge advantage over >>> dict(foo=foo, bar=bar)

[Python-ideas] A better interactive prompt

I've seen a lot of syntax proposals recently that are based around providing better ways of writing "one liner" styles of code. Typically, the proposals seem to get into trouble because: 1. They duplicate things that can already be done, just not in a single expression/statement. 2. They are seen

Re: [Python-ideas] Showing qualified names when a function call fails

On 25 October 2016 at 20:17, Nathaniel Smith wrote: > I get that this list's default is to push > back on proposed changes, and it's a good principle in general, but > "improved error messages" are *really* cheap. The bar should be pretty > low, IMO. If someone's willing to do the

Re: [Python-ideas] A better interactive prompt

On 27 October 2016 at 01:49, Steven D'Aprano wrote: >> (a bit like readline, >> but I dislike the way you can't switch off readline integration if >> it's installed)? > > This comment surprises me. To me, that's like saying "I dislike the way > you can't switch off breathing"

Re: [Python-ideas] A better interactive prompt

On 26 October 2016 at 18:25, Nick Coghlan wrote: > The built-in REPL serves two quite divergent use cases, and I think > we're well past the point where we can't readily support both use > cases with a single implementation: > > - a minimalist interactive environment, that is

Re: [Python-ideas] Null coalescing operator

On 29 October 2016 at 18:19, Stephen J. Turnbull wrote: >> For better or worse, it may be emoji that drive that change ;-) > > I suspect that the 100 million or so Chinese, Japanese, Korean, and > Indian programmers who have had systems that have no trouble >

Re: [Python-ideas] Non-ASCII in Python syntax? [was: Null coalescing operator]

On 30 October 2016 at 07:00, Stephen J. Turnbull wrote: >> as I imagine Unicode characters would be for me. I really hope it > > isn't... > > I think your imagination is running away with you. While I understand > how costly it is for those over the age of

Re: [Python-ideas] "Proposing a change" document? (was: Civility on this mailing list)

On 10 November 2016 at 21:18, Ethan Furman <et...@stoneleaf.us> wrote: > On 11/10/2016 01:07 PM, Franklin? Lee wrote: >> >> On Fri, Oct 21, 2016 at 11:07 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >>> >>> >>> I wonder. Would there be valu

Re: [Python-ideas] Deterministic iterator cleanup

On 19 October 2016 at 20:21, Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 19 October 2016 at 19:13, Chris Angelico <ros...@gmail.com> wrote: >>> Now it *won't* correctly call th

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18 October 2016 at 07:31, Nick Coghlan wrote: > > Forcing ourselves to come up with a name for the series of values > produced by the outer iteration then makes that name available as > documentation of our intent for future readers of the code. This is a key point, that

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

On 12 October 2016 at 20:22, David Mertz wrote: > I've followed this discussion some, and every example given so far > completely mystifies me and I have no intuition about what they should mean. Same here. On 12 October 2016 at 20:38, אלעזר wrote: > What is

Re: [Python-ideas] Fwd: Fwd: unpacking generalisations for list comprehension

On 14 October 2016 at 07:54, Greg Ewing wrote: >> I think it's probably time for someone to >> describe the precise syntax (as BNF, like the syntax in the Python >> docs at >>

Re: [Python-ideas] Fwd: Fwd: unpacking generalisations for list comprehension

On 14 October 2016 at 10:48, Paul Moore <p.f.mo...@gmail.com> wrote: > On 14 October 2016 at 07:54, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: >>> I think it's probably time for someone to >>> describe the precise syntax (as BNF, like the syntax in

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

On 22 October 2016 at 08:17, Chris Angelico wrote: > On Sat, Oct 22, 2016 at 5:49 PM, Ryan Birmingham > wrote: >> this proposed change aims to solve the problem caused when editors, mail >> clients, web browsers, and operating systems over-zealously

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

On 23 October 2016 at 17:10, Danilo J. S. Bellini wrote: >> Ah, that makes SIX existing solutions. Do we need a seventh? > > It might have dozens of solutions, perhaps an infinity of solutions. > Brainfuck and assembly can be used, or even turing machine instructions...

Re: [Python-ideas] Civility on this mailing list

On 21 October 2016 at 15:26, Nick Coghlan wrote: > - Remember that even if something we vehemently consider "wrong" makes > it into the reference implementation, the language does have a design > policy that allows us to correct design mistakes after a suitable > deprecation

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 21:59, Chris Barker wrote: >> So (it seems to >> me) that you're talking about changing the behaviour of for-loops to >> suit only a small proportion of cases: maybe 10% of 10%. > > > I don't see what the big overhead is here. for loops would get a new

Re: [Python-ideas] More user-friendly version for string.translate()

On 24 October 2016 at 18:39, Mikhail V wrote: > I would be happy to see a somewhat more general and user friendly > version of string.translate function. > It could work this way: > string.newtranslate(file_with_table, Drop=True, Dec=True) Using a text file seems very odd.

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 10:53, Steven D'Aprano wrote: > On Wed, Oct 19, 2016 at 12:33:57PM -0700, Nathaniel Smith wrote: > >> I should also say, regarding your specific example, I guess it's an >> open question whether we would want list_iterator.__iterclose__ to >> actually do

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 12:23, Steven D'Aprano <st...@pearwood.info> wrote: > On Fri, Oct 21, 2016 at 11:03:51AM +0100, Paul Moore wrote: > >> At the moment, the take home message for such users feels like it's >> "you might need to scatter preserve() around your co

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17 October 2016 at 22:28, Mark Lawrence via Python-ideas wrote: > How about changing https://wiki.python.org/moin/HowTo/Sorting ? Good point. Better still, https://docs.python.org/3.6/howto/sorting.html Paul ___

Re: [Python-ideas] Deterministic iterator cleanup

On 19 October 2016 at 19:13, Chris Angelico wrote: > Now it *won't* correctly call the end-of-iteration function, because > there's no 'for' loop. This is going to either (a) require that EVERY > consumer of an iterator follow this new protocol, or (b) introduce a > ton of edge

Re: [Python-ideas] Civility on this mailing list

On 19 October 2016 at 12:29, Michel Desmoulin wrote: > I feel like people are really getting hyper sensitive about communications. > While I do prefer talking to calm rational people with a friendly tone, I > acknowledge this is not always the case and it's ok if

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 15 November 2016 at 02:59, Matthias welp wrote: > Mikhail, what Paul probably means here is that python 'operators' are actually > 'syntactic sugar' for functions (it is not recommended to call > these functions directly, but it is possible): More specifically, the

Re: [Python-ideas] Decorator to avoid a mistake

On 26 November 2016 at 07:16, Nick Coghlan wrote: > On 26 November 2016 at 13:26, Guido van Rossum wrote: >> I think one reason why such proposals are unwelcome to experienced users may >> be that when done right this is totally legitimate, and the

Re: [Python-ideas] Decorator to avoid a mistake

On 23 November 2016 at 08:08, François Leblanc wrote: > It's why I'd prefer this integrate in language, but if there no way to get > it without performance cost > I will have a look to a pylint solution... The point here is that if there is a way to get it without a

Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

On 28 November 2016 at 13:28, Tomas Orsava wrote: > The ``.missing.py`` extension will be added to the end of the list, and > configured to be handled by ``SourceFileLoader``. Thus, if a module is not > found in its proper location, the ``XYZ.missing.py`` file is found and >

Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

On 28 November 2016 at 15:51, Tomas Orsava wrote: > I believe I may have found the Windows curses implementation, it's called > PDCurses [0], and this website [1] appears to be distributing it under the > name `curses`. My apologies, I should have included a pointer. That is

Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

On 28 November 2016 at 21:11, Ethan Furman wrote: > One "successful" use-case that would be impacted is the fallback import > idiom: > > try: > # this would do two full searches before getting the error > import BlahBlah > except ImportError: > import blahblah

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 02:42, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > But I am not a draconian security policy QA/security reviewer. I'd > take anything Paul Moore says pretty seriously, as he operates in such > an environment. For context, my env

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

On 17 November 2016 at 03:07, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Paul Moore writes: > > > PS Note for anyone who wants to take this off on a wild tangent - my > > above comment is *in the context of Python as it has been defined for >

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 10:58, Cory Benfield wrote: > Paul, you mentioned that discovery on PyPI is a problem: I don’t contest that > at all. But I don’t think the solution to that problem is to jam modules into > the standard library, and I think even less of that idea when

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 11:12, Stephen J. Turnbull wrote: > > However, when it comes to draconian security policies, *transitive > > recommendations have power*: if CPython is approved, and python-dev > > collectively says "we recommend pip, virtualenv, and

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 12:27, Cory Benfield wrote: > This isn’t me disagreeing with you, just me pointing out that the fuzziness > around this makes me nervous. It has been my experience that a large number > of protocol implementations in the standard library are already

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 14:45, Chris Angelico wrote: > Personally, when I hit step 6, I search the web. PyPI search is > exhaustive but not very usefully ranked (for this purpose). Searching > for a keyword or protocol will give undue weight to a module whose > name is simply

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

On 16 November 2016 at 08:51, Mikhail V wrote: > What semantics it will fundamentally break or so hard to implement? I'm afraid I don't have time at the moment to fully review your email, but my first impression is that you are proposing that the name "self" be treated

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 16 November 2016 at 13:55, Cory Benfield wrote: >> If you have any idea about how we could reach more coders I’m all ears. > > Coders who need OIDC will go looking for it and will find their options. > Ultimately, a huge number of projects haven’t suffered from being

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 14 November 2016 at 22:13, Mikhail V wrote: >> we don't want A = A + 1 to be the same as A += 1 " > > This sounds quite frustrating for me, what else could this be but A += 1? > Would I want a copy with same name? How that will make sense? >>> A = [1,2,3] >>> B = A >>> A

Re: [Python-ideas] Query Language extension to Python

On 1 November 2016 at 08:33, Pavel Velikhov wrote: > We have released PythonQL, a query language extension to Python (we have > extended Python’s comprehensions with a full-fledged query language, > drawing from the useful features of SQL, XQuery and JSONiq). Take a

  1   2   3   4   5   6   7   8   >