Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Thomas Jollans]

On 24/11/17 05:45, Andrew Z wrote:
> I have hard time seeing the benefits of this "necessity" , just
> unreasonable  overcomplications for the name of "diversity".

What complications?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Chris Angelico]

On Fri, Nov 24, 2017 at 2:52 PM, Mikhail V  wrote:
> On Fri, Nov 24, 2017 at 4:13 AM, Chris Angelico  wrote:
>> On Fri, Nov 24, 2017 at 1:44 PM, Mikhail V  wrote:
>>> From my above example, you could probably see that I prefer somewhat
>>> middle-sized identifiers, one-two syllables. And naturally, they tend to
>>> reflect some process/meaining, it is not always achievable,
>>> but yes there is such a natural tendency, although by me personally
>>> not so strong, and quite often I use totally meaningless names,
>>> mainly to avoid visual similarity to already created names.
>>> So for very expanded names, it ends up with a lot of underscores :(
>>
>> Okay. So if it makes sense for you to use English words instead of
>> individual letters, since you are fluent in English, does it stand to
>> reason that it would make sense for other programmers to use Russian,
>> Norwegian, Hebrew, Korean, or Japanese words the same way?
>
> I don't know. Probably, especially if those *programmers* don't know latin
> letters, then they would want to write code with their letters and their
> language. This target group, as I said, will have really hard time
> with programming,
> and in Python in particular, because they will be not only forced to learn
> some english, but also will have all 'pleasures' of  multi-script editing.
> But wait, probably one can write python code in, say Arabic script *only*?
> How about such feature proposal?

If Python supports ASCII identifiers only, people have no choice but
to transliterate. As it is, people get to choose which is better for
them - to transliterate or not to transliterate, that is the
readability question.

> As for non-english speaker who know some English already,
> could of course want to include identifiers in those scripts.
> But how about libraries?

If you want to use numpy, you have to understand the language of
numpy. That's a lot of technical jargon, so even if you understand
English, you have to learn that. So there's ultimately no difference.

The most popular libraries, just like the standard library, are
usually going to choose to go ASCII-only as the
lowest-common-denominator. But that is, again, their own choice.

> Ok, so we return back to my original question: apart from
> ability to do so, how beneficial is it on a pragmatical basis?
> I mean, e.g. Cyrillic will introduce homoglyph issues.
> CJK and Arabic scripts are metrically and optically incompatible with
> latin, so such mixing will end up with messy look. So just for
> the experiment, yes, it's fun.

Does it really introduce homoglyph issues in real-world situations,
though? Are there really cases where people can't figure out from
context what's going on? I haven't seen that happening. Usually there
are *entire words* (and more) in a single language, making it pretty
easy to figure out.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32122] Improve -x option documentation

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The documentation of the -x option is virtually not existing. The current short 
line of the description was enough to me for understanding what is the purpose 
of this option and how it can be used (I didn't use Windows for more than 10 
years). But I was surprised not founding more detailed information about this 
feature in the documentation. Definitely it should be better documented. Most 
of users will have no ideas about this feature.

The purpose of this option is turning Python scripts into Windows batch files 
which can be ran as other executables. Similarly as adding she-bang and setting 
the executable bit allows to run them on Unix. The extension of the Python 
script should be changed to ".bat", and the following line should be added at 
the start of the script:

@path\to\python -x %0 %* & exit /b

Or

@py -3 -x %0 %* & exit /b

Unlike a she-bang line which is a Python comment, this line is not valid Python 
syntax, and the -x option is used for skipping it.

--
assignee: docs@python
components: Documentation, Windows
messages: 306878
nosy: docs@python, paul.moore, serhiy.storchaka, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve -x option documentation
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31626] Writing in freed memory in _PyMem_DebugRawRealloc() after shrinking a memory block

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I prefer to keep the current code as is.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Andrew Z]

I have hard time seeing the benefits of this "necessity" , just
unreasonable  overcomplications for the name of "diversity".




On Nov 23, 2017 22:57, "Ben Finney"  wrote:

> Ian Kelly  writes:
>
> > On Thu, Nov 23, 2017 at 1:04 PM, Karsten Hilbert
> >  wrote:
> > > Using function arguments written in Thai script ?
> > >
> > > Understanding, let alone being able to read, code written in Arabic
> > > ?
> >
> > People are going to write code in Arabic whether you like it or not,
> > because not everybody speaks English, and not everybody who does
> > *wants* to use it.
>
> This is, I think, a good reason to allow Unicode identifiers (at least,
> those Unicode subsets which encode writing systems of languages) as
> programming-language identifiers.
>
> > Now, would you prefer to read code where the variable names are
> > written in Arabic script, or where the variable names are still in
> > Arabic but transliterated to Latin characters?
>
> (On the – evidently correct, in Karsten's case and mine – assumption
> that the reader does not understand Arabic script.)
>
> I've thought about this, and if the quesition is which would *I* prefer,
> the answer is I'd prefer the identifiers transliterated to the Latin
> (English-writing) characters.
>
> Because if I already can't understand the words, it will be more useful
> to me to be able to type them reliably at a keyboard, for replication,
> search, discussion with others about the code, etc.
>
> Set against that, though, I want the preferences of *others* to be taken
> into consideration also. And there are many more people who do not
> natively write English/Latin characters, that I want to feel welcome in
> the Python community.
>
> So it's a good thing that my own reading preference *does not* have
> weight in this matter. I'm not the primary audience for code identifiers
> written in Arabic script, so my preference should matter less than those
> who understand it.
>
> > Either way, you're not going to be able to understand it, so I'm not
> > sure why it makes a difference to you.
>
> I hope you can see that it can simultaneously make a difference – I
> would definitely prefer to read Latin-writing identifiers – while also
> being a lesser consideration that should not outweigh the benefits of
> allowing non-Latin-script identifiers.
>
> > If Arabic characters are allowed however, then it might be of use to
> > the people who are going to code in Arabic anyway. And if it isn't,
> > then they have the option not to use it either.
>
> This is a necessary consequence of increasing the diversity of people
> able to program in Python: people will express ideas originating in
> their own language, in Python code.
>
> For that diversity to increase, we English-fluent folk will necessarily
> become a smaller proportion of the programming community than we are
> today. That might be uncomfortable for us, but it is a necessary
> adaptation the community needs to undergo.
>
> --
>  \ “In any great organization it is far, far safer to be wrong |
>   `\  with the majority than to be right alone.” —John Kenneth |
> _o__)Galbraith, 1989-07-28 |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)

[Ben Finney]

Ian Kelly  writes:

> On Thu, Nov 23, 2017 at 1:04 PM, Karsten Hilbert
>  wrote:
> > Using function arguments written in Thai script ?
> >
> > Understanding, let alone being able to read, code written in Arabic
> > ?
>
> People are going to write code in Arabic whether you like it or not,
> because not everybody speaks English, and not everybody who does
> *wants* to use it.

This is, I think, a good reason to allow Unicode identifiers (at least,
those Unicode subsets which encode writing systems of languages) as
programming-language identifiers.

> Now, would you prefer to read code where the variable names are
> written in Arabic script, or where the variable names are still in
> Arabic but transliterated to Latin characters?

(On the – evidently correct, in Karsten's case and mine – assumption
that the reader does not understand Arabic script.)

I've thought about this, and if the quesition is which would *I* prefer,
the answer is I'd prefer the identifiers transliterated to the Latin
(English-writing) characters.

Because if I already can't understand the words, it will be more useful
to me to be able to type them reliably at a keyboard, for replication,
search, discussion with others about the code, etc.

Set against that, though, I want the preferences of *others* to be taken
into consideration also. And there are many more people who do not
natively write English/Latin characters, that I want to feel welcome in
the Python community.

So it's a good thing that my own reading preference *does not* have
weight in this matter. I'm not the primary audience for code identifiers
written in Arabic script, so my preference should matter less than those
who understand it.

> Either way, you're not going to be able to understand it, so I'm not
> sure why it makes a difference to you.

I hope you can see that it can simultaneously make a difference – I
would definitely prefer to read Latin-writing identifiers – while also
being a lesser consideration that should not outweigh the benefits of
allowing non-Latin-script identifiers.

> If Arabic characters are allowed however, then it might be of use to
> the people who are going to code in Arabic anyway. And if it isn't,
> then they have the option not to use it either.

This is a necessary consequence of increasing the diversity of people
able to program in Python: people will express ideas originating in
their own language, in Python code.

For that diversity to increase, we English-fluent folk will necessarily
become a smaller proportion of the programming community than we are
today. That might be uncomfortable for us, but it is a necessary
adaptation the community needs to undergo.

-- 
 \ “In any great organization it is far, far safer to be wrong |
  `\  with the majority than to be right alone.” —John Kenneth |
