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

I'm concerned in the proposal about losing access to type information (i.e. name) in this proposal. For example, I might write some code like this now: >>> from collections import namedtuple >>> Car = namedtuple("Car", "cost hp weight") >>> Motorcycle = namedtuple("Motorcycle", "cost hp weight")

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

On 20 July 2017 at 11:35, Alexander Belopolsky wrote: > On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum wrote: >> The proposal in your email seems incomplete > > The proposal does not say anything about type((x=1, y=2)). I assume > it will be

[Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

Hi, Neil. > I want to use abstractmethod, but I have my own metaclasses and I don't want > to build composite metaclasses using abc.ABCMeta. > > Thanks to PEP 487, one approach is to facator out the abstractmethod checks > from ABCMeta into a regular (non-meta) class. So, my first suggestion is

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

On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum wrote: > The proposal in your email seems incomplete The proposal does not say anything about type((x=1, y=2)). I assume it will be the same as the type currently returned by namedtuple(?, 'x y'), but will these types be

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

On Wed, Jul 19, 2017 at 6:08 PM, Guido van Rossum wrote: > Regarding that spec, I think there's something missing: given a list (or > tuple!) of values, how do you turn it into an 'ntuple'? That seems a common > use case, e.g. when taking database results like row_factory in

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

On 2017-07-20 02:08, Guido van Rossum wrote: The proposal in your email seems incomplete -- there's two paragraphs on the actual proposal, and the entire rest of your email is motivation. That may be appropriate for a PEP, but while you're working on a proposal it's probably better to focus on

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

On Thu, Jul 20, 2017 at 2:14 AM, Giampaolo Rodola' wrote > > In case of one module scripts it's not uncommon to add a leading > underscore which makes __repr__ uglier. > Actually forget about this: __repr__ is dictated by the first argument. =) -- Giampaolo -

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

On Tue, Jul 18, 2017 at 6:31 AM, Guido van Rossum wrote: > On Mon, Jul 17, 2017 at 6:25 PM, Eric Snow > wrote: > >> On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote: >> > Guido has decreed that namedtuple shall be

Re: [Python-ideas] Enabling Event.set to notify all waiters with an exception

yes thats the behviour that I was looking for. The code its enought simple. Using the shield as has been proposed to protect the cancellation, plus this pattern it will work. Thanks for the feedback and proposal, I will abandon the idea of modify the set method. Cheers, El 19/07/2017 20:39,

Re: [Python-ideas] namedtuple with ordereddict

On 7/19/2017 12:10 PM, Giampaolo Rodola' wrote: On Wed, Jul 19, 2017 at 5:20 PM, Tim Peters > wrote: [Giampaolo Rodola' >] > Still much slower (-4.3x) than plain tuples though:

Re: [Python-ideas] namedtuple with ordereddict

On Wed, Jul 19, 2017 at 12:10 PM, Giampaolo Rodola' wrote: > Should have been something like this instead: > > $ python3.7 -m timeit -s "import collections; Point = > collections.namedtuple('Point', ('x', 'y')); x = [5, 1]" "Point(*x)" > 100 loops, best of 5: 311 nsec

Re: [Python-ideas] pathlib.Path should handle Pythonpath or package root

On 19 July 2017 at 22:01, George Fischhof wrote: > Sorry it was misunderstandable. > I do not want to touch the import. > > I just would like to access the package root (of my current script). > Practically in a Path object if the package resides in the file system. > Parent

Re: [Python-ideas] namedtuple with ordereddict

On Wed, Jul 19, 2017 at 3:27 AM, Steven D'Aprano wrote: > On Tue, Jul 18, 2017 at 06:16:26PM -0400, Jim J. Jewett wrote: > > Then constructing a specific instance from the arguments used to > > create it could be as simple as keeping a reference to the temporary > > created

Re: [Python-ideas] pathlib.Path should handle Pythonpath or package root

Sorry it was misunderstandable. I do not want to touch the import. I just would like to access the package root (of my current script). Practically in a Path object if the package resides in the file system. Parent is not enough, because the place of actual running script can vary. BR, George

Re: [Python-ideas] Alternative Unicode implementations (NSString/NSMutableString)

2017-07-19 4:34 GMT+02:00 Nick Coghlan : > 2. Indicate that it's a "lazily rendered" subclass that should hold > off on calling PyUnicode_Ready for as long as possible, but still do > so when necessary (akin to creating strings via the old Py_UNICODE > APIs and then calling

Re: [Python-ideas] Enabling Event.set to notify all waiters with an exception

Yeps, > 'Event' is designed as a lowish-level primitive: the idea is that it > purely provides the operation of "waiting for something", and then you > can compose it with other data structures to build whatever > higher-level semantics you need. From this point of view, it doesn't > make much

Re: [Python-ideas] Alternative Unicode implementations (NSString/NSMutableString)

> On 19 Jul 2017, at 00:35, Jim J. Jewett wrote: > > Ronald Oussoren came up with a concrete use case for wanting the > interpreter to consider something a string, even if it isn't > implemented with the default datastructure. > > In