Re: [Python-ideas] Generator syntax hooks?

2017-08-09 Thread Nick Coghlan
On 10 August 2017 at 01:49, Soni L. wrote: > On 2017-08-09 11:54 AM, Nick Coghlan wrote: >> Right, I was separating the original request to make "{x for x in >> integers if 1000 <= x < 100}" work into the concrete proposal to >> make exactly *that* syntax work (which I

[Python-ideas] PyPI JSON Metadata Standardization for Mirrors

2017-08-09 Thread Cooper Ry Lees
Hi all, First time emailer, so please be kind. Also, if this is not the right mailing list for PyPA talk, I apologize. Please point me in the right direction if so. The main reason I have emailed here is I believe it may be PEP time to standardize the JSON metadata that PyPI makes available, like

Re: [Python-ideas] Generator syntax hooks?

2017-08-09 Thread Nick Coghlan
On 10 August 2017 at 00:54, Nick Coghlan wrote: > Yeah, if we ever did add something like this, I suspect a translation > using takewhile would potentially be easier for at least some users to > understand than the one to a break condition: > > {x for x in

Re: [Python-ideas] Mimetypes Include application/json

2017-08-09 Thread Nick Coghlan
On 10 August 2017 at 04:24, Serhiy Storchaka wrote: > 09.08.17 21:17, Brett Cannon пише: >> >> On Wed, 9 Aug 2017 at 10:43 Nate. > > wrote: >> A friend and I have hit a funny situation with the `mimetypes.py` >> library

Re: [Python-ideas] Pseudo methods

2017-08-09 Thread Nick Coghlan
On 9 August 2017 at 18:19, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > To analyse and investigate this code, we need to "just know" that: > > You can of course hope that help(input().has_vowels) will tell you > where to find it. If it doesn't,

Re: [Python-ideas] Generator syntax hooks?

2017-08-09 Thread Terry Reedy
On 8/9/2017 10:54 AM, Nick Coghlan wrote: On 9 August 2017 at 15:38, Guido van Rossum wrote: On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote: The OP's proposal doesn't fit into that category though: rather it's asking about the case where we have an

Re: [Python-ideas] Generator syntax hooks?

2017-08-09 Thread Chris Barker
On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote: > On 8 August 2017 at 09:06, Chris Barker wrote: > > It would be nice to have an easier access to an "slice iterator" though > -- > > one of these days I may write up a proposal for that. > > An idea

Re: [Python-ideas] Mimetypes Include application/json

2017-08-09 Thread Nate.
O, fun! Thank you for the guidance. I managed to find a Bug already created, http://bugs.python.org/issue30824. I'll create a Pull Request using that Bug. On Wed, Aug 9, 2017 at 1:18 PM Brett Cannon wrote: > On Wed, 9 Aug 2017 at 10:43 Nate. wrote: > >>

Re: [Python-ideas] Mimetypes Include application/json

2017-08-09 Thread Oleg Broytman
On Wed, Aug 09, 2017 at 05:42:18PM +, "Nate." wrote: > A friend and I have hit a funny situation with the `mimetypes.py` library > guessing the type for a '.json' file. Is there a reason why '.json' hasn't > been > added to the mapping? My guess is that nobody uses

Re: [Python-ideas] Mimetypes Include application/json

2017-08-09 Thread Serhiy Storchaka
09.08.17 21:17, Brett Cannon пише: On Wed, 9 Aug 2017 at 10:43 Nate. > wrote: A friend and I have hit a funny situation with the `mimetypes.py` library guessing the type for a '.json' file. Is there a reason why '.json' hasn't been

Re: [Python-ideas] Mimetypes Include application/json

2017-08-09 Thread Brett Cannon
On Wed, 9 Aug 2017 at 10:43 Nate. wrote: > Hi, > > A friend and I have hit a funny situation with the `mimetypes.py` library > guessing the type for a '.json' file. Is there a reason why '.json' hasn't > been > added to the mapping? > Probably no one thought about it since

[Python-ideas] Mimetypes Include application/json

2017-08-09 Thread Nate.
Hi, A friend and I have hit a funny situation with the `mimetypes.py` library guessing the type for a '.json' file. Is there a reason why '.json' hasn't been added to the mapping? Without `mailcap` installed: [root@de169da8cc46 /]# python3 -m mimetypes build.json I don't know anything about

Re: [Python-ideas] Generator syntax hooks?

2017-08-09 Thread Soni L.
On 2017-08-09 11:54 AM, Nick Coghlan wrote: On 9 August 2017 at 15:38, Guido van Rossum wrote: On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote: The OP's proposal doesn't fit into that category though: rather it's asking about the case where we have

Re: [Python-ideas] Generator syntax hooks?

2017-08-09 Thread Nick Coghlan
On 9 August 2017 at 15:38, Guido van Rossum wrote: > On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan wrote: >> The OP's proposal doesn't fit into that category though: rather it's >> asking about the case where we have an infinite iterator (e.g. >>

Re: [Python-ideas] Argparse argument deprecation

2017-08-09 Thread Tarek Ziadé
> Another note about the proposal: calling it "deprecated" seems odd, > since the proposal is really just a general-purpose callback. argparse > isn't generating the warning, your callback function would be doing it. > Why name it "deprecated"? How is this different than the "action" >

Re: [Python-ideas] Argparse argument deprecation

2017-08-09 Thread Michel Desmoulin
Le 09/08/2017 à 12:59, Ned Batchelder a écrit : > OK, then on a more pragmatic note: why is it easier to write a callback > than to write a simple if statement after the parsing? Generating help > is complex, and a common task that is closely tied to the syntax of the > options, so it makes

Re: [Python-ideas] Argparse argument deprecation

2017-08-09 Thread Ned Batchelder
OK, then on a more pragmatic note: why is it easier to write a callback than to write a simple if statement after the parsing? Generating help is complex, and a common task that is closely tied to the syntax of the options, so it makes sense for argparse to do it. Deprecation is neither complex,

Re: [Python-ideas] Argparse argument deprecation

2017-08-09 Thread Ned Batchelder
On 8/9/17 3:56 AM, Tarek Ziadé wrote: > Hey, > > I don't think there's any helper to deprecate an argument in argparse > > Let's say you have a --foo option in your CLI and want to deprecate it > in the next release before you completely remove it later. > > My first though on how to do this by

Re: [Python-ideas] Argparse argument deprecation

2017-08-09 Thread Michel Desmoulin
+1, but I would make "deprecated" either a warning, an exception or a callable. This way to create a simple deprecation, you just provide DeprecationWarning('This will be gone in the next release'), or ValueError('This has been removed in 2.X, use "stuff instead"') if you decide it's gone for

Re: [Python-ideas] Pseudo methods

2017-08-09 Thread Stephen J. Turnbull
Nick Coghlan writes: > To analyse and investigate this code, we need to "just know" that: You can of course hope that help(input().has_vowels) will tell you where to find it. If it doesn't, well, shame on you for depending on source-unavailable software that you don't understand. ;-) I'm with

Re: [Python-ideas] Generator syntax hooks?

2017-08-09 Thread Stephen J. Turnbull
Nick Coghlan writes: > Right now, getting the "terminate when false" behaviour requires the > use of takewhile: > > {itertools.takewhile(lambda x: x < 100, itertools.count(1000)} My objection to this interpretation is different from Guido's (I think): if you're really thinking in

[Python-ideas] Argparse argument deprecation

2017-08-09 Thread Tarek Ziadé
Hey, I don't think there's any helper to deprecate an argument in argparse Let's say you have a --foo option in your CLI and want to deprecate it in the next release before you completely remove it later. My first though on how to do this by adding a new "deprecated" option to