_o__)Galbraith, 1989-07-28 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 4:13 AM, Chris Angelico  wrote:
> On Fri, Nov 24, 2017 at 1:44 PM, Mikhail V  wrote:
>> From my above example, you could probably see that I prefer somewhat
>> middle-sized identifiers, one-two syllables. And naturally, they tend to
>> reflect some process/meaining, it is not always achievable,
>> but yes there is such a natural tendency, although by me personally
>> not so strong, and quite often I use totally meaningless names,
>> mainly to avoid visual similarity to already created names.
>> So for very expanded names, it ends up with a lot of underscores :(
>
> Okay. So if it makes sense for you to use English words instead of
> individual letters, since you are fluent in English, does it stand to
> reason that it would make sense for other programmers to use Russian,
> Norwegian, Hebrew, Korean, or Japanese words the same way?

I don't know. Probably, especially if those *programmers* don't know latin
letters, then they would want to write code with their letters and their
language. This target group, as I said, will have really hard time
with programming,
and in Python in particular, because they will be not only forced to learn
some english, but also will have all 'pleasures' of  multi-script editing.
But wait, probably one can write python code in, say Arabic script *only*?
How about such feature proposal?

As for non-english speaker who know some English already,
could of course want to include identifiers in those scripts.
But how about libraries?
Ok, so we return back to my original question: apart from
ability to do so, how beneficial is it on a pragmatical basis?
I mean, e.g. Cyrillic will introduce homoglyph issues.
CJK and Arabic scripts are metrically and optically incompatible with
latin, so such mixing will end up with messy look. So just for
the experiment, yes, it's fun.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Chris Angelico]

On Fri, Nov 24, 2017 at 1:44 PM, Mikhail V  wrote:
> From my above example, you could probably see that I prefer somewhat
> middle-sized identifiers, one-two syllables. And naturally, they tend to
> reflect some process/meaining, it is not always achievable,
> but yes there is such a natural tendency, although by me personally
> not so strong, and quite often I use totally meaningless names,
> mainly to avoid visual similarity to already created names.
> So for very expanded names, it ends up with a lot of underscores :(

Okay. So if it makes sense for you to use English words instead of
individual letters, since you are fluent in English, does it stand to
reason that it would make sense for other programmers to use Russian,
Norwegian, Hebrew, Korean, or Japanese words the same way?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 10:05 PM, Chris Angelico  wrote:
> On Fri, Nov 24, 2017 at 8:02 AM, Mikhail V  wrote:
>> On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico  wrote:
>>> On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V  wrote:
 I see you manually 'optimise' the look?
 I personally would end with something like this:

 def zip_longest(*A, **K):
 value = K.get ('fillvalue')
 count = len(a) - 1
 def sentinel():
 nonlocal count
 if not count:
 raise ZipExhausted
 count -= 1
 yield  value
 fillers = repeat (value)
 iterators = [chain (it, sentinel(), fillers) for it in A]
 try:
 while iterators:
 yield tuple (map (next, iterators))
 except ZipExhausted:
 pass


 So I would say, my option would be something inbetween.
 Note that I tweaked it for proportional font, namely Times New Roman.
>>
>>> I don't see how the font applies here, but whatever.
>>
>> For a different font, say CourierNew (monospaced) the tweaking strategy might
>> be different.
>
> If you have ANY font-specific "tweaking", you're doing it wrong.
> Thanks for making it look worse on everyone else's screen.

Trolling attempt counted :)
No I don't have any particular font-specific strategy,
it is just my wording reflecting the fact that things look different
in different fonts, even among proportional fonts.


>
>>> Which is better? The one-letter names or the longer ones that tie in with 
>>> what they're
>>> doing?
>>
>> I think I have answered more or less in previous post, that you cutted off.
>> So you were not satisfied?
>> But now I am probably not get your 'better' meaning.
>> Better for understanding, or purely visually, i.e. less eye-straining?
>
> Which one would you prefer to maintain? Which would you prefer in a code 
> review?
>
> Do you want to have one- and two-letter variable names, or longer and
> more descriptive ones?
>
> Seriously? Do I need to wrench this part out of you? This was supposed
> to be the EASY question that everyone can agree on, from which I can
> then draw my line of argument.


>From my above example, you could probably see that I prefer somewhat
middle-sized identifiers, one-two syllables. And naturally, they tend to
reflect some process/meaining, it is not always achievable,
but yes there is such a natural tendency, although by me personally
not so strong, and quite often I use totally meaningless names,
mainly to avoid visual similarity to already created names.
So for very expanded names, it ends up with a lot of underscores :(


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29512] regrtest refleak: implement bisection feature

[STINNER Victor]

STINNER Victor  added the comment:

Python 2.7.14 was released with test.bisect.

While there are corner cases, do we really have to do something?

The simplest fix is just to rename Lib/test/bisect.py to Lib/test/bisect_cmd.py 
in Python 2.7. It's a tool written for CPython developer, it's CLI is not 
stable nor documented.

It just mean replacing "./python -m test.bisect ..." with "./python -m 
test.bisect_cmd ...", not a big deal.

What do you think of renaming the script?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30657] Unsafe arithmetic in PyString_DecodeEscape

[Larry Hastings]

Larry Hastings  added the comment:

I would welcome a backport of this for 3.5 and even 3.4 (if it's vulnerable, 
which it probably is).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27068] Add a detach() method to subprocess.Popen

[STINNER Victor]

STINNER Victor  added the comment:

