[issue24981] Add a test which uses the ast module to compile the stdlib

[Raymond Hettinger]

Raymond Hettinger added the comment:

+1 This is a great idea.

--
nosy: +rhettinger

___
Python tracker 

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

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

[Larry Hastings]

Larry Hastings added the comment:

> too late for 3.5.0

How's that?

--

___
Python tracker 

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

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

[Martin Panter]

Martin Panter added the comment:

A test case with data like this would make more sense to me:

# Response without HTTP status line or header, modelling responses sent by
# some proxies that do not support CONNECT
body = b"400 Bad Request"

--

___
Python tracker 

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

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

[Martin Panter]

Martin Panter added the comment:

Left some review comments. But I don’t completely understand the test case. Is 
it true there are proxies that do not send a HTTP status line (like HTTP/1.0 
200 Connection Established), but do sned the rest of the HTTP header section? 
This is what the test case seems to be modelling:

Client to proxy request:
b"CONNECT foo:80 HTTP/1.0\r\n"
b"\r\n"

Proxy (plus tunnelled?) response, minus a status line:
b"X-Foo: bar\r\n"
b"\r\n"
b"hello world"

It seems more likely that the proxies related to this bug are misbehaving, or 
there is some other network problem. Of the proxies mentioned in this report 
that are accessible to me, both of them do not appear to accept CONNECT 
requests at all. As soon as the first CONNECT line is send, a HTML blob saying 
“400 Bad Request” is received, without any HTTP header at all.

--
nosy: +martin.panter

___
Python tracker 

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

[issue24982] shutil.make_archive doesn't archive empty directories

[Eugene Kolo]

New submission from Eugene Kolo:

Zip file is sometimes known to only contain files and the paths to them, but it 
can also have have empty folders, they are zero length files with a flag set.

make_archive just ignores empty directories, I propose that there should either 
be a flag, or it should include empty directories by default.

--
components: Library (Lib)
messages: 249522
nosy: eugenek
priority: normal
severity: normal
status: open
title: shutil.make_archive doesn't archive empty directories
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

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

[STINNER Victor]

STINNER Victor added the comment:

Ok, I fixed the issue in Python 3.6. Example with the initial message:

$ python2.7 -c 'import datetime; 
print(datetime.datetime.utcfromtimestamp(1424817268.274).microsecond); 
print(datetime.datetime.utcfromtimestamp(-1424817268.274).microsecond)'
274000
726000

$ python3.6 -c 'import datetime; 
print(datetime.datetime.utcfromtimestamp(1424817268.274).microsecond); 
print(datetime.datetime.utcfromtimestamp(-1424817268.274).microsecond)'
274000
726000

