Re: [Python-ideas] Null coalescing operator

On 1 November 2016 at 10:11, Nick Coghlan wrote: > > I do think it would be worth covering the symbol+keyword option > discussed in PEP 531 (i.e. "?else" instead of "??", but keeping "?.", > and "?[") FWIW, I'm not keen on it. As a technical question, would it be treated in

Re: [Python-ideas] PEP 531: Existence checking operators

On 28 October 2016 at 15:40, Nick Coghlan wrote: > I also don't think the idea is sufficiently general to be worthy of > dedicated syntax if it's limited specifically to "is not None" checks > - None's definitely special, but it's not *that* special. Unifying > None, NaN,

Re: [Python-ideas] Null coalescing operator

On 31 October 2016 at 17:16, Guido van Rossum wrote: > I think we should try to improve our intutition about these operators. Many > things that are intuitively clear still require long turgid paragraphs in > reference documentation to state the behavior unambiguously -- but

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

On 30 October 2016 at 12:31, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Oct 30, 2016 at 11:22 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> In mentioning emoji, my main point was that "average computer users" >> are more and more likely to want

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

On 30 October 2016 at 14:43, wrote: > Just picking a nit, here, windows will happily let you do silly things like > hook 14 keyboards up and let you map all of emoji to them. Sadly, this > requires lua. Off topic, I know, but how? I have a laptop with an external and

Re: [Python-ideas] A better interactive prompt

On 26 October 2016 at 22:40, Nikolaus Rath wrote: > It also imposes a significant burden on scripting. I often have elements > like this in shell scripts: > > output=$(python < import h5py > with h5py.File('foo', 'r') as fh: > print((fh['bla'] * fh['com']).sum()) > EOF > )

Re: [Python-ideas] A better interactive prompt

