[issue35840] Control flow inconsistency on closed asyncio stream

[Marc Schlaich]

New submission from Marc Schlaich :

After closing a StreamWriter the `StreamReaderProtocol.connection_lost` on the 
other end is not getting called. In this case the StreamReader is at EOF but 
calling write/drain does not raise any Exception (and sending data to Nirvana). 

I would expect that StreamWriter.is_closing returns True after the close and 
calling write/drain raises immediately and not just after the second call. 
Please see attached example. I see the same behavior with Proactor and Selector 
event loop on Windows.

Maybe this is expected behavior. But in this case it is completely 
undocumented. Should there be a check for `StreamReader.at_eof` (and maybe 
`StreamReader.exception`) before writing to the StreamWriter?

This might be related to bpo-34176.

--
components: asyncio
files: tcp_test.py
messages: 334450
nosy: asvetlov, schlamar, yselivanov
priority: normal
severity: normal
status: open
title: Control flow inconsistency on closed asyncio stream
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48082/tcp_test.py

___
Python tracker 

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

[issue35791] Unexpected exception with importlib

[Nick Coghlan]

Nick Coghlan  added the comment:

#35839 is follow-up enhancement request, proposing that we tweak the 
sys.modules handling in find_spec to ignore cache entries that don't have a 
__spec__ attribute set.

--

___
Python tracker 

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

[issue35839] Suggestion: Ignore sys.modules entries with no __spec__ attribute in find_spec

[Nick Coghlan]

Nick Coghlan  added the comment:

I'd also suggest that we emit ImportWarning when taking the fallback path, 
since we really would prefer that sys.modules entries either have a valid 
__spec__, or else explicitly set `__spec__ = None`.

--

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Nick Coghlan]

Nick Coghlan  added the comment:

OK, I've filed #35839 to propose falling back to a regular search when the 
__spec__ attribute is missing, while treating "obj.__spec__ is None" as a true 
negative cache entry.

--

___
Python tracker 

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

[issue35839] Suggestion: Ignore sys.modules entries with no __spec__ attribute in find_spec

[Nick Coghlan]

New submission from Nick Coghlan :

