[issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x

[Éric Araujo]

Éric Araujo added the comment:

Patch looks good and would fix the reported problem.  Being a backport from 
setuptools also gives confidence.

Does the patch change the behaviour for the handling of the MANIFEST file (not 
MANIFEST.in)?  My previous message mentions that the docs say that one can 
include symlinks in MANIFEST.

--
assignee: eric.araujo -> jason.coombs

___
Python tracker 

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

[issue23639] Not documented special names

[Raymond Hettinger]

Raymond Hettinger added the comment:

> I think most of these are either implementation details
> or "private" names, so there is no need to document them. 

Also, we want to be careful to not guarantee implementation details that are 
subject to change.  Most of these are not intended for users to base their code 
on.

IIRC, Guido already opined on some of these (preferring to keep most of them 
undocumented) in some other tracker item this year.

As one data point, I worked on the decimal module and defined the public API.  
The __decimal_context__ method is not part of the public API.

--
nosy: +rhettinger

___
Python tracker 

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

[issue24934] django_v2 benchmark not working in Python 3.6

[Florin Papa]

Florin Papa added the comment:

The Django 1.8 archive that I attached is not patched, it is downloaded from 
the django github page without modifications. I have tested and Django 1.8 
works with the latest Python version pulled from hg.python.org/cpython.

--

___
Python tracker 

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

[issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

[Roberto Sánchez]

Roberto Sánchez added the comment:

In my case, I modify the stdout but the error was thrown by a third party 
(click lib), I need to overwrite the stdout because the program has a CLI and 
the locale env in the terminal seems to be wrong:
 codecs.lookup(locale.getpreferredencoding()).name == 'ascii'
 sys.getdefaultencoding() == 'utf-8'

For these cases I try to fix it forcing the the IO encoding to the value given 
by sys.getdefaultencoding(), otherwise the script in a CLI won't work properly. 

I can apply a monkey-patch on the third party method that return 
"os.get_terminal_size()" if a ValueError exception is thrown, actually, The 
script is working now with the monkey-patch, but I thought that a bit of more 
"magic" in get_terminal_size would help to deal with the encoding issues in 
python3 CLI programs.

--

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Nathaniel Smith]

Nathaniel Smith added the comment:

On further thought, here's a slightly improved version of the patch I posted 
above.

The difference is that the first version allowed through attempted __class__ 
assignments where either the old or new class was a subclass of ModuleType; the 
new version only allows through attempted assignments if both the old AND new 
class are a subclass of ModuleType.

In practice this doesn't make any difference, because the 
compatibility-checking code will reject any attempt to switch from a ModuleType 
subclass to a non ModuleType subclass or vice-versa. So both patches are 
correct. But the new patch is more obviously correct.

--
Added file: http://bugs.python.org/file40312/issue24912-v2.patch

___
Python tracker 

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

[issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking

[Yury Selivanov]

Yury Selivanov added the comment:

Good find, David. Thanks!

Please review the attached patch.

--
keywords: +patch
nosy: +benjamin.peterson, larry, ncoghlan, serhiy.storchaka, yselivanov
priority: normal -> release blocker
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file40311/issue24975.patch

___
Python tracker 

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

[issue24931] _asdict breaks when inheriting from a namedtuple

[Eric Snow]

Eric Snow added the comment:

Doesn't the fix mean that `vars(MyNamedtuple)` will no longer work?  While I 
personally don't mind (though I prefer that spelling) and appreciate the 
benefit of simpler code, isn't there a backward-compatibility issue here?

I do concede that fixing this bug without a compatibility break is complicated 
and probably not worth it.  However I want to make sure that the point is at 
least discussed briefly.

--
nosy: +eric.snow

___
Python tracker 

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

[issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale

[R. David Murray]

R. David Murray added the comment:

I believe there is at least one open issue about Python adopting utf8 as the 
default instead of ASCII, and in any case, several conversations about how to 
deal with all this better.  This is just one example of a class of issues 
caused by the ASCII/C posix default locale, in different contexts.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

[R. David Murray]

R. David Murray added the comment:

So, the problem is needing to compensate for a broken (according to posix) 
locale setup.  I don't think quieting get_terminal_size is necessarily the 
answer here.  See issue 19846 for more than you want to know about the ASCII 
locale issue.

See also issue 15216, which is probably a solution to your problem, but is an 
open issue.

--

___
Python tracker 

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

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[Marek Otahal]

New submission from Marek Otahal:

I'd like to use @lru_cache in a library. The problem is I can't know the 
optimal values for 'maxsize', I need to set them at runtime. 

I came with 2 possibilities: 
1/ set cache's size from a hardcoded argument of the decorated method: 
@lru_cache
def foo_long(self, arg1, ..., **kwds):
  pass

# use
foo_long('hi', cacheSize = 1000)

This approach allows the users to customize cache size for their problem. 

2/ from function's **kwds retrieve a name (string) of an instance member of the 
class which will hold the cache's size value. This is not as clean as 1/, but 
offers greated functionality for the use in a library sw: we can compute 
desired cache size from internal values of the unstance, and the use of cache 
can be totally transparent to the end user: 
@lru_cache
def foo_long(self, arg1, .. , **kwds)
#use
foo_long('hi', cacheSizeRef='_cacheSize')

What do you think about the proposal? 
best regards, Mark

--
messages: 249406
nosy: Marek Otahal
priority: normal
severity: normal
status: open
title: functools.lru_cache: a way to set decorator arguments at runtime
type: enhancement

___
Python tracker 

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

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[R. David Murray]

R. David Murray added the comment:

How is (1) different from:

  @lru_cache(maxsize=1000)
   def foo_long(self, arg1...)

As for computing it at runtime: if you need to compute it, you can compute it 
and *then* define the decorator wrapped function.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[Marek Otahal]

Marek Otahal added the comment:

Hope this example is not too confusing, it's a patch to my code and lru_cache 
(backport for python 2.7 from ActiveState)

It implements both approaches as highlighted above, and in the test both of 
them are used (that does not make much sense, normally one would use either of 
them only)

--

___
Python tracker 

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

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[Marek Otahal]

Marek Otahal added the comment:

Hi David, 

> How is (1) different from:
  @lru_cache(maxsize=1000)
   def foo_long(self, arg1...)

As I mentioned, for use in a library that is called by end-users. They can call 
functions and modify params, but do not edit the code. It's up to me (lib devs) 
to prepare the cache decorator. Ie.:
class MyLib():
  @lru_cache
  def foo_long(self, arg1, **kwds):
pass
#user
import MyLib 
i = MyLib()
i.foo_long(1337)

> As for computing it at runtime: if you need to compute it, you can compute it 
> and *then* define the decorator wrapped function.

ditto as above, at runtime no new decorator definitions should be needed for a 
library. 
+ a speed penalty, I'd have to wrap a wrapper in 1 or 2 more nested functions, 
which incures a speed penalty, and we're focusing at cache here. I esp. mention 
this as I've noticed the ongoing effort to use a C implementation of lru_cache 
here.

--

___
Python tracker 

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

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[Marek Otahal]

Marek Otahal added the comment:

EDIT: 
> i.foo_long(1337)

ofc, this should be: 
i.foo_long('hi', cacheSize=1337)

or for (2): 

class MyLib():
  def __init__(arg1, arg2):
self._cacheSize = someComputation(arg1, arg2) # returns a number
  @lru_cache
  def foo_long(self, arg1, **kwds):
pass
#user
import MyLib 
i = MyLib(100, 21)
# not to make it so simple: 
i.changeInternalStateSomehow() # updates arg1, arg2, and also _cacheSize
i.foo_long(1337, cacheSizeName='_cacheSize') # ref to self._cacheSize

--

___
Python tracker 

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

[issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

[Roberto Sánchez]

Roberto Sánchez added the comment:

Thank you for the references, changing the encoding of an open stream sounds 
interesting, but It's targeted for v. 3.6 so It seems a bit far away.

Anyway, as I said I fixed on my side with monkey-patching on the third-party 
lib, the broken locale is just the context, just to explain how I got this 
issue, I opened this because I honestly though that could be better to return 
the fallback value that raise an exception, but you know better the "big 
picture" so, if It's better as is, It's ok for me.

BTW, I don't find the opened issue to use utf8 as default instead ascii (except 
for Windows)

--

___
Python tracker 

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

[issue22798] time.mktime doesn't update time.tzname

[Akira Li]

Akira Li added the comment:

The C code produces correct values according to the tz database.

If TZ=Europe/Moscow then
tzname={"MSK", "MSD"} at 2010-07-01 and
tzname={"MSK", "MSK"} at 2015-07-01. Notice the difference!

The code calls C mktime() with corresponding time tuples
and checks that *tzname* is equal to the expected values. That's all.

If C code is incomprehensible; here's its Python analog:

  >>> import os
  >>> os.environ['TZ'] = 'Europe/Moscow'
  >>> import time
  >>> time.tzset()
  >>> time.mktime((2010,7,1,0,0,0,-1,-1,-1))
  1277928000.0
  >>> time.tzname #XXX expected ('MSK', 'MSD')
  ('MSK', 'MSK')
  >>> time.mktime((2015,7,1,0,0,0,-1,-1,-1))
  1435698000.0
  >>> time.tzname
  ('MSK', 'MSK')


C tzname changes on my machine after the corresponding C mktime() calls 
but Python time.tzname does not change after the time.mktime() calls.

--

___
Python tracker 

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

[issue24934] django_v2 benchmark not working in Python 3.6

[Brett Cannon]

Brett Cannon added the comment:

Hmm, strange. I downloaded Django 1.8.latest myself and placed it and I still 
got the getargspec() failure using the default branch. I'll try again and 
verify that it wasn't something odd on my end.

--

___
Python tracker 

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

[issue24967] add errors='ignore' to print kwargs

[Brett Cannon]

Brett Cannon added the comment:

I agree with Serhiy that this isn't print's job to worry about. It's better to 
be explicit than implicit and trying to cram worrying about decoding errors 
conflates what print does.

I'm closing as "rejected". Thanks for the suggestion, though, Lukáš.

--
nosy: +brett.cannon
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue24970] Make distutils.Command an ABC

[Antony Lee]

New submission from Antony Lee:

Currently, distutils.Command is a "hand-written" ABC; i.e. direct instantiaion 
or calling the "abstract" methods initialize_options, run and finalize_options 
raises a RuntimeError saying that the method (not named in the error message, 
which is thus a little bit cryptic) must be overriden.

In particular, this makes it impossible to use super() when overriding these 
methods (while Command.{initialize_options,run,finalize_options} have empty 
implementations, using super() is a fairly normal approach when inheriting, and 
needed in the case of multiple inheritance).

Switching to an ABC-based design would solve this issue.

--
components: Distutils
messages: 249415
nosy: Antony.Lee, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Make distutils.Command an ABC
versions: Python 3.5

___
Python tracker 

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

[issue24971] os.environ.get() does not return the Environment Value in Linux

[Francis Greaves]

New submission from Francis Greaves:

I am running an up to date Gentoo Linux x86_64. using Python 2.7
I have an environment variable defined, so from the command line 'echo 
$XRIT_DECOMPRESS_PATH' gives '/usr/local/bin/xRITDecompress'
however, in a Python script, 'cmd = os.environ.get('XRIT_DECOMPRESS_PATH')' 
gives 'None' as the output.
Why is that?

--
components: Interpreter Core
messages: 249416
nosy: themetman
priority: normal
severity: normal
status: open
title: os.environ.get() does not return the Environment Value in Linux
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue22798] time.mktime doesn't update time.tzname

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> C tzname changes on my machine after the corresponding C mktime() calls 

Did you run the code that I posted?  If not - please do and report the results.

(I think there is a valid issue behind all this, but you are not helping to 
reveal it.  I suspect we can do better by just relying on system tzset() and 
not have the try June and January work-around.  That's why I added Antoine to 
the "nosy" as the developer who last touched this code.)

--

___
Python tracker 

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

[issue24971] os.environ.get() does not return the Environment Value in Linux

[eryksun]

eryksun added the comment:

Did you mark the variable for export in your shell? For example:

$ v=1
$ python -c 'import os;print os.environ.get("v")'
None

$ export v
$ python -c 'import os;print os.environ.get("v")'
1

--
nosy: +eryksun

___
Python tracker 

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

[issue24971] os.environ.get() does not return the Environment Value in Linux

[Francis Greaves]

Francis Greaves added the comment:

I have the environment variable in my .bashrc file.
Interestingly if I do 'os.environ.get("PATH")' it returns the correct value for 
$PATH. This is also defined in my .bashrc file, so it should be exported.
I have exported it manually from the command line, but it makes no difference.
The command is in a .py file run as 'python myscript.py' as follows
import os
cmd=os.environ.get("PATH")

this makes cmd as 'None'
??

--

___
Python tracker 

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

[issue24971] os.environ.get() does not return the Environment Value in Linux

[Francis Greaves]

Francis Greaves added the comment:

Sorry my error
I should have said
cmd = os.environ.get('XRIT_DECOMPRESS_PATH')' gives 'None' as the output

--

___
Python tracker 

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

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[R. David Murray]

R. David Murray added the comment:

There is no patch/example attached. 

It seems like what you really want is an API on lru_cache for updating the 
cache size.

What I'm saying is that the cache size can be passed in on the MyLib call, and 
the decorator/function constructed as part of MyLib's initialization.

--

___
Python tracker 

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

[issue24972] IDLE: revisit text highlighting for inactive windows on win32

[Mark Roseman]

New submission from Mark Roseman:

This is a followup to #14146

I don't think this is actually a Tk bug. The text widget supports an 
"inactiveselectbackground" option which controls the background color of the 
selection when the window is not active. On Win32, this is defined as empty 
(i.e. no highlighting).

This option is new in Tk 8.5. I don't believe that Tk 8.4 displayed the 
selection differently for active and inactive windows, hence why the problem 
never showed up until 8.5. 

It seems that if running 8.5, setting this widget option to the desired color 
would then remove the need for the _highlight_workaround() in EditorWindow.py.  

Can someone else besides me try this out please?

--
components: IDLE
messages: 249422
nosy: Rich.Rauenzahn, Todd.Rovito, dzabel, loewis, markroseman, roger.serwy, 
terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: revisit text highlighting for inactive windows on win32
versions: Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

[R. David Murray]

R. David Murray added the comment:

Yeah, I think I was thinking of issue 19846, which was fixed by using 
surrogateescape on the standard streams instead of "guessing" utf-8.

I'm not utterly opposed to turning the ValueError into a default return value, 
but as you can see, the fact that the ValueError was returned pointed toward 
the deeper problem (needing to have a way to change the encoding of an 
already-existing TextIO stream).

--

___
Python tracker 

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

[issue24971] os.environ.get() does not return the Environment Value in Linux

[R. David Murray]

R. David Murray added the comment:

Well, it works fine for us (I'm on Gentoo as well).  os.environ is a pretty 
thin wrapper around the os functions, so I'm not sure what to suggest as far as 
debugging why it isn't working for you.

Did you try exactly eryksun's example yourself?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24971] os.environ.get() does not return the Environment Value in Linux

[Francis Greaves]

Francis Greaves added the comment:

erykson's example works perfectly.
I have a script as follows

#!/bin/python
#
import os
cmd = os.environ.get('XRIT_DECOMPRESS_PATH')
print cmd

resulting in 'None'

and if I substitute this line
cmd = os.environ.get('PATH')

resulting in 
'/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4:/usr/include/KDE'

however from the bash prompt
$ echo $XRIT_DECOMPRESS_PATH
results in '/usr/local/bin/xRITDecompress' so the environment variable  is 
there and available in bash, but not in Python.
I find this very strange

--

___
Python tracker 

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

[issue24971] os.environ.get() does not return the Environment Value in Linux

[R. David Murray]

R. David Murray added the comment:

That means you just haven't exported it properly.  There is nothing wrong with 
Python here, as demonstrated by the fact that you were able to run eryksun's 
example (which is equivalent to your script).

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

[issue24973] CFLAGS for Visual Studio

[Chris Hogan]

New submission from Chris Hogan:

This Visual Studio project change appends to the compiler flags any values in 
the CFLAGS environment variable.

--
components: Build, Windows
files: addcflags3_5.patch
keywords: patch
messages: 249427
nosy: christopher.hogan, paul.moore, r.david.murray, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: CFLAGS for Visual Studio
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file40308/addcflags3_5.patch

___
Python tracker 

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

[issue24973] CFLAGS for Visual Studio

[Chris Hogan]

Changes by Chris Hogan :


Added file: http://bugs.python.org/file40309/addcflags2_7.patch

___
Python tracker 

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

[issue24974] ICC on Windows 8.1: _decimal fails to compile without /fp:strict

[Zachary Ware]

New submission from Zachary Ware:

When building on Windows 8.1 with ICC 15.0 (backed by VS 2015 Community), the 
_decimal module fails to compile:

ClCompile:
  mpdecimal.c
..\Modules\_decimal\libmpdec\mpdecimal.c(46): error : fenv_access cannot be 
enabled except in precise, source, double, and extended modes 
[P:\ath\to\cpython\PCbuild\_decimal.vcxproj]
#pragma fenv_access(on)
   ^

Unfortunately, I can't reproduce this on two other machines both running 
Windows Server 2012 R2, with otherwise nearly identical configurations to mine.

Since I can't reproduce it elsewhere (including on the ICC Windows buildbot) 
and have a relatively easy workaround (passing '/fp:strict' makes the problem 
go away), setting priority to 'low' until somebody else can reproduce it.

--
components: Build, Windows
messages: 249428
nosy: facundobatista, mark.dickinson, paul.moore, r.david.murray, rhettinger, 
skrah, steve.dower, tim.golden, zach.ware
priority: low
severity: normal
stage: test needed
status: open
title: ICC on Windows 8.1: _decimal fails to compile without /fp:strict
type: compile error
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue24973] CFLAGS for Visual Studio

[Steve Dower]

Steve Dower added the comment:

The patch should just set it once in pyproject.props, not in each project.

Why is this necessary? Is there an option we should be exposing in some other 
way?

--

___
Python tracker 

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

[issue24973] CFLAGS for Visual Studio

[Zachary Ware]

Zachary Ware added the comment:

The real driver for this is having a nice easy way to pass '/fp:strict' to 
icl.exe (ICC's cl.exe).  There may be other things that would be nice to be 
able to pass easily for customization.

--

___
Python tracker 

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

[issue24973] CFLAGS for Visual Studio

[Zachary Ware]

Changes by Zachary Ware :


--
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.6

___
Python tracker 

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

[issue24949] Identifier lookup in a multi-level package is flakey

[Bob Hossley]

Bob Hossley added the comment:

msg<249269>

Thank you David Murray.

I should have asked myself, what is reasonable behavior?  In the case of 
email.mime.nonmultipart an explicit import is clearly needed.

I was misled by my experience with the os library.  As a "package" it is very 
different from the email library.  Importing os also makes available all of 
what appear at the script syntax level to be all its "sub-packages."

2015-08-28 09:57:26 /home/bob06
$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print(os.path.split)


In the future I will try to remember that the effects of importing a "package" 
depend on how the "package" is packaged.

So far as I'm concerned this issue is closed.

I doubt that symptom "flakey Python behavior" is serious enough to interest 
Canonical.

--

___
Python tracker 

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

[issue24949] Identifier lookup in a multi-level package is flakey

[Bob Hossley]

Bob Hossley added the comment:

msg249272

Thank you Martin Panter for the documentation URL's.  The import machinery is 
so complicated that I have given up trying to understand what is "correct" 
behavior.Depending on the code in the relevant __init__.py and/or 
explicitly referenced Python modules each Python library can have vastly 
different import behavior.  I believe the simplest way to figure out what an 
import does and hence, what import statements I need is to run a Python 
interpreter in a terminal, execute an import statement, and then use the dir() 
function several times to see what the import statement did.

The import documentation is only slightly useful due to its great length and 
complexity.

--

___
Python tracker 

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

[issue24973] CFLAGS for Visual Studio

[Steve Dower]

Steve Dower added the comment:

I assume you're referring to #24974? The default (for MSVC) is /fp:precise, 
which should allow fenv_access, but maybe ICL uses /fp:fast by default for the 
extra speed?

It's not a safe 3.5 change now, but compiling with /fp:fast by default and 
using #pragma float_control(precise, push)/#pragma float_control(pop) around 
that section may be an option for 3.6, if the benchmarks show some value in it. 
Either way, the pragma is probably the better way to require particular 
behaviour for that section of code, rather than changing a global option.

I'm not totally opposed to allowing an extra option for setting flags when 
building, but there'll almost always be a better fix.

--

___
Python tracker 

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

[issue24974] ICC on Windows 8.1: _decimal fails to compile without /fp:strict

[Steve Dower]

Steve Dower added the comment:

It should be defaulting to precise mode, but maybe ICC has a different default?

I wrote on #24973:

It's not a safe 3.5 change now, but compiling with /fp:fast by default and 
using #pragma float_control(precise, push)/#pragma float_control(pop) around 
that section may be an option for 3.6, if the benchmarks show some value in it. 
Either way, the pragma is probably the better way to require particular 
behaviour for that section of code, rather than changing a global option.

--

___
Python tracker 

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

[issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

[Roberto Sánchez]

Roberto Sánchez added the comment:

I totally agree, on the other hand, if the detach() method can cause that some 
core methods like shutil.get_termina_size() raise an exception then I think 
that should be warned in the doc of detach().

In all places that I've seen, the detach() method is used to overwrite the 
stdout in py3, so a sort of advice about the using of detach() It'd save some 
problems.

--

___
Python tracker 

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

[issue23406] interning and list comprehension leads to unexpected behavior

[Matheus Vieira Portela]

Matheus Vieira Portela added the comment:

Does anyone else think the note should be expanded? For me, it seems to be 
pretty accurate although it may indeed be confusing to beginners.

If anything, I can work on rewriting it to be more explanatory.

--
nosy: +matheus.v.portela

___
Python tracker 

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

[issue18697] Unify arguments names in Unicode object C API documentation

[Matheus Vieira Portela]

Matheus Vieira Portela added the comment:

Just checking, it would be required to update Objects/unicodeobject.c, 
Include/unicodeobject.h, and Doc/c-api/unicode.rst, right?

As far as I saw, "unicode" means a Python object with unicode string, "u" is a 
UTF-8 encoded C string, "str" and "s" are encoded C strings (UTF-8, UTF-7, 
ASCII, Latin-1, among others). Is it alright to rename Python unicode objects 
to "unicode" and the others to simply "str"? These names are more meaningful 
than the single character alternatives.

The same logic would be applied to the other types, always keeping the longer 
name rather than the single character ones.

--
nosy: +matheus.v.portela

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Nathaniel Smith]

Nathaniel Smith added the comment:

Actually, I fail at grep, and actually there are already tons of good tests for 
__bases__ assignment in test_descr.py. So, patch attached, and analysis follows.


Background on __class__ assignment
--

While it's certainly surprising, assignment to obj.__class__ and to 
type.__bases__ has been an explicitly supported feature ever since the advent 
of new-style classes back in 2.ancient, and typeobject.c goes to great lengths 
to handle all the weird resulting cases (including stuff like "what if __del__ 
changes the __class__", "what if someone mutates __bases__ while we are in the 
middle of method lookup inside a metaclass's mro() method", etc.).

To make this safe, of course, we need to somehow check that after making the 
assignment then the resulting object will still be a valid, self-consistent 
Python object. The types in question need to have consistent in-memory 
representations, that their __dict__ slot (if present) is at the same offset, 
that their memory management callbacks are consistent (if we mutate an object 
from type A to type B, then A and B must be written in such a way that it's 
legal to pass an object allocated with A.tp_new to B.tp_dealloc), etc.

This compatibility checking occurs in two places: object_set_class and 
type_set_bases (and several utility functions that they share).

For historical reasons, there are two different C representations for type 
objects in Python: the original representation, which involves 
statically-allocated structs, and the newer representation, which involves 
heap-allocated structs. Aside from their allocation, there are a bunch of 
arcane little differences in things like reference counting, how you set them, 
etc., which are mostly motivated by the need to maintain compatibility with old 
code using the original representation -- all the places where they differ are 
places where the newer representation does something more sensible, it's not 
possible to create a statically-allocated type except by writing C code that 
*doesn't* use the stable ABI, etc. Otherwise they're supposed to work the same 
(eliminating differences between built-in and user-defined classes was the 
whole point of new-style classes!), but all these quirky implementation 
differences do leak out into little semantic differences in various places.

One of the places where they've historically leaked out is in __class__ and 
__bases__ assignment. When the compatibility-checking code for types was 
originally written, it punted on trying to handle the quirky differences 
between statically-allocated and heap-allocated type objects, and just declared 
that all statically-allocated types were incompatible with each other.


The previous patch
--

The patch that is causing all the debate here was reviewed in issue22986, after 
extensive discussion on python-dev, and the actual diff can be seen here:
https://hg.python.org/cpython/rev/c0d25de5919e/

It did two things:

1) It cleaned up a bunch of nasty stuff in the compatibility-checking and 
assignment code. This fixed some real bugs (e.g., a case where incompatible 
classes could be considered compatible based on the contents of random memory 
found by following bogus pointers), and in the process made it robust enough to 
handle all types, both statically-allocated and heap-allocated.

2) It removed the check in object_set_class that protected the downstream code 
from ever seeing statically-allocated types - that's the 'if' check here:
https://hg.python.org/cpython/rev/c0d25de5919e/#l3.97

As far as we know, this is all working exactly as designed! For example, 
Serhiy's int subclass at the beginning of the thread is compatible with the int 
class in the sense that the modified version of the '42' object is still a 
valid Python object, all its fields are valid, it won't crash the interpreter 
when deallocated, etc.

But of course what we didn't think of is that the interpreter assumes that 
instances of some particular built-in types are truly immutable, and the 
interpreter's internal invariants are violated if you can in any way modify an 
'int' object in place. Doh.


This new patch
--

So the attached patch modifies the original patch by leaving the cleanups in 
place, but puts back a guard in object_set_class that disallows __class__ 
assignment for statically-allocated types EXCEPT that it still allows it 
specifically in the case of ModuleType subclasses. It also adds a big comment 
explaining the purpose of the check, and adds tests to make sure that __class__ 
assignment is disallowed for builtin immutable types.

Analysis of the mergeability of this patch:

- We still believe that the actual compatibility checking code is strictly 
better than it used to be, so in any case where these parts of the changes 
affect Python's semantics, the new results should be better (i.e. less likely 
to break memory safety and 

[issue22555] Tracking issue for adjustments to binary/text boundary handling

[Nick Coghlan]

Nick Coghlan added the comment:

For historical purposes, also linking the change in issue #19977 to enable 
surrogateescape by default on stdin and stdout when the OS claims the locale 
encoding is ASCII.

--
dependencies: +Use "surrogateescape" error handler for sys.stdin and sys.stdout 
on UNIX for the C locale

___
Python tracker 

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

[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup

[Nick Coghlan]

Nick Coghlan added the comment:

I found this discussion again while looking for issue #19977 to reference from 
issue #24968.

"fixed" wasn't the right resolution, so I've moved it to "postponed" - the SSH 
locale forwarding problem highlighted again in #24968 means I think there's a 
discussion worth having about reading /etc/locale/conf when it's available, 
rather than always trusting the glibc locale settings.

--
resolution: fixed -> postponed

___
Python tracker 

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

[issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale

[Nick Coghlan]

Nick Coghlan added the comment:

Looking again at the *specific* bug report here, I'm moving the resolution to 
"out of date", as it's actually the one we addressed in 3.5 by enabling 
surrogateescape by default on all of the standard streams when the OS claims 
the locale encoding is ASCII, not just stderr: http://bugs.python.org/issue19977

That allows us to at least correctly roundtrip data, even if the OS has given 
has bad encoding settings.

The problem with forcing UTF-8 more generally when the OS claims ASCII is that 
it may be the wrong thing to do and result in data corruption, especially on 
systems using East Asian codecs. Querying /etc/locale.conf [1] instead of 
relying on the nominal glibc locale settings should reliably give us correct 
encoding/locale information on modern Linux systems in cases like this one, 
where SSH has forwarded mismatched locale settings from a client system to a 
server shell session.

Another issue with relevant background discussion is issue #23993, which 
speculated on extending the "default to surrogateescape" idea to all open() 
calls when glibc claims the locale encoding is ASCII.

[1] http://www.freedesktop.org/software/systemd/man/locale.conf.html

--
resolution: not a bug -> out of date

___
Python tracker 

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

[issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking

[David Beazley]

New submission from David Beazley:

The compile() function is not able to compile an AST created from code that 
uses some of the new unpacking generalizations in PEP 448.  Example:

code = ''' 
a = { 'x':1, 'y':2 }
b = { **a, 'z': 3 }
'''

# Works
ccode = compile(code, '', 'exec')

# Crashes
import ast
tree = ast.parse(code)
ccode = compile(tree, '', 'exec')

# --

Error Traceback:

Traceback (most recent call last):
  File "bug.py", line 11, in 
ccode = compile(tree, '', 'exec')
ValueError: None disallowed in expression list

Note:  This bug makes it impossible to try generalized unpacking examples 
interactively in IPython.

--
components: Library (Lib)
messages: 249442
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Python 3.5 can't compile AST involving PEP 448 unpacking
type: crash
versions: Python 3.5

___
Python tracker 

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

[issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

[R. David Murray]

R. David Murray added the comment:

"After the raw stream is detached, the buffer is in an unusable state" pretty 
much says everything that needs to be said, doesn't it?  It certainly seems 
like anything more does not belong in the detach docs.  A mention could 
possibly be added to the sys.stdin/etc docs, though.

--

___
Python tracker 

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

[issue23406] interning and list comprehension leads to unexpected behavior

[R. David Murray]

R. David Murray added the comment:

Interesting.  I usually start with a project's FAQ because I find they usually 
give me an overview of the project and an indication of its quality :)

The footnote looks very explanatory to me already (complete with examples).  
The 'confusing to beginners' text could be made a link to the FAQ, though.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale

[Roberto Sánchez]

New submission from Roberto Sánchez:

System: Python 3.4.2 on Linux Fedora 22

This issues is strongly related with: http://bugs.python.org/issue19846 But It 
isn't exactly the same case.

When I connect from my Mac OSX (using Terminal.app) to a Linux host with Fedora 
through ssh, the terminal session is forced to the OSX locale (default behavior 
in Terminal.app):

[rob@fedora22 ~]$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=

However the installed locales in Fedora are:

[rob@fedora22 ~]$ localectl list-locales
en_US
en_US.iso88591
en_US.iso885915
en_US.utf8   <-- This is the default one

And if a launch python3 I get:

[rob@fedora22 ~]$ python3
Python 3.4.2 (default, Jul  9 2015, 17:24:30) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, codecs, sys, locale
>>> locale.getpreferredencoding()
'ANSI_X3.4-1968'
>>> codecs.lookup(locale.getpreferredencoding()).name
'ascii'
>>> locale.getdefaultlocale()
('es_ES', 'UTF-8')
>>> sys.stdout.encoding
'ANSI_X3.4-1968'
>>> sys.getfilesystemencoding()
'ascii'
>>> print('España')
  File "", line 0

^
SyntaxError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal 
not in range(128)


So, If I'm understanding correctly, If the current locale is not supported by 
the system then python fallback to ascii.

I can understand this behavior when the supported locales and the current one 
has different encoding, but if both of them are 'utf-8' It sounds reasonable 
that locale.getpreferredencoding() is set to 'utf-8'.

This case is causing that programs with CLI (Command Line Interface) fails, if 
you are using a third party like click lib, a RuntimeException is thrown by the 
own lib, I learned it by the hard way, the python3 CLI programs need a valid 
encoding to deal with stdin/stdout, and in this case all systems seems 
correctly configured about the encoding, I mean, this is a real case, there is 
no manual locale config modification, IMHO the current behavior seems a bit 
strict.

--
components: Unicode
messages: 249390
nosy: ezio.melotti, haypo, rsc1975
priority: normal
severity: normal
status: open
title: Python 3 raises Unicode errors with the xxx.UTF-8 locale
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale

[STINNER Victor]

STINNER Victor added the comment:

It's not a bug on Python, but a bug on your system.

> New submission from Roberto Sánchez:
>     [rob@fedora22 ~]$ locale
>     locale: Cannot set LC_CTYPE to default locale: No such file or directory

This message means that the chosen locale doesn't exist.

>     LANG=es_ES.UTF-8
...
>     [rob@fedora22 ~]$ localectl list-locales
> 
>     en_US.utf8       <-- This is the default one

LANG must be en_US.utf8.

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 31.08.2015 10:44, Nathaniel Smith wrote:
> Before anyone panics about security issues, do keep in mind that the patch 
> you're talking about
reverting fixed a buffer overflow which I strongly suspect could be used to 
accomplish arbitrary
code execution.
> ... it lets you trigger assert checks that abort the interpreter, but AFAICT 
> it doesn't violate memory safety or allow arbitrary code execution.

I'm sure a buffer overflow can be fixed in other ways than allowing
42 to print out the Zen of Python when asked for a repr() ;-)

And if Serhiy can sneak in an os.system('rm -rf /') into a harmless
operation such as 42 + 2, I do believe we can call this arbitrary
code execution, even more so, since the patch only applies to a single
integer object which happens to be a singleton in CPython.

The point is: Python code will generally assume that it can trust
builtin types. It doesn't expect 42 + 2 to clear out the root dir,
just because some package installed from PyPI happens to feel in the
mood for Easter eggs :-)

--

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 31.08.2015 11:55, Antoine Pitrou wrote:
> 
> __class__ assignment can definitely be useful for monkey-patching, or other, 
> purposes.

The feature certainly has its place for user defined types (see the
unpickle example), but I don't think we should allow this for
static types.

--

___
Python tracker 

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

[issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +lemburg, loewis, ncoghlan, serhiy.storchaka

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I agree with Nathaniel, that this bug is not so critical to be release blocker. 
While it definitely should be fixed, it may wait for 3.5.1. Bug reproducing is 
not data driven, it needs executing special Python code, and when arbitrary 
Python code execution is available, there are a lot of other way to crash or 
compromise the interpreter. But I'm not sure that allowing __class__ assignment 
for larger domain of types is desirable. If we will desire that it is not, any 
enhancements to __class__ assignment should be withdrawn. May be __class__ 
assignment should be discouraged, deprecated and then disabled for all classes 
(in 3.6+), and other ways should be proposed to solve problems that are solved 
with __class__ assignment.

Nathaniel, can you provide a patch, that keeps the fix of a buffer overflow, 
but withdraws the ability to assign __class__ in cases that were disabled 
before?

--

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I agree with Mark. This feature opens up a security hole large enough to drive 
a train through.

Looking at the python-dev thread, the only motivation appears to be making 
module look more like classes. I'd suggest to propose a PEP for making changes 
to module objects rather than creating a backdoor which let's you implement 
those changes at the expense of putting the whole interpreter at risk.

IMO, .__class__ of static types should not be mutable. I can understand why 
heap types need this feature (to e.g. be able to copy objects without invoking 
any .__init__() methods of unknown objects as is needed for unpickle style 
operations), but for static types the set of supported objects is limited and 
the consequences of calling their constructor is known.

--
nosy: +lemburg

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Nathaniel Smith]

Nathaniel Smith added the comment:

I need to get to bed so I'll finish up tomorrow, but FYI I have a working patch 
-- I just want to add some __bases__ assignment test cases to make Larry happy. 
(Apparently there are no test cases for __bases__ assignment at all 
currently... :-(.)

Before anyone panics about security issues, do keep in mind that the patch 
you're talking about reverting fixed a buffer overflow which I strongly suspect 
could be used to accomplish arbitrary code execution. This is not a big deal, 
because all it does it let you turn the ability to execute arbitrary Python 
code into the ability to execute arbitrary machine code. If this were the JVM 
then this would be a big deal, but for CPython it isn't -- there are many 
"vulnerabilities" like this that are included in CPython by default as 
features, because CPython does not even attempt to provide a secure sandbox. 
The bug described in the current issue is bad, but security-wise AFAIK it's 
less bad than arbitrary code execution: it lets you mess with code in other 
subinterpreters (which is already possible through other means), and it lets 
you trigger assert checks that abort the interpreter, but AFAICT it doesn't 
violate memory safety or allow arbitrary code execution.

--

___
Python tracker 

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

[issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback

[Roberto Sánchez]

Roberto Sánchez added the comment:

I've added a new issue: http://bugs.python.org/issue24968 that is related with 
this one, because is the root cause to modify the stdin/stdout streams.

--

___
Python tracker 

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

[issue22798] time.mktime doesn't update time.tzname

[Akira Li]

Akira Li added the comment:

> C mktime itself should not change timezone globals, but it may indirectly if 
> it calls tzset() and TZ changed between calls.

You should have run the attached test_mktime_changes_tzname.c which 
demonstrates that (at least on some systems) C mktime *does* change tzname 
global even if TZ envvar is constant in the test.

Nowhere in my bug report I had mentioned different TZ values. I did mentioned 
*past* *future* dates -- the same timezone may have different utc offset, 
timezone abbreviations at different times. These timezone globals can change 
even if TZ is constant.

--
status: pending -> open

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Antoine Pitrou]

Antoine Pitrou added the comment:

__class__ assignment can definitely be useful for monkey-patching, or other, 
purposes.

--

___
Python tracker 

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

[issue24967] add errors='ignore' to print kwargs

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

print() doesn't encode characters. It just writes string representation of 
arguments to output text file (sys.stdout by default). It is the output file is 
responsible for encoding (or is not, if it saves or passes further a text 
directly, as StringIO).

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue24967] add errors='ignore' to print kwargs

[Lukáš Němec]

New submission from Lukáš Němec:

Please add errors='...' to print's kwargs and pass it to codecs that are called 
from print. Sometimes you have undecodable/unencodable characters that you want 
to remove from the printed text.

Now you need to call 'mytext'.encode('enc', errors='replace').decode('enc') to 
achieve the same result. This would be just a shortcut.

Thank you :)

--
messages: 249389
nosy: Lukáš.Němec
priority: normal
severity: normal
status: open
title: add errors='ignore' to print kwargs
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model

[Zachary Ware]

Changes by Zachary Ware :


--
nosy: +christopher.hogan
title: ICC on Windows 8.1: _decimal fails to compile without /fp:strict -> ICC 
on Windows 8.1: _decimal fails to compile with default fp model

___
Python tracker 

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

[issue23406] interning and list comprehension leads to unexpected behavior

[Steven D'Aprano]

Steven D'Aprano added the comment:

Which note are you referring to? There are at least two mentioned in 
this thread, the FAQ and a footnote in the docs for stdtypes.

If you're referring to the table of operations just below these:

https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange

https://docs.python.org/3/library/stdtypes.html#common-sequence-operations

where the docs say:

s * n, n * sn shallow copies of s concatenated

I think that could be worded better. It is too easy to misread it 
as saying that the items of s are copied (as I just did now, despite 
knowing that they aren't). I would word it:

repeat s n times and concatenate

which matches the common name of * as the sequence repetition operator, 
and avoids using the word prone to misinterpretation, "copy".

Given how error-prone sequence repetition is, I'd add an example 
directly in the table:

for example, [x]*3 returns [x, x, x] (note that x is not copied).

--

___
Python tracker 

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

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.6

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Nathaniel Smith]

Nathaniel Smith added the comment:

Mark Shannon wrote:
> So, just make sure that you insert the new object into sys.modules *before* 
> doing any imports or calls to code that could import your module and it will 
> all work fine.

The problem with doing this is that you're now stuck managing two diverging 
namespaces: the one associated with your new object that other modules can see, 
and the one where your __init__.py code is doing all those imports and calls. 
So if you want this to work then you have to totally rewrite your package's 
startup sequence, OR you have to insert some code like
  sys.modules[__name__].__dict__.update(orig_module.__dict__)
after *every line* of your __init__.py, OR you have to do some really 
complicated global analysis of every module inside your package to figure out 
exactly what the state of these two namespaces is at each possible point during 
the startup sequence and prove that the divergences don't matter...

The key feature of the metamodule approach is that 
sys.modules["modname"].__dict__ is always the same object as your __init__.py 
globals(), so there's no change of divergence and it can guarantee that merely 
enabling metamodule for an existing package will always be safe and have no 
behavioural effect (until you start using the new metamodule features). This 
guarantee is hugely important given that the first user will probably be numpy, 
which is a giant crufty package with millions of users.

I promise, we went over all of this on python-dev last year :-)


Mark Lemburg wrote:
> Python code will generally assume that it can trust
> builtin types. It doesn't expect 42 + 2 to clear out the root dir,
> just because some package installed from PyPI happens to feel in the
> mood for Easter eggs :-)

