[issue43347] IDLE crashes in macOS Apple chip, maybe completions

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This time I got a screen shot showing the gray completion box that appeared 
just as IDLE stopped responding and froze:

https://www.dropbox.com/s/eu3wd13vytz6tt8/Screen%20Shot%202021-03-22%20at%209.37.56%20PM.png?dl=0

Am now running Python 3.10.0a6 on Big Sur 11.2.3 running on a 2020 M-1 MacBook 
Air.

--

___
Python tracker 

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

[issue43601] Tools/c-analyzer/check-c-globals.py run throw exception err

[junyixie]

New submission from junyixie :

how to use Tools/c-analyzer/check-c-globals.py? 
in readme, 
python3 Tools/c-analyzer/check-c-globals.py

/Users/xiejunyi/cpython/Tools/c-analyzer/c_common/tables.py:236: FutureWarning: 
Possible nested set at position 12
  _COLSPEC_RE = re.compile(textwrap.dedent(r'''
Traceback (most recent call last):
  File "Tools/c-analyzer/check-c-globals.py", line 33, in 
(cmd, cmd_kwargs, verbosity, traceback_cm) = parse_args()
  File "Tools/c-analyzer/check-c-globals.py", line 16, in parse_args
_cli_check(parser, checks=''),
  File "/Users/xiejunyi/cpython/Tools/c-analyzer/cpython/__main__.py", line 
119, in _cli_check
return c_analyzer._cli_check(parser, CHECKS, **kwargs, **FILES_KWARGS)
TypeError: _cli_check() got multiple values for argument 'checks'

--
components: Demos and Tools
messages: 389370
nosy: JunyiXie
priority: normal
severity: normal
status: open
title: Tools/c-analyzer/check-c-globals.py run throw exception err
type: crash
versions: Python 3.10

___
Python tracker 

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

Re: .title() - annoying mistake

[Gene Heskett]

On Monday 22 March 2021 22:31:27 Richard Damon wrote:

> On 3/22/21 4:20 PM, Christian Gollwitzer wrote:
> > Am 22.03.21 um 16:03 schrieb Robert Latest:
> >> Chris Angelico wrote:
> >>> Cool thing is, nobody in Python needs to maintain anything here.
> >>
> >> That's great because I'm actually having trouble with sending log
> >> messages over
> >> the socket conection you helped me with, would you mind having a
> >> look?
> >
> > You misunderstood the "here".
> >
> > (native German as well, but I think it means "for keeping .title()
> > up to date)
> >
> > I agree with Chris that .title() can be useful for "title-casing" a
> > single character, whatever that means. It should be documented,
> > though, that it is not suitable to title-case a string, not even in
> > English.
> >
> > Christian
>
> Part of the difficulty in getting clear documentation for this is that
> is it IS somewhat complicated. You title-case a string by Title-casing
> the first character of each word (and the primary issue error that
> started this was the definition of a 'word'), and lower casing the
> rest of the word. The complication comes in that title-casing a
> character 99.99% of the time doesn't give you a character in
> title-case, but more often in upper-case (or uncased). There are
> apparently only 31 actual characters that are 'Title-Case'. Thus the
> action of 'title-casing' a character is a bit strange to describe,
> especially to people used to simple languages which don't have any of
> the characters that cause the issue.
>
> We don't seem to have a problme that upper doesn't always return a
> true 'upper-case', like for '1' because we realize that many character
> don't have case, so it gets largly just assumed we know that. For
> title case, the fact that almost all characters do NOT have a
> 'title-case' form makes things a bit more awkward.
>
> Yes, perhaps the documentation could be made a bit more clear. I do
> note that the documentation for str.capitalize() does talk about using
> actual title case characters if the first character is a digraph.
> Something like that might make sense in the description of str.title()
>
> Note, that str.istitle() doesn't actually check if the character is a
> real 'title case' character, but that the string follows a rule
> similar to what str.title() produces. I am not positive that its
> description exactly matches what .title() produces, but it close, and
> the way it is written, "Python's".istitle() is False, as the s at the
> end needs to be uppper case to satisfy as ' is uncased, so the next
> cased character must be upper case.
>
> --
> Richard Damon

I am as tired of this thread as anybody here. To me, it must be capable 
to subbing a considerably more caligraphic attention getting font and  a 
bit larger in order for it to be worth its space on the drive. We can do 
that in openoffice and its ilk with a bit of bother, but it can be done.  
Learning how to use this just adds more bother because you can do it by 
hand quicker than looking up the man page for this. OTOH, in the average 
title, that should be restricted to the first character only.

However, we've beat this horse to death, so it is not going to rear up 
and win the next Derby. So dig a hole and bury it please.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue1634034] Show "expected" token on syntax error

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I think that this issue should be closed as 'out of date' as it was pretty 
open-ended and it is unclear what request remains.

For the specific case "for a in (8,9)", the suggested "expected ':'" has been 
added on another issue.  I expect that there are other additions from other 
issues.

For "for a in (8,9: print a," there is no change but for "for a in (8,9]" we 
now have "closing parenthesis ']' does not match opening parenthesis '('".  
This properly does not say that "expected ')'" as the needed fix might be to 
insert opener '['.

For many other cases, the proposed additions were disputed as not helpful, 
mostly because multiple things could be expected.  I think other suggestions, 
based on current master, should be new issues.

--
nosy: +pablogsal, terry.reedy

___
Python tracker 

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

Re: .title() - annoying mistake

[Richard Damon]

On 3/22/21 4:20 PM, Christian Gollwitzer wrote:
> Am 22.03.21 um 16:03 schrieb Robert Latest:
>> Chris Angelico wrote:
>>> Cool thing is, nobody in Python needs to maintain anything here.
>>
>> That's great because I'm actually having trouble with sending log
>> messages over
>> the socket conection you helped me with, would you mind having a look?
>
> You misunderstood the "here".
>
> (native German as well, but I think it means "for keeping .title() up
> to date)
>
> I agree with Chris that .title() can be useful for "title-casing" a
> single character, whatever that means. It should be documented,
> though, that it is not suitable to title-case a string, not even in
> English.
>
> Christian

Part of the difficulty in getting clear documentation for this is that
is it IS somewhat complicated. You title-case a string by Title-casing
the first character of each word (and the primary issue error that
started this was the definition of a 'word'), and lower casing the rest
of the word. The complication comes in that title-casing a character
99.99% of the time doesn't give you a character in title-case, but more
often in upper-case (or uncased). There are apparently only 31 actual
characters that are 'Title-Case'. Thus the action of 'title-casing' a
character is a bit strange to describe, especially to people used to
simple languages which don't have any of the characters that cause the
issue.

We don't seem to have a problme that upper doesn't always return a true
'upper-case', like for '1' because we realize that many character don't
have case, so it gets largly just assumed we know that. For title case,
the fact that almost all characters do NOT have a 'title-case' form
makes things a bit more awkward.

Yes, perhaps the documentation could be made a bit more clear. I do note
that the documentation for str.capitalize() does talk about using actual
title case characters if the first character is a digraph. Something
like that might make sense in the description of str.title()

Note, that str.istitle() doesn't actually check if the character is a
real 'title case' character, but that the string follows a rule similar
to what str.title() produces. I am not positive that its description
exactly matches what .title() produces, but it close, and the way it is
written, "Python's".istitle() is False, as the s at the end needs to be
uppper case to satisfy as ' is uncased, so the next cased character must
be upper case.

-- 
Richard Damon

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

[issue20608] 'SyntaxError: invalid token' is unfriendly

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Fixed elsewhere.

>>> 04208
  File "", line 1
04208
^
SyntaxError: leading zeros in decimal integer literals are not permitted; use 
an 0o prefix for octal integers
>>> 0o38
  File "", line 1
0o38
   ^
SyntaxError: invalid digit '8' in octal literal

--
nosy: +terry.reedy
resolution:  -> out of date
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

PyWeek 31 Game Jam: March 28 - April 3

[Janine vN]

PyWeek is a twice-a-year game jam that has been running for the past 15 years. 
Starting on the first day of the jam (Sunday, March 28), you start coding, 
designing, and developing your game. This can be done as an individual or with 
a team. By Sunday, April 3rd you must submit your entry on the PyWeek website 
(pyweek.org) for it to be counted as a valid submission.

You can register on PyWeek.org. Head over to that webpage, click on the "Latest 
Challenge", and you should see an option to "Register an Entry". If you 
register now you can vote for what the theme of the game jam will be. Last's 
PyWeek had the theme of "Castaway."

If you have any questions, want to chat with other people participating, or 
find people to join a team, come hang out on Python Discord 
(https://discord.gg/python)! Feel free to tag me, Janine (kutiekatj9), if you 
have any questions in the server or feel free to just send me an email.
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue25130] Make tests more PyPy compatible

[Terry J. Reedy]

Terry J. Reedy  added the comment:

With 2.7 EOL, is this still relevant?

--
nosy: +terry.reedy

___
Python tracker 

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

[issue41064] Specialise syntax error of **dict in f-string field

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Cressey noted both a compile and IDLE Shell issue.  They must be handled 
separately by different people in separate bpo issues.

The first is about the helpful versus less helpful SyntaxError messages in the 
following (master compiled today).

>>> f'{*x}'
  File "", line 1
(*x)
 ^
SyntaxError: f-string: can't use starred expression here
>>> f'{**x}'
  File "", line 1
(**x)
 ^
SyntaxError: f-string: invalid syntax

The request is make the 2nd message the same or like the 1st.  Seems like it 
should be possible.  I am limiting this bpo issue to this request and opened 
#43600 for fixing IDLE's highlight location.

Pablo, I leave it to you to handle the message enhancement request.  Do you 
know if there is any other situation like this in which the compiled text is 
not the input code?

--
assignee: terry.reedy -> 
components:  -IDLE
title: f-string SyntaxError gives offset within fake line, other issues -> 
Specialise syntax error of **dict in f-string field

___
Python tracker 

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

[issue43600] IDLE: fix highlight locationfor f-string field errors

[Terry J. Reedy]

New submission from Terry J. Reedy :

Spinoff from #41064.  In current python, the f'{*x}' traceback ends with 

(*x)
 ^
SyntaxError: f-string: can't use starred expression here.

For f'{**x}', the message is "f-string: invalid syntax" and the ^ is also under 
the 2nd character in the replacement expression actually parsed (with a 
restricted grammar).

The Python error handler must special case a syntax error message beginning 
with 'f-string:' and search the input line for {...} and add its offset.

IDLE currently highlights "'", the 2nd char of the original code, instead of 
'*', the 2nd char of the e.text replacement.  It needs to also adjust the 
offset.

--
assignee: terry.reedy
components: IDLE
messages: 389365
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: fix highlight locationfor f-string field errors
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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

[issue37405] socket.getsockname() returns string instead of tuple

[FRANK BENNETT]

FRANK BENNETT  added the comment:

$ make test TESTOPTS="-v test_socket"

ERROR: testSendFrame (__main__.CANTest)
--
Traceback (most recent call last):
  File "/s/opt/cpython/debug/test_socket.py", line 2052, in testSendFrame
self.assertEqual(addr[1], socket.AF_CAN)
IndexError: tuple index out of range

$ cat ../.git/config
https://github.com/bennett78/cpython.git

$ uname -r
5.4.0-67-genericg$ cat /etc/issue
Ubuntu 20.04.2 LTS \n \l

$ /s/opt/cpython/debug$ ./python -V
Python 3.10.0a6+

--
components: +Tests -Documentation, Extension Modules
nosy: +bennett78
versions: +Python 3.10 -Python 3.7

___
Python tracker 

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

[issue43599] Setting long domain of locale.dgettext() crashes Python interpreter

[Xinmeng Xia]

New submission from Xinmeng Xia :

Setting the first argument of locale.dgettext() long string, Python interpreter 
crashes. 

==
Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale;locale.dgettext('abs'*1000,'')
Segmentation fault (core dumped)
==

System: Ubuntu 16.04

BTW, the api of module locale seems to be inconsistent between Ubuntu and Mac 
OS.  E.g.  there is no dgettext() for Python on Mac OS.

--
components: Library (Lib)
messages: 389363
nosy: xxm
priority: normal
severity: normal
status: open
title: Setting long domain of locale.dgettext() crashes Python interpreter
type: crash
versions: Python 3.10

___
Python tracker 

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

[issue35118] Add peek() or first() method in queue

[Raymond Hettinger]

Raymond Hettinger  added the comment:

>> FWIW, the standard library queue module doesn't have 
>> a straight-forward way to implement a peek() method.

> I currently use `q.deque[0]`

The Queue class is only allowed to call _init, _qsize, _put, and _get.  It is 
not allowed to directly touch the underlying data structure.  Otherwise, 
subclasses relying on the abstraction would fail.

--

___
Python tracker 

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

Re: .title() - annoying mistake

[dn via Python-list]

On 23/03/2021 10.00, Avi Gross via Python-list wrote:
> Speaking for myself, I am beyond tired of this topic, however informative
> parts have been.

+1


> I will say it is irrational to try to impose rationally across all possible
> languages, let alone people like me who often combine 3 or more language in
> a single sentence when talking to others like myself with a dynamic to
> nonsensical grammar. Try capitalizing someone's name when they insist on
> being known by a purely numerical name like ..., or just 7 of 9 or even
> !@zq. 

Further reading: "Falsehoods Programmers Believe About Names"
(https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/)

...
> I have seen setups where a programmer makes every imaginable function they
> can think of but at some later point, some profiling of actual usage shows
> that 80% of them are NEVER used. Often, that is because nobody reads all the
> documentation to find out if it even exists or there is a simple workaround.
> If the only thing bothering you is that a small list of words like FBI comes
> out wrong, it is simple enough to write a function that post-processes the
> result of title() and changes those words back.

Pareto principle ~ 80:20 rule, or should that be written "80/20 rule" or
maybe "80/20 Rule"...


Python gives you the choice to use (or not use) many facilities. You may
also choose to rename such facilities, or to re-use Python's own names
to customise functionality. You have complete freedom to use Python in
any way(s) you see fit. Thus:-

Freedom
noun
UK  /ˈfriː.dəm/ US  /ˈfriː.dəm/
 the condition or right of being able or allowed to do, say, think, etc.
whatever you want to, without being controlled or limited:
Cambridge Dictionary

-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue14364] Argparse incorrectly handles '--' as argument to option

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Unassigning because I haven't been able to make time for this one.

--
assignee: rhettinger -> 

___
Python tracker 

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

[issue43558] The dataclasses documentation should mention how to call super().__init__

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue43598] test_subprocess logs multiple ResourceWarning warnings

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:

len(sys.modules) of msg376374 test_sys_modules:

* Python 3.6: 184
* Python 3.7: 183
* Python 3.8: 221
* Python 3.9: 233
* master: 131

The master branch imports 102 less modules than Python 3.9 (233 => 131)! Almost 
the half.

asyncio, logging, multiprocessing, etc. are no longer always imported by 
default.

--

___
Python tracker 

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

[issue43598] test_subprocess logs multiple ResourceWarning warnings

[STINNER Victor]

New submission from STINNER Victor :

$ ./python -m test test_subprocess -v
(...)
test_send_signal_race2 (test.test_subprocess.POSIXProcessTestCase) ... 
/home/vstinner/python/master/Lib/subprocess.py:1062: ResourceWarning: 
subprocess 137193 is still running
  _warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok

test_pipesize_default (test.test_subprocess.ProcessTestCase) ... 
/home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: 
unclosed file <_io.BufferedReader name=8>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: 
unclosed file <_io.BufferedReader name=10>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok

test_pipesize_default (test.test_subprocess.ProcessTestCaseNoPoll) ... 
/home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: 
unclosed file <_io.BufferedReader name=8>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/home/vstinner/python/master/Lib/unittest/case.py:549: ResourceWarning: 
unclosed file <_io.BufferedReader name=10>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok
(...)

--
components: Tests
messages: 389359
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_subprocess logs multiple ResourceWarning warnings
versions: Python 3.10

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 9feae41c4f04ca27fd2c865807a5caeb50bf4fc4 by Victor Stinner in 
branch 'master':
bpo-41718: libregrtest avoids importing datetime (GH-24985)
https://github.com/python/cpython/commit/9feae41c4f04ca27fd2c865807a5caeb50bf4fc4


--

___
Python tracker 

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

[issue10572] Move test sub-packages to Lib/test

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I added idlelib.idletest in May 2013 with the concurrence of Nick Coughlin, who 
also suggested 'idle_test' rather than just 'test'.  It currently has 72 files 
(66 test_xyz files for idlelib modules).

Foord's opening justification for moving package tests was "Having tests in 
Lib/test instead of inside the package makes it easier to grep the unittest 
package without grepping the tests."

I presume 'tests' refers to the unittest tests but I don't understand 'easier'. 
 Is recursive grepping really not optional for the grep he uses?  In any case, 
if Michael as package author preferred to put them in /Lib, fine.

Having package tests in the package makes it possible to grep both package code 
and tests together from an editor that allows searching all files in a single 
directory or tree.  IDLE's editor and Notepad++ are 2 examples and both have a 
recurse checkmark option off by default.  I routinely do both types of searches 
of idlelib from an IDLE editor.

I have never grepped Lib/test, but if others do, would symlinks work?

For optional packages like tkinter and idlelib, having the tests in the package 
means that tests are automatically omitted when the package is.  If they were 
moved, vendors wanting a clean test directory would have to write new code to 
omit or include package tests when the package is omitted or included.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +23747
pull_request: https://github.com/python/cpython/pull/24987

___
Python tracker 

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

[issue43597] robotparser should support specifying SSL context

[Tarun Chinmai Sekar]

Change by Tarun Chinmai Sekar  :


--
pull_requests: +23746
pull_request: https://github.com/python/cpython/pull/24986

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +23745
pull_request: https://github.com/python/cpython/pull/24985

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 30793e81bd90f3346e962435d49073bc588f067c by Victor Stinner in 
branch 'master':
bpo-41718: Disable support.testresult XML output by default (GH-24982)
https://github.com/python/cpython/commit/30793e81bd90f3346e962435d49073bc588f067c


--

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0473fb222956063814b6beb5fd401f9eeaa8a56a by Victor Stinner in 
branch 'master':
bpo-41718: libregrtest runtest avoids import_helper (GH-24983)
https://github.com/python/cpython/commit/0473fb222956063814b6beb5fd401f9eeaa8a56a


--

___
Python tracker 

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

[issue43597] robotparser should support specifying SSL context

[Tarun Chinmai Sekar]

Change by Tarun Chinmai Sekar  :


--
keywords: +patch
pull_requests: +23744
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24984

___
Python tracker 

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

[issue43555] Location of SyntaxError with new parser missing (after continuation character)

[Ammar Askar]

Ammar Askar  added the comment:

> We should definitely document the column offset being 1-based

Yes please, I remember working on that issue to make it consistently 1-based a 
while ago and I remember that the tooling was relying on 1-based indexes for 
column offsets.

--
nosy: +ammar2

___
Python tracker 

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

[issue43555] Location of SyntaxError with new parser missing (after continuation character)

[Guido van Rossum]

Guido van Rossum  added the comment:

We should definitely document the column offset being 1-based, if it hasn't 
been already. But be careful, there are some APIs that are 0-based and others 
that are 1-based, for column offsets.

I was quite surprised at some point to find out that we were inconsistent with 
the column offset, and then I looked at what Emacs and vim do, and I found that 
both interpret column offsets (in the familiar "filename:lineno:offset: 
message" format) as 1-based. IIRC I had to fix it in quite a few places because 
we were actually being inconsistent.

--

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +23743
pull_request: https://github.com/python/cpython/pull/24983

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +23742
pull_request: https://github.com/python/cpython/pull/24982

___
Python tracker 

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

[issue43597] robotparser should support specifying SSL context

[Tarun Chinmai Sekar]

New submission from Tarun Chinmai Sekar  :

IMO this could be enhanced by adding a sslcontext parameter to read method

a sample change would it could look like
```
def read(self, sslcontext=None):
"""Reads the robots.txt URL and feeds it to the parser."""
try:
if sslcontext:
   f = urllib.request.urlopen(self.url, context=sslcontext)
else:
   f = urllib.request.urlopen(self.url)
except urllib.error.HTTPError as err:
if err.code in (401, 403):
self.disallow_all = True
elif err.code >= 400 and err.code < 500:
self.allow_all = True
else:
raw = f.read()
self.parse(raw.decode("utf-8").splitlines())

```

Happy to send a PR if this proposal makes sense.

--

___
Python tracker 

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

[issue43555] Location of SyntaxError with new parser missing (after continuation character)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Before the patch, IDLE highlighted the \n endline with a red background,  which 
tk displays as red background from the blank space after the 4 to the right 
edge of the text widget, including in 3.8.8.

The 3.8 result, different from REPL, is due the the difference of using 
code._maybe_compile.  The latter catches the SyntaxError for "3 \\ 4", which 
has offset 5, recompiles "3 \\ 4\n", and raises the subsequent SyntaxError, 
which has offset 6.  (In this particular case where the message remains the 
same, the original SyntaxError instance with the original offset should have 
been kept and raised.)

I have occasionally made this typing mistake and found the long red line 
slightly annoying, but never thought to compare it to the REPL caret or report 
it as a bug.  The new parser made no difference in IDLE to newly annoy.

After the patch, the (1-based) offset stays 5, which IDLE knows means the 5th 
char and hence it now highlights the '4'.  Much better.  Thank you both for the 
report and fix.

Side question: https://docs.python.org/3/library/exceptions.html#SyntaxError 
says "Instances of this class have attributes filename, lineno, offset and text 
...". Should it be documented that lineno and offset are both 1-based?  Are 
these CPython accidents or part of the language?  1-based line numbers can be 
expected as common across languages, tk and python included.  I believe that 
1-based column offsets were viewed in a previous issue as a bug that we would 
not fix.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue43597] robotparser should support specifying SSL context

[Tarun Chinmai Sekar]

Change by Tarun Chinmai Sekar  :


--
components: +Library (Lib)

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 10417dd15f135c179cf4234d1abe506915d802ff by Victor Stinner in 
branch 'master':
bpo-41718: Reduce libregrtest runtest imports (GH-24980)
https://github.com/python/cpython/commit/10417dd15f135c179cf4234d1abe506915d802ff


--

___
Python tracker 

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

[issue43597] robotparser should support specifying SSL context

[Tarun Chinmai Sekar]

Change by Tarun Chinmai Sekar  :


--
nosy: Tchinmai7
priority: normal
severity: normal
status: open
title: robotparser should support specifying SSL context
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Felix C. Stegerman]

Felix C. Stegerman  added the comment:

> external_attr == 0 may cause issues with permissions.

That may be true in some scenarios, but not being able to set it to 0 means you 
can't create identical files to those produced by other tools -- like those 
used to generate APKs -- which do in fact set it to 0.

--

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +23741
pull_request: https://github.com/python/cpython/pull/24981

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Felix C. Stegerman]

Change by Felix C. Stegerman :


--
type:  -> enhancement

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Felix C. Stegerman]

Change by Felix C. Stegerman :


--
components: +Library (Lib)

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Felix C. Stegerman]

Change by Felix C. Stegerman :


--
components:  -IO, Library (Lib)
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Felix C. Stegerman]

Felix C. Stegerman  added the comment:

I've closed the PR for now.

Using a carefully crafted ZipInfo object doesn't work because ZipFile modifies 
its .external_attr when set to 0.

Using something like this quickly hacked together ZipInfo subclass does work:

class ZeroedZipInfo(zipfile.ZipInfo):
def __init__(self, zinfo):
for k in self.__slots__:
setattr(self, k, getattr(zinfo, k))

def __getattribute__(self, name):
if name == "date_time":
return (1980,0,0,0,0,0)
if name == "external_attr":
return 0
return object.__getattribute__(self, name)

...

myzipfile.writestr(ZeroedZipInfo(info), data)

--
components: +IO
type: enhancement -> 
versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +23740
pull_request: https://github.com/python/cpython/pull/24980

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 532e063fc2bf9e6e80550670ddc5dc5d2b1d2450 by Victor Stinner in 
branch 'master':
bpo-41718: regrtest saved_test_environment avoids imports (GH-24934)
https://github.com/python/cpython/commit/532e063fc2bf9e6e80550670ddc5dc5d2b1d2450


--

___
Python tracker 

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

[issue40813] Line number of SyntaxError

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Whatever the situation was last May, current 3.10 now results in a correct and 
improved traceback ending in

  File "F:\Python\a\tem4.py", line 2
print("hello world"
 ^
SyntaxError: '(' was never closed

Same if \n or additional text is added to the file without closing ')'.

--
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions:  -Python 3.8, Python 3.9

___
Python tracker 

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

[issue39091] _PyErr_CreateException() must check that the result is an exception (CPython Segfault in 5 lines of code)

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10 -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: Pips for python2 and python3

[Tim Johnson]

On 3/21/21 5:44 PM, Dan Stromberg wrote:

python3 -m pip install

Got it. Thanks a lot.

--
Tim
tj49.com

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

Thanks for the response. I will try to address your comments inline.

> I guess it should be a good idea to answer what's the scope of this
> project - is it research one or "production" one? If it's research one,
> why be concerned with the churn of over-modern CPython versions?
> Wouldn't it be better to just use some scalable, incremental
> implementation which would allow to forward-port it to a newer version,
> if it ever comes to that?

The motivation for revisiting this idea was/is largely personal. As I
indicated, I first messed around with it over 20 years ago and it's
been in the back of my mind ever since. Somehow I never lost the code
despite I'm not sure how many computers came and went and that the
code was never uploaded to any sort of distributed version control
system. I decided to pick things up again as a way to mostly keep my
head in the game after I retired. So, neither "research" nor
"production" seems to be a correct descriptor. Still, if taken to
functional completion — functional enough for performance testing and
application to more than just toy scripts — I realized pretty quickly
that I'd need help.

> Otherwise, if it's "production", who's the "customer" and how they
> "compensate" you for doing work (chasing the moving target) which is
> clearly of little interest to you and conflicts with the goal of the
> project?

Nobody is compensating me. I have no desire to try and turn it into
something I do for hire. Maybe I misunderstood your question?

> > This PEP proposes the addition of register-based instructions to the
> > existing Python virtual machine, with the intent that they eventually
> > replace the existing stack-based opcodes.
>
> Sorry, what? The purpose of register-based instructions is to just
> replace stack-based instructions? That's not what's I'd like to hear as
> the intro phrase. You probably want to replace one with the other
> because register-based ones offer some benefit, faster execution
> perhaps? That's what I'd like to hear instead of "deciphering" that
> between the lines.

Replacing stack-based instructions would be a reasonable initial goal,
I think. Victor reported performance improvements in his
implementation (also a translator). As I indicated in the "PEP" (I use
that term rather loosely, as I have no plans at the moment to submit
it for consideration, certainly not in its current, incomplete state),
a better ultimate way to go would be to generate register instructions
directly from the AST. The current translation scheme allows me to
write simple test case functions, generate register instructions, then
compare that when called the two produce the same result.

> > They [2 instruction sets] are almost completely distinct.
>
> That doesn't correspond to the mental image I would have. In my list,
> the 2 sets would be exactly the same, except that stack-based encode
> argument locations implicitly, while register-based - explicitly. Would
> be interesting to read (in the following "pep" sections) what makes them
> "almost completely distinct".

Well, sure. The main difference is the way two pairs of instructions
(say, BINARY_ADD vs BINARY_ADD_REG) get their operands and save their
result. You still have to be able to add two objects, call functions,
etc.

> > Within a single function only one set of opcodes or the other will
> > be used at any one time.
>
> That would be the opposite of "scalable, incremental" development
> approach mentioned above. Why not allow 2 sets to freely co-exist, and
> migrate codegeneration/implement code translation gradually?

The fact that I treat the current frame's stack space as registers
makes it pretty much impossible to execute both stack and register
instructions within the same frame. Victor's implementation did things
differently in this regard. I believe he just allocated extra space
for 256 registers at the end of each frame, so (in theory, I suppose),
you could have instructions from both executed in the same frame.

> > ## Motivation
>
> I'm not sure the content of the section corresponds much to its title.
> It jumps from background survey of the different Python VM optimizations
> to (some) implementation details of register VM - leaving "motivation"
> somewhere "between the lines".
>
> > Despite all that effort, opcodes which do nothing more than move data
> > onto or off of the stack (LOAD_FAST, LOAD_GLOBAL, etc) still account
> > for nearly half of all opcodes executed.
>
> ... And - you intend to change that with a register VM? In which way and
> how? As an example, LOAD_GLOBAL isn't going anywhere - it loads a
> variable by *symbolic* name into a register.

Certainly, if you have data which isn't already on the stack, you are
going to have to move data. As the appendix shows though, a fairly
large chunk of the current virtual machine does nothing more than
manipulate the stack (LOAD_FAST, STORE_FAST, POP_TOP, etc).

> > Running Pyperformance using a development version of Python 3.9
> > showed 

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

[Eryk Sun]

Eryk Sun  added the comment:

In some cases, the problem can be worked around by setting the 
__PYVENV_LAUNCHER__ environment variable and executing the base executable. For 
example:

import os
import sys
import subprocess

def get_python_exe_env():
if sys.executable == getattr(sys, '_base_executable', sys.executable):
return sys.executable, None
environ = os.environ.copy()
environ['__PYVENV_LAUNCHER__'] = sys.executable
return sys._base_executable, environ

executable, environ = get_python_exe_env()
p = subprocess.Popen([executable], env=environ)

---

As is, I don't know how to solve the problem in which an arbitrary application 
runs a script using the "python" launcher. Half of the problem could be solved. 
When the launcher creates the base Python process, it could set the parent via 
PROC_THREAD_ATTRIBUTE_PARENT_PROCESS [1], presuming it can open a handle for 
the parent application with PROCESS_CREATE_PROCESS access. However, this 
doesn't solve the problem from the application's perspective. It still gets the 
handle and process ID of the launcher.

If the purpose of using a launcher was only to allow an in-place upgrade of the 
base "python3x.dll", then an alternative design would be to set the 
__PYVENV_LAUNCHER__ environment variable, load the Python DLL from the 
pyvenv.cfg "home" directory, and call Py_Main(argc, argv). This would eliminate 
the parent<->child problem and the application directory (__APPDIR__) problem. 

However, naively implementing something like that cannot work for the store app 
distribution. "python3x.dll" in the app installation directory under 
"%ProgramFiles%\WindowsApps" only grants execute access to users that have the 
app's WIN://SYSAPPID identifier in their access token, which gets added by 
CreateProcessW() when the "python[3[.x]].exe" appexec link is executed. I'd 
have to experiment to see what works. Maybe "python.exe" in the virtual 
environment could be created as an appexec link to "venvlauncher.exe" in the 
app, which loads the DLL, etc.

---

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute

--

___
Python tracker 

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> Yeah, that is old writing, so is probably less clear (no pun intended)
> than it should be. In frame_dealloc, Py_CLEAR is called for
> stack/register slots instead of just Py_XDECREF. Might not be
> necessary.

Also, the intent is not to change any semantics here. The
implementation of RETURN_VALUE_REG still Py_INCREFs the to-be-returned
value. It's not like the data can get reclaimed before the caller
receives it.

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

[issue43596] change assertRaises message when wrong exception is raised

[Kamil Turek]

Change by Kamil Turek :


--
nosy: +kamilturek

___
Python tracker 

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

Re: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> In the "Object Lifetime" section you say "registers should be cleared upon 
> last reference". That isn't safe, since there can be hidden dependencies on 
> side effects of __del__, e.g.:
>
> process_objects = create_pipeline()
> output_process = process_objects[-1]
> return output_process.wait()
>
> If the process class terminates the process in __del__ (PyQt5's QProcess 
> does), then implicitly deleting process_objects after the second line will 
> break the code.

Yeah, that is old writing, so is probably less clear (no pun intended)
than it should be. In frame_dealloc, Py_CLEAR is called for
stack/register slots instead of just Py_XDECREF. Might not be
necessary.

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

[issue43594] A metaclass that inherits both `ABC` and `ABCMeta` breaks on `__subclasscheck__`

[Kamil Turek]

Change by Kamil Turek :


--
nosy: +kamilturek

___
Python tracker 

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

[issue20692] Tutorial and FAQ: how to call a method on an int

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +easy
versions: +Python 3.10 -Python 2.7

___
Python tracker 

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

[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver

[Mark Shannon]

Mark Shannon  added the comment:

Numbers please.

What is "non-negligible cost of allocation/initialization" mean as a fraction 
of runtime?
What sort of speed up are you seeing on whole programs?

--

___
Python tracker 

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

RE: .title() - annoying mistake

[Avi Gross via Python-list]

Speaking for myself, I am beyond tired of this topic, however informative
parts have been.

I will say it is irrational to try to impose rationally across all possible
languages, let alone people like me who often combine 3 or more language in
a single sentence when talking to others like myself with a dynamic to
nonsensical grammar. Try capitalizing someone's name when they insist on
being known by a purely numerical name like ..., or just 7 of 9 or even
!@zq. 

So, yes, a purist might want a truly comprehensive piece of code larger than
say all the code in Microsoft WORD, that first figures out what language
might be used and uses locale and guesswork to even try to narrow down that
the words are meant to be treated as they are in Bavaria and see if the use
is informal or say adhering to the rules for submitting in APA format or
whatever. We are talking about an extremely hard problem that will still
likely make mistakes if I am from Bavaria but submitting a science fiction
article mimicking what I imagine might be the way it will be written in
3010.

So I suggest we take the source for the title function and rename it
something enlightening like changeCaseRandomMethod42dInitialUpperElseLower()
so it can be used mysteriously by anyone that wants. Then deprecate the use
of title() while keeping that as some form of alias for the fantastic new
name. Anyone wishing to have title mean anything else, feel free to redefine
it.

But that jokingly does not mean there is no room for improvement. As an
example, people often would like words like "FBI" to be left alone and not
changed to "Fbi" or in some other contexts, not be flagged as a spelling
error let alone corrected. I suspect the same or relate functions might
accept an optional arguments like maintainAllCAPS=TRUE so FBI is left alone,
albeit LOTUS123 might become Lotus123 or not.

I have seen setups where a programmer makes every imaginable function they
can think of but at some later point, some profiling of actual usage shows
that 80% of them are NEVER used. Often, that is because nobody reads all the
documentation to find out if it even exists or there is a simple workaround.
If the only thing bothering you is that a small list of words like FBI comes
out wrong, it is simple enough to write a function that post-processes the
result of title() and changes those words back.

If you designed a brand new language core today, you may indeed want to
leave title() out of the core but include it as an optional module, perhaps
with a more descriptive name.

Tell me if the base should have functions called camelCase(), PascalCase(),
arrayHungarianCase() or underscore_case() 


-Original Message-
From: Python-list  On
Behalf Of Christian Gollwitzer
Sent: Monday, March 22, 2021 4:21 PM
To: python-list@python.org
Subject: Re: .title() - annoying mistake

Am 22.03.21 um 16:03 schrieb Robert Latest:
> Chris Angelico wrote:
>> Cool thing is, nobody in Python needs to maintain anything here.
> 
> That's great because I'm actually having trouble with sending log 
> messages over the socket conection you helped me with, would you mind
having a look?

You misunderstood the "here".

(native German as well, but I think it means "for keeping .title() up to
date)

I agree with Chris that .title() can be useful for "title-casing" a single
character, whatever that means. It should be documented, though, that it is
not suitable to title-case a string, not even in English.

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

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Christian Heimes]

Christian Heimes  added the comment:

zinfo = zipfile.ZipInfo()
zinfo.date_time = (1980, 0, 0, 0, 0, 0)
zinfo.create_system = 0

external_attr == 0 may cause issues with permissions. I do something like this 
in my reproducible tarfile code:

if zinfo.isdir():
# 0755 + MS-DOS directory flag
zinfo.external_attr = 0o755 | 0x010
else:
zinfo.external_attr = 0o644

--

___
Python tracker 

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

[issue43420] Optimize rational arithmetics

[Tim Peters]

Tim Peters  added the comment:

This report is closed. Please open a different report.

We've already demonstrated that, as predicted, nothing can be said here without 
it being taken as invitation to open-ended discussion. So it goes, but it 
doesn't belong on _this_ report anymore.

--

___
Python tracker 

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

[issue43492] Upgrade to SQLite 3.35.3 in macOS and Windows

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

FYI: https://www.sqlite.org/cgi/src/info/8de4cb984a4b019f:

"We anticipate 3.35.3 in a few days. Hopefully there will never be a need for 
3.35.4."

--
title: Upgrade to SQLite 3.35.2 in macOS and Windows -> Upgrade to SQLite 
3.35.3 in macOS and Windows

___
Python tracker 

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

[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver

[Guido van Rossum]

Guido van Rossum  added the comment:

This looks like a sensible idea to me. The safeguards to ensure that customized 
'super' still works seem reasonable to me. I have to admit that I sometimes 
refrain from using super() where I should because of the expense, so this would 
be welcome.

I do wonder -- is two-arg super() important enough to support it at all? Maybe 
the code would be somewhat simpler if the special opcodes were only generated 
for zero-arg super() calls.

--

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Christian Heimes]

Christian Heimes  added the comment:

Hi,

thanks for looking into reproducible builds. I have a few suggestions:

- since it's a new feature, it cannot go into older releases.
- zeroed is not a self-explanatory term. I suggest to find a term that does 
describe the result, not the internal operation.
- I don't think you have to introduce a new argument at all. Instead you can 
provide a new method that creates a carefully crafted zipinfo object that 
results into zeroed arguments. That's how I implemented reproducible tar.bz2 
files.
- For full reproducible builds you may have to write files to zipfiles in a 
well-defined order.

--
components:  -IO
nosy: +christian.heimes
type:  -> enhancement
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue43558] The dataclasses documentation should mention how to call super().__init__

[Eric V. Smith]

Change by Eric V. Smith :


--
keywords: +easy -patch
stage: patch review -> needs patch

___
Python tracker 

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

[issue43558] The dataclasses documentation should mention how to call super().__init__

[Eric V. Smith]

Change by Eric V. Smith :


--
pull_requests:  -23731

___
Python tracker 

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

[issue43558] The dataclasses documentation should mention how to call super().__init__

[Eric V. Smith]

Change by Eric V. Smith :


--
pull_requests:  -23730

___
Python tracker 

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

[issue43588] [Subinterpreters]: use static variable under building Python with --with-experimental-isolated-subinterpreters cause crash.

[junyixie]

Change by junyixie :


--
pull_requests: +23739
pull_request: https://github.com/python/cpython/pull/24972

___
Python tracker 

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

[issue43588] [Subinterpreters]: use static variable under building Python with --with-experimental-isolated-subinterpreters cause crash.

[junyixie]

Change by junyixie :


--
pull_requests: +23738
pull_request: https://github.com/python/cpython/pull/24971

___
Python tracker 

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

Re: .title() - annoying mistake

[Christian Gollwitzer]

Am 22.03.21 um 16:03 schrieb Robert Latest:

Chris Angelico wrote:

Cool thing is, nobody in Python needs to maintain anything here.


That's great because I'm actually having trouble with sending log messages over
the socket conection you helped me with, would you mind having a look?


You misunderstood the "here".

(native German as well, but I think it means "for keeping .title() up to 
date)


I agree with Chris that .title() can be useful for "title-casing" a 
single character, whatever that means. It should be documented, though, 
that it is not suitable to title-case a string, not even in English.


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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Felix C. Stegerman]

Felix C. Stegerman  added the comment:

I've created a draft PR; RFC :)

Also:

* setting the date to (1980,0,0,0,0,0) already works;
* the main issue seems to be that external_attr cannot be 0 atm.

--

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

[Felix C. Stegerman]

Change by Felix C. Stegerman :


--
keywords: +patch
pull_requests: +23737
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24979

___
Python tracker 

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

[issue2920] Patch to print symbolic value of errno in OSError.__str__()

[Eryk Sun]

Change by Eryk Sun :


--
versions: +Python 3.10 -Python 3.9

___
Python tracker 

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

Re: .title() - annoying mistake

[Robert Latest via Python-list]

Benjamin Schollnick wrote:

> I’m sorry, but it’s as if he’s arguing for the sake of arguing.  It’s
> starting to feel very unproductive, and unnecessary.

That was never five minutes just now!

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

[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver

[Vladimir Matveev]

Vladimir Matveev  added the comment:

>Currently, super() is decoupled from the core language.  It is just a builtin 
>that provides customized attribute lookup.  This PR makes super() more tightly 
>integrated with the core language, treating it as if it were a keyword and 
>part of the grammar.  Also note, users can currently create their own versions 
>of super(), shadowing the builtin super().

This is true however:
- this patch does not block people from introducing custom version of `super` 
so this scenario still work. The idea was to streamline the common case
- based on digging into Instagram codebase and its transitive dependencies 
(which is reasonably large amount of code) all spots where `super()` appear in 
sources assume `super` to be builtin and for a pretty common use-case its cost 
is noticeable in profiler.
- zero-argument `super()` still a bit magical since it requires compiler 
support to create cell for `__class__` and assumes certain shape of the frame 
object so this patch is a step forward with a better compiler support and 
removing runtime dependency on the frame

> Do you have any evidence that the overhead of super() is significant in real 
> programs

I do see the non-negligible cost of allocation/initialization of `super` object 
in IG profiling data.

--

___
Python tracker 

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

[issue43591] Parser aborts on incomplete/incorrect unicode literals in interactive mode

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Thanks, Pablo!

--

___
Python tracker 

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

[issue43555] Location of SyntaxError with new parser missing (after continuation character)

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
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

[issue43555] Location of SyntaxError with new parser missing (after continuation character)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 994a519915bff4901abaa7476e2b91682dea619a by Miss Islington (bot) 
in branch '3.9':
bpo-43555: Report the column offset for invalid line continuation character 
(GH-24939) (#24975)
https://github.com/python/cpython/commit/994a519915bff4901abaa7476e2b91682dea619a


--

___
Python tracker 

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

Re: .title() - annoying mistake

[Chris Angelico]

On Tue, Mar 23, 2021 at 5:16 AM Karen Shaeffer via Python-list
 wrote:
>
> Hi Chris,
> Thanks for your comment.
>
> > Python doesn't work with UTF-8 encoded code points; it works with
> > Unicode code points. Are you looking for something that checks whether
> > something is a palindrome, or locates palindromes within it?
> >
> > def is_palindrome(txt):
> >return txt == txt[::-1]
> >
> > Easy.
>
> Of course, its easy. Its a pythonic idiom! But it doesn’t work. And you know 
> that. You even explained a few reasons why it doesn’t work below. There are 
> many more instances of strings that do not work. Here are two:
>
> idx = 6A man, a plan, a canal: Panama   is_palindrome() = False
> idx = 17ab́cdeedcb́a   is_palindrome() = False
>
> The palindrome isn’t worth any more time. It isn’t even a good example.
>
> In my experience processing unstructured, multilingual text, you encounter a 
> wide array of variances in both the text and in the encoding details, 
> including outright errors. You have to account for all of them, because 
> 99.99% of that text is valuable to you.
>
> The key idea: If you care about the details, working with unstructured 
> multi-lingual text is complicated. There are no easy solutions.
>
>
> >
> > Efficiently finding substring palindromes would be a bit harder, but
> > that'd be true even if you restricted it to ASCII. The advantage of
> > Python's way of doing it is that, if you have a method that would work
> > with ASCII bytes, the exact same thing will work with a Unicode
> > string.
> >
> > There's another big wrinkle not touched here, and that's what to do
> > with combining characters. Python makes it easy to normalize text as
> > much as is possible, and an NFC normalization would help a lot, but
> > it's not going to do everything. So you may want to first define a
> > proper way to split a string into whatever you're defining a character
> > to be, and that's a very difficult problem, regardless of programming
> > language. For example, Arabic text changes in visual shape when
> > letters are next to each other, and Greek has two different forms for
> > the letter sigma (U+03C2 and U+03C3) - should those distinctions
> > affect palindromminess? What about ligatures - is U+FB01 "fi" a single
> > character, or should it be matched by "if" on the other end?
> >
> > What part of this is trivial in Go?
>
> Go is simpler than Python. Both languages have the capabilities to solve any 
> text processing problem. I’m still learning Go, so I can’t really say more.
>
> Personally, I like Python for text processing. You can usually get 
> satisfactory results very quickly for most of the input space. And if you 
> don’t care about all the gotchas, then you are good to go.
>
> I have no more time for this. Thanks for your comment. I learned a little 
> reading the long thread dealing with .title(). (chuckles ;)
>

Hey, you're the one who brought up palindrome testing as a difficult
problem in Python :) Your post implied that it was easier in Go, and I
can't see that that's possible.

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

Re: .title() - annoying mistake

[Karen Shaeffer via Python-list]

Hi Chris,
Thanks for your comment.

> Python doesn't work with UTF-8 encoded code points; it works with
> Unicode code points. Are you looking for something that checks whether
> something is a palindrome, or locates palindromes within it?
> 
> def is_palindrome(txt):
>return txt == txt[::-1]
> 
> Easy.

Of course, its easy. Its a pythonic idiom! But it doesn’t work. And you know 
that. You even explained a few reasons why it doesn’t work below. There are 
many more instances of strings that do not work. Here are two:

idx = 6A man, a plan, a canal: Panama   is_palindrome() = False
idx = 17ab́cdeedcb́a   is_palindrome() = False

The palindrome isn’t worth any more time. It isn’t even a good example.

In my experience processing unstructured, multilingual text, you encounter a 
wide array of variances in both the text and in the encoding details, including 
outright errors. You have to account for all of them, because 99.99% of that 
text is valuable to you.

The key idea: If you care about the details, working with unstructured 
multi-lingual text is complicated. There are no easy solutions.


> 
> Efficiently finding substring palindromes would be a bit harder, but
> that'd be true even if you restricted it to ASCII. The advantage of
> Python's way of doing it is that, if you have a method that would work
> with ASCII bytes, the exact same thing will work with a Unicode
> string.
> 
> There's another big wrinkle not touched here, and that's what to do
> with combining characters. Python makes it easy to normalize text as
> much as is possible, and an NFC normalization would help a lot, but
> it's not going to do everything. So you may want to first define a
> proper way to split a string into whatever you're defining a character
> to be, and that's a very difficult problem, regardless of programming
> language. For example, Arabic text changes in visual shape when
> letters are next to each other, and Greek has two different forms for
> the letter sigma (U+03C2 and U+03C3) - should those distinctions
> affect palindromminess? What about ligatures - is U+FB01 "fi" a single
> character, or should it be matched by "if" on the other end?
> 
> What part of this is trivial in Go?

Go is simpler than Python. Both languages have the capabilities to solve any 
text processing problem. I’m still learning Go, so I can’t really say more.

Personally, I like Python for text processing. You can usually get satisfactory 
results very quickly for most of the input space. And if you don’t care about 
all the gotchas, then you are good to go.

I have no more time for this. Thanks for your comment. I learned a little 
reading the long thread dealing with .title(). (chuckles ;)

Humbly,
Karen


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

[issue43592] test_importlib: test_multiprocessing_pool_circular_import() fails with "Too many open files" error on os.pipe()

[Ned Deily]

Ned Deily  added the comment:

FWIW, I don't recall ever seeing a "too many open files" failure for 
test_importlib on any of my macOS systems.

--
nosy: +ned.deily

___
Python tracker 

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

[issue42444] pathlib.PurePath properties annotated with .. data directive

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 6.0 -> 7.0
pull_requests: +23736
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24977

___
Python tracker 

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

[issue15751] [subinterpreters] Make the PyGILState API compatible with subinterpreters

[Gabriel Amine Eddine]

Change by Gabriel Amine Eddine :


--
nosy: +gabrielhae

___
Python tracker 

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

[issue17792] Unhelpful UnboundLocalError due to del'ing of exception target

[Irit Katriel]

Change by Irit Katriel :


--
pull_requests: +23735
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24976

___
Python tracker 

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

[issue43555] Location of SyntaxError with new parser missing (after continuation character)

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +23734
pull_request: https://github.com/python/cpython/pull/24975

___
Python tracker 

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

[issue43555] Location of SyntaxError with new parser missing (after continuation character)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 96eeff516204b7cc751103fa33dcc665e387846e by Pablo Galindo in 
branch 'master':
bpo-43555: Report the column offset for invalid line continuation character 
(GH-24939)
https://github.com/python/cpython/commit/96eeff516204b7cc751103fa33dcc665e387846e


--

___
Python tracker 

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

[issue43010] @functools.wraps and abc.abstractmethod interoperability

[Dennis Sweeney]

Dennis Sweeney  added the comment:

> other attributes will not be copied

The signature of wraps() is

wraps(wrapped, assigned=('__module__', '__name__', '__qualname__', 
'__doc__', '__annotations__'), updated=('__dict__',))

Passing the updated=() will prevent the __dict__ from being updated, but those 
other attributes will still be assigned to:

>>> from functools import wraps
>>> def f(x: int) -> int:
... "Square of a number"
... return x ** 2
...
>>> @wraps(f, updated=())
... def g(*args, **kwargs):
... return f(*args, **kwargs)
...
>>> help(g)
Help on function f in module __main__:

f(x: int) -> int
Square of a number

> This is an interoperability bug

This is probably somewhat subjective, but I think the current behavior is okay: 
copy all of the attributes of the wrapped function into the wrapper. That's 
predictable, well-specified behavior, even if it has unexpected consequences in 
some situations -- I would say unusual situations, since 90% of the time I've 
seen @wraps used is in making custom decorators, where you really do mean to 
copy *all* of the attributes of the old function into the new one, and never 
think of the wrapped function again.

My thinking is also that to add a special case for abstract methods in 
functools would be to unnecessarily couple the functools module to 
implementation details of the ABC module. If someone using the ABC module wants 
to not update the __dict__ when using functools.wraps, there's already an easy 
switch for that, and it's completely orthogonal to what the __dict__ contains.

For an interesting precedent, @abstractclassmethod was created in 
https://bugs.python.org/issue5867 to solve a similar (I think) interoperability 
problem between @abstractmethod and @classmethod rather than adding a special 
case to @classmethod.

I would be interested in hearing if others want something to change about 
wraps().

--

___
Python tracker 

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

[issue43563] Use dedicated opcodes to speed up calls/attribute lookups with super() as receiver

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy: +gvanrossum

___
Python tracker 

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

[issue43181] Python macros don’t shield arguments

[STINNER Victor]

STINNER Victor  added the comment:

Me:
> I don't think that PR 24533 should be backported to Python 3.8 and Python 
> 3.9. I prefer to avoid any risk of regression, and so only change Python 3.10.

Sometimes. I'm wise :-D This change broken 2 extension modules which rely on 
the fact that the macro magically add parenthesis:

python-cvxopt: "if Matrix_Check((PyObject *)val)" with: "#define 
Matrix_Check(self) PyObject_TypeCheck(self, _tp)"
https://bugzilla.redhat.com/show_bug.cgi?id=1941557
PR proposed: https://github.com/cvxopt/cvxopt/pull/190

python-Bottleneck: "if PyArray_Check(a_obj) {" with: "#define PyArray_Check(op) 
PyObject_TypeCheck(op, _Type)"
https://bugzilla.redhat.com/show_bug.cgi?id=1941559

"if func(...) {" is not valid C code, but the old macro added magically 
parenthesis!

It's hard to say if the Python change is a backward incompatible or not... I 
prefer to keep it and fix the few broken C extensions.

--

___
Python tracker 

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

[issue43596] change assertRaises message when wrong exception is raised

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue12762] OSError msg should display symbolic error codes

[Zackery Spytz]

Zackery Spytz  added the comment:

This is a duplicate of bpo-2920 (which has a PR).

--
nosy: +ZackerySpytz
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Patch to print symbolic value of errno in OSError.__str__()

___
Python tracker 

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

[issue26403] Catch FileNotFoundError in socketserver.DatagramRequestHandler

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10 -Python 3.5

___
Python tracker 

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

[issue43591] Parser aborts on incomplete/incorrect unicode literals in interactive mode

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 123ff266cda9ad279106f20dca06ba114f6a9b8a by Pablo Galindo in 
branch 'master':
bpo-43591: Fix error location in interactive mode for errors at the end of the 
line (GH-24973)
https://github.com/python/cpython/commit/123ff266cda9ad279106f20dca06ba114f6a9b8a


--

___
Python tracker 

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

[issue43591] Parser aborts on incomplete/incorrect unicode literals in interactive mode

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
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

[issue43596] change assertRaises message when wrong exception is raised

[Nathaniel Manista]

Change by Nathaniel Manista :


--
nosy: +Nathaniel Manista

___
Python tracker 

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

[issue43596] change assertRaises message when wrong exception is raised

[R. Samuel Klatchko]

New submission from R. Samuel Klatchko :

Right now, this code:

class FooError(Exception): pass
class BarError(Exception): pass

def test_me(self):
  with self.assertRaises(FooError):
raise BarError("something")

will have the error "BarError: something" with no indication that an exception 
was expected but just that we got the wrong one.

It would be help to change the message to something like:

  Expected exception of type FooError but exception BarError('something') was 
raised.

--
messages: 389328
nosy: rsk2
priority: normal
severity: normal
status: open
title: change assertRaises message when wrong exception is raised

___
Python tracker 

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

[issue12762] OSError msg should display symbolic error codes

[Irit Katriel]

Change by Irit Katriel :


--
title: EnvironmentError_str contributes to unportable code -> OSError msg 
should display symbolic error codes
versions: +Python 3.10 -Python 3.4

___
Python tracker 

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

[issue24147] Dialect class defaults are not documented.

[Irit Katriel]

Irit Katriel  added the comment:

Brandon's patch has not been applied, it needs to be converted into a git PR.

--
keywords: +easy -patch
nosy: +iritkatriel
versions: +Python 3.10 -Python 3.4, Python 3.5

___
Python tracker 

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

Re: .title() - annoying mistake

[Benjamin Schollnick]

>> That's not true for digraphs where there is a third, distinct and
>> different "title" case. I think the doc should state that the initial
>> character is converted to titlecase. A parenthentical statement that
>> titlecase is usually but not always equal to uppercase would be nice,
>> but the current statement is obsolete and not correct in all, um...
>> cases.
> 
> Fair enough, but the trouble is that getting too pedantic in a
> docstring just makes it read like IBM documentation. :)

And actually conversely makes it harder to keep updating, because you’ll need 
to document every and all edge-cases, and then need to know when one of those 
edge cases breaks, etc.  

The core concept is documented, and it’s pretty straight-forward.  

I’m sorry, but it’s as if he’s arguing for the sake of arguing.  It’s starting 
to feel very unproductive, and unnecessary.

- Benjamin


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

[issue42137] Prefer using __spec__ over module_repr() for ModuleType.__repr__

[Brett Cannon]

Brett Cannon  added the comment:

Meant to say, "existence of the _method_ isn't problematic".

--

___
Python tracker 

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

Re: .title() - annoying mistake

[Benjamin Schollnick]

>> I guess it depends on what you mean by "character". In my mind, the
>> first character of string s is s[1], and I would then expect that
>> 
>> s.title()[1] == s[1].upper()
>> 
> 
> I presume you mean [0], but no, that's not the case. A single
> character can titlecase to two characters, or to a single character
> that isn't the same as if you uppercase or lowercase it. See examples
> in previous post.

Or Kanji, etc.  Where a single character can represent more than one in a 
different unicode standard, as I understand. 

- Benjamin

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

[issue43573] [types] Document __spec__ for types.ModuleType

[Brett Cannon]

Change by Brett Cannon :


--
assignee: docs@python -> brett.cannon
stage: patch review -> 

___
Python tracker 

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

[issue43573] [types] Document __spec__ for types.ModuleType

[Brett Cannon]

Change by Brett Cannon :


--
keywords: +patch
pull_requests: +23733
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24974

___
Python tracker 

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