Sorry, but I'm not sure that it's a good idea to add a detach() method. It's 
hard to follow who owns all resources attached to a process, not only it's pid, 
but also streams which may be buffered. I propose the close the issue.

The webbrowser issue can be fixed differently without detach().

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23719] PEP 475: port test_eintr to Windows

[STINNER Victor]

STINNER Victor  added the comment:

Sorry, I lost track of this idea, and I was unable to review 
win32-sleep-test.diff :-( While it would be "nice to have", the code is well 
tested on Unix. I close the issue.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31805] support._is_gui_available() hangs on x86-64 Sierra 3.6/3.x buildbot

[STINNER Victor]

STINNER Victor  added the comment:

The issue is gone.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31520] ResourceWarning: unclosed warning

[STINNER Victor]

STINNER Victor  added the comment:

I'm not confortable to expose the value of the private _io_refs attribute in 
repr(socket.socket). I'm not sure that anything should really be done here. I 
close the issue.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31911] Use malloc_usable_size() in pymalloc for realloc

[STINNER Victor]

STINNER Victor  added the comment:

I agree. I don't think that it's worth it to overcompilates the API.

I proposed this change since we may change the API to add PyMem_AlignedAlloc(). 
Since I just rejected bpo-18835, it's no more the case.

I close this issue as rejected.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32050] Fix -x option documentation

[STINNER Victor]

STINNER Victor  added the comment:

The initial proposition was to *deprecate* the option.

In the meanwhile, I removed an outdated note.

While the documentation is not perfect, I don't feel confortable to fix it, so 
I left it unchanged.

I close this PR. Please open a new issue (with a PR if possible ;-)) if you 
want to enhance -x option documentation.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32089] In developer mode (-X dev), ResourceWarning is only emited once per line numbers

[STINNER Victor]

STINNER Victor  added the comment:

Antoine: What do you think of using the "default" action for pydebug build and 
-X dev?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31626] Writing in freed memory in _PyMem_DebugRawRealloc() after shrinking a memory block

[STINNER Victor]

STINNER Victor  added the comment:

Serhiy: I added a Py_FatalError() to Python 2.7 if the case that must not 
happen does happen. Are you ok to apply the same change for Python 3.6 (commit 
ed4743a2f2bb8d88f7f1aa9307794be9a44f1e0f), or do you prefer to backport your 
more complex patch using a small buffer allocated on the stack?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31626] Writing in freed memory in _PyMem_DebugRawRealloc() after shrinking a memory block

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ed4743a2f2bb8d88f7f1aa9307794be9a44f1e0f by Victor Stinner in 
branch '2.7':
bpo-31626: Fix _PyObject_DebugReallocApi() (#4310)
https://github.com/python/cpython/commit/ed4743a2f2bb8d88f7f1aa9307794be9a44f1e0f


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31543] Optimize wrapper descriptors using FASTCALL

[STINNER Victor]

STINNER Victor  added the comment:

It seems like these specific descriptors are rare, so the added complexity is 
not worth it. I close my issue as rejected.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18835] Add PyMem_AlignedAlloc()

[STINNER Victor]

STINNER Victor  added the comment:

Because of the lack of strong motivition compared to the size of the change and 
the cost to maintain it, I reject this issue. For the archives, I attach a copy 
of the latest version of my implementation.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed
Added file: https://bugs.python.org/file47285/pymem_alignedalloc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Ian Kelly]

On Thu, Nov 23, 2017 at 2:19 PM, Richard Damon  wrote:
> The Unicode Standard provides a fairly good classification of the
> characters, and it would make sense to define that an character that is
> defined as a 'Letter' or a 'Number', and some classes of Punctuation
> (connector and dash) be allowed in identifiers.
>
> Fully implementing may be more complicated than it is worth. An interim
> simple solution would be just allow ALL (or maybe most, excluding a limited
> number of obvious exceptions) of the characters above the ASCII set, with a
> warning that only those classified as above are promised to remain valid,
> and that other characters, while currently not generating a syntax error,
> may do so in the future. It should also be stated that while currently no
> character normalization is being done, it may be added in the future, so
> identifiers that differ only by code point sequences that are defined as
> being equivalent, might in the future not be distinct.

It's already implemented; nothing needs to be done. Unicode Standard
Annex #31 defines a recommended syntax of identifiers, which Python
basically follows, except that for backward compatibility Python also
allows identifiers to begin with an underscore. Compare the
recommended syntax at
http://unicode.org/reports/tr31/#Default_Identifier_Syntax with the
Python syntax at
https://docs.python.org/3/reference/lexical_analysis.html#identifiers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Ian Kelly]

On Thu, Nov 23, 2017 at 1:04 PM, Karsten Hilbert
 wrote:
> On Thu, Nov 23, 2017 at 08:46:01PM +0100, Thomas Jollans wrote:
>
>> > I mean for a real practical situation - for example for an average
>> > Python programmer or someone who seeks a programmer job.
>> > And who does not have a 500-key keyboard,
>>
>> I don't think it's too much to ask for a programmer to have the
>> technology and expertise necessary to type their own language in its
>> proper alphabet.
>
> Surely, but it can make reusing code a nightmare.
>
> Using function arguments written in Thai script ?
>
> Understanding, let alone being able to read, code written in Arabic ?

People are going to write code in Arabic whether you like it or not,
because not everybody speaks English, and not everybody who does
*wants* to use it. Now, would you prefer to read code where the
variable names are written in Arabic script, or where the variable
names are still in Arabic but transliterated to Latin characters?
Either way, you're not going to be able to understand it, so I'm not
sure why it makes a difference to you.

If Arabic characters are allowed however, then it might be of use to
the people who are going to code in Arabic anyway. And if it isn't,
then they have the option not to use it either.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32121] tracemalloc.Traceback.format() should have an option to reverse the traceback

[Jesse Bakker]

Jesse Bakker  added the comment:

I can work on this if you want. Can have a PR ready in a few minutes.

--
nosy: +Jesse Bakker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32121] tracemalloc.Traceback.format() should have an option to reverse the traceback

[Jesse Bakker]

Change by Jesse Bakker :


--
keywords: +patch
pull_requests: +4470
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31325] req_rate is a namedtuple type rather than instance

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31325] req_rate is a namedtuple type rather than instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset ff847d1ac7e6a8ee1fb6f8883cfb4aec4b4a9b03 by Raymond Hettinger 
(Miss Islington (bot)) in branch '3.6':
bpo-31325: Fix usage of namedtuple in RobotFileParser.parse() (GH-4529) (#4533)
https://github.com/python/cpython/commit/ff847d1ac7e6a8ee1fb6f8883cfb4aec4b4a9b03


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31325] req_rate is a namedtuple type rather than instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 3df02dbc8e197053105f9dffeae40b04ec66766e by Raymond Hettinger 
(Berker Peksag) in branch 'master':
bpo-31325: Fix usage of namedtuple in RobotFileParser.parse() (#4529)
https://github.com/python/cpython/commit/3df02dbc8e197053105f9dffeae40b04ec66766e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31325] req_rate is a namedtuple type rather than instance

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4469

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Thomas Jollans]

