[Python-ideas] Re: Descriptor __get__ and __set__ argument discrepancy
Hi, The __get__ method of descriptors can be called at the class level (that's how methods work) and in that case instance would be None, but owner will always reference the current class. __set__ can only be called for instances on that class (`Cls.attr = ...` would redefine the class-attribute and not call the descriptor), so instance can never be None and owner is type(instance). Le jeu. 19 oct. 2023 à 09:45, Dom Grigonis a écrit : > > > On 19 Oct 2023, at 10:27, dn via Python-ideas > wrote: > > > > On 19/10/2023 19.50, Dom Grigonis wrote: > >> Thank you, > >> Good information, thank you. Was not aware of __set_name__. > > > > IIRC that was one of the updates/improvements. Thanks to whomsoever...! > > > > The: > > > >instance.__dict__[self.name] = value > > > > may require a bit of thought before it feels comfortable, but it is > significantly easier to understand than what we had to do 'before'. > I am using `setattr(instance, self.name, value)`. But I see that > instance.__dict__ is more appropriate in this case. > > > > Another surprise, and I've assumed you're asking in the context of > [Custom] Descriptors, is in how many places/functions Python makes use of a > descriptor/descriptor protocol. Yet few of us seem to make use of them in > our application code... > > (YMMV!) > I use them more and more. > > > However, I was more interested, why doesn't __set__ have an `owner` > argument, while `__get__` does. I am aware that this is not an issue at all > as one can simply do `inst.__class__`, but I am just curious about the > reason for inconsistency. > > Although, answers that I got were very useful. > > DG > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/64MSMP4FFIT4FHPJQ66RW3OWXSP7RUFC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VPNJEO2A36LKQVSK764TJPXXSBE2QKLI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Extract variable name from itself
Why would an object always be linked to a variable name, and why only one
name?
Le mar. 12 sept. 2023 à 10:23, Dom Grigonis a
écrit :
> As far as I understand, it is not possible. Is it?
>
> Something similar to:
>
> var = 710
> variable_name = [k for k, v in locals().items() if v == 710][0]
> print("Your variable name is " + variable_name)
>
> ,except robust.
>
> Possible ways to expose it:
> * builtin function `varname(obj: object) —> str`
> * object.__varname__ dunder (this one wouldn’t clutter general namespace)
>
> I am working on some code and just got to the point where it seems I could
> make use of it. The case is as follows:
>
> # What I do now:class A:
> defaults = dict()
>
> def set_default(self, a):
> self.defaults['a'] = a
>
> def make_something(self, a=None):
> a = a if a is not None else self.defaults.get('a')
> return Something(a)
> # What I would like to be able to do:class A:
> defaults = dict()
>
> def set_default(self, a):
> self.defaults[a.__varname__] = a
>
> def make_something(self, a=None):
> a = a if a is not None else self.defaults.get(a.__varname__)
> return Something(a)
>
>
> In this case I like second one, because it allows a tight coupling of
> variable names, which has the following benefits:
> 1. General simplification, where one doesn’t have to think variable name
> and its key value in dictionary. Code looks cleaner.
> 2. If one was to change a variable name of `set_default` it would
> immediately surface as an error.
> 3. For someone working with IDEs or making use of clever multiple
> selection tools, it would be easy to change all in one go.
>
> Any reasons why the above would not be a good practice?
> Any reasons why exposing it is not a good idea?
> Would this be difficult to achieve from python dev’s perspective?
>
>
> — This one can’t be solved with deferred eval :/ —
> Regards,
> DG
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/H3O6N2W62EDU75JEQQGN63HETAZNANLP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/RINOBZMXRJIHY2U7AYKKA5YAXZ5WJNAP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make ellipsis an indicator of missing implementation
Raising an exception in that case would be a breaking change only for an aesthetic preference. Some codes use ellipsis as this in functions body and don't want it to raise an error. Also it's going to be confusing to understand why an exception is raised in that place. Le jeu. 27 avr. 2023 à 15:50, haael a écrit : > > In examples in the web very often we see unfinished or partial code, > where the ellipsis "..." is used in place of missing instructions. > > Idea: make ellipsis used in that context throw an exception, reminding > the user that this code is work in progress. > > The exception could be called ToDoError, or WorkInProgressError, or > simply EllipsisError, and could be derived from NotImplementedError. > > > ``` > > def my_fun(): > ... # todo > > my_fun() > > > WorkInProgressError: Implementation of `my_fun` is not finished. > > ``` > > This change could break some code, as for now ellipsis in the middle of > code is silently ignored, but I don't think anybody seriously relies on > that behavior. > > haael > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/QAU7LB46VGVZYESJUI6RKM2UB3WQR5N4/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6RX2H4WBASSUIBYB62GFPCTYZ6S3WBMW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ampersand operator for strings
It's not that tricky to have the lstrip/rstrip behaviour with a join:
def space_join(*args):
first, *middle, last = args
return ' '.join((first.rstrip(), *(s.strip() for s in middle),
last.lstrip()))
What is harder is to be sure that this would be the expected behaviour when
using a `&` operator on strings.
Why `' a' & 'b'` would produce `'a b'` and `' ' & 'b'` produce `' b'`
for example?
Le sam. 11 mars 2023 à 10:04, Rob Cliffe via Python-ideas <
python-ideas@python.org> a écrit :
>
>
> On 07/03/2023 09:54, Valentin Berlier wrote:
> > I'm -1 on this. You can easily make a helper that achieves the desired
> syntax. Presenting "human readable data" isn't just about collapsing
> spaces, and having your own helper means that you can adjust the formatting
> to your specific use case if needed (for example with a different
> separator).
> >
> > from typing import Self
> >
> > class StripJoin:
> > def __init__(self, value: str = "") -> None:
> > self.value = value
> > def __and__(self, other: str) -> Self:
> > other = other.strip()
> > separator = bool(self.value and other) * " "
> > return StripJoin(f"{self.value}{separator}{other}")
> > def __str__(self) -> str:
> > return self.value
> >
> > j = StripJoin()
> > print(j & " foo " & " bar " & " something ")
> > # Output: "foo bar something"
> >
> > The example above is more efficient than a possible implementation
> directly on the str builtin as it doesn't strip the left side over and
> over. However it still incurs repeated allocations and encourages a pattern
> that performs badly in loops. With a lot of input you should probably
> accumulate the stripped strings in a list and join them all at once.
> As Steven d'Aprano pointed out re a similar suggestion, this is not the
> same as my proposal, where
> " foo " & " bar " & " something "
> would evaluated to
> " foo bar something "
> Far from stripping the left side over and over, it doesn't strip it at
> all! (Or the right side.)
> This is trickier to write using join. And if the first or last string
> can be blank, or all whitespace, it is trickier still.
> As it is so easy to get these things wrong, perhaps having it built in
> is not such a terrible idea?
> Best wishes
> Rob Cliffe
> >
> > In any case I recommend reaching out for a library like Rich (
> https://github.com/Textualize/rich) if you care about formatting the
> output of your program nicely.
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/A7RPR3FSBXEMRYAUXJVYYROCHVHL7DVP/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/J356SW4PG3KUDYFBLXAWDS723VCV3EVE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PDYA2XENUSG3SVYYUZC35UMUGCLEBJRQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: join() could add separators at start or end
I think `'\n'.join(lines, 1)` & `'\n'.join(lines, 'e')` are worse than
`'\n'.join(lines,
at_end=True)` or others, it's much more complicated to understand what will
be produced.
Le ven. 10 mars 2023 à 00:47, Rob Cliffe via Python-ideas <
python-ideas@python.org> a écrit :
>
>
> On 09/03/2023 05:25, Bruce Leban wrote:
>
>
> On Wed, Mar 8, 2023 at 4:34 PM Rob Cliffe via Python-ideas <
> python-ideas@python.org> wrote:
>
>> It seems to me that it would be useful to be able to make the str.join()
>> function put separators, not only between the items of its operand, but
>> also optionally at the beginning or end.
>> E.g. '|'.join(('Spam', 'Ham', 'Eggs')) returns
>> 'Spam|Ham|Eggs'
>> but it might be useful to make it return one of
>> '|Spam|Ham|Eggs'
>> 'Spam|Ham|Eggs|'
>> '|Spam|Ham|Eggs|'
>>
>
> Compare these two lines:
>
> '\n'.join(lines) + '\n'
> '\n'.join(lines, atEnds=1)
>
>
>
> The first is not only shorter, it's more clear what it's doing. I'd have
> to look up everytime to remember whether the value atEnds=1 is doing the
> right thing. It's just IMHO not valuable enough for the cost. Not every
> potential optimization is worth including in the core language or the
> stdlib (if this even is an optimization).
>
> I don't think your comparison is fair.
> If the second one were written
> '\n'.join(lines, 1)
> it would be shorter. And if it were spelt
> '\n'.join(lines, 'e') # s for at Start, e for at End, b for Both
> which I now think is preferable, it would still be shorter and you
> probably wouldn't need to look it up.
> And when it comes to examples like
> return policy.linesep.join(lines) + policy.linesep
> return policy.linesep.join(lines, 'e')
> it would save even more characters and very likely be (more of) an
> optimisation.
>
> Ben mentions being able to specify if a terminal separator is wanted when
> the list is empty. That is an idea which I think is worth considering.
> How about:
> 'S' = always add a separator at start
> 's' = add a separator at start unless the list is empty
> 'E' = always add a separator at end
> 'e' = add a separator at end unless the list is empty
> with these combinations being allowed:
> 'se, 'SE', 'Se', 'sE'
> (the last two would have the same effect, but the difference in emphasis
> might clarify the author's thought).
> If nothing else, this would push authors into thinking about the empty
> list case, rather than being sloppy about it as Ben suspects in one or two
> cases.
>
> Best wishes
> Rob Cliffe
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UXPYKBZL7Z2XQUH2DWXPT5A3QVCLUOAT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IQHXPDJMRCYNEYPILSCBN3UW7GP5E64Q/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Delete dictionary entry if key exists using -= operator via __isub__()
You could use the pop method on dictionary (with a default value of None
for example) to remove the key only if it exists.
The method returns the value associated with this key but you can ignore it.
I'm not sure the __isub__ implementation would be easy to understand as
it's weird to make a subtraction between a dict and a str. Even sets only
support subtraction between sets.
(Also you have Counter objects from collections module that implement a
kind of subtraction between dicts)
Le jeu. 28 avr. 2022 à 15:19, a écrit :
> *Background*
> It is frequently desirable to delete a dictionary entry if the key exists.
> It is necessary to check that the key exists or, alternatively, handle a
> KeyError: for, where `d` is a `dict`, and `k` is a valid hashable key, `del
> d[k]` raises KeyError if `k` does not exist.
>
> Example:
> ```
> if k in d:
> del d[k]
> ```
>
> *Idea*
> Use the `-=` operator with the key as the right operand to delete a
> dictionary if the key exists.
>
> *Demonstration-of-Concept*
> ```
> class DemoDict(dict):
> def __init__(self, obj):
> super().__init__(obj)
>
> def __isub__(self, other):
> if other in self:
> del self[other]
> return self
>
>
> if __name__ == '__main__':
> given = {'a': 1, 'b': 2, 'c': 3, 'd': 4}
> demo = DemoDict(given)
> demo -= 'c'
> assert(demo == {'a': 1, 'b': 2, 'd': 4})
> ```
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BBFALX57PJI4ALF4O6YGYMHMLNL4U4YI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NUAZIYUFTGMIWIBORQQOKEO63HWK2XRW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
> And, on top of that, the actual change needed to switch from today's solution to adoption is extremly simple. > replace > ``` > class A(B,C): ... > ``` > with > ``` > class A(B(C)): ... > ``` > That's it. `class A(B(C))` is already a valid Python syntax (for example you could use `class A(namedtuple(...))`), your change to add a specific meaning to this syntax would break existing code. Le mar. 12 avr. 2022 à 23:22, Eric V. Smith a écrit : > On 4/12/2022 12:57 PM, malmiteria wrote: > > So the amount of actual breakings left shouldn't be enough to justify > denying this feature IMO. Again, we'll have a clearer view on that once we > get experimental data. > > What's to look for is usage of super in MI cases, since each super call > in MI today should be replaced by one super call per parent, in my proposal. > > If this turns out to be an issue, we can try to imagine solution for it. > Maybe a solution such as : super calls implicitely run a super call to each > parent when there's multiple parent, and super isn't given arguments. This > i think would behave strictly as today's super + MRO, except for cases > where one class appears multiple time in an inheritance tree. > > The last breaking change would be that scenario, class appearing > multiple time in an inheritance tree. > > And we're getting on even rarer occasions here, but again, we can think > of solutions here. > > I have code in a non-public repository that your proposed change will > break. I'm sure I'm not the only one. It is not realistic to implement a > change like this that will break code and then say "there's a workaround > that you'll need to implement". Especially for library code that needs > to run across multiple python versions. > > > As much as i understand we don't want breaking change, i don't think it > is *that* strong an argument, in this case. > > And, on its own, breaking changes aren't a strict veto, there's been > some, and there's gonna be more. > > As a long-time core developer, I can assure you that this is one of > those cases where a breaking change will not be allowed. I'm trying to > save you some time here, but if you're committed to continuing this, > then you can't say you weren't warned when it's ultimately rejected. My > suggestion is to rework your proposal to not break any existing code. > It's a constraint we've all had to live with at one time or another, as > much as we don't like it. > > Eric > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/KWXDZBGZBX3LLCP3FQ33T27YUXDKXXL5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XWL6V6ACH4M2OZTDBVZ5TY777IFB5I75/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
If these examples were possible (I wouldn't say they are smart designs)
they would lead to recursion errors.
Limitations on MRO are good, they force to keep a quite simple structure.
Le jeu. 7 avr. 2022 à 17:41, malmiteria a écrit :
> Antoine Rozo writes:
> > If the only feature you need from super is the proxy one, why don't you
> > code your own parent-proxy-type?
>
> I did :
> https://github.com/malmiteria/super-alternative-to-super/blob/master/parent.py
>
> This is irrelevant to the discussion we're having i think.
> Essentially, I'm arguing against today's state of some edge case of MRO +
> super, and against the UX associated with it.
> Those are issues with today's python, and the update that i propose would
> reduce the UX problems with super and MRO, would allow for use case of
> super more in line with the expectation of the majority, and would open the
> door to a few cases locked behind MRO errors today.
> Technically, with my proposal, you could even do circular inheritance,
> which is definitely unheard of today:
> ```
> class Day:
> def tell_time(self):
> print("it's daytime")
> sleep(1)
> super().tell_time()
>
> class Night(Day):
> def tell_time(self):
> print("it's night time")
> sleep(1)
> super().tell_time()
>
> Day.__bases__ = (Night, )
>
> Day().tell_time() # infinitely loops over "it's daytime" and "it's night
> time"
> ```
> That would be an incredibely easy way to articulate process that repeat in
> a cycle, with no end, cron style.
> No need to get multiple class too:
> ```
> class CronTask:
> def task(self):
> # do something
> time.sleep(1)
> super().task()
>
> CronTask.__bases__ = (CronTask, )
>
> CronTask().task() # runs the task forever with a time sleep in between
> ```
>
> I'm convinced there's some smart designs that are banned from python
> because of MRO and super's limitations.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BKFSLLICTCAYBPIZBTVW4Y4OPT3UKBZ2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NFHV3F2ELGZ6EW6QHDNOQGLZHNHJ54HH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: mro and super don't feel so pythonic
> > > Chris Angelico writes: > > I'm curious when you would ever be subclassing something from another > > library without knowing its hierarchy. > This is common in Django. > > > Stephen J. Turnbull writes: > > One really plausible example is given in Raymond's piece: a later > > version of the same library refactors a "monolithic" class as a child > > of one or more "private" classes that are not intended to be exposed > > in the public API, but your multiply-derived class *written before the > > refactoring* Just Works. As far as I can see, super(), and maybe even > > the deterministic MRO, is needed to make that work. > I'm curious about this exemple, do you have a link to share so i could > have a look at the code / change in code? This could be a good exercice. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/LRKJNN7RQUEYURNZZTSRDDXBEJQO5AMA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BETUQI4NEOCPQNX6PN23QITFLVNK5RZK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8
One other solution is to use a `yield from` with an empty iterable, then you don't need to have an unreachable `yield`. Le ven. 3 sept. 2021 à 09:52, Serhiy Storchaka a écrit : > > 03.09.21 10:28, Thomas Grainger пише: > > the way to make an (aysnc)generator that immediately raises > > Stop(Async)Iteration immediately is to insert an unreachable `yield` > > statement, however there's two ways to do it: > > I think it is too uncommon case to specify it in PEP 8. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/M4TIXVDUNKPCHJUR5DNB5QLBYXC5JCWC/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NDQDM6KJOCHTADZJEV3CGEMJJKKDD4ZK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: staticmethod with property
Properties couldn't work with static methods as they need to access the instance or its type. And properties are not class-properties by design, because you may want to access directly to the fields of the property object. But you can define your own descriptor type to make a kind of class-property (read-only). Le mer. 25 août 2021 à 01:56, Henry Harutyunyan a écrit : > > Currently Python does not support using `@staticmethod` decorator along with > `@property` decorator. > I think that the it currently works is a bit misleading since it will not > give an error, but gives the following outcome. > > ``` > class Foo: > @staticmethod > @property > def bar(): > return "1" > ``` > > ``` > class Foo: > @property > @staticmethod > def bar(): > return "1" > ``` > > In wither of the cases the outcome is the following > > ``` > Foo.bar > >>> > > a = Foo() > a.bar > >>> > ``` > > Is there any particular reason for this? Any don't we make it work? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/M45PDOVAKJPFI55JUM3QREW3OYMW7NF5/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3RMJ6YS4KOTT5OZGBKA5D5JWEEVCNOAH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Getting rid of FOR loops and simplifying cicular conviolutions with Circular Indexing
e folded into a cylinder for indexing. Further this cylinder >> can be folded into a toroid to reduce a triple FOR loop to a single FOR >> loop. A deep mathematical justification for cylindrical indexing of 2D and >> in general nD arrays is offered by the fact that n-dimensional DFT reduces >> n-dimensional circular convolution to element-wise multiplication. >> >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/5TJYKFLBHB26WEFFQXMY6AGWS34XTIUR/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > > CALVIN SPEALMAN > > SENIOR QUALITY ENGINEER > > cspea...@redhat.com M: +1.336.210.5107 > [image: https://red.ht/sig] <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/RRW5ZMPRJBOYATS7U2N7SGAWRYSNF4NY/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ER3QN4ATKKNHOHCD35ZIKXGRNOCUE44M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Getting rid of FOR loops and simplifying cicular conviolutions with Circular Indexing
So why don't you implement your own type/wrapper with the semantics you need? Le mer. 25 nov. 2020 à 18:49, Mathew M. Noel via Python-ideas a écrit : > > If circular indexing is used then instead of using a double FOR loop to go > through a list M times we can iterate from 0 to M*N (where N is the length of > the list) !!! > > > Almost all Machine Learning (ML) algorithms iterate for some predefined > epochs over a large data-set. So a double FOR loop is extremely common in ML. > Using circular indexing gets rid of this extra FOR loop. If we have to > iterate 2 times you can iterate using range(-n,n) but in most cases you need > to iterate over 10 or more epochs in ML. > > > Most scientific applications of Python involve an outer FOR loop which > progressively refines an approximation with an inner FOR loop by going > through a list of items. So circular indexing is useful. In the following I > discuss increasingly compelling reasons for adopting a circular indexing > scheme in Python. > > > Python uses an index of -1 to index the last element in a list. Since -1 > occurs before 0 we might think of the elements of the linear list are being > bent into a circle making the last element occur before the 0th element. > Consider a list with n elements: it would be perfectly reasonable to address > the element 0 of the list using an index of n since n occurs after n-1 (if we > assume that the list is bent into a circle). This feature can prove to be > extremely useful. Consider the following example: > > > days_of_the_week = > ["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"] > > It would be nice if > > days_of_the_week[0] > > is the same as > > days_of_the_week[7] > > is the same as > > days_of_the_week[14] etc > > In other words use modular indexing. In other words if the index is outside > the range 0 to n-1, we simply take the remainder when the index is divided by > n as the index. > Because of the close relationship between finite length sequences and > periodic sequences this feature might simplify scientific computing(circular > convolution etc). > > If circular indexing is used then we don't need the arbitrary rule that -1 is > the index of the last element. Since -1 is the same as n-1 automatically in > modular arithmetic. > > > A trivial objection: "why not use list_name[i%n] whenever we need this > feature?" By the same token we could do away with negative indices and use > -1%n for example when we need to index with -1! > > > Its unclear why that people have an irrational preference for indices that > lie to the left of 0 while strongly rejecting the idea of indices that lie to > the right of n-1! > > Python does not raise a "index out of bound" exception for negative indices > like other programming languages. If this negative indexing is a "feature" > (although it allows some fatal errors to slip) then indices above n-1 can > also be considered a feature! > > Are there any deep mathematical reasons for adopting circular convention? > Circular convolution is a most important operation in a wide variety of > scientific disciplines since the Discrete Fourier Transform (DFT) of the > circular convolution of two signals is the product of the transforms. Because > of the universal applicability of Fourier ideas in science and the close > mathematical relationship between finite length and periodic sequences > circular indexing is extensively used in signal processing and mathematics. > > We can extend the idea of circular indexing to multidimensional arrays. A 2D > array can be folded into a cylinder for indexing. Further this cylinder can > be folded into a toroid to reduce a triple FOR loop to a single FOR loop. A > deep mathematical justification for cylindrical indexing of 2D and in general > nD arrays is offered by the fact that n-dimensional DFT reduces n-dimensional > circular convolution to element-wise multiplication. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/5TJYKFLBHB26WEFFQXMY6AGWS34XTIUR/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/64CU3BMLW5FSYD23NSIPUY2JEE6GDOAK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
And if you can't / don't want to create new lists for the values you
want to compare, a solution could be to use zip & all builtins:
print(all(a == b for a, b in zip(tuple_, list_)))
Le sam. 2 mai 2020 à 16:58, Steele Farnsworth a écrit :
>
> You can get the desired behavior by casting a list to a tuple, or a tuple to
> a list, in the equality statement. That way those that rely on the existing
> implementation don't have to change their code.
>
> my_tup = (1, 2, 3)
> my_list = [1, 2, 3]
> print(list(my_tup) == my_list)
>
> On Sat, May 2, 2020, 9:04 AM Ahmed Amr wrote:
>>
>> I'd like to take your opinion on modifying some of the indexed collections
>> like tuples, lists, arrays to evaluate its equality to True when having the
>> same items in the same indexes.
>> Currently, when comparing a list of items to an array of the same items for
>> equality (==) it returns False, I'm thinking that it would make sense to
>> return True in that context, as we're comparing item values and we have the
>> same way of indexing both collections, so we can compare item values.
>>
>> So what do you think about applying such behavior on collections that can be
>> indexed the same way such as tuples, lists, and arrays?
>>
>> Example: (Current)
>>
>> import array
>> tuple_ = (1.1, 2.2, 3.3)
>> list_ = [1.1, 2.2, 3.3]
>> array_ = array.array('f', [1.1, 2.2, 3.3])
>>
>> # all of the following prints False.
>> print(tuple_ == list_)
>> print(tuple_ == array_)
>> print(array_ == list_)
>>
>> Example: (Proposed):
>> All prints above to show True as they are populated with the same data in
>> the same indexes.
>>
>> A Side Note:
>> An extra point to discuss, based on arrays implementation, array_.to_list()
>> would actually get [1.10023841858, 2.20047683716, 3.29952316284]
>> which is not exactly what we've passed as args and this is normal, but I'm
>> thinking about leaving it to the array implementation to encapsulate that
>> implementation and perform exact equality based on passed arguments.
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/UE5HGECRTS3ERK5OMG3GB77EKSAFJV7R/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/NPEIUL3A7JYPFTDLVLOOENT5UXFYJKUT/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JKFATHEGVF4JPHTPYJJNPPB44DY5D72F/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SQL string prefix idea
Like PEP-501 https://www.python.org/dev/peps/pep-0501/ ? Le ven. 21 févr. 2020 à 15:28, Jonathan Fine a écrit : > > Hi > I like the problem, but not the solution suggested. > -- > Jonathan > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/ZQLRODALCDEBTFDYICNZZR3SSI2DICG3/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WFYOO247PYWQNQW5CGOTVVBFBBLGCYCJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal: Complex comprehensions containing statements
> Would you feel better if `yield` was always required? Yes but then it's the same as defining a generator-function. > For almost all the examples I've provided a corresponding equivalent in the > current syntax, so are you saying that you're still confused now or that you > can't figure it out until you look at the 'answer'? I think it's ambiguous, like in this example: clean = [ for line in lines: stripped = line.strip() if stripped: stripped ] what says that it's the last stripped that should be yielded? > If that function is the whole statement and there is no other expression > statement in the comprehension, it will be yielded. I can't tell if there's > more to your question. Imagine this one: foo = [ for x in range(5): f(x) if x % 2: x ] what will be the result? [f(x) for x in range(5)]? [x for x in range(5) if x%2]? [x if x%2 else f(x) for x in range(5)]? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3YLKX24UR2CCSKY2UWQHLAMVKSR3BX5P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal: Complex comprehensions containing statements
> creates an uncomfortable grey area where it's hard to decide between > squeezing maybe a bit too much into an expression or doing things 'manually'. > This can lead to analysis paralysis and disagreements between coders and > reviewers. For example, which of the following is the best? > > clean = [ > line.strip() > for line in lines > if line.strip() > ] > > stripped = [line.strip() for line in lines] > clean = [line for line in stripped if line] > > clean = list(filter(None, map(str.strip, lines))) > > clean = [] > for line in lines: > line = line.strip() > if line: > clean.append(line) > > def clean_lines(): > for line in lines: > line = line.strip() > if line: > yield line > > clean = list(clean_lines()) > > You probably have a favourite, but it's very subjective and this kind of > problem requires judgement depending on the situation. For example, I'd > choose the first version in this case, but a different version if I had to > worry about duplicating something more complex or expensive than `.strip()`. > And again, there's an awkward sweet spot where it's hard to decide whether I > care enough about the duplication. > > What about assignment expressions? We could do this: > > clean = [ > stripped > for line in lines > if (stripped := line.strip()) > ] > > Like the nested loops, this is tricky to parse without experience. The > execution order can be confusing and the variable is used away from where > it's defined. Even if you like it, there are clearly many who don't. I think > the fact that assignment expressions were a desired feature despite being so > controversial is a symptom of this problem. It's the kind of thing that > happens when we're stuck with the limitations of a single expression. > > The solution with the new syntax is: > > clean = [ > for line in lines: > stripped = line.strip() > if stripped: > stripped > ] > > or if you'd like to use an assignment expression: > > clean = [ > for line in lines: > if stripped := line.strip(): > stripped > ] > > I think both of these look great and are easily better than any of the other > options. And I think it would be the clear winner in any similar situation - > no careful judgement needed. This would become the one (and only one) obvious > way to do it. The new syntax has the elegance of list comprehensions and the > flexibility of multiple statements. It's completely scalable and works > equally well from the simplest comprehension to big complicated constructions. > > ### Easy to change > > I hate when I've already written a list comprehension but a new requirement > forces me to change it to, say, the `.append` version. It's a tedious > refactoring involving brackets, colons, indentation, and moving things > around. It also leaves me with a very unhelpful `git diff`. With the new > syntax I can easily add logic as I please and get a nice simple diff. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/5UIXE23B26XPIQGPYNI575XN3NNX6JRR/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VUPTDIVHZ5TINEYBQCFCPYZNK2DFYBU3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Binary module.
What is 110011 here? A number written in decimal where you want to interpret digits as binary digits? Why don't you use 0b110011 to have a litteral written in binary representation? Le dim. 16 févr. 2020 à 16:32, a écrit : > > I'll show the example using one's and two's complement. > >>binary.ones_complement(110011) > 001100 > >>binary.twos_complement(110011) > 001101 > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/RJLGYE4N7NR6JYFSA64VES375U45PIKW/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JTVV74CXKBOZJ4REKXWQWU4WGEXSNDGJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Binary module.
And what do you call "decimal numbers"? Decimal representation of numbers like returned by str(123456)? Le dim. 16 févr. 2020 à 15:00, Mark Dickinson a écrit : > > ananthakrishnan15.2001＠gmail.com wrote: > > In the below examples a and b are binary numbers. > > Please can you clarify what this means, in Python terms? Are you proposing a > _new_ Python type that represents a "binary number", or is `binary.add` (for > example) intended to work with existing Python types (for example `int` and > `str`)? > > Who are the intended users of the new functionality, and what would they use > it for? Could you perhaps show some example code that might use the module? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/VGPNG4IBWGRWPEQOAKCNTLBINWQS4BZO/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4AZ3E4BFMGPJABJ7Q4HHH6GFJTBJM5M7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Annotated string literals
Why don't you define a LOCALIZE function (x → x) like in your C example?
Le lun. 3 févr. 2020 à 13:01, Soni L. a écrit :
>
>
>
> On 2020-02-02 11:29 p.m., Eric V. Smith wrote:
> > On 2/2/2020 8:28 PM, Soni L. wrote:
> >> It'd be cool to attach metadata to string literals that doesn't end
> >> up in the resulting string object. This metadata could be used by all
> >> sorts of tools, everything from localization to refactoring.
> >>
> >> In C, some localization libraries use macros for it, such as:
> >>
> >> #define LOCALIZE(s) s
> >>
> >> and it acts like an annotation, and then you do:
> >>
> >> printf("%s", get_localized(locale, LOCALIZE("This string gets
> >> extracted and used in language files")));
> >>
> >> And I think Python could do better and have special string literals
> >> explicitly for this purpose.
> >>
> >> It could even be something with fstrings, like: f"{#localize}This
> >> string gets extracted and used in language files"
> >>
> >> Ofc, there's nothing preventing one from using something like
> >> f"{(lambda _:'')('localize')}This string gets extracted and used in
> >> language files" today, but I feel like having some sort of dedicated
> >> syntax for it would be an improvement.
> >
> > You might want to look at PEP 501.
> >
> > Eric
>
> Oh. No, I want it to return plain strings.
>
> e.g. you should be able to replace an existing
>
> MY_STRING = "This string gets extracted and used in language files"
>
> with
>
> MY_STRING = [uhh idk what would go here tbh]
>
> and maintain full backwards-compatibility.
>
> It's for external tools to consume, not for python code to consume.
>
> >
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-ideas@python.org/message/GEBY52WVQBFB7J27MRJPZZPJMWUZZJWO/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/HY6N3CA2FEJL5EGY5QWJHBLP5KVETTD3/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/DGSVOSOXX4RS4M2JA4NBE5LGKUMJDCE2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The "When" Keyword
Hi, Adding a new keyword will break many code because "when" would be a new reserved word, and may currently be used as a variable name. Also, "when" is not an equivalent of "if", it has a time-related connotation. If I see a "when" keyword in a code, I will think that the body will be executed later, when the expression will be true. Regards, Le dim. 29 déc. 2019 à 19:29, Abdur-Rahmaan Janhangeer a écrit : > > Greetings list, > > I was wondering if adding the When keyword is a good idea. > Normally every when is theoretically an if as you can't be sure if the event > will 100% come to pass. > > if x == 5: > ... > else: > ... > > However, we use the when keyword in normal language. When you reach home, > phone me. When you pass this avenue, turn right etc. Using it in programming > might convey the intent of the programmer. > > when x == 5: > ... > else: > ... > > which still sells the idea of maybe if but hints away the expectation of the > author. > > Yours, > > Abdur-Rahmaan Janhangeer > pythonmembers.club | github > Mauritius > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3VOQUSHPYTKLL65V6BUN4MMKKJOXCIKO/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Antoine Rozo ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JGWIQPG5VVHVJC2SLJEKD5WZM32W7GC2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)
I think the small time difference you noticed is only due to method lookup.
Le mar. 3 déc. 2019 à 13:57, Kyle Stanley a écrit :
>
> > Actually there's no need to optimize the |= operator -- for strings we have
> > to optimize += *because* strings are immutable, but for dicts we would
> > define |= as essentially an alias for .update(), just like the relationship
> > between += and .extend() for lists, and then no unnecessary objects would
> > be created.
>
> Yeah that's why I noted that any form of optimization for the |= operator on
> dicts would not be the same as += is for strings. I wasn't actually sure of
> what form any potential optimization would take for the |= operator though.
> What exactly was the performance question/point in reference to? The question
> seemed to imply that there would be some minor performance detriment from
> using |=, but it's not clear to me as to when that would be a factor.
>
> > ## What about performance?
>
> > Performance is not the only objective when using Python. Switching to
> > inplace operators (here |=) is a generally useful and well-known technique
> > (it also applies to string and list concatenation, for example).
>
> Also with lists, I recall that using the += operator is very slightly faster
> than list.extend() in most situations:
>
> >>> ls_plus_eq = """\
> for i in range(1_000):
> ls += [x for x in range(10)]
> """
> >>> ls_extend = """\
> for i in range(1_000):
> ls.extend([x for x in range(10)])
> """
> >>> timeit.timeit(ls_plus_eq, setup="ls = []", number=10_000)
> 6.563132778996078
> >>> timeit.timeit(ls_extend, setup="ls = []", number=10_000)
> 6.695127692000824
> >>> timeit.timeit("ls+=other", setup="ls = []; other=[i for i in
> >>> range(100_000)]", number=10_000)
> 4.400735091003298
> >>> timeit.timeit("ls.extend(other)", setup="ls = []; other=[i for i in
> >>> range(100_000)]", number=10_000)
> 4.574331789997814
> >>> timeit.timeit("ls+=other", setup="ls = []; other=[i for i in
> >>> range(100)]", number=10_000_000)
> 3.5332175369985634
> >>> timeit.timeit("ls.extend(other)", setup="ls = []; other=[i for i in
> >>> range(100)]", number=10_000_000)
> 3.7756526679950184
>
> (Python 3.8)
>
> It seems to be a difference of only ~2-4% in most cases (~6-7% with the last
> set), but I find it interesting that += is barely faster. Of course, some of
> the above examples are fairly unrealistic, for most practical use cases
> they're essentially the same. I tend to prefer ls.extend() most of the time
> myself (the behavior is a bit more obvious). I'm mostly just curious if the
> difference between |= and dict.update() would end up being similar as far as
> performance goes, with |= having a negligible advantage over dict.update() in
> most situations.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/243KH67NWORPWGR75D3ZWRNGKUPRWG5F/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/O63JWBV2L6WQTFVTWWKOVPPCXVLXKNQL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Additional meanings for "in" operator and ability to customize implementation
Hello,
For your last example you have the __contains__ special methods.
Le dim. 13 oct. 2019 à 15:18, Steve Jorgensen a écrit :
> Note that I'm new to this system, so I'm not sure if this will format
> correctly or whether I'll be able to edit it afterward to format it
> properly if not. Fingers crossed.
>
> Examples:
> import re
> from collections import Sequence
>
> # Equivalent of re.compile(r'b.d').search()
> re.compile(r'b.d') in 'abcdef' # -> <_sre.SRE_Match object; span=(1,
> 4), match='bcd'>
> re.compile(r'b.d') in 'xyz' # -> None
>
> # Equivalent of isinstance([1, 2], Sequence)
> [1, 2] in Sequence # -> True
>
> class BrightColorsMeta(type):
> def __rin__(self, other):
> other.startswith('bright ')
>
> class BrightColors(metaclass=BrightColorsMeta): pass
>
> 'red' in BrightColors # -> False
> 'bright blue' in BrightColors # -> True
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LOWRX42JL3SWG4QSOMV3WX4SOLJBXPXV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/7XV6HPKUYRFZ5XC5RFFBWBGNB54PD3AL/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] ternary without else
Dismiss my message, I have read `if "art_wt" not in article`. But in the same way, you could have a function to reset a value in your dict if the current value evaluates to False. 2018-05-26 11:21 GMT+02:00 Antoine Rozo <antoine.r...@gmail.com>: > > if not article["art_wt"]: article["art_wt"] = 0 > > if not article["px_pchs"]: article["px_pchs"] = 0 > > if not article["px_calc"]: article["px_calc"] = 0 > > if not article["px_sell"]: article["px_sell"] = 0 > > I think what you need is the setdefault method of dictionnaries, instead > of a new syntax construct. > > 2018-05-26 1:52 GMT+02:00 Carl Smith <carl.in...@gmail.com>: > >> You cannot have `expression if expression` in a language that also >> supports >> `expression if expression else expression` (like Python). Otherwise, you >> have >> the dangling else problem: >> >> https://en.wikipedia.org/wiki/Dangling_else >> >> -- Carl Smith >> carl.in...@gmail.com >> >> On 25 May 2018 at 15:21, Rob Cliffe via Python-ideas < >> python-ideas@python.org> wrote: >> >>> >>> >>> On 25/05/2018 12:38, Steven D'Aprano wrote: >>> >>>> >>>> PEP 8 is not holy writ. Ignore it when your code is better for ignoring >>>> it. >>>> >>>> >>>> +1. Not infrequently I judge that my code is easier both to read and >>> to maintain with more than 1 (short) statement on a line, >>> often when it allows similar items to be aligned vertically. A >>> spur-of-the moment, totally invented example: >>> if MON <= day <= FRI:Rate = Normal >>> if day==SAT: Rate = DoubleTime >>> if day==SUN:Rate = TripleTime >>> I also feel no inhibitions about using Jacco's original example: >>> if cond: do_something >>> Rob Cliffe >>> >>> ___________ >>> Python-ideas mailing list >>> Python-ideas@python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> > > > -- > Antoine Rozo > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] ternary without else
> if not article["art_wt"]: article["art_wt"] = 0 > if not article["px_pchs"]: article["px_pchs"] = 0 > if not article["px_calc"]: article["px_calc"] = 0 > if not article["px_sell"]: article["px_sell"] = 0 I think what you need is the setdefault method of dictionnaries, instead of a new syntax construct. 2018-05-26 1:52 GMT+02:00 Carl Smith <carl.in...@gmail.com>: > You cannot have `expression if expression` in a language that also > supports > `expression if expression else expression` (like Python). Otherwise, you > have > the dangling else problem: > > https://en.wikipedia.org/wiki/Dangling_else > > -- Carl Smith > carl.in...@gmail.com > > On 25 May 2018 at 15:21, Rob Cliffe via Python-ideas < > python-ideas@python.org> wrote: > >> >> >> On 25/05/2018 12:38, Steven D'Aprano wrote: >> >>> >>> PEP 8 is not holy writ. Ignore it when your code is better for ignoring >>> it. >>> >>> >>> +1. Not infrequently I judge that my code is easier both to read and to >> maintain with more than 1 (short) statement on a line, >> often when it allows similar items to be aligned vertically. A >> spur-of-the moment, totally invented example: >> if MON <= day <= FRI:Rate = Normal >> if day==SAT: Rate = DoubleTime >> if day==SUN:Rate = TripleTime >> I also feel no inhibitions about using Jacco's original example: >> if cond: do_something >> Rob Cliffe >> >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow additional separator character in variables
What will the hyphen bring to what is already allowed with underscore? It is not possible to break compatibility with '-' character. 2017-11-19 3:01 GMT+01:00 Mikhail V <mikhail...@gmail.com>: > Python allows underscore character as a separator in variables. > This is better than nothing, still it does not make the look much better. > > **Proposal**: allow additional separator, namely hyphen character. > > **Benefits**: this should provide significant readability improvement. > Compared to most syntax change proposals that I remember till now, > this seems to have really tangible benefits. So all in all I see it as > a significant > language improvement. > Besides its direct benefit as a good looking separator, it also gives > an opprtunity > to reduce "camelCase" or similar ugly inclusions in code. > > So one can easily compose human-readable variable names e.g.: > my-variable > figure-shape---width > etc. > > **Problem**: currently hyphen character is used as a minus operator! > The problem is as old as the history of most programming languages, > and inherited from initial poorness of character sets. > Therefore I don't see a single optimal solution to this. > > Possible solutions: > > Solution 1: > Use another similar looking character from unicode, > for example: U+02D7 (modifier letter minus sign). > At the same time IMO it is needed to allow the minus character > for the minus operator, namely U+2212 Minus sign. This will > allow proper typography of source code. > Main benefit of such approach: no breakage of current code base, > since new chars are additional to existing ones. > > Solution 2: (radical) > Disallow hyphen as minus operator, and use only U+2212 Minus sign. > I.e. "a-b" would be a variable and "a − b" a minus operation. > Advantage: opportunity to correct the improper character usage once and > for all. > Disadvantage: breakage of current code base + force UTF-8 storage use > (consider > e.g. editors without unicode support). > Thus most probably such solution will cause howl reaching to the sky among > users, despite many modern editors allow unicode and custom operator > styling, > for example to distinguish dash from hyphen in a monospaced editor. > > So is my proposal, and as usual urging for constructive conversation. > (i.e. proposing to write own language/translator is not constructive > conversation) > > > Cheers, > Mikhail > _______ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] install pip packages from Python prompt
Hi,
What would be the difference with current pip module?
pip.main(['install', 'some_package'])
2017-10-29 20:26 GMT+01:00 Alex Walters <tritium-l...@sdamon.com>:
> I have a somewhat better, imo, implementation of a pip object to be loaded
> into the repl.
>
>
>
> class pip:
>
> def __call__(self, *a, **kw):
>
> sys.stderr.write(str(self))
>
>
>
> def __repr__(self):
>
> return str(self)
>
>
>
> def __str__(self):
>
> return “Please run pip from your system command prompt”
>
>
>
>
>
>
>
> *From:* Python-ideas [mailto:python-ideas-bounces+tritium-list=sdamon.com@
> python.org] *On Behalf Of *Stephan Houben
> *Sent:* Sunday, October 29, 2017 3:19 PM
> *To:* Python-Ideas <python-ideas@python.org>
> *Subject:* [Python-ideas] install pip packages from Python prompt
>
>
>
> Hi all,
>
> Here is in somewhat more detail my earlier proposal for
>
> having in the interactive Python interpreter a `pip` function to
>
> install packages from Pypi.
>
> Motivation: it appears to me that there is a category of newbies
>
> for which "open a shell and do `pip whatever`" is a bit too much.
>
> It would, in my opinion, simplify things a bit if they could just
>
> copy-and-paste some text into the Python interpreter and have
>
> some packages from pip installed.
>
> That would simplify instructions on how to install package xyz,
>
> without going into the vagaries of how to open a shell on various
>
> platforms, and how to get to the right pip executable.
>
> I think this could be as simple as:
>
> def pip(args):
> import sys
> import subprocess
> subprocess.check_call([sys.executable, "-m", "pip"] + args.split())
>
> print("Please re-start Python now to use installed or upgraded
> packages.")
>
> Note that I added the final message about restarting the interpreter
>
> as a low-tech solution to the problem of packages being already
>
> imported in the current Python session.
>
> I would imagine that the author of package xyz would then put on
>
> their webpage something like:
>
> To use, enter in your Python interpreter:
>
> pip("install xyz --user")
>
> As another example, consider prof. Baldwin from Woolamaloo university
>
> who teaches a course "Introductory Python programming for Sheep Shavers".
>
> In his course material, he instructs his students to execute the
>
> following line in their Python interpreter.
>
>pip("install woolamaloo-sheepshavers-goodies --user")
>
> which will install a package which will in turn, as dependencies,
>
> pull in a number of packages which are relevant for sheep shaving but
>
> which have nevertheless irresponsibly been left outside the stdlib.
>
> Stephan
>
>
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
--
Antoine Rozo
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add a module itertools.recipes
I am not searching for an external library (as I pointed, there are some on PyPI like iterutils or more-itertools). My point was that recipes are documented in itertools module, but not implemented in standard library, and it would be useful to have them available. 2017-10-13 20:35 GMT+02:00 Chris Angelico <ros...@gmail.com>: > On Sat, Oct 14, 2017 at 5:16 AM, Antoine Rozo <antoine.r...@gmail.com> > wrote: > > Hello, > > > > A very useful part of the itertools module's documentation is the section > > "Recipes", giving utility functions that use itertools iterators. > > But when you want to use one of theese functions, you have to copy it in > > your source code (or use external PyPI modules like iterutils). > > > > Can we consider making itertools a package and adding a module > > itertools.recipes that implements all these utilility functions? > > Check out more-itertools on PyPI - maybe that's what you want? > > ChrisA > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add a module itertools.recipes
Hello, A very useful part of the itertools module's documentation is the section "Recipes", giving utility functions that use itertools iterators. But when you want to use one of theese functions, you have to copy it in your source code (or use external PyPI modules like iterutils). Can we consider making itertools a package and adding a module itertools.recipes that implements all these utilility functions? Regards. -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Make map() better
> And for that matter, why isn't append/extend a global? I can add things
to lots of different collections. lists, sets, strings...
No, append is relevant when the collection is ordered. You update
dictionnaries, you make unions of sets, and you append lists to another
ones.
These operations are specific for each datatype.
And not all iterables need operations to append new elements.
But you can chain generic iterables (with itertools.chain).
2017-09-15 16:21 GMT+02:00 Jason H <jh...@gmx.com>:
> I'm going to respond to a few replies with this one.
>
> > > Because join apply on a string, and strings are defined by the str
> class,
> > > not by a specific protocol (unlike iterables).
> >
> > Join actually used to only be available as a function (string.join in
> > Python 2.x). However, nobody could ever remember whether the parameter
> > order was "join this series of strings with this separator" or "use
> > this separator to join this series of strings" - it didn't have the
> > same kind of natural ordering that map and filter did thanks to the
> > old "apply" builtin ("apply this function to these arguments" - while
> > the apply builtin itself is no longer around, the "callable(*args,
> > **kwds)" ordering that corresponds to the map() and filter() argument
> > ordering lives on).
> >
> > This meant that when string.join became a builtin interface, it became
> > a string method since:
> >
> > 1. Strings are one of the few Python APIs that *aren't* protocol
> > centric - they're so heavily intertwined with the interpreter
> > implementation, that most folks don't even try to emulate or even
> > subclass them*.
> > 2. As a string method, it's obvious what the right order has to be
> > (separator first, since it's the separator that has the method)
>
> Your second point is aligned with my initial point. Providing it as a
> class method further removes the ambiguity of what the right order is
> because of there is only one parameter: the function.
>
> As for the comment about Python being better designed, I never implied it
> wasn't. Python is my favorite. However as someone who uses multiple
> languages, and JS has risen in popularity, and it's not going anywhere, I
> seek a more peaceful co-existence with this language - a language that was
> designed in 10 days in 1995. In a covert way, by embracing some of the
> not-too-terrible syntax you make it easier for JS programmers to feel at
> home in Python, and adopt it. I see this only has promoting a peaceful
> coexistence.
>
> Another pain point is python uses [].append() and JS uses [].join() Having
> a wrapper for append would be helpful.
>
> And for that matter, why isn't append/extend a global? I can add things to
> lots of different collections. lists, sets, strings...
>
>
>
>
>
--
Antoine Rozo
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Make map() better
> Why? I can iterate over a string. [c for c in 'abc'] It certainly behaves
like one... I'd say this is inconsistent because there is no __iter__() and
next() on the str class.
Yes, strings are iterables. You can use a string as argument of str.join
method.
But only strings can be used as separators, so there is non need for a
generic join method for all types of separators.
Python is well designed, you are just not used to it
2017-09-14 21:31 GMT+02:00 Chris Angelico <ros...@gmail.com>:
> On Fri, Sep 15, 2017 at 5:06 AM, Jason H <jh...@gmx.com> wrote:
> >
> >>> Why is it ','.join(iterable), why isn't there join(',', iterable)
> >
> >> Because join apply on a string, and strings are defined by the str
> class, not by a specific protocol (unlike iterables).
> > Why? I can iterate over a string. [c for c in 'abc'] It certainly
> behaves like one... I'd say this is inconsistent because there is no
> __iter__() and next() on the str class.
>
> There is __iter__, but no next() or __next__() on the string itself.
> __iter__ makes something iterable; __next__ is on iterators, but not
> on all iterables.
>
> >>> "abc".__iter__()
>
>
> > I do think Python is superior in many, many, ways to all other
> languages, but as Python and JS skills are often desired in the same
> engineer, it seems that we're making it harder on the majority of the labor
> force.
> >
>
> "We" are making it harder? Who's "we"? Python predates JavaScript by a
> few years, and the latter language was spun up in less than two weeks
> in order to create an 'edge' in the browser wars. So I don't think
> anyone really planned for anyone to write multi-language code
> involving Python and JS.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Make map() better
> Why is it ','.join(iterable), why isn't there join(',', iterable)
Because join apply on a string, and strings are defined by the str class,
not by a specific protocol (unlike iterables).
2017-09-14 18:43 GMT+02:00 MRAB <pyt...@mrabarnett.plus.com>:
> On 2017-09-14 03:55, Steven D'Aprano wrote:
>
>>
>> On Wed, Sep 13, 2017 at 11:05:26PM +0200, Jason H wrote:
>>
>> > And look, map() even works with all of them, without inheritance,
>>> > registration, and whatnot. It's so easy!
>>>
>>> Define easy.
>>>
>>
>> Opposite of hard or difficult.
>>
>> You want to map a function?
>>
>> map(function, values)
>>
>> is all it takes. You don't have to care whether the collection of values
>> supports the map() method, or whether the class calls it "apply", or
>> "Map", or something else. All you need care about is that the individual
>> items inside the iterable are valid for the function, but you would need
>> to do that regardless of how you call it.
>>
>> [1, 2, 3, {}, 5].map(plusone) # will fail
>>
>>
>> It's far easier for me to do a dir(dict) and see what I can do with it.
>>>
>>
>> And what of the functions that dict doesn't know about?
>>
>>
>>
>> This is what python does after all. "Does it have the interface I
>>> expect?" Global functions like len(), min(), max(), map(), etc(), don't
>>> really tell me the full story. len(7) makes no sense. I can attempt to call
>>> a function with an invalid argument.
>>>
>>
>> And you can attempt to call a non-existent method:
>>
>> x = 7
>> x.len()
>>
>> Or should that be length() or size() or count() or what?
>>
>> [].len() makes more sense.
>>>
>>
>> Why? Getting the length of a sequence or iterator is not specifically a
>> list operation, it is a generic operation that can apply to many
>> different kinds of things.
>>
>>
>> Python is weird in that there are these special magical globals
>>>
>>
>> The word you want is "function".
>>
>> that operate on many things.
>>>
>>
>> What makes that weird? Even Javascript has functions. So do C, Pascal,
>> Haskell, C++, Lisp, Scheme, and thousands of other languages.
>>
>> Why is it ','.join(iterable), why isn't there join(',', iterable) At what
>>> point does a method become a global? A member? Do we take the path that
>>> everything is a global? Or should all methods be members? So far it seems
>>> arbitrary.
>>>
>>
>> Okay, its arbitrary.
>>
>> Why is it called [].len instead of [].length or {}.size? Why None
>> instead of nil or null or nul or NULL or NOTHING?
>>
>> Many decisions in programming languages are arbitrary.
>>
>> In Java, strings have .length(), arrays have .length, and collections
> have .size().
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New PEP 550: Execution Context
ield
> finally:
> if old_x is not_there:
> del_execution_context_item('x')
> else:
> set_execution_context_item('x', old_x)
>
>
> Can we fix ``PyThreadState_GetDict()``?
> ---
>
> ``PyThreadState_GetDict`` is a TLS, and some of its existing users
> might depend on it being just a TLS. Changing its behaviour to follow
> the Execution Context semantics would break backwards compatibility.
>
>
> PEP 521
> ---
>
> :pep:`521` proposes an alternative solution to the problem:
> enhance Context Manager Protocol with two new methods: ``__suspend__``
> and ``__resume__``. To make it compatible with async/await,
> the Asynchronous Context Manager Protocol will also need to be
> extended with ``__asuspend__`` and ``__aresume__``.
>
> This allows to implement context managers like decimal context and
> ``numpy.errstate`` for generators and coroutines.
>
> The following code::
>
> class Context:
>
> def __enter__(self):
> self.old_x = get_execution_context_item('x')
> set_execution_context_item('x', 'something')
>
> def __exit__(self, *err):
> set_execution_context_item('x', self.old_x)
>
> would become this::
>
> class Context:
>
> def __enter__(self):
> self.old_x = get_execution_context_item('x')
> set_execution_context_item('x', 'something')
>
> def __suspend__(self):
> set_execution_context_item('x', self.old_x)
>
> def __resume__(self):
> set_execution_context_item('x', 'something')
>
> def __exit__(self, *err):
> set_execution_context_item('x', self.old_x)
>
> Besides complicating the protocol, the implementation will likely
> negatively impact performance of coroutines, generators, and any code
> that uses context managers, and will notably complicate the
> interpreter implementation. It also does not solve the leaking state
> problem for greenlet/gevent.
>
> :pep:`521` also does not provide any mechanism to propagate state
> in a local context, like storing a request object in an HTTP request
> handler to have better logging.
>
>
> Can Execution Context be implemented outside of CPython?
>
>
> Because async/await code needs an event loop to run it, an EC-like
> solution can be implemented in a limited way for coroutines.
>
> Generators, on the other hand, do not have an event loop or
> trampoline, making it impossible to intercept their ``yield`` points
> outside of the Python interpreter.
>
>
> Reference Implementation
>
>
> The reference implementation can be found here: [11]_.
>
>
> References
> ==
>
> .. [1] https://blog.golang.org/context
>
> .. [2] https://msdn.microsoft.com/en-us/library/system.threading.
> executioncontext.aspx
>
> .. [3] https://github.com/numpy/numpy/issues/9444
>
> .. [4] http://bugs.python.org/issue31179
>
> .. [5] https://en.wikipedia.org/wiki/Hash_array_mapped_trie
>
> .. [6] http://blog.higher-order.net/2010/08/16/assoc-and-clojures-
> persistenthashmap-part-ii.html
>
> .. [7] https://github.com/1st1/cpython/tree/hamt
>
> .. [8] https://michael.steindorfer.name/publications/oopsla15.pdf
>
> .. [9] https://gist.github.com/1st1/9004813d5576c96529527d44c5457dcd
>
> .. [10] https://gist.github.com/1st1/dbe27f2e14c30cce6f0b5fddfc8c437e
>
> .. [11] https://github.com/1st1/cpython/tree/pep550
>
> .. [12] https://www.python.org/dev/peps/pep-0492/#async-await
>
> .. [13] https://github.com/MagicStack/uvloop/blob/master/examples/
> bench/echoserver.py
>
> .. [14] https://github.com/MagicStack/pgbench
>
> .. [15] https://github.com/python/performance
>
> .. [16] https://gist.github.com/1st1/6b7a614643f91ead3edf37c4451a6b4c
>
>
> Copyright
> =
>
> This document has been placed in the public domain.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Antoine Rozo
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pseudo methods
Hi, With this kind of feature, you never know which methods are included in the class (depending of which modules have been loaded). I don't think this is a good idea. 2017-08-04 9:39 GMT+02:00 Paul Laos <paul_l...@outlook.com>: > 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 methods would make that > easier. > > Code example: (The syntax can most likely be improved upon) > def has_vowels(self: str): > for vowel in ["a", "e,", "i", "o", "u"]: > if vowel in self: return True > > This allows one to wring `string.has_vowels()` instead of > `has_vowels(string)`, > which would make it easier to read, and would make it easier to add > functionality to existing classes, without having to extend them. This > would be > useful for builtins or imported libraries, so one can fill in "missing" > methods. > > * Simple way to extend classes > * Improves readability > * Easy to understand > > ~Paul > > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] ImportError raised for a circular import
But circular imports are sometimes needed in modules. For example when you have two classes in two different modules that reference each other in their methods (and because you can't pre-declare classes like in C++). 2017-06-13 20:30 GMT+02:00 Barry Scott <ba...@barrys-emacs.org>: > Recently I fell into the trap of creating a circular import and yet again > it took time to figure out what was wrong. > > I'm wondering why the python import code does not detect this error and > raise an exception. > > I took a look at the code and got as far as figuring out that I would need > to add the detection to the > python 3 import code. Unless I missed something I cannot get the detection > without > modifying the core code as I could see no way to hook the process cleanly. > > Is it reasonable idea to add this detection to python? > > I am willing to work on a patch. > > Barry > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] π = math.pi
Does this really make expressions more readable? More, these characters are difficult to write. 2017-06-01 9:53 GMT+02:00 Stephan Houben <stephan...@gmail.com>: > Tau was kind of a joke. > > Stephan > > Op 1 jun. 2017 09:47 schreef "Serhiy Storchaka" <storch...@gmail.com>: > > 01.06.17 10:03, David Mertz пише: > > It's awfully easy to add in your own code. Since they are simply aliases, >> I don't see why bother put the duplication in the standard library. You can >> even monkey patch if you want it in the 'math' namespace. I'd prefer a bare >> 'π' in my own code though. >> > > As well as adding tau = 2*math.pi in your own code. But this deserved the > whole PEP and was added as a feature in 3.6. > > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)
Also, how do you handle special methods for operators, such as __add__? 2017-05-14 13:18 GMT+02:00 Steven D'Aprano <st...@pearwood.info>: > On Sun, May 14, 2017 at 11:12:21AM +0400, Abdur-Rahmaan Janhangeer wrote: > > Whatever you all propose, > > > > coming from a java and c++ background, OOP in python is quite cumbersome. > > In what way it is cumbersome? > > > if you tell that i am not a python guy, then consider that current oop > > style does not reflect python's style of ease and simplicity > > That is one opinion. > > > > is __init__ really a good syntax choice? > > I don't understand the question. Are you complaining about the name > "__init__"? Do you think it would be easier to write if it was spelled > "init" or "new" or "Constructor"? > > > > -- > Steve > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)
l seconds to load it can be annoying. Its always >> loaded when importing any library that uses it internally, because of >> module level imports that should be class/instance level. Even if we just >> wanted to do --help on the command line and needed that library before >> argparse for some reason. >> >> > (-/+) Speed: The `def`-based objects take 0.6 μs to create while the >>> > `class`-based objects take only 0.4 μs. For method execution however >>> the >>> > closure takes only 0.15 μs while the proper method takes 0.22 μs >>> (script >>> > <https://gist.github.com/rmst/78b2b0f56a3d9ec13b1ec6f3bd50aa9c>). >>> >>> I don't think you can really evaluate the performance impact of >>> this >>> alternative just based on a trivial example like that. >>> >>> Agree, I don't know really how well this would perform. >>> >> >> > (-/+) Checking types: In the proposed example above the returned object >>> > wouldn't know that it has been created by `MyClass`. There are a couple >>> > of solutions to that, though. The easiest to implement would be to >>> > change the first line to `self = subclass(ParentClass())` where the >>> > subclass function looks at the next item in the call stack (i.e. >>> > `MyClass`) and makes it the type of the object. Another solution would >>> > be to have a special rule for functions with capital first letter >>> > returning a single object to append itself to the list of types of the >>> > returned object. Alternatively there could be a special keyword e.g. >>> > `classdef` that would be used instead of `def` if we wouldn't want to >>> > rely on the name. >>> >>> Those special rules sound very hackish to me. >> >> >>> > (-) The current syntax for adding a function to an object is >>> > cumbersome. That's what is preventing me from actually using the >>> > proposed pattern. But is this really the only reason for not using it? >>> > And if so, wouldn't that be a good argument for enabling something like >>> > below? >>> > * >>> > * >>> > *attribute function definitions*: >>> > | >>> > defMyClass(x): >>> > self=ParentClass() >>> > defself.my_method(y): >>> > z=x+y >>> > returnz >>> > returnself >>> > | >>> > >>> > >>> > or alternatively*multiline lambdas*: >>> > >>> > | >>> > defMyClass(x): >>> > self=ParentClass() >>> > self.my_method=(y): >>> > z=x+y >>> > returnz >>> > returnself >>> > | >>> >>> To be honest, from all your examples, I don't really see what >>> the point >>> is. It's a different syntax for doing some of the same things the >>> existing class syntax does, while providing no apparent way to do some >>> important things (like mutating attributes). I think Python's existing >>> class syntax is simple, clear, and quite nice overall, and creating >>> class instances by calling a function instead of a class doesn't add >>> anything. In fact, even JavaScript has recently added classes to allow >>> programmers to move away from the old approach that you describe here. >>> Also, as I alluded to above, JavaScript is so terrible in so many ways >>> that the mere idea of imitating it inherently makes me skeptical; >>> there's almost nothing about JavaScript's design that couldn't be done >>> better, and most of what it does are things that Python already does >>> better and has done better for years. In short, I don't see any >>> advantages at all to doing classes this way, and there are some >>> non-negligible disadvantages. >>> >> >> Interesting, didn't know that about Javascript. I also don't like >> Javascript's prototypes very much but thought adding "JavaScript-like" to >> the title might help explain what I meant. >> >> Leaving the possible replacement for classes aside, do you have an >> opinion specifically about the following? >> >> def obj.my_function(a, b): >>... >> >> as syntactic sugar for >> >> def my_function(a, b): >> ... >> >> obj.my_function = my_function >> >> In my experience this pattern comes actually up quite a bit. E.g. when >> working with these "symbolic" machine learning frameworks like theano or >> tensorflow. Apart from that it mixins very easy. >> >> What do you think are the odds of something like this actually making it >> into the Python and if greater than 0 in which timeframe? >> >> >> >>> -- >>> Brendan Barnwell >>> "Do not follow where the path may lead. Go, instead, where there is no >>> path, and leave a trail." >>> --author unknown >>> ___ >>> Python-ideas mailing list >>> Python-ideas@python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> Thanks, >> >> Simon >> >>> >>> >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Antoine Rozo ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