(Alternate proposal inspired by the discussions in #35806 and #35791)

Currently, a sys.modules entry with no __spec__ attribute will prevent 
importlib.util.find_spec() from locating the module, requiring the following 
workaround:

   def find_spec_bypassing_module_cache(modname):
   _missing = object()
   module = sys.modules.pop(modname, _missing)
   try:
   spec = importlib.util.find_spec(modname)
   finally:
   if module is not _missing:
   sys.modules[modname] = module

The big downside of that approach is that it requires mutation of global state 
in order to work.

One of the easiest ways for this situation to be encountered is with code that 
replaces itself in sys.modules as a side effect of import, and doesn't bind 
__spec__ on the new object to the original module __spec__.

While we could take the hard line that all modules doing that need to transfer 
the attribute in order to be properly compatible with find_spec, I think 
there's a more pragmatic path we can take by differentiating between "__spec__ 
attribute doesn't exist" and "__spec__ attribute exists, but is None".

"__spec__ attribute doesn't exist" would be handled by find_spec as "Ignore the 
sys.modules entry entirely, and run the same search that would be run if the 
cache lookup had failed". This will then implicitly handle cases where a module 
replaces its own sys.modules entry.

By contrast, "__spec__ attribute is set to None" would be a true negative cache 
entry that indicated "this is a synthetic module that cannot be directly 
introspected or reloaded".

--
components: Library (Lib)
messages: 334446
nosy: brett.cannon, eric.snow, ncoghlan, ronaldoussoren
priority: normal
severity: normal
status: open
title: Suggestion: Ignore sys.modules entries with no __spec__ attribute in 
find_spec
type: enhancement

___
Python tracker 

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

[issue35832] Installation error

[Steve Dower]

Steve Dower  added the comment:

Thanks. You should have some more log files - I'm particularly interested in 
the one with "3.7.2" and "core_JustForMe" in the filename, as that is the one 
that failed.

Also, did you notice that you have 64-bit 3.7.0 and 32-bit 3.7.2? Is that 
deliberate? You can find the 64-bit version at 
https://www.python.org/downloads/release/python-372/

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

Yes, I signed the CLA and now I have to wait at least 1 business day.
So I will wait for that confirmation before making the PR to the CPython repo.

Thanks,

JM

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

@jcrmatos yes, you should be making a PR to CPython repo's master branch since 
GitHub PRs are accepted. I hope also need to sign the CLA for your contribution 
to get merged though it's a documentation fix.

Thanks

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

On the previous message I forgot to mention that the pull request was made in 
my fork, not the cpython repo.
Should I made a PR in the cpython repo at this point?

Thanks,

JM

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

I'm using Github web interface.
I did these steps:
- Forked cpython and changed the pdb.rst file.
- Created a branch called "fix-issue-35835".
- Made the commit with description "Add reference to Python 3.7 new function 
breakpoint()".
- Made the pull request with title "bpo-35835: Add reference to Python 3.7 new 
function breakpoint()".
- Made the merge commit.

Now I have an option to delete the fix-issue-35835 branch.
Should I do it? I read some Git tutorials and I think I can, but can you 
confirm?

After that, how should I procede to create the patch?

Thanks,

JM

--

___
Python tracker 

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

[issue31710] setup.py: _ctypes won't get built when system ffi is only in $PREFIX

[Chih-Hsuan Yen]

Change by Chih-Hsuan Yen :


--
nosy:  -yan12125

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

Yes, I'm interested in learning, thanks.
I use Windows not Linux. Is that a problem?
I will read the guide and let you know if I have any questions. Thanks again.

JM

--

___
Python tracker 

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

[issue29541] Python3 error while building on Alt-F

[Chih-Hsuan Yen]

Change by Chih-Hsuan Yen :


--
nosy:  -yan12125

___
Python tracker 

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

[issue35838] ConfigParser calls optionxform twice when assigning dict

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue35838] ConfigParser calls optionxform twice when assigning dict

[Phil Kang]

New submission from Phil Kang :

ConfigParser calls ConfigParser.optionxform twice per each key when assigning a 
dictionary to a section.

The following code:

ini = configparser.ConfigParser()
ini.optionxform = lambda x: '(' + x + ')'

# Bugged
ini['section A'] = {'key 1': 'value 1', 'key 2': 'value 2'}
# Not bugged
ini.add_section('section B')
ini['section B']['key 3'] = 'value 3'
ini['section B']['key 4'] = 'value 4'

   inifile = io.StringIO()
   ini.write(inifile)
   print(inifile.getvalue())

...results in an INI file that looks like:

[section A]
((key 1)) = value 1
((key 2)) = value 2

[section B]
(key 3) = value 3
(key 4) = value 4

Here, optionxform has been called twice on key 1 and key 2, resulting in the 
double parentheses.

This also breaks conventional mapping access on the ConfigParser:

print(ini['section A']['key 1'])# Raises KeyError('key 1')
print(ini['section A']['(key 1)'])  # OK

# Raises ValueError: too many values to unpack (expected 2)
for key, value in ini['section A']:
print(key + ', ' + value)

--
components: Library (Lib)
messages: 334439
nosy: Phil Kang
priority: normal
severity: normal
status: open
title: ConfigParser calls optionxform twice when assigning dict
type: behavior
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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Cheryl Sabella]

Cheryl Sabella  added the comment:

@jcrmatos,

No problem.  :-)  If you are interested in learning how, we can guide you.  
However, if you'd rather not, then that's OK too and we'll make the patch.  
Just let us know which you'd prefer.

If you need help deciding, take a look at the devguide on how to get started.  
https://devguide.python.org/

Thanks!