On 24/11/17 00:18, Richard Damon wrote:
> On 11/23/17 5:45 PM, Thomas Jollans wrote:
>> On 23/11/17 23:15, Richard Damon wrote:
>>> My thought is you define a legal only those Unicode characters that via
>>> the defined classification would be normally legal, but perhaps the
>>> first implementation doesn't diagnose many of the illegal combinations.
>>> If that isn't Pythonic, then yes, implementing a fuller classification
>>> would be needed. That might also say normalization questions would need
>>> to be decided too.
>>>
>> You do realise that Python has a perfectly good definition of what's
>> allowed in an identifier that is thoroughly grounded in the Unicode
>> standard and works very well, right?
>>
>>
>> -- Thomas
> 
> No, I wasn't aware that Python was already Unicode enabled in the source
> code set. Still fairly new with it, but the fact that people seemed to
> argue about doing it made me think it was allowed yet.
> 

It's an old favourite some people to shout about on slow news days...

Python allows identifiers to start with any letter or an underscore, and
continue with any letter or number, or an underscore. The details follow
the Unicode XID_* properties.

In comments and strings, anything goes.


-- Thomas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Richard Damon]

On 11/23/17 5:45 PM, Thomas Jollans wrote:

On 23/11/17 23:15, Richard Damon wrote:

My thought is you define a legal only those Unicode characters that via
the defined classification would be normally legal, but perhaps the
first implementation doesn't diagnose many of the illegal combinations.
If that isn't Pythonic, then yes, implementing a fuller classification
would be needed. That might also say normalization questions would need
to be decided too.


You do realise that Python has a perfectly good definition of what's
allowed in an identifier that is thoroughly grounded in the Unicode
standard and works very well, right?


-- Thomas


No, I wasn't aware that Python was already Unicode enabled in the source 
code set. Still fairly new with it, but the fact that people seemed to 
argue about doing it made me think it was allowed yet.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

[issue32096] Py_DecodeLocale() fails if used before the runtime is initialized.

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4467

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30860] Consolidate stateful C globals under a single struct.

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4468

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Thomas Jollans]

On 23/11/17 23:15, Richard Damon wrote:
> 
> My thought is you define a legal only those Unicode characters that via
> the defined classification would be normally legal, but perhaps the
> first implementation doesn't diagnose many of the illegal combinations.
> If that isn't Pythonic, then yes, implementing a fuller classification
> would be needed. That might also say normalization questions would need
> to be decided too.
> 

You do realise that Python has a perfectly good definition of what's
allowed in an identifier that is thoroughly grounded in the Unicode
standard and works very well, right?


-- Thomas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Richard Damon]

On 11/23/17 4:31 PM, Chris Angelico wrote:

On Fri, Nov 24, 2017 at 8:19 AM, Richard Damon  wrote:

On 11/23/17 2:46 PM, Thomas Jollans wrote:

On 23/11/17 19:42, Mikhail V wrote:

I mean for a real practical situation - for example for an average
Python programmer or someone who seeks a programmer job.
And who does not have a 500-key keyboard,

I don't think it's too much to ask for a programmer to have the
technology and expertise necessary to type their own language in its
proper alphabet.


My personal feeling is that the language needs to be fully usable with just
ASCII, so the - character (HYPHEN/MINUS) is the subtraction/negation
operator, not an in-name hyphen. This also means the main library should use
just the ASCII character set.

I do also realize that it could be very useful for programmers who are
programming with other languages as their native, to be able to use words in
their native language for their own symbols, and thus useful to use their
own character sets. Yes, doing so may add difficulty to the programmers, as
they may need to be switching keyboard layouts (especially if not using a
LATIN based language), but that is THEIR decision to do so. It also may make
it harder for outside programmers to hep, but again, that is the teams
decision to make.

The Unicode Standard provides a fairly good classification of the
characters, and it would make sense to define that an character that is
defined as a 'Letter' or a 'Number', and some classes of Punctuation
(connector and dash) be allowed in identifiers.

That's exactly how Python's identifiers are defined (modulo special
handling of some of the ASCII set, for reasons of backward
compatibility).


Fully implementing may be more complicated than it is worth. An interim
simple solution would be just allow ALL (or maybe most, excluding a limited
number of obvious exceptions) of the characters above the ASCII set, with a
warning that only those classified as above are promised to remain valid,
and that other characters, while currently not generating a syntax error,
may do so in the future. It should also be stated that while currently no
character normalization is being done, it may be added in the future, so
identifiers that differ only by code point sequences that are defined as
being equivalent, might in the future not be distinct.

No, that would be a bad idea; some of those characters are more
logically operators or brackets, and some are most definitely
whitespace. Also, it's easier to *expand* the valid character set than
to *restrict* it, so it's better to start with only those characters
that you know for sure make sense, and then add more later. If the
xid_start and xid_continue classes didn't exist, it might be
reasonable to use "Letter, any" and "Number, any" as substitutes; but
those classes DO exist, so Python uses them.

But broadly speaking, yes; it's not hard to allow a bunch of
characters as part of Python source code. Actual language syntax (eg
keywords) is restricted to ASCII and to those symbols that can easily
be typed on most keyboards, but your identifiers are your business.

ChrisA


My thought is you define a legal only those Unicode characters that via 
the defined classification would be normally legal, but perhaps the 
first implementation doesn't diagnose many of the illegal combinations. 
If that isn't Pythonic, then yes, implementing a fuller classification 
would be needed. That might also say normalization questions would need 
to be decided too.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

[issue32099] Use range in itertools roundrobin recipe

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 0858495a50e19defde786a4ec050ec182e920f46 by Raymond Hettinger in 
branch 'master':
bpo-32099 Add deque variant of roundrobin() recipe (#4497)
https://github.com/python/cpython/commit/0858495a50e19defde786a4ec050ec182e920f46


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32099] Use range in itertools roundrobin recipe

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Chris Angelico]

On Fri, Nov 24, 2017 at 8:19 AM, Richard Damon  wrote:
> On 11/23/17 2:46 PM, Thomas Jollans wrote:
>>
>> On 23/11/17 19:42, Mikhail V wrote:
>>>
>>> I mean for a real practical situation - for example for an average
>>> Python programmer or someone who seeks a programmer job.
>>> And who does not have a 500-key keyboard,
>>
>> I don't think it's too much to ask for a programmer to have the
>> technology and expertise necessary to type their own language in its
>> proper alphabet.
>
>
> My personal feeling is that the language needs to be fully usable with just
> ASCII, so the - character (HYPHEN/MINUS) is the subtraction/negation
> operator, not an in-name hyphen. This also means the main library should use
> just the ASCII character set.
>
> I do also realize that it could be very useful for programmers who are
> programming with other languages as their native, to be able to use words in
> their native language for their own symbols, and thus useful to use their
> own character sets. Yes, doing so may add difficulty to the programmers, as
> they may need to be switching keyboard layouts (especially if not using a
> LATIN based language), but that is THEIR decision to do so. It also may make
> it harder for outside programmers to hep, but again, that is the teams
> decision to make.
>
> The Unicode Standard provides a fairly good classification of the
> characters, and it would make sense to define that an character that is
> defined as a 'Letter' or a 'Number', and some classes of Punctuation
> (connector and dash) be allowed in identifiers.

