Re: [Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

I see no reason to introduce clutter like this at this point in time - code needing to run in both Py 2 nd 3, if not using something like "six" could do: compat.py try: unicode except NameError: unicode = basestring = str elsewhere: from compat import unicode, basestring Or rather:

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

On Tue, 28 Feb 2017 at 17:19 David Mertz wrote: > On Tue, Feb 28, 2017 at 7:16 AM, Michel Desmoulin < > desmoulinmic...@gmail.com> wrote: > > Le 28/02/2017 à 15:45, Steven D'Aprano a écrit : > > No you don't. You can use slicing. > > alist = [1, 2, 3] > > print(alist[99:100]) #

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

On 03/03/2017 06:29 AM, Victor Stinner wrote: An alternative for generated signature of multiple optional arguments is "bytearray([source[, encoding[, errors]]])", but I'm not a big fan of nested [...], But that's not the same thing. bytearry([source,] [encoding,] [errors]) says that each

Re: [Python-ideas] For/in/as syntax

On 03/03/2017 01:14 AM, Brice PARENT wrote: Sorry for the very long message, I hope it will get your interest. And I also hope my English was clear enough. Long messages that explain the idea are welcome! I think it looks interesting. -- ~Ethan~

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

On 03/03/2017 08:09 AM, Ed Kellett wrote: P.S. all the talk of PEP 463 seems misplaced. That it solves (FSVO solve) this problem doesn't mean it should supersede this discussion. The advantage of PEP 463 is that issues like this would be less pressing, and it's much more general purpose.

Re: [Python-ideas] For/in/as syntax

Hi Brice, On Fri, Mar 3, 2017 at 1:14 AM, Brice PARENT wrote: > > A word about compatibility and understandability before: > "as" is already a keyword, so it is already reserved and easy to parse. It > couldn't be taken for its other uses (context managers, import statements

Re: [Python-ideas] For/in/as syntax

Thanks Matthias for taking the time to give your opinion about it. Just to set the focus where I may have failed to point it: the main purpose of this proposal is the creation of the object itself, an object representing the loop. What we can do with it is still a sub-level of this proposal,

Re: [Python-ideas] For/in/as syntax

Thanks for the idea and prior research. I'm not convinced that this warrants new syntax. Most of what you propose (skipping, counting, exposing a length if available, tracking if completed) could be solved already by creating your own wrapper around an iterable: elements_loop =

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

On 03/02/2017 12:36 PM, Sven R. Kunze wrote: On 01.03.2017 06:34, Ethan Furman wrote: On the bright side, if enough use-cases of this type come up (pesky try/except for a simple situation), we may be able to get Guido to reconsider PEP 463. I certainly think PEP 463 makes a lot more sense

Re: [Python-ideas] For/in/as syntax

On 03/03/2017 08:21 AM, Matthias Bussonnier wrote: ## # forloop.break(), to break out of nested loops (or explicitly out of current #loop) - a little like pep-3136's first proposal has_dog_named_rex = False for owner in owners: for dog in

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

On Fri, 3 Mar 2017 at 17:03 Ethan Furman wrote: > On 03/03/2017 08:09 AM, Ed Kellett wrote: > > > P.S. all the talk of PEP 463 seems misplaced. That it solves (FSVO > solve) this problem doesn't mean it should supersede > > this discussion. > > The advantage of PEP 463 is

Re: [Python-ideas] For/in/as syntax

On Sat, Mar 4, 2017 at 5:50 AM, Matthias Bussonnier wrote: > Thanks, I think it does make sens, I'm going to guess, > outerloop.brk(inners=True) might also be helpful if you have more > inners loops. I think that implicitely breaking inner ones might > not always be

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

On Fri, Mar 3, 2017 at 11:15 AM, Kyle Lahnakoski wrote: > Python > has a fundamentally different philosophy about None that conflicts with > what I need for my domain [2] where I am transforming and interpreting > data. Using a set of classes that make a different set

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

On 03.03.2017 19:29, Ed Kellett wrote: The reasons already stated boil down to "lists aren't dicts so they shouldn't share methods", which seems ill-advised at best, and "I wouldn't use this". I wonder if those arguing against it also think dicts should not have item access: a[0] dict or

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

I must mention a get() method for lists and tuples would be very useful for me too. It is so useful, that I spent too much time making my own module to handle this case, plus many of the other dealing-with-None subjects found on this list. Michel is correct to point out that this is domain

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

On Fri, Mar 3, 2017 at 12:06 PM, Chris Barker wrote: > M.A. Lemberg has been talking about that on this list (in this thread? > I've lost track...) > it was in the "Optional parameters without default value" thread. -CHB -- Christopher Barker, Ph.D. Oceanographer

Re: [Python-ideas] For/in/as syntax

Hi Brice, On Fri, Mar 3, 2017 at 10:00 AM, Brice PARENT wrote: > Thanks Matthias for taking the time to give your opinion about it. > > Just to set the focus where I may have failed to point it: > the main purpose of this proposal is the creation of the object itself, an >

Re: [Python-ideas] For/in/as syntax

On 2017-03-03 01:52 PM, Chris Angelico wrote: > On Sat, Mar 4, 2017 at 5:50 AM, Matthias Bussonnier > wrote: >> Thanks, I think it does make sens, I'm going to guess, >> outerloop.brk(inners=True) might also be helpful if you have more >> inners loops. I think that

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

On Fri, Mar 3, 2017 at 11:01 AM, Sven R. Kunze wrote: > I wonder if those arguing against it also think dicts should not have item > access: > > a[0] > > dict or list? Why should it matter? > Because a mapping that happens to have an integer key is a fundamentally different

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

On 03.03.2017 21:09, Chris Barker wrote: On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze > wrote: For me to think (list/tuple).get() was needed would be if lots of folk either cast their lists to dicts or made their own list-dict class to

Re: [Python-ideas] For/in/as syntax

On Sat, Mar 4, 2017 at 5:56 AM, Matthias Bussonnier wrote: >> *scratches head* How do you break an outer loop without breaking the >> inner loop? What happens? > > Finish running the inner, then breaking the outer. Instead of breaking > inner and outer. > > for i in

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

On 03.03.2017 16:24, Yury Selivanov wrote: TBH I think that optional parameters isn't a problem requiring new syntax. We probably do need syntax for positional-only arguments (since we already have them in a way), but optional parameters can be solved easily without a new syntax. Syntax like:

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

On 03/03/2017 10:48 AM, Sven R. Kunze wrote: On 03.03.2017 18:06, Ethan Furman wrote: On 03/02/2017 12:36 PM, Sven R. Kunze wrote: It then would make sense to remove .get() on dicts. ;-) and to remove parameter "default" of max(). and to remove parameter "default" of getattr(). Backwards

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

Thanks Chris for your idea. Right now, I could not think of an example "non-trivial and simple and small enough" especially in the context of JSON. But maybe the other proponents have. The part of data series from simulations (so proper datastructures available). So, data lists which

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

On 03.03.2017 20:35, Ethan Furman wrote: On 03/03/2017 11:01 AM, Sven R. Kunze wrote: On 03.03.2017 19:29, Ed Kellett wrote: The reasons already stated boil down to "lists aren't dicts so they shouldn't share methods", which seems ill-advised at best, and "I wouldn't use this". I wonder

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

On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze wrote: > For me to think (list/tuple).get() was needed would be if lots of folk > either cast their lists to dicts or made their own list-dict class to solve > that problem. > > > The easier solution would be to provide list.get ;-)

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