--

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Note that I will have to special case namespaces like typing.re anyway in my 
code, being a namespace that does not correspond to a "real" module whose code 
I can analyse.

#35791 was mostly about 3th-party code like apipkg that are "real" modules, but 
for some reason effectively erase there __spec__ attribute. In those cases 
find_spec could return valid value.

As I mentioned in the other issue I have a simple workaround for this, and 
that's something I'll have to keep around for a while anyway. 

I'm not convinced at this point that anything needs to be changed, as long as 
the documentation is clear on the requirement that modules should have a 
__spec__ attribute (which makes it easier to convince 3th-party authors to 
update their code). 

Special cases like typing.re will always be special, and adding __spec__ to 
them won't change a lot there (the only vaguely useful attribute in the 
ModuleSpec for typing.re would be "name" and "parent") and IMHO would be 
needless code churn.

--

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Guido van Rossum]

Guido van Rossum  added the comment:

Option 2 sounds best. I am also not against adding __spec__ but I think we
should support the idiom regardless, and I don’t consider this a bug in the
typing module — at best there’s a slight improvement.

On Sun, Jan 27, 2019 at 6:50 AM Nick Coghlan  wrote:

>
> Nick Coghlan  added the comment:
>
> Closing this without any changes contradicts the answer we gave Ronald on
> #35791 that it's expected behaviour for importlib.find_spec() to throw an
> exception for already loaded modules without a __spec__ attribute.
>
> So if this stays closed, then we should reopen #35791, and treat it as a
> feature request to either:
>
> 1. add a "ignore_module_cache" option to bypass sys.modules; or
> 2. revert to searching for the original spec in cases where the
> sys.modules entry has no __spec__ attribute (which has the virtue of just
> working for cases of the "replace yourself in sys.modules" idiom)
>
> That said, the typing pseudo submodules *can* populate their __spec__ with
> useful information by copying most of their attributes from
> `typing.__spec__`, but setting their __spec__.loader attribute to one that
> throws an ImportError with a message saying to import `typing` instead of
> attempting to reload the submodule directly.
>
> --
>
> ___
> Python tracker 
> 
> ___
>
-- 
--Guido (mobile)

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

I'm sorry, I have no idea how to do it.

JM

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Cheryl Sabella]

Cheryl Sabella  added the comment:

@jcrmatos, would you like to create a Github pull request with the change?

--

___
Python tracker 

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

[issue35832] Installation error

[Stefano Bonalumi]

Stefano Bonalumi  added the comment:

Hi
plesaes find these files attached
Please give me further instructions

Thanks a lot

Il giorno sab 26 gen 2019 alle ore 16:21 Steve Dower 
ha scritto:

>
> Steve Dower  added the comment:
>
> You should have a set of log files in your %TEMP% directory. Their names
> will start with Python and end in .log. If you could collect these into a
> zip file and post them here, that would be very helpful.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: https://bugs.python.org/file48080/Python 3.7.0 
(64-bit)_20190127100020.log
Added file: https://bugs.python.org/file48081/Python 3.7.2 
(32-bit)_20190127100056.log

___
Python tracker 

___[1AC8:289C][2019-01-27T10:00:20]i001: Burn v3.11.1.2318, Windows v10.0 (Build 
17763: Service Pack 0), path: 
C:\Users\Admin\AppData\Local\Temp\{8B2A7EA8-B5D7-44A3-856A-29C72168}\.cr\python-3.7.0-amd64.exe
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'ActionLikeInstalling' to value 'Installing'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'ActionLikeInstallation' to value 'Setup'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'ShortVersion' to value '3.7'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'ShortVersionNoDot' to value '37'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'WinVer' to 
value '3.7'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'WinVerNoDot' to value '37'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'InstallAllUsers' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'InstallLauncherAllUsers' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'TargetDir' 
to value ''
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'DefaultAllUsersTargetDir' to value '[ProgramFiles64Folder]Python[WinVerNoDot]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'TargetPlatform' to value 'x64'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'DefaultJustForMeTargetDir' to value 
'[LocalAppDataFolder]Programs\Python\Python[WinVerNoDot]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'OptionalFeaturesRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstalledFeatures'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'TargetDirRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstallPath'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'DefaultCustomTargetDir' to value ''
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'InstallAllUsersState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'InstallLauncherAllUsersState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'TargetDirState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'CustomBrowseButtonState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_core' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_exe' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_dev' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_lib' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_test' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_doc' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_tools' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_tcltk' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_pip' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_launcher' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 
'Include_launcherState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_symbols' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'Include_debug' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'LauncherOnly' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 
'DetectedLauncher' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing 