I wrote:
"On Python < 3.3, datetime.datetime.fromtimestamp(float) doesn't use exactly 
ROUND_HALF_EVEN, but it looks more to "round half away from zero" (the decimal 
module doesn't seem to support this exact rounding method)."

I was wrong: it's decimal.ROUND_HALF_UP in fact.

I will backport the change to Python 3.4 and 3.5. Since this issue was defined 
as a bugfix, it should be fixed in Python 3.5.1 (too late for 3.5.0).

--

___
Python tracker 

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

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

[Roundup Robot]

Roundup Robot added the comment:

New changeset b690bf218702 by Victor Stinner in branch 'default':
Issue #23517: datetime.datetime.fromtimestamp() and
https://hg.python.org/cpython/rev/b690bf218702

--

___
Python tracker 

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

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

[Roundup Robot]

Roundup Robot added the comment:

New changeset abeb625b20c2 by Victor Stinner in branch 'default':
Issue #23517: Add "half up" rounding mode to the _PyTime API
https://hg.python.org/cpython/rev/abeb625b20c2

--
nosy: +python-dev

___
Python tracker 

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

[issue24929] _strptime.TimeRE should not enforce range in regex

[Steve Yeung]

Steve Yeung added the comment:

I'm not sure what format I'm supposed to provide the test in. I attached a file 
that has the diff of the changes I made, and how the error message is changed 
(and improved!) in both datetime and time.

--
Added file: http://bugs.python.org/file40319/file

___
Python tracker 

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

[issue24981] Add a test which uses the ast module to compile the stdlib

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +yselivanov

___
Python tracker 

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

[issue24981] Add a test which uses the ast module to compile the stdlib

[Brett Cannon]

New submission from Brett Cannon:

Issue #24975 shows that we can easily end up with holes in support from the ast 
module. We should probably make sure we have a test that goes through the 
entire stdlib, Does an ast.parse(), and then passes the result to compile() to 
verify no exceptions are raised. We should either avoid the test/ directory or 
blacklist specific files which will fail because they are designed to be 
syntactically incorrect. The test can also be behind a -u flag if it turns out 
to be an expensive test.

--
components: Tests
messages: 249516
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add a test which uses the ast module to compile the stdlib
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

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

[Brett Cannon]

Brett Cannon added the comment:

Created issue #24981 to track the test case idea.

--

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

Larry,

I created a PR for you: 
https://bitbucket.org/larry/cpython350/pull-requests/10/issue-24975-fix-ast-compilation-for-pep/diff

Brett,

Should we do that in a separate issue targeting 3.6 only?

--

___
Python tracker 

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

[issue24891] race condition in initstdio() (python aborts running under nohup)

[Yi Ding]

Yi Ding added the comment:

I'm not sure this is a race condition. There's a crash every single time python 
is started when running the test.sh script under nohup.

If it's a race condition, it should only happen some of the time, not every 
single time.

Can you reeevaluate the priority?

--

___
Python tracker 

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

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

[Garfield222]

Garfield222 added the comment:

This error occurs when using youtube-dl 
Complete log is here:
https://github.com/rg3/youtube-dl/issues/6727

--

___
Python tracker 

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

[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper

[Garfield222]

Garfield222 added the comment:

Same error happens if http_proxy="223.19.230.181:80" variable is set.

--
nosy: +Garfield222

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

Pull request version of patch is here:

https://bitbucket.org/larry/cpython350/pull-requests/9/fix-issue-24912-disallow-reassigning-the/diff

(identical to issue24912-v2.patch except for the addition of a NEWS entry)

--

___
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

[Guido van Rossum]

Guido van Rossum added the comment:

OK, then I think it's between you and Serhiy.

--

___
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 do understand your predicament. Can you live with just a special case for 
> modules? __class__ assignment is full of non-portable special cases already.

Not only can I live with it, but -- unless I misunderstand your meaning -- this 
is exactly the approach that I am advocating and have submitted a patch to 
implement :-).

--

___
Python tracker 

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

[issue7175] Define a standard location and API for configuration files

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Sep 01, 2015, at 07:15 PM, Glyph Lefkowitz wrote:

>There are other advantages to following the XDG spec.  If we follow it
>correctly (and not, like Barry suggested, start adding random other
>directories like ~/.python)

I was really just suggesting reading from other locations for backward
compatibility.

--

___
Python tracker 

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

[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'

[Joshua Harlow]

Joshua Harlow added the comment:

Initial possible patch.

--
keywords: +patch
type: enhancement -> 
Added file: http://bugs.python.org/file40318/add_future_callback.patch

___
Python tracker 

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

[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'

[Eric Fried]

Changes by Eric Fried :


--
nosy: +2uasimojo

___
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

[Guido van Rossum]

Guido van Rossum added the comment:

PS. I have very little time this week or next to review everything -- if we 
don't find a reasonable compromise it *will* be rolled back.

--

___
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

[Guido van Rossum]

Guido van Rossum added the comment:

I don't think I told you to do it this way -- that message of mind sounded 
pretty noncommittal in all directions.

I do understand your predicament. Can you live with just a special case for 
modules? __class__ assignment is full of non-portable special cases already.

Given how close we are to the release we should tread with a lot of care here 
-- rolling back a diff is also a big liability.

Maybe the "right" solution is to allow __dict__ assignment for modules. But 
we're too close to the release to add that. Perhaps we can revisit the right 
way to do it for 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

[Mark Shannon]

Mark Shannon added the comment:

I think Nathaniel and Eugene argument that you cannot replace the module in 
sys.modules safely in erroneous.

Immediately after the module is created by importlib it is inserted into 
sys.modules. The code object for the module is then executed.
At that point, when the module code starts executing, no code outside the 
module has executed since the module was created and the import lock is held so 
no other thread will be able to import the module.
Therefore the only code that can see the module object is the module's own code.

Given a custom subclass of module that overrides __getattr__ to fetch values 
from the original module's __dict__, then an instance of that class can be 
inserted into sys.modules before any imports or calls to code that would access 
sys.modules, and the substitution of the module can be done safely.

--

___
Python tracker 

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

[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'

[Joshua Harlow]

Changes by Joshua Harlow :


--
components: +Library (Lib)

___
Python tracker 

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

[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'

[Joshua Harlow]

Changes by Joshua Harlow :


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

[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'

[Joshua Harlow]

Changes by Joshua Harlow :


--
type:  -> enhancement

___
Python tracker 

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

[issue7175] Define a standard location and API for configuration files

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

XDG_CONFIG_HOME is not generally set to anything; the default of ~/.config is 
usually fine. However, the point is that you _can_ set it to point at a 
different location.  The relevant specification is here:

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

The biggest reason I strongly believe we should follow a specification is that 
Python is not the only software on the system.  If I am an ops person that has 
to deal with Python and Ruby and Java and C software all the time, *any* 
consistency is a big help.  We don't have to follow *this* specification, but 
we should follow *some* specification (although this specific one looks like a 
good one to me).  The Python community has no special expertise deciding on 
locations for configuration files, and so we should not be trying to invent a 
new and better place for them.

There are other advantages to following the XDG spec.  If we follow it 
correctly (and not, like Barry suggested, start adding random other directories 
like ~/.python), users can easily switch between configuration environments by 
switching the XDG environment variables (both XDG_CONFIG_DIRS and 
XDG_CONFIG_HOME), which would be a handy way of ignoring both user-specified 
config files _and_ system-specified ones, to get a pristine virtualenv-like 
separation between different config files.

Given that they are going to need to set these env vars anyway to redirect 
spec-compliant libraries that their application may be using, it would be nice 
to just have _one_ set of meta-configuration variables rather than one for 
Python and one for C and one for Ruby and so on.  Consider the fact that 
distutils respects "CFLAGS", and did not feel the need to invent 
"DISTUTILS_FLAGS_FOR_THE_C_COMPILER".

--

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

Guido van Rossum wrote:
> But first, why is it so important to assign the __class__ of a module?  It 
> seems somebody is trying to make modules into what they weren't meant to be.

Because you told me to do it this way on python-dev :-(

https://mail.python.org/pipermail/python-dev/2014-December/137430.html

The goal is to make it possible for projects (e.g. numpy) to safely issue a 
deprecation warning when people access certain module-level constants.

The reason this is difficult is that we have several almost-conflicting 
requirements:

1) we want to be able to override special methods like __getattr__ and __dir__ 
on modules. And it'd nice if we could have access to things like properties and 
__repr__ too.

2) we can't control the type used to originally construct the module, because 
the module object is constructed before the first line of our code is run.

3) we want sys.modules[our_module].__dict__ to always refer to the namespace 
where __init__.py is executing, for reasons described at the top of msg249446. 
This is not currently possible when replacing the module object in-place -- if 
you make a new module object, then now you have the old module's namespace and 
the new module's namespace, and are responsible for manually keeping them in 
sync. (This is not a case where "let's do more of those" applies ;-).)

Other solutions that were previously considered (in two threads on python-dev 
and python-ideas with 40+ messages each) include:

- tackling (1) directly by defining a new set of special-purpose hooks just for 
modules (e.g. make ModuleType.__getattr__ check for a special 
__module_getattr__ function in the module namespace and call it). This is what 
Marc-Andre is suggesting now (msg249473). OTOH it would be nice to re-use the 
existing class mechanism instead of reimplementing parts of it just for modules.

- tackling (2) directly via wacky stuff like preparsing the file to check for 
special markers that tell the import machinery what ModuleType subclass to 
instantiate before the module starts executing (similar to how __future__ 
imports work)

- tackling (3) by adding some new special machinery to module objects, like the 
ability to replace their __dict__ attribute. This is what Eugene Toder is 
suggesting now (msg249483).

The advantage of allowing __class__ assignment on ModuleType instances is that 
it solves all these problems by using an existing feature rather than adding 
any new ones.

(I also tried the strategy of switching ModuleType to just *be* a heap type and 
avoid all these issues, but unfortunately it turns out that this would have 
broken the stable ABI so I gave up on that.)

The diff from 3.4 to 3.5rc2+the attached patch consists of uncontroversial bug 
fixes, plus two lines of code in typeobject.c that cause module subtypes to be 
treated similarly to heap types with respect to __class__ assignment:

-if (!(newto->tp_flags & Py_TPFLAGS_HEAPTYPE) ||
-!(oldto->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
+if (!(PyType_IsSubtype(newto, &PyModule_Type) &&
+  PyType_IsSubtype(oldto, &PyModule_Type)) &&
+(!(newto->tp_flags & Py_TPFLAGS_HEAPTYPE) ||
+ !(oldto->tp_flags & Py_TPFLAGS_HEAPTYPE))) {

These two lines of code solve an important user-facing issue for numpy, and are 
far simpler than any of the other proposed solutions. This approach was 
reviewed by python-dev, and has stood through the entire pre-release cycle so 
far without anyone producing a single argument yet for why it will cause any 
problem whatsoever.

I'm very sorry for introducing the bug with immutable types, and for not 
initially addressing it with the seriousness that it deserved. But that bug is 
fixed now, and unless someone can name an actual problem with the above two 
lines then I don't see why their association with a now-fixed bug is any reason 
to go rehash the entire discussion from scratch.

--

___
Python tracker 

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

[issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor'

[Joshua Harlow]

New submission from Joshua Harlow:

In situations where thread-local variables need to be setup it is quite useful 
to be able to hook into the thread creation process, so that as each new thread 
is spun up by the ThreadPoolExecutor that the threads created initially call 
into a provided callback (the callback can then setup thread local state as 
needed).

--
messages: 249501
nosy: harlowja
priority: normal
severity: normal
status: open
title: Allow for providing 'on_new_thread' callback to 
'concurrent.futures.ThreadPoolExecutor'

___
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

[Guido van Rossum]

Guido van Rossum added the comment:

If we don't reach an agreement we should fall back to Serhiy's (1) only.

Eugene: Without more motivation that sounds like very questionable 
functionality to want to add to modules. I don't have time to read the 
discussion that led up to this, but modules are *intentionally* dumb. We 
already have classes and instances.

--

___
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

[Eugene Toder]

Eugene Toder added the comment:

Guido: IIUC the general intention is to support @property and __getattr__ style 
hooks on the module level. Assigning to sys.modules[name] from the module 
itself is a bit too late -- there's already a global dict for this module, and 
no way to create a module from an existing dict, so you end up with two global 
namespaces which is annoying (but admittedly people live with that). One way 
around that is to set up import hooks, but this is also annoying, and leaks 
module implementation outside of its code.

--

___
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

[Brett Cannon]

Brett Cannon added the comment:

Do we not have a test that compiles the entire stdlib using the ast module? We 
used to have one for the old compiler package. If don't have such a test we 
should probably add it even if it requires a -u option.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue24978] Contributing to Python 2x and 3x Documentation. Translation to Russian.

[Georg Brandl]

Georg Brandl added the comment:

Someone will have to step up to manage this effort. The technical side is 
pretty much solved with sphinx-i18n.

I think this is something the PSF should sponsor. (I wrote a proposal to the 
board a while ago, but I couldn't find a candidate to do it.)

--
nosy: +georg.brandl

___
Python tracker 

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

[issue24978] Contributing to Python 2x and 3x Documentation. Translation to Russian.

[Brett Cannon]

Brett Cannon added the comment:

Is it time we start managing translations somehow? Or at least have a link off 
of docs.python.org to various translations so they are easier to discover?

--
nosy: +brett.cannon

___
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 c0d25de5919e changeset consists of three parts:

1) Fixes a bug (disallow an assignment of incompatible __class__ that happens 
to have the same __basesize__).
2) Allows __class__ assignment for module type.
3) Allows __class__ assignment for other types, in particular non-heap builtin 
types.

I think we should keep (1) and disallow (3). (2) is questionable and I for 
disallowing it too (special cases aren't special enough to break the rules). It 
is too little time left to 3.5 release, we will have more time to discuss this 
for 3.6.

Nataniel's new patch without special casing ModuleType would be good to me.

--

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

I would still rather wait until Django 1.9.0 is officially released else we are 
benchmarking alpha code which doesn't seem worth it. With Python 3.6.0 not due 
out until about 15 months after 1.9.0 comes out I think going 3 months without 
a Django benchmark for 3.6 is acceptable.

--

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

Changes by Brett Cannon :


--
assignee:  -> brett.cannon

___
Python tracker 

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

[issue7175] Define a standard location and API for configuration files

[Antoine Pitrou]

Antoine Pitrou added the comment:

If this is about existing config files, then we should make sure we don't break 
existing installations. Also, multiple possible locations in the home dir are 
confusing.

If this is about new config files, then ~/.config/python/XXX is probably ok.

I'm not sure what XDG_CONFIG_HOME is but $XDG_CONFIG_HOME doesn't seem defined 
under my shell (Xubuntu 15.04).

--
assignee: eric.araujo -> 
versions: +Python 3.6 -Python 3.3

___
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

[Stefan Krah]

Stefan Krah added the comment:

If "#pragma float_control(precise, push)" is exactly the MSVC default
then I'm fine with putting it on top of FENV_ACCESS.

There's nothing speed sensitive going on here: In the 32-bit build
the x87 FPU is used for modular multiplication of integers and needs
the control word set to 80-bit prec + ROUND_CHOP.

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +yselivanov

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

All environment variables are promoted to MSBuild properties, so if you "set 
IncludeSSL=false" before building then it will show up (which is exactly how 
the proposed patch is getting CFLAGS in).

Unfortunately, batch file argument parsing is pretty horrid. I'd be happy to 
move to PowerShell based scripts, but that'll be asking a lot of some people, 
and probably isn't feasible for the existing buildbots.

Another concern about using CFLAGS is people ending up with broken builds 
because they had something else set in there - mostly because it's near 
impossible to diagnose remotely.

If we call it PY_CFLAGS< move it to pyproject.props, and require 
"$(BuildForRelease) != 'true'", then I'm fine with it. (The last condition 
ensures that official release builds via Tools\msi\buildrelease.bat will never 
be affected, and gives a fairly strong indication not to rely on implicit 
settings like this. Defaults that we need for actual releases should be 
integrated properly.)

--

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

Zachary Ware added the comment:

Steve Dower added the comment:
> fenv_access is not available when compiling with /fp:fast, which is 
> apparently ICC's default.
>
> The proposed workaround here changes that default to /fp:strict, which is a 
> very different model, for all of CPython. I proposed using #pragma 
> float_control to force /fp:strict locally and enable fenv_access, rather than 
> changing the entire build to use /fp:strict (even though fenv_access is not 
> enabled everywhere by default).

Note that I'm not suggesting changing the default for everything to
/fp:strict.  The goal of the project building Python with ICC on
Windows is to change nothing for an MSVC build.  The default floating
point model should not change without a good reason, and this is not
it :)

I'll experiment with your suggestions, Steve and Stefan, discuss it
with Intel, and get back to you here.

--

___
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

[STINNER Victor]

STINNER Victor added the comment:

Sorry, I don't have time to read the whole discussion. Since we are *very* 
close to 3.5 final, I agree with Mark:

"Please revert c0d25de5919e. Breaking the interpreter in order to facilitate 
some obscure use case is unacceptable."

We can reintroduce the feature in Python 3.6 with a longer discussion how to 
implement it, or ensure that we really want it.

--
nosy: +haypo

___
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

[Steve Dower]

Steve Dower added the comment:

fenv_access is not available when compiling with /fp:fast, which is apparently 
ICC's default.

The proposed workaround here changes that default to /fp:strict, which is a 
very different model, for all of CPython. I proposed using #pragma 
float_control to force /fp:strict locally and enable fenv_access, rather than 
changing the entire build to use /fp:strict (even though fenv_access is not 
enabled everywhere by default).

--

___
Python tracker 

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

[issue7175] Define a standard location and API for configuration files

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I'm of mixed opinion.  I personally don't like cluttering up my $HOME with a
jillion dotfiles so I appreciate the organization XDG_CONFIG_HOME offers.  But
that also makes things less discoverable.  Looking in XDG_CONFIG_HOME first
with a fallback to $HOME seems like a workable compromise.

--

___
Python tracker 

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

[issue7175] Define a standard location and API for configuration files

[R. David Murray]

R. David Murray added the comment:

That standard is just wrong, dotfiles belong in $HOME :)  I'm only half joking, 
having grown up with Unix and having had the experience of flailing around for 
a while before I figured out a particular program's rc file was in .config 
instead of where I expected it to be, but I *am* half joking, because putting 
them all in .config is convenient. But most programs don't, so also looking in 
~ makes sense to me.

--

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

I agree that the table entry could be made more precise.  I would suggest 
replacing the table entry with "equivalent to adding s to itself n times".  
This formulation serves to explain *why* the multiply operation works the way 
it does:

>>> a = [1, []]
>>> b = a * 4
>>> c = a + a + a + a
>>> b
[1, [], 1, [], 1, [], 1, []]
>>> c
[1, [], 1, [], 1, [], 1, []]
>>> a.append(2)
>>> a
[1, [], 2]
>>> b
[1, [], 1, [], 1, [], 1, []]
>>> c
[1, [], 1, [], 1, [], 1, []]
>>> a[1].append(3)
>>> a
[1, [3], 2]
>>> b
[1, [3], 1, [3], 1, [3], 1, [3]]
>>> c
[1, [3], 1, [3], 1, [3], 1, [3]]

I don't think it is appropriate to put an example in the table; IMO that 
belongs in the footnote where it currently is.  You could hyperlink the table 
entry to the FAQ entry, though.

--

___
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

[Guido van Rossum]

Guido van Rossum added the comment:

I don't want to own this, but this is absolutely a release blocker. I see three 
ways out:

- Fix it right (if possible) -- "system immutable" types such as int should not 
allow __class__ assignment. Risk: there might be other cases (the code being 
patched is clearly too complex for humans to comprehend).

- Roll back the patch; I'm unclear on why Nathaniel would be so heartbroken if 
he couldn't assign the __class__ of a module (since there are other approaches 
such as assignment to sys.module[__name__].

- Roll back the patch but replace it with a narrower patch that specifically 
allows __class__ assignment for modules (but not for other types).

But first, why is it so important to assign the __class__ of a module?  It 
seems somebody is trying to make modules into what they weren't meant to be.

--
assignee: Guido.van.Rossum -> 
nosy: +gvanrossum

___
Python tracker 

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

[issue24912] The type of cached objects is mutable

[Eugene Toder]

Eugene Toder added the comment:

Nathaniel, what if we allow creating module objects from an existing dict 
instead of always creating a new one. Does this solve your namespace diversion 
problem?

FWIW, when I discovered this change I was quite surprised this came through 
without a PEP. I agree that the old rules were somewhat arbitrary, but this is 
a significant change with non-trivial compatibility concerns.

--

___
Python tracker 

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

[issue24979] Allow timezone offsets greater than 24 hours

[TJ]

New submission from TJ:

The datetime module only supports timezone offsets within 24 hours of UTC:

https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset

This seems like an arbitrary restriction, and prevents the library from being 
used in arbitrary timezone translations. For various reasons, one might need to 
start a new day (perhaps to implement some business logic) during the regular 
day. Depending on when/where this is, the effective offset can easily be 
greater than 24 hours.

>>> import datetime
>>> import pytz

>>> dt = pytz.utc.localize(datetime.datetime.utcnow())
>>> dt
datetime.datetime(2015, 8, 31, 23, 30, 55, 590037, tzinfo=)

>>> tz = pytz.timezone('Pacific/Auckland_Custom')
>>> dt.astimezone(tz)
datetime.datetime(2015, 9, 2, 4, 30, 55, 590037, tzinfo=)

>>> dt_local = datetime.datetime.now()
>>> tz.localize(dt_local)
.../python2.7/site-packages/pytz/tzinfo.py in localize(self, dt, is_dst)
314 loc_dt = tzinfo.normalize(dt.replace(tzinfo=tzinfo))
315 if loc_dt.replace(tzinfo=None) == dt:
--> 316 possible_loc_dt.add(loc_dt)
317
318 if len(possible_loc_dt) == 1:

ValueError: tzinfo.utcoffset() returned 1440; must be in -1439 .. 1439


Note that although only offsets within 24 hours are supported, it seems to be 
possible to use astimezone() with arbitrary offsets. So perhaps we gain 
consistency in removing the restriction altogether?

This would not be unprecedented. RFC 2822 allows any offset
representable as HHMM: "the zone MUST be within the range -9959
through +9959" Section 3.3 of http://tools.ietf.org/html/rfc2822.html

--
components: Library (Lib)
messages: 249482
nosy: tjhnson
priority: normal
severity: normal
status: open
title: Allow timezone offsets greater than 24 hours
type: enhancement

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

Make sure f-strings are identified as literals in error messages.

--
Added file: http://bugs.python.org/file40317/pep-498-2.diff

___
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

[Facundo Batista]

Changes by Facundo Batista :


--
nosy:  -facundobatista

___
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

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

BTW: The most portable way to access the timezone name of a given local time is 
to use strftime() with %Z as format character.

--

___
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

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

mktime() does change several global C runtime variables on Linux. See the man 
page on http://linux.die.net/man/3/mktime

However, the Python documentation does not mention anything about having 
time.tzname being tied to the C lib global: 
https://docs.python.org/3.5/library/time.html#time.tzname

So I don't think this qualifies as bug.

Note that those global C variable are not thread-safe, so you can't really 
trust their values relating to anything you've just set using mktime() anyway.

--
nosy: +lemburg

___
Python tracker 

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

[issue24978] Contributing to Python 2x and 3x Documentation. Translation to Russian.

[Eugene]

New submission from Eugene:

I am very much begging pardon if this is not the place to ask for, but..

I would like to make a thorough translation of the official Library Reference 
and the beginners guide to Python 2.x 3.x in Russian language.

I am aware this type of translation will be placed at
https://wiki.python.org/moin/RussianLanguage
as current https://docs.python.org/2/ does not allow changing language.

I am pretty much aware the translation should not sound any differently from 
the original in terms of its style, form and overall attitude. And I would also 
like to know, if possible, can this link be promoted somewhere at python.org. I 
am not in the slightest have the intentions of promoting in anywhere but in the 
place where most russian programmers could most definitely find it - at the 
oficial Python website.

Kind regards, Evgeniy.

--
assignee: docs@python
components: Documentation
messages: 249478
nosy: docs@python, overr1de
priority: normal
severity: normal
status: open
title: Contributing to Python 2x and 3x Documentation. Translation to Russian.
type: enhancement
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

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

[Stefan Krah]

Stefan Krah added the comment:

Steve: What do you mean by "global option"? The C99 standard says
that FENV_ACCESS (if set), is active until the end of the translation
unit (here: mpdecimal.c).

--

___
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

[Stefan Krah]

Stefan Krah added the comment:

On Linux ICC has something like "fast-math" by default.  The situation
is a bit annoying: On Unix ICC defines __GNUC__, but does not really
have all the features. Here ICC defines _MSC_VER, but does not behave
like cl.exe.

[I know it's a hard problem to be fully compatible, so I'm not blaming
the authors.]


What happens if you take the C99 path (starting in mpdecimal.c:48)?

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

Fixed validate_exprs bug.

--
Added file: http://bugs.python.org/file40316/pep-498-1.diff

___
Python tracker 

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

[issue24977] shutil copy to non-existant directory

[Jake Howard]

New submission from Jake Howard:

If you try and copy a file using shutil.copy to a directory that doesnt exist, 
it tries to copy the file to the location of the directory, and errors as 
shutil can't open a directory for 'WB' access, throwing an error, that doesnt 
reflect the problem.

--
messages: 249474
nosy: TheOrangeOne
priority: normal
severity: normal
status: open
title: shutil copy to non-existant directory
type: behavior

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

FWIW: I still think that allowing to change .__class__ on instances of static 
types if wrong and should be undone. If we want to make this a feature of the 
language we should have a PEP and the associated discussion to be able to judge 
and document the possible consequences of such a change. This ticket is the 
wrong place for such a discussion.

Regarding you module object change: Why don't you propose a change on the 
object itself instead of trying to monkey patch it via a mod.__class__ 
replacement ? E.g. by defining a hook in the object to set which then permits 
whatever modification you'd like to make.

--

___
Python tracker 

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

[issue24946] Tkinter tests that fail on linux in tiling window manager

[Florian Bruhin]

Changes by Florian Bruhin :


--
nosy:  -The-Compiler

___
Python tracker 

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

[issue24946] Tkinter tests that fail on linux in tiling window manager

[Florian Bruhin]

Florian Bruhin added the comment:

At least with my WM, there is no concept of having floating windows when in 
tiling mode, so I don't think that would be possible.

I also don't think there's a standard way to tell a window manager to not tile 
windows.

What about opening a simple window with a fixed geometry, checking if this was 
changed by the WM, and if it is, skip those tests?

--
nosy: +The Compiler

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

> From where I sit this all looks like a massive
> overreaction/misunderstanding: I introduced a bug, the cause is
> obvious, and it's straightforward to fix.

I agree with Nathaniel here. Let's just commit the fix instead of acting like 
irrational beings.

--

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

Thanks Raymond. Hi Guido. Sorry about the mess.

My overview of the situation so far, and of the patch currently attached to 
this bug, is here (and a bit in the next post):
  https://bugs.python.org/issue24912#msg249438

>From where I sit this all looks like a massive overreaction/misunderstanding: 
>I introduced a bug, the cause is obvious, and it's straightforward to fix. If 
>we want to fix the bug in the most general manner then that's straightforward 
>but probably more work than we want to do in rc3. If we want to just apply a 
>conservative fix and move on then we have an 8 line patch attached to this bug 
>that does that. Even if we don't apply the patch then there's no security 
>hole, that's just factually incorrect. But it doesn't even matter, because 
>again, we have a patch. If we do apply this patch, then literally the only 
>outcome of all of this will be that __class__ assignment in 3.5 will be (1) 
>less buggy in general, and (2) be allowed, safely, on instances of ModuleType 
>subclasses. I get that the whole concept of __class__ assignment is kinda 
>freaky and unnerving, but I do not understand why some people are insisting 
>that the above needs a PEP...

You know, in fact, note to everyone: I hereby withdraw any suggestion that we 
might want to "fix" the __class__ assignment code to handle the general case 
beyond ModuleType. Obviously this is super controversial and distracting for 
reasons I don't really understand, but I don't have to -- the only reason to 
brought it up in the first place is out of a vague desire to make Python 
"better", and frankly all I care about at this point is that I don't want to 
wait another 2 years before I can safely deprecate module-level constants. So 
let's just apply the attached patch and move on? Nothing broken, no security 
hole, nothing to eek about.

--

___
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

[Adam Bartoš]

Adam Bartoš added the comment:

How about reconsidering in the case that the machinery around PyOS_Readline is 
rewritten as I suggest in #17620 ?

--

___
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

[Raymond Hettinger]

Raymond Hettinger added the comment:

Guido, do you have any thoughts on this?

Several of us (me included) think http://hg.python.org/lookup/c0d25de5919e 
probably should not have been done.  Mutating non-heap types crosses an 
implicit boundary that we've long resisted crossing because it opens a can 
worms and has potential to violate our expectations about how the language 
works.

[Mark Shannon]
> Breaking the interpreter in order to facilitate some obscure use case is 
> unacceptable.

[Marc-Andre Lemburg]
I agree with Mark. This feature opens up a security hole large enough to drive 
a train through.

[Benjamin Peterson]
Probably the patch on that bug should be reverted.
  
[Larry Hastings]
As Python 3.5 Release Manager, my official statement is: Eek!

--
assignee:  -> Guido.van.Rossum
nosy: +Guido.van.Rossum, 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

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 01.09.2015 04:38, Nathaniel Smith wrote:
> 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...

I think you're being overly optimistic here. People run unchecked and
unverified code all the time; that's not the same as untrusted, since
trust develops with time and doesn't get reset with each new package
release.

Regardless, the above was only an example. The much more likely thing
to happen is that some code replaces the .__class__ of some unrelated
object by accident via a bug and causes all hell to break loose.

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

You can disable ctypes easily. OTOH, your patch is inherently changing the
language and making it less secure. There's no way to disable it or
even prevent using it from inside Python. IMO, that's a huge difference.

I also believe that the overall approach is wrong: if you want to add a
feature to Python module objects, please stick to those instead of
changing the overall interpreter semantics.

Some more background:

Replacing .__class__ of class instances is a known and useful Python
feature. However, in the past this was only possible for regular instances,
not for types. With new style classes, this differentiation got
blurred and in Python 3 we only have new style classes, so it may look
like we always wanted this feature to be available. Yet, I'm not sure
whether this was ever intended, or a conscious design decision and
because it creates serious problems for the interpreter, it
definitely needs go through a PEP process first to make everyone
aware of the consequences.

--

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

Please download Django from their github website: 
https://github.com/django/django

I checked and their latest stable release - Django 1.8.4 - from 
https://pypi.python.org/pypi/Django still has the getargspec issue.

Apparently the github version is 1.9.0 alpha. I have modified the patch and 
archive accordingly.

--
Added file: http://bugs.python.org/file40314/django_v3.patch

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

Changes by Florin Papa :


Added file: http://bugs.python.org/file40315/Django-1.9.zip

___
Python tracker 

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

[issue7175] Define a standard location and API for configuration files

[flying sheep]

flying sheep added the comment:

no, sorry, but ~/.python is wrong on linux.

there exists a standard about where things belong:

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

it says that configuration stuff belongs into `XDG_CONFIG_HOME`, with a 
fallback to `~/.config/`

i propose to add the `appdirs` module to the stdlib so that programs finally 
don’t have to guess and hack around this kind of things.

https://pypi.python.org/pypi/appdirs

--
nosy: +flying sheep

___
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, that makes sense, besides David pointed me about another opened issue that 
could help to solve cases like this: http://bugs.python.org/issue15216 If the 
encoding is wrong because the environment but we can change the initial stream 
encodings (in stdin/out) easily we have a powerful tool to adapt our scripts 
and patch broken locales like the generated with SSH sessions.

--

___
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

[Berker Peksag]

Berker Peksag added the comment:

I just downloaded Django-1.8.zip (florin.papa, 2015-08-27 11:49) and opened 
Django-1.8/django/__init__.py to check the Django version:

VERSION = (1, 9, 0, 'alpha', 0)

I think GitHub lets you download the master branch by default. I'd suggest to 
download the source release of Django 1.8.4 at 
https://pypi.python.org/pypi/Django/1.8.4

--
nosy: +berker.peksag

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

Yeah, sorry, actually I was thinking in the stdin/out section, the detach() doc 
itself is Ok, the problem comes when is called in stdin/out.

--

___
Python tracker 

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