About JSON and schema-less data: I need to deal with this fairly often as well, but: JSON has a data model that includes both mappings and sequences: Sequences (arrays, lists, etc) are the "right" thing to use when an object has zero or more of something. Usually, these somethings are all the

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

On 03.03.2017 18:06, Ethan Furman wrote: On 03/02/2017 12:36 PM, Sven R. Kunze wrote: On 01.03.2017 06:34, Ethan Furman wrote: On the bright side, if enough use-cases of this type come up (pesky try/except for a simple situation), we may be able to get Guido to reconsider PEP 463. I

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

On Fri, Mar 3, 2017 at 1:35 PM, Michel Desmoulin wrote: > > > Le 03/03/2017 à 22:21, Chris Barker a écrit : > > On Fri, Mar 3, 2017 at 12:21 PM, Sven R. Kunze > > wrote: > > > >> For my part, I think casting a list to a

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

On Fri, Mar 3, 2017 at 12:33 PM, Sven R. Kunze wrote: > Right now, I could not think of an example "non-trivial and simple and > small enough" especially in the context of JSON. But maybe the other > proponents have. > Always a challenge -- sorry to lack imagination, I tend to

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

On Fri, Mar 3, 2017 at 1:35 PM, Michel Desmoulin wrote: > I am serious. It depends on the use case. If the data are an But that's the all problem isn't it? Since the start of the discussion, contesters have been offering numerous solutions, all being contextual and

[Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

I found this in an old post: > Maybe too late now but there should have been 'unicode', > 'basestring' as aliases for 'str'. I guess it is too late to think about it again ... Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/

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

On 02.03.2017 04:41, Chris Barker wrote: Maybe someone else will chime in with more "I'd really have a use for this" examples. It also makes refactoring easier. Regards, Sven ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] for/except/else

On 03/03/2017 04:36 AM, Nick Coghlan wrote: On 2 March 2017 at 21:06, Wolfgang Maier > wrote: - overall I looked at 114 code blocks that contain one or more breaks Thanks for doing that research :)

Re: [Python-ideas] for/except/else

On 03.03.2017 09:47, Wolfgang Maier wrote: However, the fact that else exists generates a regrettable asymmetry in that there is direct language support for detecting one outcome, but not the other. Stressing the analogy to try/except/else one more time, it's as if "else" wasn't available

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

On 01.03.2017 06:34, Ethan Furman wrote: On the bright side, if enough use-cases of this type come up (pesky try/except for a simple situation), we may be able to get Guido to reconsider PEP 463. I certainly think PEP 463 makes a lot more sense that adding list.get(). It then would make

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

2017-03-03 6:13 GMT+01:00 Mike Miller : > Agreed, I've rarely found a need for a "second None" or sentinel either, but > once every few years I do. So, this use case doesn't seem to be common > enough to devote special syntax or a keyword to from my perspective. The

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

On 03.03.2017 14:06, Victor Stinner wrote: 2017-03-03 6:13 GMT+01:00 Mike Miller : Agreed, I've rarely found a need for a "second None" or sentinel either, but once every few years I do. So, this use case doesn't seem to be common enough to devote special syntax or a

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

Since yet another sentinel singleton sounds like a dead end, I suggest to use [arg=value] syntax and require a default value in the prototype, as currently required for *optional keyword* arguments. "[...]" syntax for optional parameter is commonly used in Python documentation (but the exact

Re: [Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

The thread is here in the archive (https://mail.python.org/ pipermail/python-ideas/2016-June/040761.html) if anyone's wondering context, as I was. In short, someone wanted an alias from string to basestring. This is addressed in the "What's new in Python 3.0" (

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

TBH I think that optional parameters isn't a problem requiring new syntax. We probably do need syntax for positional-only arguments (since we already have them in a way), but optional parameters can be solved easily without a new syntax. Syntax like: 1. def a(?foo), 2. def a(foo=pass), 3. def