[issue32834] test_gdb fails with Posix locale in 3.7

[STINNER Victor]

STINNER Victor  added the comment:

> Possibly fixed with issue34537 ?

"LC_ALL=C ./python -We -m test -vuall -m test_strings test_gdb" still fails for 
me on Fedora 29.

==
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
--
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 380, in 
test_strings
check_repr('\u2620')
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 372, in 
check_repr
self.assertGdbRepr(text)
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 302, in 
assertGdbRepr
gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 269, in 
get_gdb_repr
gdb_output = self.get_stack_trace(source, breakpoint=BREAKPOINT_FN,
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 249, in 
get_stack_trace
self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ["Python Exception  'ascii' codec can't encode 
character '\\u2620' in position 1: ordinal not in range(128): "

+ []
- ["Python Exception  'ascii' codec can't encode "
-  "character '\\u2620' in position 1: ordinal not in range(128): ",
-  "Python Exception  'ascii' codec can't encode "
-  "character '\\u2620' in position 1: ordinal not in range(128): "]


Note: "LC_ALL=C ./python -m test -m test_strings test_gdb" (simpler command) 
also fails.

--

___
Python tracker 

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

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Sorry, I overlooked that one. While searching for other smtpd issues many of 
them were closed as won't fix and hence my message. Thanks for the link.

--

___
Python tracker 

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

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

[Samuel Colvin]

Samuel Colvin  added the comment:

Hi, did you see https://bugs.python.org/issue35788#msg334155 later in the issue?

--

___
Python tracker 

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

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

[Sjoerd]

Change by Sjoerd :


--
nosy: +samuelcolvin

___
Python tracker 

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[Paul Ganssle]

Paul Ganssle  added the comment:

> It seems a little odd to need to pull in a third-party library for this; it 
> seems far more tempting for me to just do 
> "datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I know my 
> dates are produced by a JSON API.

Yes, this is also a viable solution. Generally speaking, third party libraries 
are less onerous these days than they have been in the past, and there are many 
things that are delegated to third party libraries because staying out of the 
standard library gives more flexibility in release cycles and the APIs don't 
need to be quite as stable.

> FWIW, I do think that fromisoformat() is the right function to provide 
> RFC3339 support.  I don't think
> users would benefit from having to choose between several different functions 
> that parse similar but
> subtly different date formats; this seems likely to cause confusion.

This is in fact one of the reasons to proceed with caution here, because ISO 
8601, RFC 3339 and datetime.isoformat() are three slightly different and in 
some senses *incompatible* datetime serialization formats. If I had the choice, 
I would probably either not have named `isoformat` the way it is named, or I 
would have stuck to the standard, but what's done is done. As it is now, all 
the "fromX" alternate constructors are simply the inverse operation of the 
corresponding "X" method. If we make fromisoformat accept the RFC 3339 subset 
of ISO 8601, people will find it confusing that it doesn't support even some of 
the most common *other* ISO 8601 formats, considering it's called 
`fromisoformat` not `fromrfcformat`.

To give you an idea of why this sort of thing is a problem, it's that with each 
minor change, expanding the scope a little sounds reasonable, but along with 
that comes maintenance burdens. People start to rely on the specific behavior 
of the function, and eventually you get into a position where someone asks for 
a very reasonable expansion of the scope that is incompatible with the way 
people are already using the function. This leads you to either stop developing 
the function at some arbitrary point or to start tacking on a configuration API 
to resolve these incompatibilities.

If instead we design the function from the beginning with a very clear scope, 
we can also design the configuration API (and the default values) from the 
beginning as well. I definitely believe there is a place for a function that 
parses at least the timestamp portions of the ISO 8601 spec in CPython. I think 
I would prefer it to be a separate function from fromisoformat. I also think 
that it's worth letting it marinate in dateutil a bit, so that we can get a 
sense of what works and what doesn't work as a configuration API so that it's 
at least *easier* for people to select which of the subtly different datetime 
formats they're intending to parse.

--

___
Python tracker 

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

[issue35537] use os.posix_spawn in subprocess

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
pull_requests: +11528

___
Python tracker 

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

[issue35806] typing module adds objects to sys.modules that don't look like modules

[Nick Coghlan]

Nick Coghlan  added the comment:

Closing this without any changes contradicts the answer we gave Ronald on 
#35791 that it's expected behaviour for importlib.find_spec() to throw an 
exception for already loaded modules without a __spec__ attribute.

So if this stays closed, then we should reopen #35791, and treat it as a 
feature request to either:

1. add a "ignore_module_cache" option to bypass sys.modules; or
2. revert to searching for the original spec in cases where the sys.modules 
entry has no __spec__ attribute (which has the virtue of just working for cases 
of the "replace yourself in sys.modules" idiom)

That said, the typing pseudo submodules *can* populate their __spec__ with 
useful information by copying most of their attributes from  `typing.__spec__`, 
but setting their __spec__.loader attribute to one that throws an ImportError 
with a message saying to import `typing` instead of attempting to reload the 
submodule directly.

--

___
Python tracker 

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

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the report. smtpd is deprecated in favor of aiosmtpd. Some of the 
fixes were closed in the past as won't fix. Please see 
https://bugs.python.org/issue35788#msg334088 and the discussion for deprecation 
and removal.

--
nosy: +barry, xtreak

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I am ok with Cheryl's idea too.

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

In my first message I said exactly that (the replacement used the previous 
text, if you check it).

I'm ok with the wording from Cheryl. How about you Karthikeyan?

Thanks,

JM

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I agree with Karthikeyan.  If it's added to the pdb doc page, I think the 
existing text should stay as it is, but a 'New in 3.7' added after it.

Something like:

The typical usage to break into the debugger from a running program is to insert

import pdb; pdb.set_trace()

at the location you want to break into the debugger. You can then step through 
the code following this statement, and continue running without the debugger 
using the continue command.

New in version 3.7: The built-in :func:`breakpoint()`, when called with 
defaults, can be used instead of ``import pdb; pdb.set_trace()``.

--
nosy: +cheryl.sabella

___
Python tracker 

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

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch, patch
pull_requests: +11526, 11527
stage:  -> patch review

___
Python tracker 

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

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +11526
stage:  -> patch review

___
Python tracker 

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

[issue11315] unicode support in Cookie module

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

[Sjoerd]

New submission from Sjoerd :

According to https://python.readthedocs.io/en/stable/whatsnew/3.5.html:

The SMTPServer class now advertises the 8BITMIME extension (RFC 6152) if 
decode_data has been set True. If the client specifies BODY=8BITMIME on the 
MAIL command, it is passed to SMTPServer.process_message() via the mail_options 
keyword. (Contributed by Milan Oberkirch and R. David Murray in bpo-21795.)

This means that process_message gets a mail_options kwarg. However, the smtpd 
PureProxy and MailmanProxy don't take keyword arguments, which results in an 
exception.

One way to trigger this is to run a debug mailserver and send a mail to it:

$ python3 -m smtpd -n
error: uncaptured python exception, closing channel <__main__.SMTPChannel 
connected ('::1', 52007, 0, 0) at 0x10e7eddd8> (:process_message() got an unexpected keyword argument 
'mail_options' 
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncore.py|read|83]
 
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncore.py|handle_read_event|422]
 
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asynchat.py|handle_read|171]
 
