Re: [Python-ideas] Add "default" kwarg to list.pop()

+1 one this. And a list.get method has well, with a default value. Le 31/10/2018 à 00:44, Giampaolo Rodola' a écrit : Sorry in advance if this has been proposed in the past but I couldn't find anything on python-ideas:  >>> l = []  >>> l.pop(default=1) 1 FWIW my use case consists in reading e

Re: [Python-ideas] JS’ governance model is worth inspecting

Le 22/09/2018 à 20:27, James Lu a écrit : > > To my mind, there is one very big reason we should be cautious about > > adopting JS language-design policies, namely, that they have led to a > > very, very poorly designed language. No doubt a good deal of that is > > baggage from early stages in wh

Re: [Python-ideas] Moving to another forum system where moderation is possible

Le 20/09/2018 à 10:20, Cameron Simpson a écrit : > On 20Sep2018 10:16, Chris Barker - NOAA Federal > wrote: >> Let's just keep it on email -- I, at least, find i never participate >> in any >> other type of discussion forum regularly. > > As do I. Email comes to me. Forums, leaving aside their

Re: [Python-ideas] Moving to another forum system where

Le 19/09/2018 à 15:28, Chris Angelico a écrit : > On Wed, Sep 19, 2018 at 11:23 PM Michel Desmoulin > wrote: >> - A is telling B this is a bad idea. It should be easy to tell if the >> person is experienced or not. You probably don't want to interact the >> same w

Re: [Python-ideas] Moving to another forum system where

Le 19/09/2018 à 00:37, James Lu a écrit : >> Is that really an issue here? I personally haven't seen threads where >> Brett tried to stop an active discussion, but people ignored him and >> kept fighting. > Not personally with Brett, but I have seen multiple people try to stop the > “reword or r

Re: [Python-ideas] Pre-conditions and post-conditions

Isn't the purpose of "assert" to be able to do design by contract ? assert test, "error message is the test fail" I mean, you just write your test, dev get a feedback on problems, and prod can remove all assert using -o. What more do you need ? Le 15/08/2018 à 23:06, Marko Ristin-Kaufmann a

Re: [Python-ideas] Keyword only argument on function call

Le 06/09/2018 à 03:15, Anders Hovmöller a écrit : > I have a working implementation for a new syntax which would make using > keyword arguments a lot nicer. Wouldn't it be awesome if instead of: > > foo(a=a, b=b, c=c, d=3, e=e) > > we could just write: > > foo(*, a, b, c, d=3, e)

Re: [Python-ideas] Revisiting dedicated overloadable boolean operators

Adding one operator is hard in Python. Adding 4 operators, just for the sake of a bit of syntaxic suggar for DSL based projects is never going to fly. And I say that as a long time SQLA user. Le 03/08/2018 à 19:46, Todd a écrit : > Coming back to the previous discussion about a new set of overlo

Re: [Python-ideas] Syntactic sugar to declare partial functions

I'd rather have functools.partial() to be added as a new method on function objects. > > fromfunctools importpartial > > > def add(x:int,y:int)->int: > returnx +y > > > add_2 = partial(add,2) > Would become: add_2 = add.partial(2) Nothing to change on the parser, no obscure syntax for futur

Re: [Python-ideas] As-do statements/anonymous blocks in python

I like the concept, and I several times wished I could have had a reference to the block of code in a `with` clause. However, it is unlikely to happen: 1 - Guido restricted lambda to one expression, and this would just be a way around that 2 - This will be tempting to use for callbacks and chain

Re: [Python-ideas] A better (simpler) approach to PEP 505

Le 23/07/2018 à 17:12, David Mertz a écrit : > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the > actual legitimate purpose served by the PEP 505 syntax is easily served > by existing Python simply by using

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

Proposal a __very__ dumbed down "try" expression variable = try Expression as not sentinel [else default] The semantic is: 1 - try the expression. If any call (from a normal method, or a __dunder__ one) returns the sentinel, we shortcircui

Re: [Python-ideas] grouping / dict of lists

Counter also consider any missing key has the value "0". With the constructor (accepting any iterable) and the most_common(n), it's just a very set of features if you need to count anything. Le 13/07/2018 à 19:45, Michael Selik a écrit : > On Mon, Jul 2, 2018 at 8:49 AM Chris Barker

