I've run into issue 25939 (https://bugs.python.org/issue25939) when trying
to deploy a python webapp with IIS on Windows. This issue is preventing us
from deploying the app to production as the workaround AFAICT requires
running the app under an admin account.
Apologies if this is an inappropriate forum for a +1 but I just wanted to
let the devs know that this is an issue which affects the use of Python
(on Windows) in the enterprise. I noticed that the patch hasn't been
merged yet so was interested in making sure it didn't fall by the
As a mere user I don't expect the devs to prioritize my own problems which
no doubt only affect a very small number of python users but I would be
very grateful if the patch did make it into a minor release.
I've a question about the implementation of the `type` builtin (in Python
In Objects/typeobject.c, the `tp_alloc` slot of PyType_Type gets set to 0.
However, I can see (using gdb) that it later gets assigned to
`&PyType_GenericAlloc`. I'd argue that this makes sense because, in
`type_new`, there is a line where that member function gets called without
previously checking whether that member points to something:
/* Allocate the type object */
type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots);
Yet, I can't seem to understand where and when does the `tp_alloc` slot of
PyType_Type get re-assigned to PyType_GenericAlloc. Does that even happen?
Or am I missing something bigger?
And, just out of further curiosity, why doesn't the aforementioned slot get
initialised to `PyType_GenericAlloc` in the first place?
Thanks a lot.
Recent Python versions randomize the hashes of str, bytes and
datetime objects. I suppose that the choice of these three types
is the result of a compromise. Has this been discussed somewhere
I'm not a web programmer, but don't web applications also use
dictionaries that are indexed by, say, tuples of integers?
This is Alecsandru from the Dynamic Scripting Languages Optimization Team at Intel Corporation. I want to open a discussion regarding the way CPython is built, mainly the options that are available to the programmers. Analyzing the CPython ecosystem we can see that there are a lot of users that just download the sources and hit the commands "./configure", "make" and "make install" once and then continue using it with their Python scripts. One of the problems with this workflow it that the users do not benefit from the entire optimization features that are existing in the build system, such as PGO and LTO.
Therefore, I propose a workflow, like the following. Assume some work has to be done into the CPython interpreter, a developer can do the following steps:
A. Implementation and debugging phase.
1. The command "./configure PYDIST=debug" is ran once. It will enable the Py_DEBUG, -O0 and -g flags
2. The command "make" is ran once or multiple times
B. Testing the implementation from step A, in a pre-release environment
1. The command "./configure PYDIST=devel" is ran once. It will disable the Py_DEBUG flags and will enable the -O3 and -g flags, and it is just like the current implementation in CPython
2. The command "make" is ran once or multiple times
C. For any other CPython usage, for example distributing the interpreter, installing it inside an operating system, or just the majority of users who are not CPython developers and only want to compile it once and use it as-is:
1. The command "./configure" is ran once. Alternatively, the command "./configure PYDIST=release" can be used. It will disable all debugging functionality, enable the -O3 flag and will enable PGO and LTO.
2. The command "make" is ran once
If you think this benefits CPython, I can create an issue and post the patches that enable all of the above.
This came up in python-ideas, and has met mostly positive comments,
although the exact syntax rules are up for discussion.
Title: Underscores in Numeric Literals
Author: Georg Brandl
Type: Standards Track
Abstract and Rationale
This PEP proposes to extend Python's syntax so that underscores can be used in
integral and floating-point number literals.
This is a common feature of other modern languages, and can aid readability of
long literals, or literals whose value should clearly separate into parts, such
as bytes or words in hexadecimal notation.
# grouping decimal numbers by thousands
amount = 10_000_000.0
# grouping hexadecimal addresses by words
addr = 0xDEAD_BEEF
# grouping bits into bytes in a binary literal
flags = 0b_0011_1111_0100_1110
The current proposal is to allow underscores anywhere in numeric literals, with
* Leading underscores cannot be allowed, since they already introduce
* Trailing underscores are not allowed, because they look confusing and don't
contribute much to readability.
* The number base prefixes ``0x``, ``0o``, and ``0b`` cannot be split up,
because they are fixed strings and not logically part of the number.
* No underscore allowed after a sign in an exponent (``1e-_5``), because
underscores can also not be used after the signs in front of the number
* No underscore allowed after a decimal point, because this leads to ambiguity
with attribute access (the lexer cannot know that there is no number literal
There appears to be no reason to restrict the use of underscores otherwise.
The production list for integer literals would therefore look like this::
integer: decimalinteger | octinteger | hexinteger | bininteger
decimalinteger: nonzerodigit [decimalrest] | "0" [("0" | "_")* "0"]
decimalrest: (digit | "_")* digit
octinteger: "0" ("o" | "O") (octdigit | "_")* octdigit
hexinteger: "0" ("x" | "X") (hexdigit | "_")* hexdigit
bininteger: "0" ("b" | "B") (bindigit | "_")* bindigit
hexdigit: digit | "a"..."f" | "A"..."F"
bindigit: "0" | "1"
For floating-point literals::
floatnumber: pointfloat | exponentfloat
pointfloat: [intpart] fraction | intpart "."
exponentfloat: (intpart | pointfloat) exponent
intpart: digit (digit | "_")*
fraction: "." intpart
exponent: ("e" | "E") "_"* ["+" | "-"] digit [decimalrest]
Underscore Placement Rules
Instead of the liberal rule specified above, the use of underscores could be
limited. Common rules are (see the "other languages" section):
* Only one consecutive underscore allowed, and only between digits.
* Multiple consecutive underscore allowed, but only between digits.
A proposed alternate syntax was to use whitespace for grouping. Although
strings are a precedent for combining adjoining literals, the behavior can lead
to unexpected effects which are not possible with underscores. Also, no other
language is known to use this rule, except for languages that generally
disregard any whitespace.
C++14 introduces apostrophes for grouping, which is not considered due to the
conflict with Python's string literals. _
Behavior in Other Languages
Those languages that do allow underscore grouping implement a large variety of
rules for allowed placement of underscores. This is a listing placing the known
rules into three major groups. In cases where the language spec contradicts the
actual behavior, the actual behavior is listed.
**Group 1: liberal (like this PEP)**
* D _
* Perl 5 (although docs say it's more restricted) _
* Rust _
* Swift (although textual description says "between digits") _
**Group 2: only between digits, multiple consecutive underscores**
* C# (open proposal for 7.0) _
* Java _
**Group 3: only between digits, only one underscore**
* Ada _
* Julia (but not in the exponent part of floats) _
* Ruby (docs say "anywhere", in reality only between digits) _
A preliminary patch that implements the specification given above has been
posted to the issue tracker. _
..  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html
..  http://dlang.org/spec/lex.html#integerliteral
..  http://perldoc.perl.org/perldata.html#Scalar-value-constructors
..  http://doc.rust-lang.org/reference.html#number-literals
..  https://github.com/dotnet/roslyn/issues/216
..  http://archive.adaic.com/standards/83lrm/html/lrm-02-04.html#2.4
..  http://ruby-doc.org/core-2.3.0/doc/syntax/literals_rdoc.html#label-Numbers
..  http://bugs.python.org/issue26331
This document has been placed in the public domain.
MicroPython is a lean and efficient Python implementation for
microcontrollers, embedded, and mobile systems (which also runs just as
fine on desktops, servers, and clouds).
There're following major changes since 1.5:
1. LwIP module support for embedded TCP/IP networking.
2. IPv6 support in the Unix port.
3. Beta support for persistent bytecode (similar to CPython's .pyc)
4. 64-bit NaN boxing (improved floating-point performance if enabled).
5. Support for new official PyBoards PYBv1.1 and PYBLITEv1.0.
6. Long int constant folding during bytecode compilation (glad that
CPython will catch up in that area thanks to FAT Python project).
7. There's a ongoing crowdfunding campaign to fund complete and
well-maintained MicroPython port to ubiquitous ESP8266 WiFi SoC, and
improve networking and IoT support in MicroPython in general:
Sorry to bringing this up again. I was hoping we were done with that.
When discussing the name of the Py_SETREF macro I was supposed to add a
pair of macros: for Py_DECREF and Py_XDECREF. But I got a lot of
opinions to be limited to only one macro.
On 28.02.14 15:58, Kristján Valur Jónsson wrote:
> Also, for the equivalence to hold there is no separate Py_XSETREF, the X
> behaviour is implied, which I favour. Enough of this X-proliferation
On 16.12.15 16:53, Random832 wrote:
> I think "SET" names imply that it's safe if the original
> reference is NULL. This isn't an objection to the names, but if
> it is given one of those names I think it should use Py_XDECREF.
It was my initial intension. But then I had got a number of voices for
On 16.12.15 23:16, Victor Stinner wrote:
> I would prefer a single macro to avoid bugs, I don't think that such
> macro has a critical impact on performances. It's more designed for
> safety, no?
On 17.12.15 08:22, Nick Coghlan wrote:
>> 1. Py_SETREF
> +1 if it always uses Py_XDECREF on the previous value (as I'd expect
> this to work even if the previous value was NULL)
There was no (besides my) clearly expressed vote for two macros.
As a result I have replaced both Py_DECREF and Py_XDECREF with the macro
that always uses Py_XDECREF.
Now Raymond, who was not involved in the previous discussions, expressed
the view that we should to rename Py_SETREF to Py_XSETREF and add new
Py_SETREF that uses Py_DECREF for using in the code that used Py_DECREF
We should discuss the need for this, and may be re-discuss the names for