That's exactly how Python's identifiers are defined (modulo special
handling of some of the ASCII set, for reasons of backward
compatibility).

> Fully implementing may be more complicated than it is worth. An interim
> simple solution would be just allow ALL (or maybe most, excluding a limited
> number of obvious exceptions) of the characters above the ASCII set, with a
> warning that only those classified as above are promised to remain valid,
> and that other characters, while currently not generating a syntax error,
> may do so in the future. It should also be stated that while currently no
> character normalization is being done, it may be added in the future, so
> identifiers that differ only by code point sequences that are defined as
> being equivalent, might in the future not be distinct.

No, that would be a bad idea; some of those characters are more
logically operators or brackets, and some are most definitely
whitespace. Also, it's easier to *expand* the valid character set than
to *restrict* it, so it's better to start with only those characters
that you know for sure make sense, and then add more later. If the
xid_start and xid_continue classes didn't exist, it might be
reasonable to use "Letter, any" and "Number, any" as substitutes; but
those classes DO exist, so Python uses them.

But broadly speaking, yes; it's not hard to allow a bunch of
characters as part of Python source code. Actual language syntax (eg
keywords) is restricted to ASCII and to those symbols that can easily
be typed on most keyboards, but your identifiers are your business.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29302] add contextlib.AsyncExitStack

[privatwolke]

Change by privatwolke :


--
nosy: +privatwolke

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32121] tracemalloc.Traceback.format() should have an option to reverse the traceback

[STINNER Victor]

STINNER Victor  added the comment:

The option seems reasonable. Would you like to work on a pull request?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Richard Damon]

On 11/23/17 2:46 PM, Thomas Jollans wrote:

On 23/11/17 19:42, Mikhail V wrote:

I mean for a real practical situation - for example for an average
Python programmer or someone who seeks a programmer job.
And who does not have a 500-key keyboard,

I don't think it's too much to ask for a programmer to have the
technology and expertise necessary to type their own language in its
proper alphabet.


My personal feeling is that the language needs to be fully usable with 
just ASCII, so the - character (HYPHEN/MINUS) is the 
subtraction/negation operator, not an in-name hyphen. This also means 
the main library should use just the ASCII character set.


I do also realize that it could be very useful for programmers who are 
programming with other languages as their native, to be able to use 
words in their native language for their own symbols, and thus useful to 
use their own character sets. Yes, doing so may add difficulty to the 
programmers, as they may need to be switching keyboard layouts 
(especially if not using a LATIN based language), but that is THEIR 
decision to do so. It also may make it harder for outside programmers to 
hep, but again, that is the teams decision to make.


The Unicode Standard provides a fairly good classification of the 
characters, and it would make sense to define that an character that is 
defined as a 'Letter' or a 'Number', and some classes of Punctuation 
(connector and dash) be allowed in identifiers.


Fully implementing may be more complicated than it is worth. An interim 
simple solution would be just allow ALL (or maybe most, excluding a 
limited number of obvious exceptions) of the characters above the ASCII 
set, with a warning that only those classified as above are promised to 
remain valid, and that other characters, while currently not generating 
a syntax error, may do so in the future. It should also be stated that 
while currently no character normalization is being done, it may be 
added in the future, so identifiers that differ only by code point 
sequences that are defined as being equivalent, might in the future not 
be distinct.


Since my native language is English, this isn't that important to me, 
but I do see it as being useful to others with different native tongues. 
The simple implementation shouldn't be that hard, you can just allow 
character codes 0x80 and above as being acceptable in identifiers, with 
the documented warning that the current implementation allows some forms 
that may generate errors in the future. If enough interest is shown, 
adding better classification shouldn't be that hard.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Chris Angelico]

On Fri, Nov 24, 2017 at 8:02 AM, Mikhail V  wrote:
> On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico  wrote:
>> On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V  wrote:
>>> I see you manually 'optimise' the look?
>>> I personally would end with something like this:
>>>
>>> def zip_longest(*A, **K):
>>> value = K.get ('fillvalue')
>>> count = len(a) - 1
>>> def sentinel():
>>> nonlocal count
>>> if not count:
>>> raise ZipExhausted
>>> count -= 1
>>> yield  value
>>> fillers = repeat (value)
>>> iterators = [chain (it, sentinel(), fillers) for it in A]
>>> try:
>>> while iterators:
>>> yield tuple (map (next, iterators))
>>> except ZipExhausted:
>>> pass
>>>
>>>
>>> So I would say, my option would be something inbetween.
>>> Note that I tweaked it for proportional font, namely Times New Roman.
>
>> I don't see how the font applies here, but whatever.
>
> For a different font, say CourierNew (monospaced) the tweaking strategy might
> be different.

If you have ANY font-specific "tweaking", you're doing it wrong.
Thanks for making it look worse on everyone else's screen.

>> Which is better? The one-letter names or the longer ones that tie in with 
>> what they're
>> doing?
>
> I think I have answered more or less in previous post, that you cutted off.
> So you were not satisfied?
> But now I am probably not get your 'better' meaning.
> Better for understanding, or purely visually, i.e. less eye-straining?

Which one would you prefer to maintain? Which would you prefer in a code review?

Do you want to have one- and two-letter variable names, or longer and
more descriptive ones?

Seriously? Do I need to wrench this part out of you? This was supposed
to be the EASY question that everyone can agree on, from which I can
then draw my line of argument.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico  wrote:
> On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V  wrote:
>> I see you manually 'optimise' the look?
>> I personally would end with something like this:
>>
>> def zip_longest(*A, **K):
>> value = K.get ('fillvalue')
>> count = len(a) - 1
>> def sentinel():
>> nonlocal count
>> if not count:
>> raise ZipExhausted
>> count -= 1
>> yield  value
>> fillers = repeat (value)
>> iterators = [chain (it, sentinel(), fillers) for it in A]
>> try:
>> while iterators:
>> yield tuple (map (next, iterators))
>> except ZipExhausted:
>> pass
>>
>>
>> So I would say, my option would be something inbetween.
>> Note that I tweaked it for proportional font, namely Times New Roman.

> I don't see how the font applies here, but whatever.

For a different font, say CourierNew (monospaced) the tweaking strategy might
be different.

> Which is better? The one-letter names or the longer ones that tie in with 
> what they're
> doing?

I think I have answered more or less in previous post, that you cutted off.
So you were not satisfied?
But now I am probably not get your 'better' meaning.
Better for understanding, or purely visually, i.e. less eye-straining?

> Also, why do you have those loose spaces stuck in random places, eg
> before some of the open parentheses but not others?

Is it not allowed? I like how it looks with Times font.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Chris Angelico]

On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V  wrote:
> I see you manually 'optimise' the look?
> I personally would end with something like this:
>
> def zip_longest(*A, **K):
> value = K.get ('fillvalue')
> count = len(a) - 1
> def sentinel():
> nonlocal count
> if not count:
> raise ZipExhausted
> count -= 1
> yield  value
> fillers = repeat (value)
> iterators = [chain (it, sentinel(), fillers) for it in A]
> try:
> while iterators:
> yield tuple (map (next, iterators))
> except ZipExhausted:
> pass
>
>
> So I would say, my option would be something inbetween.
> Note that I tweaked it for proportional font, namely Times New Roman.