The only reason that'd be possible though is because you went and ran some 
untrusted code with permissions allowing it to clear out the root dir -- the 
only way to set up this "exploit" is to run untrusted Python code. Basically 
you've handed someone a gun, and now you're worried because this patch gives 
them a new and particularly rube-goldbergian method for pulling the trigger...

Except it isn't even a new method; your nasty PyPI package can trivially 
implement this "easter egg" using only fully-supported features from the 
stdlib, in any version of Python since 2.5. Here's some nice portable code to 
do __class__ assignment while dodging *all* the checks in object_set_class:

  from ctypes import *
  def set_class(obj, new_class):
  ob_type_offset = object.__basicsize__ - sizeof(c_void_p)
  c_void_p.from_address(id(obj) + ob_type_offset).value = id(new_class)

I mean, obviously ctypes is nasty and breaks the rules, I'm not saying this 
justifies making __class__ assignment broken as well. But this bug is no more a 
*security* problem than the existence of ctypes is.

Larry Hasting wrote:
> Consider for a moment Google App Engine. If GAE updated to 3.5 with this bug, 
> users would now have the ability to inject code into other people's programs, 
> because interned ints (and a couple other types) are shared across 
> interpreters.

Okay, fair enough :-). On GAE this *would* be a security bug because GAE I 
guess runs an extensively modified and audited fork of Python that implements a 
full sandbox. I assume this is also why it took them ~2 years to upgrade to 
2.7, and why they're shipping 3 year old versions of all their libraries, and 
why they're now starting to move people to a new setup using OS-level 
sandboxing instead of interpreter-level sandboxing...

