On Oct 26, 2019, at 19:59, Random832 wrote:
>
> A string representation considering of (say) a UTF-8 string, plus an
> auxiliary list of byte indices of, say, 256-codepoint-long chunks [along with
> perhaps a flag to say that the chunk is all-ASCII or not] would provide O(1)
> random access, t
On Oct 26, 2019, at 21:33, Steven D'Aprano wrote:
>
> IronPython and Jython use whatever .Net and Java use.
Which makes them sequences of UTF-16 code units, not code points. Which is
allowed for the Python 2.x unicode type, but would violate the rules for 3.x
str, but neither one has a 3.x. If
Steve Jorgensen wrote:
> After messing around with Enum for a while, there's one small thing that
> I'd like to see improved. It seems limiting to me that the only way to trigger
> _generate_next_value is to pass auto().
> What if, for a particular Enum, I would like to be able to use
> () as a sho
Le sam. 26 oct. 2019 à 13:15, Steve Jorgensen a écrit :
> What if, for a particular `Enum`, I would like to be able to use `()` as a
> shorthand for `auto()`? How about a more complex auto-generation that
> determines the final value based on both the given value and the name/key
>
What if I wan
Antoine Rozo wrote:
> Le sam. 26 oct. 2019 à 13:15, Steve Jorgensen ste...@stevej.name a écrit :
> > What if, for a particular Enum, I would
> > like to be able to use () as a
> > shorthand for auto()? How about a more complex auto-generation that
> > determines the final value based on both the gi
On Sun, Oct 27, 2019, at 03:39, Andrew Barnert via Python-ideas wrote:
> (Actually, IIRC, one of the two has a str type that, despite being 2.x,
> is unicode rather than bytes, but with some extra undocumented
> functionality to smuggle bytes around in a str and have it sometimes
> work.)
I do
I repeatedly make proposals without examples. Sorry about that, and I'm going
to stop doing that.
Upon trying to compose an example, I realize that what I'm asking for is not
actually the best pattern for what I'd like to see, so when I have composed a
better pattern and sample implementation,
On Sun, Oct 27, 2019 at 03:33:16PM +1100, Steven D'Aprano wrote:
> else:
> assert c <= '\U0001':
Oops, missplaced a zero there. That was supposed to be '\U0010'.
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
T
On Sun, Oct 27, 2019 at 12:10:22AM -0700, Andrew Barnert via Python-ideas wrote:
> If you redesign your find, re.search, etc. APIs to not return
> character indexes, then I think you can get away with not having
> character-indexable strings.
If string.index(c) doesn't return the index of c in
On Sun, Oct 27, 2019 at 11:43 PM Steven D'Aprano wrote:
>
> On Sun, Oct 27, 2019 at 12:10:22AM -0700, Andrew Barnert via Python-ideas
> wrote:
>
> > If you redesign your find, re.search, etc. APIs to not return
> > character indexes, then I think you can get away with not having
> > character-ind
foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid
syntax, which makes pyparsing useless.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/m
Just define a function. And don't be a dick.
> On 27 Oct 2019, at 14:57, Soni L. wrote:
>
> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid
> syntax, which makes pyparsing useless.
> ___
> Python-ideas mailing list -- python-id
that's a waste of a perfectly good name in the namespace.
On 2019-10-27 11:27 a.m., Anders Hovmöller wrote:
Just define a function. And don't be a dick.
> On 27 Oct 2019, at 14:57, Soni L. wrote:
>
> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid syntax, which makes py
On Sun, Oct 27, 2019, 10:38 AM Soni L. wrote:
> that's a waste of a perfectly good name in the namespace.
>
> On 2019-10-27 11:27 a.m., Anders Hovmöller wrote:
> > Just define a function. And don't be a dick.
> >
> > > On 27 Oct 2019, at 14:57, Soni L. wrote:
> > >
> > > foo.setParseAction(lamb
There's also the workaround:
def raise_(t, *a,*kw):
raise t(*a,**kw)
> On 27 Oct 2019, at 14:57, Soni L. wrote:
>
> foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid
> syntax, which makes pyparsing useless.
> ___
> Python-ide
> On Oct 27, 2019, at 05:38, Steven D'Aprano wrote:
>
>> On Sun, Oct 27, 2019 at 12:10:22AM -0700, Andrew Barnert via Python-ideas
>> wrote:
>>
>> If you redesign your find, re.search, etc. APIs to not return
>> character indexes, then I think you can get away with not having
>> character-ind
On Oct 27, 2019, at 05:49, Chris Angelico wrote:
>> Given zero-based indexing, and the string:
>>
>>"abÇÐεф"
>>
>> the index of "ф" better damn well be 5 rather than 8 (UTF-8), 10
>> (UTF-16) or 20 (UTF-32) or I'll be knocking on the API designer's door
>> with a pitchfork and a flaming tor
On 10/27/2019 10:35 AM, Soni L. wrote:
that's a waste of a perfectly good name in the namespace.
Names are cheap. If "wasting" a name is a concern, then perhaps Python
isn't the language for you. It also lacks local scopes inside code
blocks, for example, which also "waste" names, as compared
On 2019-10-27 12:14 p.m., Eric V. Smith wrote:
On 10/27/2019 10:35 AM, Soni L. wrote:
that's a waste of a perfectly good name in the namespace.
Names are cheap. If "wasting" a name is a concern, then perhaps Python
isn't the language for you. It also lacks local scopes inside code
blocks,
throw is an expression, not a statement, in C++. I see no reason raise
couldn't be an expression in Python. It doesn't even need a special
rule in the grammar:
from __future__ import raise_function
foo.setParseAction(lambda a, b, c: raise(MumbleMumble()))
Looking up and calling the rais
On Oct 27, 2019, at 15:07, Ben Rudiak-Gould wrote:
>
> throw is an expression, not a statement, in C++. I see no reason raise
> couldn't be an expression in Python. It doesn't even need a special
> rule in the grammar:
>
>from __future__ import raise_function
>
>foo.setParseAction(lamb
On Mon, Oct 28, 2019 at 10:20 AM Andrew Barnert via Python-ideas
wrote:
>
> And meanwhile, if you want to change the language to turn raise into an
> expression, why not just turn it into an expression with the same syntax,
> just like with yield somewhere around 2.4? Then all existing code that
On Oct 27, 2019, at 16:37, Chris Angelico wrote:
>
> But a raise expression doesn't really make sense in that way - it
> can't possibly have any value. It would be possible to use a raise
> expression in a lambda function or an if/else expression, but other
> than that, there wouldn't be much to
On Mon, Oct 28, 2019 at 11:17 AM Andrew Barnert wrote:
>
> On Oct 27, 2019, at 16:37, Chris Angelico wrote:
> >
> > But a raise expression doesn't really make sense in that way - it
> > can't possibly have any value. It would be possible to use a raise
> > expression in a lambda function or an if
On Sun, Oct 27, 2019 at 06:56:16PM -0300, Soni L. wrote:
> that's why I use nested functions.
I'm pretty sure that the memory and time overhead of using nested
functions is far greater than the saving in names.
I'm not even sure what it is that you think you are saving. Why do you
care if a fu
On Oct 27, 2019, at 18:00, Steven D'Aprano wrote:
>
> On Sun, Oct 27, 2019 at 10:07:41AM -0700, Andrew Barnert via Python-ideas
> wrote:
>
>>> File "/home/rosuav/tmp/demo.py", line 1
>>> print("Hello, world!')
>>>^
>>> SyntaxError: EOL while scanning string literal
>>
I do agree that this is a worthwhile feature-ish, but it's marred by the
tuples-for-values assumption. We've build very much the same thing in tri.token
(https://github.com/TriOptima/tri.token) but tri.token is much more scalable to
many arguments because it uses keyword arguments and not positi
Anders Hovmöller wrote:
> I do agree that this is a worthwhile feature-ish, but it's marred by the
> tuples-for-values assumption. We've build very much the same thing in
> tri.token (https://github.com/TriOptima/tri.token)
> but tri.token is much more scalable to many arguments because it uses ke
28 matches
Mail list logo