Re: [Python-ideas] Allow filtered dir built in

Le 14/06/2018 à 11:27, Steve Barnes a écrit : > Currently when working with interactive sessions using the dir() or > dir(module) built in is incredibly useful for exploring what > functionality is available in a module. (Especially the regrettable > libraries or modules that add really valuab

Re: [Python-ideas] Give regex operations more sugar

Le 14/06/2018 à 07:29, Steven D'Aprano a écrit : > On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote: > >>> Attaching an entire module to a type is probably worse than >>> adding a slew of extra methods to the type. >>> >> >> Not

Re: [Python-ideas] Give regex operations more sugar

Le 13/06/2018 à 22:53, David Mertz a écrit : > On Wed, Jun 13, 2018, 4:44 PM Michel Desmoulin > mailto:desmoulinmic...@gmail.com>> wrote: > > several startswith() and endswith() require a loop, but we could > make them accept *args. > > > You mean som

Re: [Python-ideas] Give regex operations more sugar

> > Both accept a tuple. For example: > >>>> "foo".startswith(("f", "b")) >True >>>> "bar".startswith(("f", "b")) >True > Nice. Now let's do that for str.replace. >> Also, we do have to saturate the str namespace with all the re >> functions. We could decide to go for `str.re

Re: [Python-ideas] Give regex operations more sugar

Le 13/06/2018 à 19:11, Mike Miller a écrit : > > On 2018-06-13 06:33, Michel Desmoulin wrote: >> >> I often wished for findall and sub to be string methods, so +1 on that. >> > > Agreed, and there are a few string functions that could be extended (to > take

Re: [Python-ideas] Give regex operations more sugar

>> I suggest building all regex operations into the str class itself, as well >> as a new syntax for regular expressions. > >There are many different regular expression implementation (regex, > re2). How to make ``s.search(pattern)`` work with all of them? > You don't, they work stand alone

Re: [Python-ideas] Give regex operations more sugar

Le 13/06/2018 à 13:06, Ken Hilton a écrit : > Hi all, > > Regexes are really useful in many places, and to me it's sad to see the > builtin "re" module having to resort to requiring a source string as an > argument. It would be much more elegant to simply do "s.search(pattern)" > than "re.search

Re: [Python-ideas] Add hooks to asyncio lifecycle

> > I still don't get it... If you have a framework you presumably have an > entry point. Why can't you set up your policy in that entrypoint? Why > would a user attempt to change the policy at runtime (you haven't > listed examples of libraries that do this)? Not at run time. But several lib

Re: [Python-ideas] Add hooks to asyncio lifecycle

I like it. First, it solves the issue for policies, and let people decide how they want to deal with the problem (drop the lib, subclass the policy/factory, etc). But it also solves the problem for loops, because loops are set by the task factory, and so you can easily check somebody is changing

Re: [Python-ideas] Add hooks to asyncio lifecycle

> > IMHO, it is not any framework's job to check for this.  It is a > programmer error.  Not clearing the memory is a programmer error either but a gc helps. Not closing a file either but using `with` help. Not passing the proper type is a programmer error but we have type hints. We even have

Re: [Python-ideas] Add hooks to asyncio lifecycle

Le 09/06/2018 à 12:33, Andrew Svetlov a écrit : > If we consistently apply the idea of hook for internal python structure > modification too many things should be changed. Import > machinery, tracemalloc, profilers/tracers, name it. > If your code (I still don't see the real-life example) wants t

Re: [Python-ideas] Allow callables in slices

Le 09/06/2018 à 11:47, Steven D'Aprano a écrit : > On Sat, Jun 09, 2018 at 11:17:05AM +0200, Michel Desmoulin wrote: >> Such as that: >> >> def starting_when(element): >> ... >> >> a_list[starting_when:] > >> Is equiv

[Python-ideas] Allow callable in slices

Given 2 callables checking when a condition arises and returning True: def starting_when(element): ... def ending_when(element: ... Allow: a_list[starting_when:] To be equivalent to: from itertools import dropwhile list(dropwhile(lambda x: not starting_when

[Python-ideas] Allow callables in slices

Such as that: def starting_when(element): ... a_list[starting_when:] Is equivalent to: from itertools import dropwhile def starting_when(element): ... list(dropwhile(lambda x: not starting_when(x), a_list)) And def ending_when(element: ...

Re: [Python-ideas] Making Path() a built in.

écrit : > I think you forgot to to reply to the list. > Barry > > >> On 8 Jun 2018, at 13:16, Michel Desmoulin wrote: >> >> Creating builtin dynamically is not a good idea. tools complains, new comers >> wonder where it comes from, it sets a precedent for

Re: [Python-ideas] Add hooks to asyncio lifecycle

Hi Yuri, > > I actually want to propose to reduce policies API surface by > deprecating and then removing "set_child_watcher()" methods. Besides, > there are many other higher priority To-Do items for asyncio in 3.8, > like implementing Trio's nursery-like objects and cancellation scopes > or

[Python-ideas] Making Path() a built in.

There are very few programs that never use any path operation. Opening a file is such a common one we have a built-in for it with open(), but you usually need to do some manipulation to get the file path in the first place. We have __file__, but the most common usage is to get the parent dir, wit

Re: [Python-ideas] Runtime assertion with no overhead when not active

Maybe somebody already answered this, but what's the difference between this and the keyword "assert", which basically can be stripped of using "python -o" ? Le 05/05/2018 à 10:04, Eloi Gaudry a écrit : > > Hi folks, > > > I intend to add a runtime assertion feature in python. Before >

[Python-ideas] Add hooks to asyncio lifecycle

After years of playing with asyncio, I'm still having a harder time using it than any other async architecture around. There are a lot of different reasons for it, but this mail want to address one particular one: The event loop and policy can be tweaked at any time, by anyone. Now, it's hard eno

Re: [Python-ideas] Make asyncio.get_event_loop a builtin

Well that doesn't matter anyway. With breakpoint() we choose the debugger implementation, so we could do the same here. However, this would be addressing the wrong problem the problem is verbosity. asyncio s are already aware of that, since they are working on providing asycio.run() in 3.7. Now t

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

Le 11/04/2018 à 23:34, George Leslie-Waksman a écrit : > I really like this proposal in the context of `while` loops but I'm > lukewarm in other contexts. > > I specifically like what this would do for repeated calls. > > ... > > md5 = hashlib.md5() > with open(filename, 'rb') as file_reader:

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Le 10/04/2018 à 00:54, Peter O'Connor a écrit : > Kyle, you sounded so reasonable when you were trashing > itertools.accumulate (which I now agree is horrible).  But then you go > and support Serhiy's madness:  "smooth_signal = [average for average in > [0] for x in signal for average in [(1-deca

Re: [Python-ideas] Dart like multi line strings identation

Le 02/04/2018 à 07:09, Mike Miller a écrit : > > On 2018-04-01 05:36, Steven D'Aprano wrote: >> You are right that many of the prefixes can be handled by the same code: >> >> rfd rfD rFd rFD rdf rdF rDf rDF >> Rfd RfD RFd RFD Rdf RdF RDf RDF >> frd frD fRd fRD fdr fdR fDr fDR >>   

Re: [Python-ideas] Dart like multi line strings identation

A "d" prefix to do textwrap.dedent is something I wished for a long time. It's like the "f" one: we already can do it, be hell is it convenient to have a shortcut. This is especially if, like me, you take a lot of care in the error messages you give to the user. I write a LOT of them, very long,

Re: [Python-ideas] Split, slice, join and return "syntax" for str

Even if replace would be a better fit, I can see why doing those 3 operations in one row can be valuable. But, first, they are not common enough so that it's hard to do: spam = docs.python.org" eggs = 'wiki.' + '.'.join(spams.split('.')[1:]) It's not that long to type, and certainly is not happe

Re: [Python-ideas] Please consider adding of functions file system operations to pathlib

+1 We already merged, os.path and glob with pathlib. Let's do all os and shutil. It's weird enough for beginners to even sumble upon that many ways of doing thing for FS. Le 20/02/2018 à 23:11, George Fischhof a écrit : > Good day all, > > as a continuation of thread "OS related file operations

Re: [Python-ideas] Complicate str methods

Le 03/02/2018 à 23:04, Franklin? Lee a écrit : > Let s be a str. I propose to allow these existing str methods to take > params in new forms. > > s.replace(old, new): >     Allow passing in a collection of olds. >     Allow passing in a single argument, a mapping of olds to news. >     Allow the

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

Le 13/11/2017 à 19:57, Chris Barker a écrit : > This has gotten to be a big thread, and it's a pretty intractable > problem, but I think there are a few fairly small things that could be > done to at least make it a bit easier: > > 1) Add python2.exe and python3.exe files to the Windows installers

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

General summary so far ### This debate has been very civil so far and quite productive, so thanks to everyone involved. Several issues and solution proposals have been mentioned, so I will make a summary here. Issue 1: running Python is a different command different OS when

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

Le 12/11/2017 à 19:02, Stephan Houben a écrit : > > 2017-11-12 13:20 GMT+01:00 Paul Moore <mailto:p.f.mo...@gmail.com>>: > > On 12 November 2017 at 06:19, Michel Desmoulin > mailto:desmoulinmic...@gmail.com>> wrote: > > > Well, not exactly.

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

Le 10/11/2017 à 12:41, Oleg Broytman a écrit : > On Fri, Nov 10, 2017 at 09:50:22AM +, Paul Moore > wrote: >> The biggest reason we don't add Python to PATH, as I understand it, is >> because we need to consider the implications of people having multiple >> versions of Python installed. >

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

Le 10/11/2017 à 09:01, Nick Coghlan a écrit : > On 10 November 2017 at 17:05, Michel Desmoulin > wrote: >> >>> Which is why we advise getting into a virtual environment ASAP, such >>> that the only platform specific thing folks necessarily need to learn >>&g

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

> On Windows, which is the only platform I can reasonably comment on, > the killer issue is that the installer doesn't make the commands > "python" and "pip" available by default. Just checking my PC, both go > and rust (which I installed *ages* ago) do appear to, so they "just > work". Java sort-

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

Le 07/11/2017 à 14:06, אלעזר a écrit : > On Tue, Nov 7, 2017 at 2:45 PM Nick Coghlan <mailto:ncogh...@gmail.com>> wrote: > > On 7 November 2017 at 03:52, Michel Desmoulin > mailto:desmoulinmic...@gmail.com>> wrote: > > > And assume that stuf

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

Le 07/11/2017 à 14:08, Paul Moore a écrit : > On 7 November 2017 at 12:44, Nick Coghlan wrote: >>> - make sure the system path is correctly set >> >> Recent python.org Windows installers do this automatically, but there >> are unfortunately still lots of ways for things to go wrong. > > I belie

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

> Which is why we advise getting into a virtual environment ASAP, such > that the only platform specific thing folks necessarily need to learn > to get started is how to get to that first working virtual > environment. > You can't start by teaching virtualenv. I tried. It doesn't work. And it's

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

Le 07/11/2017 à 22:26, Paul Moore a écrit : > On 7 November 2017 at 20:38, Chris Barker wrote: >> On Tue, Nov 7, 2017 at 5:04 AM, Thomas Jollans wrote: >>> >>> As Ivan said earlier, perhaps the Windows installers should provide a >>> "python3" executable, so "python3 -m pip" works everywhere. >

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

> > there can be multiple python2 or 3s too... > > at least with: > > python? -m pip install > > you will get the pip that matches the python you use... Not on windows. You have the py command. My all point is that each of the specific issues I mentioned are A and B but not C propositions. It

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

> Isn't pip installed by default on Windows and OSX? On Linux some > distribution will probably do something unexpected and mess up your > grand plan. Some installers download pip, which won't work if you don't have an internet connection or a proxy setup. But my point is, all this should be u

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

> > I.e., Install under the "Python 3.6" start menu an additional > "Python command prompt", which will > start cmd.exe with an appropriate PATH so that python and pip > run without further prefix. > > That way, the installer still doesn't need to mess with global PATH and > you can > easily ha

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

Le 06/11/2017 à 23:48, Chris Barker a écrit : > On Mon, Nov 6, 2017 at 9:52 AM, Michel Desmoulin > mailto:desmoulinmic...@gmail.com>> wrote: > > I know and you still: > > - have to use py -m on windows, python3 linux, python in virtualenv... > > > can

Re: [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?

Le 07/11/2017 à 22:39, אלעזר a écrit : > > > בתאריך יום ג׳, 7 בנוב׳ 2017, 22:59, מאת Chris Angelico > ‏mailto:ros...@gmail.com>>: > > > -1 on hiding eval/exec; these features exist in many languages, and > they're identically dangerous everywhere. Basically, use eval only > with t

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

> I don't see anything particularly bogging here. > It's always like this when you have multiple versions of the same > software on the system. There's only one PATH, after all. > > Heck, *the mere fact that Python allows to work like this is already a > huge leap forward.* **Doing this cross-pla

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

Le 06/11/2017 à 09:50, Stephan Houben a écrit : > Hi Michel, > > That's exactly why I proposed a `pip` function available from the Python > prompt. > I suppose you could still tell your students to copy/paste the following > into their > Python interpreter. > > def pip(args): >     import sys >

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

> > Software Carpentry starts out with the Anaconda distribution, as it > not only improves the cross-platform UX consistent situation, it also > deals with the external binary dependency problem (at least for the > core set of packages provided either natively or via conda-forge). > Yeah but t

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

Le 06/11/2017 à 09:47, Nick Coghlan a écrit : > On 6 November 2017 at 16:47, Michel Desmoulin > wrote: >> I really want some people from this list to discuss here so we can find >> a way to either unify a bit the way we install and use pip, or find a >> way to expres

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

> > Do you know about "fades"? > > https://fades.readthedocs.io/en/release_6_0/ So when they read any tutorial online they don't have reusable knowledge ? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listi

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

> > > This is pretty much how I thought things worked for all built-in > packages until this thread came up.  Is there any reason to not do this > for all of stdlib? > > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.pytho

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

Hello, Today I'm going to give a training in Python again. And again it will go the same way. On Mac I will have to make people install python, then tell them to use pip3. On Windows, I will have to warn them about checking the "add python executable to system path" (that one of them will ALWAY

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

Le 06/11/2017 à 07:07, Nick Coghlan a écrit : > It's the default on Unix as well - you have to do "make install > ENSUREPIP=no" to avoid getting it. (And some distros also modify their > Python installations so that pip is missing by default) On debian and derivatives (so Ubuntu) you need to inst

Re: [Python-ideas] Moving typing out of the stdlib in Python 3.7?

I could see the typing module staying but: - typing_extension (or the new official external module) append types in the typing module; - if typing_extension is not installed or too old and missing some types, any missing type being accessed returns some kind of mock object that avoid crashing; - a

Re: [Python-ideas] Membership of infinite iterators

Given that: - it doesn't break anything; - the behavior makes sense; - it can avoid the machine freezing when one is not careful; It can be a good idea. Those generators could have iterators that are not themselves and have a __contains__ method behaving accordingly. I only did the mistake of u

[Python-ideas] Add pop_callback to deque signature

My initial proposal would have been to add a data structure to allow something like deque, but allowing cheaper random accesses. However I realized it was a use case more suitable for an external lib. Thinking about how I would implement such a new data structure, I imagined several possibilities,

Re: [Python-ideas] Move some regrtest or test.support features into unittest?

Can you elaborate on _why_ you think something is good for core/a plugin ? Cause right now it's impossible to know what's the logic behind. Le 17/09/2017 à 22:31, Antoine Pitrou a écrit : > On Wed, 13 Sep 2017 15:42:56 +0200 > Victor Stinner > wrote: >> I would like to see if and how we can integ

Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)

Le 18/09/2017 à 06:40, Cody Piersall a écrit : > On Sun, Sep 17, 2017 at 9:49 PM, Guido van Rossum wrote: >> I ave to agree with the other committers who already spoke up. >> >> I'm not using tab completion much (I have a cranky old Emacs setup), but >> isn't making tab completion better a job fo

Re: [Python-ideas] PEP 562

If I recall there was a proposal a few months for a "lazy" keyword that would render anything lazy, including imports. Instead of just adding laziness on generators, the on imports, then who knows where, maybe it's time to consider laziness is a hell of a good general concept and try to generaliz

Re: [Python-ideas] Adding new lines to "Zen of Python"

Zen would suppose to remove things from it, not add. Le 08/09/2017 à 14:47, Thomas Güttler a écrit : > I curious if there are any plans to update the "Zen of Python". > > What could be added to the "Zen of Python"? > > What do you think? > > Regards, > Thomas Güttler > > > > _

Re: [Python-ideas] Argparse argument deprecation

't know how to make the distinction between deprecated and removed from the introspection point of view. All in all, I think it's an interesting proposal, but I'm not going to fight over it. If it never happens, I can fit a bunch of "if" like you said. > > --Ned

Re: [Python-ideas] Argparse argument deprecation

Argparse is not just about parsing, it's about providing convenient tooling associated with parsing. Otherwise you would not have automatically generated a "usage" message or a "--help" command. Following your definition, those are not parsing. But there are here, because we all end up coding the

Re: [Python-ideas] Argparse argument deprecation

+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 good

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

Le 29/07/2017 à 18:14, Alex Walters a écrit : > My $0.02 on the entire series of nametuple threads is… there **might** > be value in an immutable namespace type, and a mutable namespace type, > but namedtuple’s promise is that they can be used anywhere a tuple can > be used. If passing in kwargs

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

To void introducing a new built-in, we could do object.bag = SimpleNamespace Le 27/07/2017 à 05:23, Mike Miller a écrit : > Many times in the olden days when I needed a bag o' attributes to be > passed around like a struct I'd make a dummy class, then instantiate > it. (A lot harder than the java

Re: [Python-ideas] namedtuple redesign goals

Le 24/07/2017 à 13:45, Ethan Furman a écrit : > [redirecting back to list] > > On 07/24/2017 04:19 AM, Michel Desmoulin wrote: >> Le 24/07/2017 à 13:02, Ethan Furman a écrit : >>> On 07/23/2017 10:47 AM, Michel Desmoulin wrote: > >>>> I'm not sur

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

Le 24/07/2017 à 16:12, Nick Coghlan a écrit : > On 22 July 2017 at 01:18, Guido van Rossum wrote: >> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's >> encourage the use of objects rather than tuples (named or otherwise) for >> most data exchanges. I know of a large co

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

Le 24/07/2017 à 15:31, Steven D'Aprano a écrit : > On Sun, Jul 23, 2017 at 07:47:16PM +0200, Michel Desmoulin wrote: > >> I'm not sure why everybody have such a grip on the type. >> >> When we use regular tuples, noone care, it's all tuples, no matter wh

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

I'm not sure why everybody have such a grip on the type. When we use regular tuples, noone care, it's all tuples, no matter what. Well in that case, let's make all those namedtuple and be done with it. If somebody really needs a type, this person will either used collections.namedtuple the old w

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

Having to define objects for scripts or small projects is really adding a burden. A namedtuple litteral strike the perferfect balance between expressivity and concision for those cases. Le 21/07/2017 à 17:18, Guido van Rossum a écrit : > Honestly I would like to declare the bare (x=1, y=0) proposa

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

Le 17/05/2017 à 13:08, Stephan Houben a écrit : > Hi Michel, > >> Now OPP is already hard to teach to my students, but if I have to add >> this to the mix, I will just have to tell them to copy / paste it >> blindly for a long time before I can get to the point they can >> understand what it doe

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

Le 17/05/2017 à 07:22, Guido van Rossum a écrit : > On Tue, May 16, 2017 at 8:14 PM, Juancarlo Añez > wrote: > > What I like about attrs is: > > * The class level declaration of instance attributes > * That the reasonable *init*, *repr*, and *eq* are g

[Python-ideas] pathlib.Path.walk

Like os.walk, but from a Path instance. We have Path.iterdir, but it's not recursive. Which you use either os.scandir, or os.walk. In any case, you end up doing: import os import pathlib directory = pathlib.Path(get_dir()) # do things with directory for root, dirs, files os.walk(directory):

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

Yes Python is turing complete, there is always a solution to everything. You can also do decorators with func = wrapper(func) instead of @wrapper, no need for a new syntax. Le 26/03/2017 à 20:42, Chris Angelico a écrit : > On Mon, Mar 27, 2017 at 5:22 AM, Michel Desmoulin > wrote: >>

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

Le 26/03/2017 à 10:31, Victor Stinner a écrit : > print(msg) calls sys.stdout.write(msg): write() expects text, not bytes. What you are saying right now is that the API is not granular enough to just add a parameter. Not that it can't be done. It just mean we need to expose stdout.write() encodi

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

Le 24/03/2017 à 17:37, Victor Stinner a écrit : > *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 > > You can already set the PYTHONIOENCODING environment variabl

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

Hello, I've been following PythonQL with interest. I like the clever hack using Python encoding. It's definitely not something I would recommend to do for an inclusion in Python as it hijack the Python encoding method, which prevent your from... well choosing an encoding. And requires to have a fi

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

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 dict is often the RIGHT >> way to address these issues. > > You can't be serious about this. Especially beca

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

Le 01/03/2017 à 02:23, Ethan Furman a écrit : > On 02/28/2017 05:18 PM, Michel Desmoulin wrote: > >> I love this proposal but Guido rejected it. Fighting for it right now >> would probably be detrimental to the current proposed feature which >> could potentially

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

> > I am aware of that. I'm just saying you don't have to use try...except, > you can use slicing instead. Obviously you have to adapt the code since > you are getting a list not a single item: > > # may fail, if alist is empty > if alist[0] == "spam": ... > > # cannot fail > if alist[0:1] ==

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

Le 01/03/2017 à 01:02, Steven D'Aprano a écrit : > On Tue, Feb 28, 2017 at 07:10:15PM +0100, Sven R. Kunze wrote: > >> 1. advantage: it looks like dict access -> allows duck typing (oh how >> often I'd missed that) > > Dicts and lists don't duck-type because they are very different things. >

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

most wanted feature ever in Python. Le 01/03/2017 à 01:22, Rob Cliffe a écrit : > > > On 28/02/2017 11:54, Michel Desmoulin wrote: >> dict.get() is a very useful method, but for lists and tuples, we need to >> rely on try/except instead. >> >> Can we get list.g

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Only if "None" is not a proper value from .get(). And this doest solve the problems with more general callbacks that are not trying to get a value (cf Django lazy_gettext). Besides, "??" does not exist yet for Python, so let's counter the argument for lazy with the potential benefits of something

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Good luck Le 28/02/2017 à 16:08, Joseph Hackman a écrit : > Yes I do think this is precisely where a lazy or delayed feature would work > well. I'm working on writing up a complete PEP now, and have made some > progress on the things left unsolved in the other thread. I will post again > when t

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

Le 28/02/2017 à 15:45, Steven D'Aprano a écrit : > On Tue, Feb 28, 2017 at 12:54:26PM +0100, Michel Desmoulin wrote: >> dict.get() is a very useful method, but for lists and tuples, we need to >> rely on try/except instead. > > No you don't. You can use slicing.

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Le 28/02/2017 à 13:47, Markus Meskanen a écrit : > You don't need list comprehension, you can use a for loop. > > You don't need upacking you can use indexing. > > And you don't need lazy, it's just convenient. > > > With this sole argument you can add almost anything to the langua

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Le 28/02/2017 à 13:27, Markus Meskanen a écrit : > Well you could just use a dict subclass here with get() that takes > callable... > As I said to Angelico: Yes but this assumes: - I have access to the code instantiating conf; - all code using conf are using load_from_db as a default value;

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Le 28/02/2017 à 13:19, Chris Angelico a écrit : > On Tue, Feb 28, 2017 at 11:04 PM, Michel Desmoulin > wrote: >> Instead, I think it's a good example of were 'lazy' could help. You >> can't get simpler than: >> >> conf.get('setting_name

[Python-ideas] Expose a child factory using MappingProxyType in builtins

We have the immutable frozenset for sets and and tuples for lists. But we also have something to manipulate dict as immutable datastructures: >>> from types import MappingProxyType as idict >>> d = idict({'a':1, 'b':2, 'c':3}) >>> d['a'] = 4 Traceback (most recent call last): File "", line 1, i

[Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

The debate on the 'lazy' keyword seems to have settled, but I don't know if somebody is trying to write a PEP about it. Anyway, I was doing something like this the other day: conf.get('setting_name', load_from_db('setting_name')) And then realized I could save a query not doing the load_from_db(

  1   2   >