I don't see how the font applies here, but whatever. Which is better?
The one-letter names or the longer ones that tie in with what they're
doing?

Also, why do you have those loose spaces stuck in random places, eg
before some of the open parentheses but not others?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 8:15 PM, Chris Angelico  wrote:

>
> Let's start with a simpler question. Which of these is better code?
>
> # == Option 1
> class ZipExhausted(Exception):
> pass
>
> def zip_longest(*args, **kwds):
> # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
> fillvalue = kwds.get('fillvalue')
> counter = len(args) - 1
> def sentinel():
> nonlocal counter
> if not counter:
> raise ZipExhausted
> counter -= 1
> yield fillvalue
> fillers = repeat(fillvalue)
> iterators = [chain(it, sentinel(), fillers) for it in args]
> try:
> while iterators:
> yield tuple(map(next, iterators))
> except ZipExhausted:
> pass
>
> # = Option 2
>
> class e(Exception):
> pass
>
> def zl(*a, **k):
> f = f.get('fillvalue')
> c = len(a) - 1
> def s():
> nonlocal c
> if not c:
> raise e
> c -= 1
> yield f
> ff = repeat(f)
> i = [chain(i, s(), ff) for i in args]
> try:
> while i:
> yield tuple(map(next, i))
> except e:
> pass
>
> # 
>
> One of them is cribbed straight from the itertools docs. The other is
> the same functionality with shorter variable names. What makes one of
> them better than the other? Answer me that, and I'll continue.


I see you manually 'optimise' the look?
I personally would end with something like this:

def zip_longest(*A, **K):
value = K.get ('fillvalue')
count = len(a) - 1
def sentinel():
nonlocal count
if not count:
raise ZipExhausted
count -= 1
yield  value
fillers = repeat (value)
iterators = [chain (it, sentinel(), fillers) for it in A]
try:
while iterators:
yield tuple (map (next, iterators))
except ZipExhausted:
pass


So I would say, my option would be something inbetween.
Note that I tweaked it for proportional font, namely Times New Roman.

Particularly I find too narrow lines/words a bit eye-straining at times.
Also self-explanation is important in many cases. But that depends of
what context you cut the example.

But if you only ask which code of two looks better for me,
then, probably Second, but it has some issues for me, e.g. "c" and "e"
almost homoglyhs, too loose 'sieve'-like, short lines.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30456] 2to3 docs: example of fix for duplicates in second argument of isinstance has superfluous parentheses

[Berker Peksag]

Berker Peksag  added the comment:

Looks like I forgot to backport this 3.6 branch. Now it's done. Thanks, Eli.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30456] 2to3 docs: example of fix for duplicates in second argument of isinstance has superfluous parentheses

[Berker Peksag]

Berker Peksag  added the comment:


New changeset a645b23ffc76073a2eb4e77b88cb7648cfc6ef77 by Berker Peksag in 
branch '3.6':
bpo-30456: Clarify example for duplicates in second argument of isinstance 
(GH-1699)
https://github.com/python/cpython/commit/a645b23ffc76073a2eb4e77b88cb7648cfc6ef77


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30456] 2to3 docs: example of fix for duplicates in second argument of isinstance has superfluous parentheses

[Berker Peksag]

Change by Berker Peksag :


--
keywords: +patch
pull_requests: +4466
stage: backport needed -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32121] tracemalloc.Traceback.format() should have an option to reverse the traceback

[Antoine Pitrou]

New submission from Antoine Pitrou :

Right now tracemalloc.Traceback.format() returns the frames in "most recent 
call first" order.  This is not intuitive since ordinary Python tracebacks are 
displayed in "most recent call last" order.  It would be nice to add a 
`reverse` argument to change that.

--
components: Library (Lib)
messages: 306856
nosy: pitrou, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: tracemalloc.Traceback.format() should have an option to reverse the 
traceback
type: enhancement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 8:46 PM, Thomas Jollans  wrote:
> On 23/11/17 19:42, Mikhail V wrote:
>> I mean for a real practical situation - for example for an average
>> Python programmer or someone who seeks a programmer job.
>> And who does not have a 500-key keyboard,
>
> I don't think it's too much to ask for a programmer to have the
> technology and expertise necessary to type their own language in its
> proper alphabet.

And I don't think it is too much of benefit of using two scripts in one
source to compensate the need to constantly switching. Do you
have a method to input e.g. Cyrillic and Latin without switching the
layout? If I just use few extra chars, then I'll bind a keyboard shortcut.
but even a two-language input is annoyance.
And I need to use Cyrillic and Latin constantly, so I know how it feels.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Karsten Hilbert]

On Thu, Nov 23, 2017 at 08:46:01PM +0100, Thomas Jollans wrote:

> > I mean for a real practical situation - for example for an average
> > Python programmer or someone who seeks a programmer job.
> > And who does not have a 500-key keyboard, 
> 
> I don't think it's too much to ask for a programmer to have the
> technology and expertise necessary to type their own language in its
> proper alphabet.

Surely, but it can make reusing code a nightmare.

Using function arguments written in Thai script ?

Understanding, let alone being able to read, code written in Arabic ?

No, thanks.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32107] test_uuid uses the incorrect bitmask

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'm sorry, but this tests and the typo were added by me in issue23015. This 
check is a pair of the check for _random_getnode(). They use the same mask and 
test the same bit. I forgot about this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Thomas Jollans]

On 23/11/17 19:42, Mikhail V wrote:
> I mean for a real practical situation - for example for an average
> Python programmer or someone who seeks a programmer job.
> And who does not have a 500-key keyboard, 

I don't think it's too much to ask for a programmer to have the
technology and expertise necessary to type their own language in its
proper alphabet.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32107] test_uuid uses the incorrect bitmask

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Nov 23, 2017, at 11:24, Serhiy Storchaka  wrote:

> Wait, now I understand the purpose of the current test! There is just a typo 
> in a comment, should be 41 instead of 47. The test itself is correct. If the 
> address is obtained from network cards, it should have the 41 bit clear. If 
> it is generated randomly, it should have the 41 bit set, to avoid conflicts 
> with addresses obtained from network cards. There is nothing about the 42 bit.

It’s not just a typo in the comment, it’s a typo in the bitmask, at least if 
the intent of the test is to ensure that the MAC address is universally 
administered.  That is defined as having a 0 in the “second least significant 
bit of the first octet”.  Here’s a way to make that clearer.

# Second least significant bit of the first octet of the 48-bit MAC address
>>> 0b0010_____
219902322
# Constant from the PR
>>> 1<<41
219902322
# Literal bit mask from the original code.
>>> 0x0100
1099511627776

The latter is off by 1 place.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31325] req_rate is a namedtuple type rather than instance

[Berker Peksag]

Change by Berker Peksag :


--
keywords: +patch
pull_requests: +4465

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Chris Angelico]

On Fri, Nov 24, 2017 at 5:42 AM, Mikhail V  wrote:
> Chris A wrote:
>
>>> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote:
>>>
 Chris A wrote:

 Fortunately for the world, you're not the one who decided which
 characters were permitted in Python identifiers. The ability to use
 non-English words for function/variable names is of huge value; the
 ability to use a hyphen is of some value, but not nearly as much.