[/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/smtpd.py|found_terminator|386])

--
components: Library (Lib)
messages: 334424
nosy: Sjoerder, giampaolo.rodola, r.david.murray
priority: normal
severity: normal
status: open
title: smtpd PureProxy breaks on mail_options keyword argument
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I didn't want the doc to sound like breakpoint() is encouraged since it's 
optional and a shortcut. Hence my personal preference to just add a note with 
link to breakpoint() that it does the same thing. I will wait for someone else 
to rephrase it better since I am not a native speaker myself.

Thanks

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[jcrmatos]

jcrmatos  added the comment:

Hello,

What about like this
import pdb; pdb.set_trace()
New in version 3.7: breakpoint() is preferable to using the previous line.

Thanks,

JM

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

> New in version 3.7: breakpoint() replaces the previous line.

replaces sounds little more like removed or deprecated to me. How about the 
below under pdb.set_trace() doc and example using it in the beginning?

New in version 3.7: breakpoint() is a convenience function that internally 
calls pdb.set_trace()

Thanks

--
nosy: +xtreak

___
Python tracker 

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

[issue32834] test_gdb fails with Posix locale in 3.7

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Possibly fixed with issue34537 ?

--
nosy: +xtreak

___
Python tracker 

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

[issue35836] ZeroDivisionError class should have a __name__ attr