Python.org doesn't provide any sandbox guarantees, and this bug is a tiny drop 
in the bucket compared to what anyone will need to do to add a trustworthy 
sandbox to CPython 3.5, so for me I still wouldn't call this release critical. 
But you're the RM, so here's a patch if you want it :-).

Serhiy Storchaka wrote;
> I'm not sure that allowing __class__ assignment for larger domain of types is 
> desirable. If we will desire that it is not, any enhancements to __class__ 
> assignment should be withdrawn. May be __class__ assignment should be 
> discouraged, deprecated and then disabled for all classes (in 3.6+), and 
> other ways should be proposed to solve problems that are solved with 
> __class__ assignment.

I don't necessarily object to the idea of eventually removing __class__ 
assignment in some future version of Python. It kind of freaks me out too. 
(Though Guido seems to like it.)

I really, really, REALLY object to the idea of -- at this point in the release 
cycle! -- rejecting a new feature that has gone through review on python-dev, 
that solves a real problem that's impacting a bunch of people (see all the 
replies on the numpy-discussion thread linked above of people saying "oh ugh 
yes this has totally bitten me! please fix it!"), and to do this on the grounds 
that someone *might* later make an argument for it be removed again in 3.7 and 
that python-dev might 

[issue24969] functools.lru_cache: a way to set decorator arguments at runtime