>>>
>>> Fortunately for the world we have Chris A. Who knows what is
>>> fortunate and of huge values.
>>> So is there any real world projects example of usage of non-latin scripts
>>> in identifiers? Or is it still only a plan for the new world?
>
>
>> Yes, I've used them personally. And I know other people who have.
>
>
> Oh, I though it would be more impressive showcase for 'huge value'.
> If we drop the benefit of the bare fact that you can do it, or you just
> don't know English, how would describe the practical benefit?
> If you don't know english, then programming at all will be just too hard.
> (or one must define a new whole language specially for some local script)

Let's start with a simpler question. Which of these is better code?

# == Option 1
class ZipExhausted(Exception):
pass

def zip_longest(*args, **kwds):
# zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
fillvalue = kwds.get('fillvalue')
counter = len(args) - 1
def sentinel():
nonlocal counter
if not counter:
raise ZipExhausted
counter -= 1
yield fillvalue
fillers = repeat(fillvalue)
iterators = [chain(it, sentinel(), fillers) for it in args]
try:
while iterators:
yield tuple(map(next, iterators))
except ZipExhausted:
pass

# = Option 2

class e(Exception):
pass

def zl(*a, **k):
f = f.get('fillvalue')
c = len(a) - 1
def s():
nonlocal c
if not c:
raise e
c -= 1
yield f
ff = repeat(f)
i = [chain(i, s(), ff) for i in args]
try:
while i:
yield tuple(map(next, i))
except e:
pass

# 

One of them is cribbed straight from the itertools docs. The other is
the same functionality with shorter variable names. What makes one of
them better than the other? Answer me that, and I'll continue.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue12382] [msilib] Obscure exception message when trying to open a non-existent MSI database

[Berker Peksag]

Change by Berker Peksag :


--
pull_requests: +4464
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

Chris A wrote:

>> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote:
>>
>>> Chris A wrote:
>>>
>>> Fortunately for the world, you're not the one who decided which
>>> characters were permitted in Python identifiers. The ability to use
>>> non-English words for function/variable names is of huge value; the
>>> ability to use a hyphen is of some value, but not nearly as much.
>>
>> Fortunately for the world we have Chris A. Who knows what is
>> fortunate and of huge values.
>> So is there any real world projects example of usage of non-latin scripts
>> in identifiers? Or is it still only a plan for the new world?


> Yes, I've used them personally. And I know other people who have.


Oh, I though it would be more impressive showcase for 'huge value'.
If we drop the benefit of the bare fact that you can do it, or you just
don't know English, how would describe the practical benefit?
If you don't know english, then programming at all will be just too hard.
(or one must define a new whole language specially for some local script)

I mean for a real practical situation - for example for an average
Python programmer or someone who seeks a programmer job.
And who does not have a 500-key keyboard, and who has
a not enough high threshold of vision sensitivity to bear the look
of various scripts in one small text piece?

Ok, I personally could find some practical usage for that, but
merely for fun. I doubt though that someone with less
typographical experience and overall computer literacy could
really make benefits even for personal usage.

So - fun is one benefit. And fun is important. But is that the
idea behind it?


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

[Berker Peksag]

Berker Peksag  added the comment:


New changeset dcaed6b2d954786eb5369ec2e8dfdeefe3cdc6ae by Berker Peksag in 
branch 'master':
bpo-19610: setup() now raises TypeError for invalid types (GH-4519)
https://github.com/python/cpython/commit/dcaed6b2d954786eb5369ec2e8dfdeefe3cdc6ae


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

[Berker Peksag]

Change by Berker Peksag :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31979] Simplify converting non-ASCII strings to int, float and complex

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 6a54c676e63517653d3d4a1e164bdd0fd45132d8 by Victor Stinner in 
branch 'master':
bpo-31979: Remove unused align_maxchar() function (#4527)
https://github.com/python/cpython/commit/6a54c676e63517653d3d4a1e164bdd0fd45132d8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b9197959c186f9061bd74d0adc20e96556426db4 by Victor Stinner in 
branch 'master':
bpo-32030: Fix calculate_path() on macOS (#4526)
https://github.com/python/cpython/commit/b9197959c186f9061bd74d0adc20e96556426db4


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31324] support._match_test() used by test.bisect is very inefficient

[STINNER Victor]

STINNER Victor  added the comment:

I tested set_match_tests() on python2.7 with:

python2.7 -m test --list-cases > cases
python2.7 -m test.bisect -i cases

Good news: the set().__contains__ matcher can be used!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31324] support._match_test() used by test.bisect is very inefficient

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 35d99830f1878867e3964577741d9a2d5a7fc8f7 by Victor Stinner in 
branch '2.7':
bpo-31324: Optimize support._match_test() (#4523) (#4524)
https://github.com/python/cpython/commit/35d99830f1878867e3964577741d9a2d5a7fc8f7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32055] Reconsider comparison chaining for containment tests

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'm reading the list of most rated in a week questions on StackOverflow 
(https://python-weekly.blogspot.com/), and it seems to me that the question 
about chained "in" and "not in" is raised every few months. This may be the one 
of the most confusing quirks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> How about not posting about this topic for 24 hours.

OK, makes sense :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Guido van Rossum]

Guido van Rossum  added the comment:

I think we all need to calm down a bit. How about not posting about this
topic for 24 hours.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31979] Simplify converting non-ASCII strings to int, float and complex

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4463

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4462

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13986] ValueError: cannot convert float NaN to integer

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy:  -gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Guido, I am not sure about the complete removal, this is probably to radical. 
What I think we are missing more detailed docs that would be clear about the 
corner cases. (I already mentioned this in https://bugs.python.org/issue32113)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31324] support._match_test() used by test.bisect is very inefficient

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4461

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Yury Selivanov]

Yury Selivanov  added the comment:

> Yury OK, sorry then this is a misunderstanding from my side.

NP.  Again, sorry if I sounded that way to you.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Yury OK, sorry then this is a misunderstanding from my side.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Yury Selivanov]

Yury Selivanov  added the comment:

>> Do you understand the difference?

> Yury, sorry, but what is your problem? Have I said something about that this 
> is bad. Your tone is clearly insulting, and this is not the first time. Maybe 
> it makes sense to have some respect?

Sorry, I didn't mean to insult anybody.  I asked an honest question with an 
intent to clarify if there's some misunderstanding of the topic that I'm 
partially responsible for in CPython.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Do you understand the difference?

Yury, sorry, but what is your problem? Have I said something about that this is 
bad. Your tone is clearly insulting, and this is not the first time. Maybe it 
makes sense to have some respect?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31324] support._match_test() used by test.bisect is very inefficient

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 70b2f8797146a56a6880743424f0bedf4fc30c62 by Victor Stinner in 
branch '3.6':
[3.6] bpo-31324: Optimize support._match_test() (#4523)
https://github.com/python/cpython/commit/70b2f8797146a56a6880743424f0bedf4fc30c62


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Yury Selivanov]