[jcrmatos]

jcrmatos  added the comment:

Hello,

You are correct. My bad.

Thanks,

JM

--

___
Python tracker 

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

[issue35835] There is no mention of breakpoint() in the pdb documentation

[SilentGhost]

Change by SilentGhost :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
stage:  -> needs patch

___
Python tracker 

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

[issue35836] ZeroDivisionError class should have a __name__ attr

[Steven D'Aprano]

Steven D'Aprano  added the comment:

You are not looking at the class, you are looking at an instance:

py> exc = ZeroDivisionError('divide by zero')
py> type(exc).__name__
'ZeroDivisionError'
py> exc.__name__
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'ZeroDivisionError' object has no attribute '__name__'

--
nosy: +steven.daprano
resolution:  -> not a bug
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

[issue35834] get_type_hints exposes an instance of ForwardRef (internal class) in its result, with `from __future__ import annotations` enabled

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

It looks like an opposite side of https://github.com/python/typing/issues/508 
(I wanted to work on it, but never had time to, sorry).

This question appeared couple times before, and I think there are pros and cons 
for both returning a ForwardRef() and for raising a NameError. So as I proposed 
in the issue above, there should be a flag to `get_type_hints()` that controls 
what to do (the name of the flag, and the default are of course debatable).

Of course, we should try to make `get_type_hints()` behave as much similar as 
possible with and without PEP 563, regardless. But my point is that currently 
we have this "in-between" behavior, and it is harder to maintain this 
"in-between" behavior against PEP 563, than two clearly defined extremes.

> So I expect that when calling get_type_hints it should return the unquoted 
> string, rather than a ForwardReference.

I think the values in the returned dictionary should always be types, either 
fully evaluated, or ForwardRefs (expecting two options is easier than expecting 
three).

--

___
Python tracker 

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

[issue35836] ZeroDivisionError class should have a __name__ attr

[jcrmatos]

New submission from jcrmatos :

Hello,

When trying this
try:
1/0
except Exception as exc:
print(type(exc))  # returns 
print(exc.__name__)  # returns AttributeError: 'ZeroDivisionError' object 
has no attribute '__name__'

I believe all classes should have a __name__ attr, correct?

It would be nice to check all the other exceptions to see if any other is also 
missing the __name__ attr.

Thanks,

JM

--
messages: 334416
nosy: jcrmatos
priority: normal
severity: normal
status: open
title: ZeroDivisionError class should have a __name__ attr
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