[Raymond Hettinger]

Raymond Hettinger added the comment:

> The problem is I can't know the optimal values for 'maxsize',
> I need to set them at runtime. 

The easiest way to go is to wait to start caching until you know the cache size 
you want:
   
   def foo(a, b, c):
pass

   size = get_user_request()
   foo = lru_cache(foo, maxsize=size)

If there is a subsequent need to change the cache size, just rewrap it:

   size = get_user_request()
   original_function = foo.__wrapped__
   foo = lru_cache(foo, maxsize=size)

--
priority: normal -> low

___
Python tracker 

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

[issue23406] interning and list comprehension leads to unexpected behavior

[Matheus Vieira Portela]

Matheus Vieira Portela added the comment:

I was referring to the table of operations.

So, what if I replace "n shallow copies of s concatenated" by "repeat s n times 
and concatenate (to create a multidimensional list, refer to [link to FAQ])"?

--

___
Python tracker 

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

[issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking

[Nick Coghlan]

Nick Coghlan added the comment:

Patch looks good to me. I was initially going to query the changes to the 
break/continue AST tests, but then realised they were needed to avoid a compile 
error for break/continue outside a loop now that we ensure the resulting AST 
can be used to generate code.

--

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What if just add settable __class__ property in ModuleType?

--

___
Python tracker 

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

[issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking

[Larry Hastings]

Larry Hastings added the comment:

Good catch!  Please file a pull request via bitbucket.

--

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The first time this bug was discovered in issue23726.

--

___
Python tracker 

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

[issue24973] CFLAGS for Visual Studio

[Zachary Ware]

Zachary Ware added the comment:

Steve Dower wrote:
> I assume you're referring to #24974?

It's somewhat related, yes, but I didn't intend for the two issues to be 
tightly coupled.  Both should be dealt with independently of each other.

> The default (for MSVC) is /fp:precise, which should allow
> fenv_access, but maybe ICL uses /fp:fast by default for the extra
> speed?

I believe that's correct.

> I'm not totally opposed to allowing an extra option for setting flags
> when building, but there'll almost always be a better fix.

That's probably true.  I will say though that it's really hard to pass build 
options to a buildbot.  I have yet to find a way to pass properties with no 
spaces in the value, for example, "/p:IncludeSSL=false" (if you know of a way 
to pass that to MSBuild correctly through Tools/buildbot/build.bat called by 
2.7's subprocess module, I'm all ears :)).  To continue the floating point 
example, the only method (other than this) I've found to pass in a different 
model is to hack in another property to check and set FloatingPointModel in the 
ClCompile ItemDefinitionGroup, which has the same problem as the 'IncludeSSL' 
issue I mentioned above.  With a nice simple 'CFLAGS' property that doesn't 
care about extra spaces in the value, it becomes possible to pass '/fp:strict' 
to a buildbot easily.

Also, ICC has *a lot* of extra command line options that may be interesting to 
pass in, but I'm quite sure we don't want to hack any of them into the project 
files.

By the way, '/fp:strict' is just what we've been manually defaulting to for ICC 
builds since before issue21167 was committed, which made '/fp:strict' 
unnecessary.

--

___
Python tracker 

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

[issue24829] Use interactive input even if stdout is redirected

[Raymond Hettinger]

Raymond Hettinger added the comment:

I recommend this feature request be rejected.  The current behavior has been in 
place for a long time.  Changing it may cause more harm than good (especially 
if the behavior between operating systems becomes more divergent).

--
nosy: +rhettinger

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +eltoder

___
Python tracker 

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

[issue22798] time.mktime doesn't update time.tzname

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> You should have run the attached test_mktime_changes_tzname.c ...

I did run it and tried several times to understand what it does.  It did not 
help.

If you claim that calling mktime() changes the value of the global tzname 
variable, you should be able to demonstrate it in five lines of code:

extern char **tzname;
tzset();
printf("%s %s\n", tzname[0], tzname[1]);
mktime();
printf("%s %s\n", tzname[0], tzname[1]);

(plus a few lines to initialize tt)


If the code above prints two different lines - file a bug report with your C 
library vendor.

--

___
Python tracker 

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

[issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale

[Roberto Sánchez]

Roberto Sánchez added the comment:

OK, I already knew that "It is not a bug", but the scenario seems quite common, 
connection to a Linux host from a Mac with Terminal.app and different locales 
(default behavior), so a bit of "magic" when the locale's encoding part is 
correct would help to deal with some Unicode issues in python3 scripts.

I just say that It would be a desirable enhancement, but I have no idea how to 
complex can be to change the current behavior, maybe It isn't worth the effort.

--

___
Python tracker 

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

[issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale

[Nick Coghlan]

Nick Coghlan added the comment:

CPython inherits this behaviour from glibc's locale handling, so it's 
potentially worth raising the question further upstream. If anyone wanted to 
pursue that, looking at http://www.gnu.org/software/libc/development.html 
suggests to me that the appropriate starting point would be to email 
libc-h...@sourceware.org and ask for advice.

--

___
Python tracker 

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

[issue22798] time.mktime doesn't update time.tzname

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +pitrou

___
Python tracker 

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