Yury Selivanov  added the comment:

> Well, after all I am thinking maybe it is indeed makes sense to ban `yield` 
> inside both sync/async and both comprehensions/generator expressions.

I agree, as I can't imagine a real use case for

   a = ((yield a) for a in as)

which is really equivalent to

   def a():
  for a in as:
 yield (yield a)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Guido van Rossum]

Guido van Rossum  added the comment:

I honestly think we went too far here. Asynchronous generators are still
provisional. Though the PEP is silent about this, the acceptance notice is
clear:
https://mail.python.org/pipermail/python-dev/2016-September/146267.html. I
propose to rip them out.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

Well, after all I am thinking maybe it is indeed makes sense to ban `yield` 
inside both sync/async and both comprehensions/generator expressions. Since we 
already have a smörgåsbord of intuitive behaviors.

This, _together_ with extensive clarification to the docs and error messages 
can fix the problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Yury Selivanov]

Yury Selivanov  added the comment:

> ... but [await x for x in xs] is still valid _only_ inside async def.

Yes, because it's computed right where it is defined.

a = [x for x in xs]  # `a` is a list object
a = (x for x in xs)  # `a` is a generator

Do you understand the difference?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

... but [await x for x in xs] is still valid _only_ inside async def.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Yury Selivanov]

Yury Selivanov  added the comment:

It's also important to note, that in 3.7, this is legal:

  def foo():
return (await x for x in xs)

Note that 'foo' is a regular function, not 'async def'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Yury Selivanov]

Yury Selivanov  added the comment:

> Yury explained why this happens in https://bugs.python.org/issue32113

It happens because '(x for x in xs)' creates a synchronous generator.  So when 
there's an 'await' in it, it creates an asynchronous generator.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

(Of course there should be not [1, 2] in the argument, but a list of some 
awaitables, otherwise there will be an error later.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

> Remind me what happens when you use `await` in a generator expression that 
> survives the async function's scope?

Awaiting on f([1, 2]) will result in an async generator (even though yield 
never appears here). Yury explained why this happens in 
https://bugs.python.org/issue32113

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32107] test_uuid uses the incorrect bitmask

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Wait, now I understand the purpose of the current test! There is just a typo in 
a comment, should be 41 instead of 47. The test itself is correct. If the 
address is obtained from network cards, it should have the 41 bit clear. If it 
is generated randomly, it should have the 41 bit set, to avoid conflicts with 
addresses obtained from network cards. There is nothing about the 42 bit.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10544] yield expression inside generator expression does nothing

[Guido van Rossum]

Guido van Rossum  added the comment:

Remind me what happens when you use `await` in a generator expression that
survives the async function's scope?

async def f(xs):
return (await x for x in xs)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27535] Ignored ResourceWarning warnings leak memory in warnings registries

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b98f1715a35d2cbd1e9e45e1e7ae51a39e00dc4a by Victor Stinner in 
branch 'master':
bpo-27535: Cleanup create_filter() (#4516)
https://github.com/python/cpython/commit/b98f1715a35d2cbd1e9e45e1e7ae51a39e00dc4a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32118] Docs: add note about sequence comparisons containing non-orderable elements

[R. David Murray]

R. David Murray  added the comment:

The surprising thing is the behavior of NaN, which is *not equal* to itself.

The statement about orderability says "...are ordered the same as their first 
unequal elements".  This is explicit and unambiguous, there is no difference in 
this context between the number 1 and the singleton None, or the reflexivity 
enforced on NaN: all are equal to the corresponding element from the other 
sequence.  The whole point of the paragraph is that *no order test is done 
until the first unequal element is encountered*.

If we want to make this *more* explicit, I would suggest simply adding the 
following sentence after the first example in the original paragraph: "This 
means that reflexive elements that are otherwise unorderable (such as None and 
NaN) do not trigger a TypeError during a comparison."

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30657] Unsafe arithmetic in PyString_DecodeEscape

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Right, but it is not easy to exploit this bug. You need to parse Python sources 
longer than 512 MiB in 32-bit Python.

Python 3.5 currently takes only fixes for security bugs. I left on to Larry to 
decide whether it is worth to port the fix to 3.5.

--
nosy: +larry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29512] regrtest refleak: implement bisection feature

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 448c6739877a4143a2c3599f041fa6127f354044 by Victor Stinner in 
branch '2.7':
bpo-29512: Fix Lib/test/bisect.py shebang (#4522)
https://github.com/python/cpython/commit/448c6739877a4143a2c3599f041fa6127f354044


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0327bde9da203bb256b58218d012ca76ad0db4e4 by Victor Stinner in 
branch 'master':
bpo-32030: Rewrite calculate_path() (#4521)
https://github.com/python/cpython/commit/0327bde9da203bb256b58218d012ca76ad0db4e4


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31324] support._match_test() used by test.bisect is very inefficient

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4460

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29512] regrtest refleak: implement bisection feature

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +4459
stage: resolved -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30657] Unsafe arithmetic in PyString_DecodeEscape

[Leo kirotawa silva]

Leo kirotawa silva  added the comment:

I couldn't reproduce using the poc, but seems python3.5 is also vulnerable to 
this bug. The code from py3.5 are quite similar to 2.7. 
In py3.5: Objects/bytesobject.c PyBytes_DecodeEscape

--
nosy: +Leo kirotawa silva

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4458

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Allow additional separator character in variables

[Chris Angelico]

On Fri, Nov 24, 2017 at 1:39 AM, Mikhail V  wrote:
> Chris A wrote:
>
> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V  wrote:
>>
>> > Well, then there is some bitter irony in this, so it allows pretty
>> > much everything,
>> > but does not allow me to beautify code with hyphens.
>> > I can fully understand the wish to use non-latin scripts in strings or 
>> > comments.
>> > As for identifiers, IMO, apart from latin letters and underscore, the
>> > first unicode candidate
>> > I would add is U+2010. And probably the LAST one I would add.
>> >
>>
>> Fortunately for the world, you're not the one who decided which
>> characters were permitted in Python identifiers. The ability to use
>> non-English words for function/variable names is of huge value; the
>> ability to use a hyphen is of some value, but not nearly as much.
>>
>
>
> Fortunately for the world we have Chris A. Who knows what is
> fortunate and of huge values.
> So is there any real world projects example of usage of non-latin scripts
> in identifiers? Or is it still only a plan for the new world?

Yes, I've used them personally. And I know other people who have.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python loop and web server (bottle) in the same script

[Chris Angelico]

On Fri, Nov 24, 2017 at 1:27 AM,   wrote:
> I would like to have a script that collects data every minute and at the same 
> time serve newly collected data as web pages.
>
> Timely collecting data is more important than serving web pages, so 
> collecting data should have priority and should never be interrupted by 
> serving web pages.
>
> Looks like I need some sort of parallelization.

Sounds like you want threads. Spin off a thread that collects data and
sleeps, collects data and sleeps; meanwhile, serve web pages. But
there's no way you can *guarantee* that the serving of pages won't
interrupt data collection. With separate processes, you could
potentially use OS-level prioritization to help your data collection
process, but even then, it's not a guarantee. What are the
consequences of mistimed data collection?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list