On Thu, Oct 13, 2016 at 5:17 PM, Stephen J. Turnbull
wrote:
> Chris Angelico writes:
>
> > I'm not sure what you mean by "strcmp-able"; do you mean that the
> > lexical ordering of two Unicode strings is guaranteed to be the same
> > as the byte-wise ordering of their UTF-8 encodings?
>
> This
On 13 October 2016 at 08:02, Greg Ewing wrote:
> Mikhail V wrote:
>>
>> Consider unicode table as an array with glyphs.
>
>
> You mean like this one?
>
> http://unicode-table.com/en/
>
> Unless I've miscounted, that one has the characters
> arranged in rows of 16, so it would be *harder* to
> look
On 13 October 2016 at 04:49, Emanuel Barry wrote:
>> From: Mikhail V
>> Sent: Wednesday, October 12, 2016 9:57 PM
>> Subject: Re: [Python-ideas] Proposal for default character representation
>
> Hello, and welcome to Python-ideas, where only a small portion of ideas go
> further, and where most ne
Mikhail V wrote:
Consider unicode table as an array with glyphs.
You mean like this one?
http://unicode-table.com/en/
Unless I've miscounted, that one has the characters
arranged in rows of 16, so it would be *harder* to
look up a decimal index in it.
--
Greg
Mikhail V wrote:
And decimal is objectively way more readable than hex standard character set,
regardless of how strong your habits are.
That depends on what you're trying to read from it. I can
look at a hex number and instantly get a mental picture
of the bit pattern it represents. I can't do
On 13 October 2016 at 04:18, Brendan Barnwell wrote:
> On 2016-10-12 18:56, Mikhail V wrote:
>>
>> Please don't mix the readability and personal habit, which previuos
>> repliers seems to do as well. Those two things has nothing
>> to do with each other.
>
>
> You keep saying this, but it'
> From: Mikhail V
> Sent: Wednesday, October 12, 2016 9:57 PM
> Subject: Re: [Python-ideas] Proposal for default character representation
Hello, and welcome to Python-ideas, where only a small portion of ideas go
further, and where most newcomers that wish to improve the language get hit
by the re
On 2016-10-13 00:50, Chris Angelico wrote:
On Thu, Oct 13, 2016 at 10:09 AM, Mikhail V wrote:
On 12 October 2016 at 23:58, Danilo J. S. Bellini
wrote:
Decimal notation is hardly
readable when we're dealing with stuff designed in base 2 (e.g. due to the
visual separation of distinct bytes).
On Oct 12, 2016 9:25 PM, "Chris Angelico" wrote:
>
> On Thu, Oct 13, 2016 at 12:56 PM, Mikhail V wrote:
> > But as said I find this Unicode only some temporary happening,
> > it will go to history in some future and be
> > used only to study extinct glyphs.
>
> And what will we be using instead
On Oct 12, 2016 4:33 PM, "Mikhail V" wrote:
>
> Hello all,
>
> *snip*
>
> PROPOSAL:
> 1. Remove all hex notation from printing functions, typing,
> documention.
> So for printing functions leave the hex as an "option",
> for example for those who feel the need for hex representation,
> which is st
On Thu, Oct 13, 2016 at 12:56 PM, Mikhail V wrote:
> But as said I find this Unicode only some temporary happening,
> it will go to history in some future and be
> used only to study extinct glyphs.
And what will we be using instead?
Morbid curiosity trumping a plonking, for the moment.
Chris
On 2016-10-12 18:56, Mikhail V wrote:
Please don't mix the readability and personal habit, which previuos
repliers seems to do as well. Those two things has nothing
to do with each other.
You keep saying this, but it's quite incorrect. The usage of decimal
notation is itself just a conventio
On 13 October 2016 at 01:50, Chris Angelico wrote:
> On Thu, Oct 13, 2016 at 10:09 AM, Mikhail V wrote:
>> On 12 October 2016 at 23:58, Danilo J. S. Bellini
>> wrote:
>>
>>> Decimal notation is hardly
>>> readable when we're dealing with stuff designed in base 2 (e.g. due to the
>>> visual separ
On Thu, Oct 13, 2016 at 10:09 AM, Mikhail V wrote:
> On 12 October 2016 at 23:58, Danilo J. S. Bellini
> wrote:
>
>> Decimal notation is hardly
>> readable when we're dealing with stuff designed in base 2 (e.g. due to the
>> visual separation of distinct bytes).
>
> Hmm what keeps you from separa
On Thu, Oct 13, 2016 at 2:35 AM Steven D'Aprano wrote:
> On Wed, Oct 12, 2016 at 04:11:55PM +, אלעזר wrote:
>
> > Steve, you only need to allow multiple arguments to append(), then it
> makes
> > perfect sense.
>
> I think you're missing a step. What will multiple arguments given to
> append
On Wed, Oct 12, 2016 at 04:11:55PM +, אלעזר wrote:
> Steve, you only need to allow multiple arguments to append(), then it makes
> perfect sense.
I think you're missing a step. What will multiple arguments given to
append do? There are two obvious possibilities:
- collect all the arguments
On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote:
> On 12.10.2016 17:41, Nick Coghlan wrote:
> >This particular proposal fails on the first question (as too many
> >people would expect it to mean the same thing as either "[*expr, for
> >expr in iterable]" or "[*(expr for expr in iterab
On Wed, Oct 12, 2016 at 4:26 PM Terry Reedy wrote:
> I suspect that optimizing string sorting
> will take some experimentation. If the initial item is str, it might be
> worthwhile to record the highest 'kind' during the type scan, so that
> strncmp can be used if all are ascii or latin-1.
>
My
On 12 October 2016 at 23:50, Thomas Nyberg wrote:
> Since when was decimal notation "standard"?
Depends on what planet do you live. I live on planet Earth. And you?
> opposite. For unicode representations, byte notation seems standard.
How does this make it a good idea?
Consider unicode table as
On 12 October 2016 at 23:58, Danilo J. S. Bellini
wrote:
> Decimal notation is hardly
> readable when we're dealing with stuff designed in base 2 (e.g. due to the
> visual separation of distinct bytes).
Hmm what keeps you from separateting the logical units to be represented each
by a decimal nu
Forgot to reply to all, duping my mesage...
On 12 October 2016 at 23:48, M.-A. Lemburg wrote:
> Hmm, in Python3, I get:
>
s = "абв.txt"
s
> 'абв.txt'
I posted output with Python2 and Windows 7
BTW , In Windows 10 'print' won't work in cmd console at all by default
with unicode but th
Paul Moore wrote:
What I'm *not* quite clear on is why Python 3's change to reject
comparisons between unrelated types makes this optimisation possible.
I think the idea was that it's likely to be *useful* a higher
proportion of the time, because Python 3 programmers have to
be careful that the
On Wed, Oct 12, 2016 at 3:34 PM, Alexander Belopolsky
wrote:
>
> On Wed, Oct 12, 2016 at 6:14 PM, Elliot Gorokhovsky
> wrote:
>>
>> so then Latin1 strings are memcmp-able, and others are not.
>
>
> No. Strings of the same kind are "memcmp-able" regardless of their kind.
I don't think this is tr
On 2016-10-12 23:34, Alexander Belopolsky wrote:
On Wed, Oct 12, 2016 at 6:14 PM, Elliot Gorokhovsky
mailto:elliot.gorokhov...@gmail.com>> wrote:
so then Latin1 strings are memcmp-able, and others are not.
No. Strings of the same kind are "memcmp-able" regardless of their kind.
Surely
On Wed, Oct 12, 2016 at 6:14 PM, Elliot Gorokhovsky <
elliot.gorokhov...@gmail.com> wrote:
> so then Latin1 strings are memcmp-able, and others are not.
No. Strings of the same kind are "memcmp-able" regardless of their kind.
___
Python-ideas mailing
On 10/12/2016 1:40 PM, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> I learned the hard way that if I don't put the breaking space at
> the beginning of the next fragment, I probably wouldn't put it at
> the end of the previous fragment either.
The converse applies in my case, so that
On 10/12/2016 5:57 PM, Elliot Gorokhovsky wrote:
On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith mailto:n...@pobox.com>> wrote:
But this isn't relevant to Python's str, because Python's str never
uses UTF-8.
Really? I thought in python 3, strings are all unicode...
They are ...
so
Ah. That makes a lot of sense, actually. Anyway, so then Latin1 strings are
memcmp-able, and others are not. That's fine; I'll just add a check for
that (I think there are already helper functions for this) and then have
two special-case string functions. Thanks!
On Wed, Oct 12, 2016 at 4:08 PM Al
On Thu, Oct 13, 2016 at 8:51 AM, Nathaniel Smith wrote:
> The comparison methods on Python's str are codepoint-by-codepoint.
Thanks, that's what I wasn't sure of.
ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mail
On Wed, Oct 12, 2016 at 5:57 PM, Elliot Gorokhovsky <
elliot.gorokhov...@gmail.com> wrote:
> On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith wrote:
>
>> But this isn't relevant to Python's str, because Python's str never uses
>> UTF-8.
>>
>
> Really? I thought in python 3, strings are all unicode
On 12 October 2016 at 22:57, Elliot Gorokhovsky
wrote:
> On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith wrote:
>>
>> But this isn't relevant to Python's str, because Python's str never uses
>> UTF-8.
>
>
> Really? I thought in python 3, strings are all unicode... so what encoding
> do they use,
On 10/12/2016 5:52 PM, Terry Reedy wrote:
On 10/12/2016 12:06 PM, Enguerrand Pelletier wrote:
b = {k, v for k,v in a.items() if k in interesting_keys}
Test code before posting. The above is a set comprehension creating a
set of tupes.
I should have followed my own advice. The above is a
I'm -1 on this.
Just type "0431 unicode" on your favorite search engine. U+0431 is the
codepoint, not whatever digits 0x431 has in decimal. That's a tradition and
something external to Python.
As a related concern, I think using decimal/octal on raw data is a terrible
idea (e.g. On Linux, I alway
On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith wrote:
> But this isn't relevant to Python's str, because Python's str never uses
> UTF-8.
>
Really? I thought in python 3, strings are all unicode... so what encoding
do they use, then?
___
Python-ideas
On 10/12/2016 12:06 PM, Enguerrand Pelletier wrote:
Hi all,
It always bothered me to write something like this when i want to strip
keys from a dictionnary in Python:
a = {"foo": 1, "bar": 2, "baz": 3, "foobar": 42}
interesting_keys = ["foo", "bar", "baz"]
If the keys are hashable, this shoul
The comparison methods on Python's str are codepoint-by-codepoint.
A neat fact about UTF-8 is that bytewise comparisons on UTF-8 are
equivalent to doing codepoint comparisons.
But this isn't relevant to Python's str, because Python's str never uses UTF-8.
-n
On Wed, Oct 12, 2016 at 2:45 PM, Ellio
On 12.10.2016 23:33, Mikhail V wrote:
> Hello all,
>
> I want to share my thoughts about syntax improvements regarding
> character representation in Python.
> I am new to the list so if such a discussion or a PEP exists already,
> please let me know.
>
> So in short:
>
> Currently Python uses he
On 10/12/2016 05:33 PM, Mikhail V wrote:
Hello all,
Hello! New to this list so not sure if I can reply here... :)
Now printing it we get:
u'\u0430\u0431\u0432.txt'
By "printing it", do you mean "this is the string representation"? I
would presume printing it would show characters nicel
> So what's Python doing? Is it a codepoint ordering?
>
...ya...how is the python interpreter supposed to know what language
strings are in? There is a unique ordering of unicode strings defined by
the unicode standard, AFAIK.
If you want to sort by natural language ordering, see here:
https://pyp
On Wed, Oct 12, 2016 at 3:39 PM Nathaniel Smith wrote:
> It looks like PyUnicode_Compare already has a special case to use
> memcmp when both of the strings fit into latin1:
>
Wow! That's great! I didn't even try reading through unicode_compare,
because I felt I might miss some subtle detail tha
On Thu, Oct 13, 2016 at 8:19 AM, Elliot Gorokhovsky
wrote:
>
> My first question was how expensive python compares are vs C compares. And
> since python 2 has PyString_AS_STRING, which just gives you a char* pointer
> to a C string, I went in and replaced PyObject_RichCompareBool with strcmp
> and
On Wed, Oct 12, 2016 at 2:19 PM, Elliot Gorokhovsky
wrote:
[...]
> So that was the motivation for all this. Actually, if I wrote this for
> python 2, I might be able to get even better numbers (at least for strings),
> since we can't use strcmp in python 3. (Actually, I've heard UTF-8 strings
> ar
The semantics seem fairly obvious if you treat it as changing the method calls.
For lists, * uses .extend() instead of .append(). Sets use * for .update()
instead of .add(). Dicts use ** for .update() instead of __setitem__. In that
case x should be a mapping (or iterable of pairs maybe), and al
On Wed, Oct 12, 2016 at 5:36 AM Paul Moore wrote:
> On 12 October 2016 at 11:16, Steven D'Aprano wrote:
> > On Wed, Oct 12, 2016 at 12:25:16AM +, Elliot Gorokhovsky wrote:
> >
> >> Regarding generalization: the general technique for special-casing is
> you
> >> just substitute all type check
Hello all,
I want to share my thoughts about syntax improvements regarding
character representation in Python.
I am new to the list so if such a discussion or a PEP exists already,
please let me know.
So in short:
Currently Python uses hexadecimal notation
for characters for input and output.
Fo
On Tue, Oct 11, 2016 at 9:56 PM Nick Coghlan wrote:
> Once you get to the point of being able to do performance mentions on
> a CPython build with a modified list.sort() implementation, you'll
> want to take a look at the modern benchmark suite in
> https://github.com/python/performance
>
Yup, t
On Wed, Oct 12, 2016 at 9:20 AM Tim Peters wrote:
> > What I'm *not* quite clear on is why Python 3's change to reject
> > comparisons between unrelated types makes this optimisation possible.
>
> It doesn't. It would also apply in Python 2. I simply expect the
> optimization will pay off more
To be honest, I don't have a clear picture of what {**x for x in d.items()}
should be. But I do have such picture for
dict(**x for x in many_dictionaries)
Elazar
On Wed, Oct 12, 2016 at 11:37 PM אלעזר wrote:
> On Wed, Oct 12, 2016 at 11:26 PM David Mertz wrote:
>
> On Wed, Oct 12, 20
On 12.10.2016 21:38, אלעזר wrote:
What is the intuition behind [1, *x, 5]? The starred expression is
replaced with a comma-separated sequence of its elements.
The trailing comma Nick referred to is there, with the rule that [1,,
5] is the same as [1, 5].
I have to admit that I have my pr
On Wed, Oct 12, 2016 at 11:26 PM David Mertz wrote:
> On Wed, Oct 12, 2016 at 12:38 PM, אלעזר wrote:
>
> What is the intuition behind [1, *x, 5]? The starred expression is
> replaced with a comma-separated sequence of its elements.
>
> I've never actually used the `[1, *x, 5]` form. And therefo
On 12 October 2016 at 20:22, David Mertz wrote:
> I've followed this discussion some, and every example given so far
> completely mystifies me and I have no intuition about what they should mean.
Same here.
On 12 October 2016 at 20:38, אלעזר wrote:
> What is the intuition behind [1, *x, 5]? The
That discussion seemed to mostly just conclude that dicts shouldn't have
all set operations, and then it kind of just dropped off. No one really
argued the subset part.
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github
On Wed, Oct 12, 2016 at 12:38 PM, אלעזר wrote:
> What is the intuition behind [1, *x, 5]? The starred expression is
> replaced with a comma-separated sequence of its elements.
>
I've never actually used the `[1, *x, 5]` form. And therefore, of course,
I've never taught it either (I teach Python
What is the intuition behind [1, *x, 5]? The starred expression is replaced
with a comma-separated sequence of its elements.
The trailing comma Nick referred to is there, with the rule that [1,, 5] is
the same as [1, 5].
All the examples follow this intuition, IIUC.
Elazar
בתאריך יום ד׳, 12 באו
I've followed this discussion some, and every example given so far
completely mystifies me and I have no intuition about what they should mean.
On Oct 12, 2016 8:43 AM, "Steven D'Aprano" wrote:
> On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
> > Hello list
> >
> > I love the "new
אלעזר writes:
> Steve, you only need to allow multiple arguments to append(), then it makes
> perfect sense.
No, because that would be explicit. Here it's implicit and ambiguous.
Specifically, it requires guessing "operator associativity". That is
something people have different intuitions ab
Steven D'Aprano writes:
> I learned the hard way that if I don't put the breaking space at
> the beginning of the next fragment, I probably wouldn't put it at
> the end of the previous fragment either.
The converse applies in my case, so that actually doesn't matter to
me. When I don't put it
> On 7 Oct 2016, at 16:18, Nick Coghlan wrote:
>
> However, if you're running in a context that embeds CPython inside a
> larger application (e.g. mod_wsgi inside Apache), then gevent's
> assumptions about how the C thread states are managed may be wrong,
> and hence you may be in for some "inte
Looks like it was discussed before:
https://mail.python.org/pipermail/python-ideas/2012-January/013252.html
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/
On 12.10.2016 17:41, Nick Coghlan wrote:
This particular proposal fails on the first question (as too many
people would expect it to mean the same thing as either "[*expr, for
expr in iterable]" or "[*(expr for expr in iterable)]")
So, my reasoning would tell me: where have I seen * so far? *ar
Hi all,
It always bothered me to write something like this when i want to strip
keys from a dictionnary in Python:
a = {"foo": 1, "bar": 2, "baz": 3, "foobar": 42}
interesting_keys = ["foo", "bar", "baz"]
b = {k, v for k,v in a.items() if k in interesting_keys}
Wouldn't it be nice to have a s
Steve, you only need to allow multiple arguments to append(), then it makes
perfect sense.
בתאריך יום ד׳, 12 באוק' 2016, 18:43, מאת Steven D'Aprano <
st...@pearwood.info>:
> On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
> > Hello list
> >
> > I love the "new" unpacking generalisa
On Tue, Oct 11, 2016 at 10:24:47PM -0400, Terry Reedy wrote:
> >>Heh--not to bikeshed, but my personal preference is to leave the
> >>trailing space on the first line. This is because by the time I've
> >>started a new line (and possibly have spent time fussing with
> >>indentation for the odd ca
On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
> Hello list
>
> I love the "new" unpacking generalisations as of pep448. And I found
> myself using them rather regularly, both with lists and dict.
> Today I somehow expected that [*foo for foo in bar] was equivalent to
> itertools.ch
[Nick Coghlan]
> It's probably more relevant that cmp() went away, since that
> simplified the comparison logic to just PyObject_RichCompareBool,
> without the custom comparison function path.
Well, the current sort is old by now, and was written for Python 2.
But it did anticipate that rich compa
On 12 October 2016 at 23:58, Sven R. Kunze wrote:
> Reading PEP448 it seems to me that it's already been considered:
> https://www.python.org/dev/peps/pep-0448/#variations
>
> The reason for not-inclusion were about concerns about acceptance because of
> "strong concerns about readability" but als
[Paul Moore]
> My understanding is that the code does a per-check that all the
> elements of the list are the same type (float, for example). This is a
> relatively quick test (O(n) pointer comparisons). If everything *is* a
> float, then an optimised comparison routine that skips all the type
> ch
On 12 October 2016 at 21:35, Paul Moore wrote:
> What I'm *not* quite clear on is why Python 3's change to reject
> comparisons between unrelated types makes this optimisation possible.
> Surely you have to check either way? It's not that it's a particularly
> important question - if the optimisat
Hi Martti,
On 11.10.2016 14:42, Martti Kühne wrote:
Hello list
I love the "new" unpacking generalisations as of pep448. And I found
myself using them rather regularly, both with lists and dict.
Today I somehow expected that [*foo for foo in bar] was equivalent to
itertools.chain(*[foo for foo i
On 12 October 2016 at 11:16, Steven D'Aprano wrote:
> On Wed, Oct 12, 2016 at 12:25:16AM +, Elliot Gorokhovsky wrote:
>
>> Regarding generalization: the general technique for special-casing is you
>> just substitute all type checks with 1 or 0 by applying the type assumption
>> you're making.
On Wed, Oct 12, 2016 at 12:25:16AM +, Elliot Gorokhovsky wrote:
> Regarding generalization: the general technique for special-casing is you
> just substitute all type checks with 1 or 0 by applying the type assumption
> you're making. That's the only way to guarantee it's safe and compliant.
Hi guys,
I'm writing some code that uses `threading.Condition` and I found that I
want to access condition._waiters. I want to do it in two different parts
of my code for two different reasons:
1. When shutting down the thread that manages the condition, I want to be
sure that there are no waiter
72 matches
Mail list logo