On 26 October 2016 at 22:11, Todd wrote: > Isn't this what aliases are for? Just set "python" to be an alias for > "ipython" for your interactive shell. I hadn't thought of that option. I might give it a try. Although I'm not sure how I'd set up a Powershell function (I'm on

Re: [Python-ideas] PEP 531: Existence checking operators

On 29 October 2016 at 07:21, Nick Coghlan wrote: > A short-circuiting if-else protocol for arbitrary "THEN if COND else > ELSE" expressions could then look like this: > > _condition = COND > if _condition: > _then = THEN > if hasattr(_condition,

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

On 11 October 2016 at 17:49, Nick Coghlan wrote: > On 12 October 2016 at 02:16, Elliot Gorokhovsky > wrote: >> So I thought, wow, this will give some nice numbers! But I underestimated >> the power of this optimization. You have no idea. It's

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

On 13 October 2016 at 15:32, Sven R. Kunze wrote: > Steven, please. You seemed to struggle to understand the notion of the > [*] construct and many people (not just me) here tried their best to > explain their intuition to you. And yet, the fact that it's hard to explain

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

On 12 October 2016 at 11:16, Steven D'Aprano wrote: > On Wed, Oct 12, 2016 at 12:25:16AM +, Elliot Gorokhovsky wrote: > >> Regarding generalization: the general technique for special-casing is you >> just substitute all type checks with 1 or 0 by applying the type

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

On 13 October 2016 at 20:51, Random832 wrote: > On Thu, Oct 13, 2016, at 15:46, Random832 wrote: >> so, under a similar 'transformation', "*foo for foo in bar" likewise >> becomes "def f(): for foo in bar: yield from foo" >> >> bar = [(1, 2), (3, 4)] >> (*(1, 2), *(3, 4))

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

On 13 October 2016 at 21:40, Sjoerd Job Postmus wrote: > However, consider the following spelling: > > l = [from f(t) for t in iterable] > > To me, it does not seem far-fetched that this would mean: > > def gen(): > for t in iterable: > yield

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

On 17 October 2016 at 20:35, Sven R. Kunze wrote: > P.S. It's very artificial to assume user are unable to use 'from itertools > import chain' to try to make chain() seem more cumbersome than it is. > > I am sorry but it is cumbersome. Imports are a fundamental part of Python.

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

On 17 October 2016 at 21:22, Random832 wrote: > For a more concrete example: > > [*range(x) for x in range(4)] > [*(),*(0,),*(0,1),*(0,1,2)] > [0, 0, 1, 0, 1, 2] > > There is simply no way to get there by using flatten(range(4)). The only > way flatten *without* a

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

On 17 October 2016 at 21:30, Random832 <random...@fastmail.com> wrote: > On Mon, Oct 17, 2016, at 16:12, Paul Moore wrote: >> And finally, no-one has even *tried* to explain why we need a third >> way of expressing this construction. Nick made this point, and >>

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

On 17 October 2016 at 18:32, Steven D'Aprano wrote: > On Mon, Oct 17, 2016 at 12:11:46PM -0400, Random832 wrote: > >> Honestly, it goes beyond just being "wrong". The repeated refusal to >> even acknowledge any equivalence between [...x... for x in [a, b, c]] >> and [...a...,

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

On 17 October 2016 at 21:43, Sven R. Kunze wrote: > The statement about "cumbersomeness" was specific to this whole issue. Of > course, importing feature-rich pieces from the stdlib is really cool. It was > more the missed ability to do the same with list comprehensions of what

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

On 28 November 2016 at 22:33, Steve Dower wrote: > Given that, this wouldn't necessarily need to be an executable file. The > finder could locate a "foo.missing" file and raise ModuleNotFoundError with > the contents of the file as the message. No need to allow/require any

Re: [Python-ideas] Input characters in strings by decimals (Was: Proposal for default character representation)

On 7 December 2016 at 23:52, Mikhail V wrote: > Proposal: I would want to have a possibility to input it *by decimals*: > > s = "first cyrillic letters: \{1040}\{1041}\{1042}" > or: > s = "first cyrillic letters: \(1040)\(1041)\(1042)" > > = > > This is more compact

Re: [Python-ideas] Things that won't change (proposed PEP)

On 12 January 2017 at 04:39, Mikhail V wrote: > And my first though is about "will not change". Like: never ever change or > like: will not change in 10 years or 20 years. Like: "Please don't waste people's time trying to start a discussion about them". In 10 or 20 years,

Re: [Python-ideas] Settable defaulting to decimal instead of float

On 12 January 2017 at 10:28, Victor Stinner wrote: > George requested this feature on the bug tracker: > http://bugs.python.org/issue29223 > > George was asked to start a discusson on this list. I posted the > following comment before closing the issue: > > You are not

Re: [Python-ideas] Settable defaulting to decimal instead of float

On 12 January 2017 at 15:34, Victor Stinner wrote: > 2017-01-12 13:13 GMT+01:00 Stephan Houben : >> Something like: >> from __syntax__ import decimal_literal > > IMHO you can already implement that with a third party library, see for > example: >

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

On 29 November 2016 at 10:51, Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> wrote: > On 29.11.2016 10:39, Paul Moore wrote: >> >> On 28 November 2016 at 22:33, Steve Dower <steve.do...@python.org> wrote: >>> >>> Given that, this would

Re: [Python-ideas] Better error messages [was: (no subject)]

On 30 November 2016 at 02:14, Stephen J. Turnbull wrote: > How about: > > class Blog: > pass > > blog = get_blog_for_date(someday) > > logn = log(blog.size) > > NameError: Python doesn't recognize the function "log". Did you > mean

Re: [Python-ideas] incremental hashing in __hash__

On 5 January 2017 at 13:28, Neil Girdhar wrote: > The point is that the OP doesn't want to write his own hash function, but > wants Python to provide a standard way of hashing an iterable. Today, the > standard way is to convert to tuple and call hash on that. That may

Re: [Python-ideas] incremental hashing in __hash__

On 6 January 2017 at 07:26, Neil Girdhar wrote: > On Fri, Jan 6, 2017 at 2:07 AM Stephen J. Turnbull > wrote: >> >> Neil Girdhar writes: >> >> > I don't understand this? How is providing a default method in an >> > abstract base

Re: [Python-ideas] VT100 style escape codes in Windows

Would this only apply to recent versions of Windows? (IIRC, the VT100 support is Win10 only). If so, I'd be concerned about scripts that worked on *some* Windows versions but not others. And in particular, about scripts written on Unix using raw VT codes rather than using a portable solution like

Re: [Python-ideas] incremental hashing in __hash__

On 5 January 2017 at 00:31, Steven D'Aprano wrote: > This is a good point. Until now, I've been assuming that > hash.from_iterable should consider order. But frozenset shows us that > sometimes the hash should *not* consider order. > > This hints that perhaps the

Re: [Python-ideas] Adding an 'errors' argument to print

On 24 March 2017 at 16:37, Victor Stinner wrote: > *If* we change something, I would prefer to modify sys.stdout. The > following issue proposes to add > sys.stdout.set_encoding(errors='replace'): > http://bugs.python.org/issue15216 I thought I recalled seeing something

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On 28 March 2017 at 08:54, Simon D. wrote: > I believe that the u"" notation in Python 2.7 is defined by while > importing the unicode_litterals module. That's not true. The u"..." syntax is part of the language. from future import unicode_literals is something completely

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 15:40, Ram Rachum wrote: > Another idea: Maybe make json.load and json.dump support Path objects? If they currently supported filenames, I'd say that's a reasonable extension. Given that they don't, it still seems like more effort than it's worth to save a

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 15:48, Eric V. Smith wrote: > On 3/27/17 10:40 AM, Ram Rachum wrote: >> >> Another idea: Maybe make json.load and json.dump support Path objects? > > > json.dump requires open file objects, not strings or Paths representing > filenames. > > But does this

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 17:43, Bruce Leban wrote: > the ability to read one json object from the input rather than reading the > entire input Is this a well-defined idea? From a quick read of the JSON spec (which is remarkably short on details of how JSON is stored in files, etc) the

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

On 27 March 2017 at 10:54, Brice PARENT wrote: > I get it, but it's more a matter of perception. To me, the version I > described is just Python, while yours is Python + specific syntax. As this > syntax is only used in PyQL sub-language, it's not really Python any more... ...

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

On 25 March 2017 at 11:24, Pavel Velikhov wrote: > No, the current solution is temporary because we just don’t have the > manpower to > implement the full thing: a real system that will rewrite parts of PythonQL > queries and > ship them to underlying databases. We need

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 15:33, Donald Stufft wrote: > What do you think about adding methods pathlib.Path.write_json and > pathlib.Path.read_json , similar to write_text, write_bytes, read_text, > read_bytes? > > > > -1, I also think that write_* and read_* were mistakes to begin

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27 March 2017 at 13:50, Ram Rachum wrote: > This would make writing / reading JSON to a file a one liner instead of a > two-line with clause. That hardly seems like a significant benefit... Paul ___ Python-ideas mailing list

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On 31 March 2017 at 09:20, Stephan Houben wrote: > FWIW, I also strongly prefer the Verbal Expression style and consider > "normal" regular expressions to become quickly unreadable and > unmaintainable. Do you publish your code widely? What's the view of 3rd party users of

Re: [Python-ideas] Adding an 'errors' argument to print

On 24 March 2017 at 15:41, Ryan Gonzalez wrote: > Recently, I was working on a Windows GUI application that ends up running > ffmpeg, and I wanted to see the command that was being run. However, the > file name had a Unicode character in it (it's a Sawano song), and when I >

Re: [Python-ideas] "import me" to display some summary of the current python installation

On 12 April 2017 at 14:35, Kamal Mustafa wrote: > Never mind. site._script() as pointed out by Wes Turner is what I need:- > > Python 3.4.2 (default, Oct 8 2014, 10:45:20) > [GCC 4.9.1] on linux > Type "help", "copyright", "credits" or "license" for more information.

Re: [Python-ideas] Thread-safe generators

On 15 April 2017 at 10:45, Nick Coghlan wrote: > So I'd be opposed to trying to make generator objects natively thread > aware - as Stephen notes, the GIL is an implementation detail of > CPython, so it isn't OK to rely on it when defining changes to > language level semantics

Re: [Python-ideas] get() method for list and tuples

On 5 March 2017 at 19:13, Ed Kellett wrote: >> I think we're going to have to just disagree. You won't convince me >> it's worth adding list.get unless you can demonstrate some *existing* >> costs that would be removed by adding list.get, and showing that they >> are greater

Re: [Python-ideas] get() method for list and tuples

On 5 March 2017 at 13:03, Ed Kellett wrote: > > No. I'm asking: if list.get did exist, are there any cases (compatibility > with old versions aside) where list.get's semantics would be applicable, but > one of the alternatives would be the better choice? Self-evidently no. But

Re: [Python-ideas] Pseudo methods

On 4 August 2017 at 08:39, Paul Laos wrote: > Hi folks > I was thinking about how sometimes, a function sometimes acts on classes, > and behaves very much like a method. Adding new methods to classes existing > classes is currently somewhat difficult, and having pseudo

Re: [Python-ideas] Generator syntax hooks?

On 10 August 2017 at 14:42, Steven D'Aprano wrote: > I don't think it is confusing. Regardless of the implementation, the > meaning of: > > [expression for x in sequence while condition] > > should (I believe) be obvious to anyone who already groks comprehension > syntax. The

Re: [Python-ideas] Generator syntax hooks?

On 11 August 2017 at 05:49, Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, Aug 10, 2017 at 01:25:24PM -0700, Chris Barker wrote: >> On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> >> >> > Also, there's a potential issu

Re: [Python-ideas] Generator syntax hooks?

On 10 August 2017 at 21:25, Chris Barker <chris.bar...@noaa.gov> wrote: > On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > >> >> Also, there's a potential issue >> here - consider >> >> [expr for var

Re: [Python-ideas] PEP: Hide implementation details in the C API

On 11 July 2017 at 11:19, Victor Stinner wrote: > XXX should we abandon the stable ABI? Never really used by anyone. Please don't. On Windows, embedding Python is a pain because a new version of Python requires a recompile (which isn't ideal for apps that just want to

Re: [Python-ideas] Arguments to exceptions

On 6 July 2017 at 18:59, Mark E. Haase <meha...@gmail.com> wrote: > On Thu, Jul 6, 2017 at 5:58 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> >> To use the (already >> >> over-used) NameError example, Ken's proposal doesn't include any >> change to

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On 20 July 2017 at 07:58, Nathaniel Smith wrote: > From the above it sounds like this ntuple literal idea would be giving > us a third independent way to solve this niche use case (ntuple, > namedtuple, structseq). This seems like two too many? Especially given > that namedtuple

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On 20 July 2017 at 10:15, Clément Pit-Claudel <cpitclau...@gmail.com> wrote: > On 2017-07-20 11:02, Paul Moore wrote: >>> Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e., >>> why does this need to be syntax instead of a library? >> >

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On 24 July 2017 at 17:37, Michel Desmoulin wrote: > You are in the wrong thread. This thread is specifically about > namedtupels literal. In which case, did you not see Guido's post "Honestly I would like to declare the bare (x=1, y=0) proposal dead."? The namedtuple

Re: [Python-ideas] + operator on generators

On 1 July 2017 at 07:13, Steven D'Aprano wrote: > But the more I think about it the more I agree with Nick. Let's start > by moving itertools.chain into built-ins, with zip and map, and only > consider giving it an operator after we've had a few years of experience > with

Re: [Python-ideas] Arguments to exceptions

On 4 July 2017 at 06:08, Nick Coghlan <ncogh...@gmail.com> wrote: > On 4 July 2017 at 09:46, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: >> Paul Moore wrote: >>> >>> As noted, I disagree that people are not passing components because >>> str(

Re: [Python-ideas] Arguments to exceptions

On 3 July 2017 at 20:46, Jeff Walker wrote: > I think you are fixating too much on Ken's example. I think I understand > what he > is saying and I agree with him. It is a problem I struggle with routinely. It > occurs in > the following situations: Possibly. I

Re: [Python-ideas] Arguments to exceptions

On 3 July 2017 at 09:59, Ken Kundert wrote: > I think in trying to illustrate the existing behavior I made things more > confusing than they needed to be. Let me try again. > > Consider this code. > > >>> import Food > >>> try: > ... import meals >

Re: [Python-ideas] CPython should get...

On 1 July 2017 at 18:35, Nick Timkovich wrote: > Devil's advocate: why prepare a patch and submit it if it is going to be > dismissed out of hand. Trying to gauge support for the idea is a reasonable > first-step. That's perfectly OK, but it's important to phrase the

Re: [Python-ideas] Arguments to exceptions

On 6 July 2017 at 02:53, Jeff Walker wrote: > Could you please expand on these statements: > >> the idea doesn't actually solve the problem it is intended to > > Specifically Ken started by saying that it should not be necessary to parse > the > messages to get the

Re: [Python-ideas] Arguments to exceptions

On 7 July 2017 at 04:54, Jeff Walker wrote: > Here is an example: > > class NameError(BaseException): > pass > > try: > raise NameError('welker', db='users', template='{0}: unknown {db}.') > except NameError as e: > unknown_name =

Re: [Python-ideas] Augmented assignment syntax for objects.

On 25 April 2017 at 23:30, Erik wrote: > As I said above, it's not about the effort writing it out. It's about the > effort (and accuracy) of reading the code after it has been written. Well, personally I find all of the syntax proposals relatively unreadable. So that's

Re: [Python-ideas] Augmented assignment syntax for objects.

On 26 April 2017 at 16:17, Erik <pyt...@lucidity.plus.com> wrote: > On 26/04/17 08:59, Paul Moore wrote: >> >> It should be possible to modify the decorator to take a list >> of the variable names you want to assign, but I suspect you won't like >> that > >

Re: [Python-ideas] Augmented assignment syntax for objects.

On 26 April 2017 at 21:51, Erik wrote: > It doesn't make anything more efficient, however all of the suggestions of > how to do it with current syntax (mostly decorators) _do_ make things less > efficient. Is instance creation the performance bottleneck in your

Re: [Python-ideas] Augmented assignment syntax for objects.

On 26 April 2017 at 22:42, Erik wrote: > 2) The original proposal, which does belong on -ideas and has to take into > account the general case, not just my specific use-case. > > The post you are responding to is part of (2), and hence reduced performance > is a

Re: [Python-ideas] Augmented assignment syntax for objects.

On 28 April 2017 at 14:07, Nick Coghlan wrote: >> Am I missing some point? > > Yes, the point I attempted to raise earlier: at the language design > level, "How do we make __init__ methods easier to write?" is the > *wrong question* to be asking. It's treating the symptom

Re: [Python-ideas] Augmented assignment syntax for objects.

On 28 April 2017 at 23:04, Erik wrote: >> See what I mean? Things get out of hand *very* fast. > > I don't see how that's getting "out of hand". The proposal is nothing more > complicated than a slightly-different spelling of assignment. It could be > done today with a

Re: [Python-ideas] Augmented assignment syntax for objects.

On 28 April 2017 at 12:55, Tin Tvrtković wrote: > I'm putting forward three examples. These examples are based on attrs since > that's what I consider to be the best way of having declarative classes in > Python today. Your comments and examples are interesting, but don't

Re: [Python-ideas] Augmented assignment syntax for objects.

On 25 April 2017 at 03:53, Steven D'Aprano wrote: > On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote: > >> I often find myself writing __init__ methods of the form: >> >> def __init__(self, foo, bar, baz, spam, ham): >> self.foo = foo >> self.bar = bar >> self.baz =

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On 30 July 2017 at 16:24, Nick Coghlan wrote: > Rather than being about any changes on that front, these threads are > mostly about making it possible to write that first line as: > > MyNT = type(implicitly_typed_named_tuple_factory(foo=None, bar=None)) Is that really

Re: [Python-ideas] "any" and "all" support multiple arguments

On 1 August 2017 at 14:01, Louie Lu wrote: > I'm not sure if this is discuss before, but can "any" and "all" > support like min_max "arg1, arg2, *args" style? I don't see any particular reason why not, but is there a specific use case for this or is it just a matter of

Re: [Python-ideas] Pseudo methods

On 4 August 2017 at 14:20, Joao S. O. Bueno wrote: > Had not this been discussed here earlier this year? > > (And despite there being perceived dangers to readability in the long term, > was accepted?) > > Here it is on an archive: >

Re: [Python-ideas] Improving Catching Exceptions

On 23 June 2017 at 15:20, Sven R. Kunze wrote: > On 23.06.2017 03:02, Cameron Simpson wrote: > > > How about something like this? > >try: >val = bah[5] >except IndexError: ># handle your expected exception here >else: >foo(val) > > > That is

Re: [Python-ideas] ImportError raised for a circular import

On 13 June 2017 at 23:36, Chris Angelico wrote: > On Wed, Jun 14, 2017 at 8:10 AM, Mahmoud Hashemi wrote: >> I didn't interpret the initial email as wanting an error on *all* circular >> imports. Merely those which are unresolvable. I've definitely helped

Re: [Python-ideas] Decorators for running a function in a Process or Thread

On 1 May 2017 at 12:13, NoxDaFox wrote: > > I think it could be a good fit for the `concurrent.futures` module. > Decorated functions would return a `Future` object and run the logic in a > separate thread or process. > > > @concurrent.futures.thread > def function(arg,

Re: [Python-ideas] Add an option for delimiters in bytes.hex()

On 3 May 2017 at 02:48, Erik wrote: > Anyway, I know you can't stop anyone from *proposing* something like this, > but as soon as they do you may decide to quote the recipe from > "https://docs.python.org/3/library/functions.html#zip; and try to block > their

Re: [Python-ideas] Suggestion: Add shutil.get_dir_size

On 3 May 2017 at 06:43, Serhiy Storchaka wrote: > On 02.05.17 22:07, Ram Rachum wrote: >> >> I have a suggestion: Add a function shutil.get_dir_size that gets the >> size of a directory, including all the items inside it recursively. I >> currently need this functionality and

Re: [Python-ideas] + operator on generators

On 28 June 2017 at 05:30, Terry Reedy wrote: > On 6/27/2017 10:47 PM, Nick Coghlan wrote: > >> While I haven't been following this thread closely, I'd like to note >> that arguing for a "chain()" builtin has the virtue that would just be >> arguing for the promotion of the

Re: [Python-ideas] Hexadecimal floating literals

On 21 September 2017 at 02:53, Steven D'Aprano wrote: > On Thu, Sep 21, 2017 at 11:13:44AM +1000, Nick Coghlan wrote: > >> I think so, as consider this question: how do you write a script that >> accepts a user-supplied string (e.g. from a CSV file) and treats it as >> hex

Re: [Python-ideas] PEP draft: context variables

On 14 October 2017 at 17:50, Nick Coghlan <ncogh...@gmail.com> wrote: > On 14 October 2017 at 21:56, Paul Moore <p.f.mo...@gmail.com> wrote: > > TL;DR of below: PEP 550 currently gives you what you're after, so your > perspective counts as a preference for "

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 13:51, Amit Green <amit.mi...@gmail.com> wrote: > Once again, I think Paul Moore gets to the heart of the issue. > > Generators are simply confusing & async even more so. > > Per my earlier email, the fact that generators look like functions

Re: [Python-ideas] PEP draft: context variables

On 15 October 2017 at 05:39, Nick Coghlan <ncogh...@gmail.com> wrote: > On 15 October 2017 at 05:47, Paul Moore <p.f.mo...@gmail.com> wrote: >> >> On 14 October 2017 at 17:50, Nick Coghlan <ncogh...@gmail.com> wrote: >> > If you capture the context e

Re: [Python-ideas] Ternary operators in list comprehensions

>>> a = [1,2,3] >>> [x if x & 1 else 'even' for x in a] [1, 'even', 3] You're mixing the if clause of the list comprehension up with a ternary expresssion. There's no "else" in the list comprehension if clause. Paul On 5 October 2017 at 16:40, Jason H wrote: a = [1,2,3]

Re: [Python-ideas] PEP draft: context variables

On 13 October 2017 at 19:32, Yury Selivanov wrote: >>> It seems simpler to have one specially named and specially called function >>> be special, rather than make the semantics >>> more complicated for all functions. >> > > It's not possible to special case __aenter__ and

Re: [Python-ideas] if as

On 7 September 2017 at 11:43, Denis Krienbühl wrote: > What I would love to see is the following syntax instead, which to me is much > cleaner: > >if computation() as result: >do_something_with_result(result) Hi - thanks for your suggestion! This has actually come up

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 7 September 2017 at 20:14, Eric Snow <ericsnowcurren...@gmail.com> wrote: > On Thu, Sep 7, 2017 at 11:52 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> Is there any reason why passing a callable and args is unsafe, and/or >> difficult? Naively, I'd assume th

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 7 September 2017 at 19:26, Eric Snow wrote: > As part of the multi-core work I'm proposing the addition of the > "interpreters" module to the stdlib. This will expose the existing > subinterpreters C-API to Python code. I've purposefully kept the API > simple.

Re: [Python-ideas] Remote package/module imports through HTTP/S

On 23 August 2017 at 18:49, Chris Angelico wrote: > Still -1 on this becoming a stdlib package, as there's nothing I've > yet seen that can't be done as a third-party package. But it's less > scary than I thought it was :) IMO, this would make a great 3rd party package (I note

Re: [Python-ideas] tarfile.extractall progress

On 1 September 2017 at 12:50, Tarek Ziadé wrote: > Hey, > > For large archives, I want to display a progress bar while the archive > is being extracted with: > > https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall > > I could write my own version of

Re: [Python-ideas] Membership of infinite iterators

On 18 October 2017 at 10:56, Koos Zevenhoven wrote: > I'm unable to reproduce the "uninterruptible with Ctrl-C" problem with > infinite iterators. At least itertools doesn't seem to have it: > import itertools for i in itertools.count(): > ... pass > ... >

Re: [Python-ideas] Membership of infinite iterators

On 18 October 2017 at 16:27, Koos Zevenhoven wrote: > So you're talking about code that would make a C-implemented Python iterable > of strictly C-implemented Python objects and then pass this to something > C-implemented like list(..) or sum(..), while expecting no Python code

Re: [Python-ideas] Membership of infinite iterators

OK, looks like I've lost track of what this thread is about then. Sorry for the noise. Paul On 18 October 2017 at 16:40, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Wed, Oct 18, 2017 at 6:36 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> >> On 18 October 2017 at 1

Re: [Python-ideas] Looking for input to help with the pip situation

On 10 November 2017 at 11:37, Oleg Broytman wrote: > On Fri, Nov 10, 2017 at 07:48:35AM +0100, Michel Desmoulin > wrote: >> On linux you >> can't pip install, you need --users, admin rights or a virtualenv. > >Isn't it the same on Windows? For an

Re: [Python-ideas] Looking for input to help with the pip situation

On 10 November 2017 at 08:01, Nick Coghlan wrote: > You can't have it both ways - the only way we can systematically mask > the environmental differences between Windows, Linux and Mac OS X is > by providing tooling that actually masks those differences, which > means

Re: [Python-ideas] Looking for input to help with the pip situation

On 10 November 2017 at 10:01, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 November 2017 at 19:50, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 10 November 2017 at 08:01, Nick Coghlan <ncogh...@gmail.com> wrote: >>> That tooling is venv: >>>

Re: [Python-ideas] How assignment should work with generators?

On 27 November 2017 at 16:05, Chris Angelico wrote: > On Tue, Nov 28, 2017 at 2:35 AM, Steven D'Aprano wrote: >> In this case, there is a small but real benefit to counting the >> assignment targets and being explicit about the number of items to >> slice.

Re: [Python-ideas] Possible Enhancement to py.exe Python Launcher

If I understand your proposal correctly, this is already possible, see https://www.python.org/dev/peps/pep-0397/#python-version-qualifiers The details are likely a little different than what you're proposing, but if they don't cover what you're trying to do, maybe you could give a more specific

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

On 29 November 2017 at 12:41, Nick Coghlan wrote: > On 29 November 2017 at 22:38, Stephan Houben wrote: >> What about more English-like syntax: >> >> X or else Y > > The problem with constructs like this is that they look like they > should mean the same

Re: [Python-ideas] How assignment should work with generators?

On 30 November 2017 at 16:16, Steve Barnes wrote: > I had a sneaky feeling that it did, which raises the question of what > the bleep this enormous thread is about, since the fundamental syntax > currently exists Essentially, it's about the fact that to build

Re: [Python-ideas] How assignment should work with generators?

On 27 November 2017 at 21:54, Kirill Balunov <kirillbalu...@gmail.com> wrote: > 2017-11-27 19:23 GMT+03:00 Paul Moore <p.f.mo...@gmail.com>: > >> >> It should be reasonably easy >> to do a code search for something like "=.*islice", to find code >&

Re: [Python-ideas] How assignment should work with generators?

ty, etc... Personally I don't think it's a significant enough benefit but I'm willing to be swayed if good enough arguments are presented (currently the "a, b, ... = value" syntax is my preferred proposal, but I don't think there's enough benefit to justify implementing it). > 2017-

<    1   2   3   4   5   6   7   8   >