28.03.18 23:19, Antoine Pitrou пише:
Agreed. Do you know by which timeframe you'll know which opcodes you
want to add?
I'm currently in the middle of the first part, trying to implement
pickling local classes with static and class methods without creating
loops. Other parts exist just like g
29.03.18 13:17, Jeff Allen пише:
'{1} {0}'.format(a(), b()) # E1
f'{b()}{a()}' # E2
I think I would be very surprised to find b called before a in E1
because of the general contract on the meaning of method calls. I'm
assuming that's what an AST-based optimisation woul
30.03.18 02:16, Steven D'Aprano пише:
Is there a down-side to 2b? It sounds like something you might end up
doing at a later date regardless of what you do now.
This complicate the compiler and the eval loop, especially in the case
of nested substitutions in formats, like
f'{value:+{widt
30.03.18 09:28, INADA Naoki пише:
As far as I know, most amd64 and arm64 systems use only 48bit address spaces.
(except [1])
[1]
https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf
It means there are some chance to compact some data structures.
I point t
29.03.18 18:06, Terry Reedy пише:
On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes semantic. Non-optimized "if a and True:"
would call bool(a) twice, but optimized code calls it only once.
Perhaps Ref 3.3.1 object.__bool__ entry, after " should
30.03.18 16:54, Antoine Pitrou пише:
We could also simply nuke wstr. I frankly don't think it's very
important. It's only used when calling system functions taking a
wchar_t argument, as an « optimization ». I'd be willing to
guess that modern workloads aren't bottlenecked by the cost overhead
03.04.18 01:57, Lukasz Langa пише:
On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote:
On Mon, 2 Apr 2018 13:48:46 -0700
Lukasz Langa wrote:
Pickle protocol version 4.0 was originally defined back in PEP 3154 and shipped
as part of Python 3.4 back in 2011. Yet it's still not the default.
Becau
I expect that for IntFlag `x in flags` is equivalent either to
bool(x | flags.value)
or to
(x | flags.value) == x
It should return some result only if x is an integer (or compatible with
integers) and raise a TypeError otherwise.
Don't add any special checks unless there are good re
06.04.18 19:32, Anthony Flury via Python-Dev пише:
The three pull requests are :
Python 2.7 - doc string fix : https://github.com/python/cpython/pull/6015
There are several open issues for "sequence" vs "iterable" in docstrings
and documentation for different functions. It would be worth to m
07.04.18 23:21, Stéphane Blondon пише:
I wonder if it's useful to update the cgitb module, in particular the
html output.
I see some possible improvements:
1. In both text and html versions:
When a module is called, there are no parameters (displayed as '()'). I
think they are unnecessary. Perh
08.04.18 19:10, Antoine Pitrou пише:
On Sat, 7 Apr 2018 17:31:47 -0500
Skip Montanaro wrote:
It's been a long while since I rebuilt Python from the Git source. I
tried for the first time the other day. Everything passed except
test_poplib and test_asyncio. The former just runs and runs and runs
15.04.18 16:09, Nick Coghlan пише:
On 15 April 2018 at 22:50, Jeroen Demeyer wrote:
I've been told that there might also be a problem with Random._randbelow,
even though it doesn't cause test failures.
From Raymond's description (and from an initial reading of the code),
the _randbelow case
13.04.18 16:27, INADA Naoki пише:
Then, I want to reschedule the removal of these APIs.
Can we remove them in 3.8? 3.9? or 3.10?
I prefer sooner as possible.
I suppose that many users will start porting to Python 3 only in 2020,
after 2.7 EOL. After that time we shouldn't support compatibility
In Python 2.5 `0or[]` was accepted by the Python parser. It became an
error in 2.6 because "0o" became recognizing as an incomplete octal
number. `1or[]` still is accepted.
On other hand, `1if 2else 3` is accepted despites the fact that "2e" can
be recognized as an incomplete floating point nu
There is an inconsistence in passing arguments to functions.
Explicit positional arguments should precede keyword arguments (both
explicit and variable), but variable positional arguments can follow
explicit keyword arguments and precede variable keyword arguments.
For example, for function
26.04.18 22:02, Lukasz Langa пише:
On Apr 26, 2018, at 11:37 AM, Serhiy Storchaka wrote:
I propose to change the Python syntax by adding a requirement that there should
be a whitespace or delimiter between a numeric literal and the following
keyword.
-1
This would make Python 3.8 reject
27.04.18 13:25, Nick Coghlan пише:
and PEP 3099 (explicitly
rejected ideas that also didn't get their own PEPs).
"There will be no alternative binding operators such as :=."
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
04.05.18 16:14, Steven D'Aprano пише:
Have there been many features removed since 3.1? I know there were some
features removed in 3.0, like callable(), which were later put back in,
but I can't think of anythin removed since then. If there were, the pace
of it is pretty slow.
Read "What's New"
04.05.18 20:57, Matthias Bussonnier пише:
But when I hit a DeprecationWarning message there is one crucial piece of
information missing most of the time: Since which version number it's
deprecated
(and sometime since when the replacement is available could be good if
overlap
between functional
07.05.18 14:19, Nick Coghlan пише:
And as the current python-ideas discussion about accessing paths
relative to __file__ shows,
I can't believe this is discussed seriously. Forgot about the Python 2
legacy, just use importlib.
___
Python-Dev mailin
07.05.18 16:50, Joao S. O. Bueno пише:
May it is important to note that
Python 3.7 already has very little syntactic changes.
Actually, there are no new syntac changes with PEP 563 -
(Postponed Evaluation of Annotations) being maybe
the only change to existing behavior, and PEP 562 as new
"non-li
08.05.18 18:51, Joni Orponen пише:
If one can import from the future can one can also import from the past?
One can move removed feature to a third-party module and import them
from it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail
04.05.18 22:08, Matthias Bussonnier пише:
Maybe to push people forward, but from experience it is hard to predict
future, so saying when
it _will_ be remove is hard.
Right. But the data of removing is usually specified when the code for
removing already is written, or even merged in the next
08.05.18 19:10, Ethan Furman пише:
X.Y+1: added a deprecation warning. Many users need to support only
two recent versions and can move to using the
replacement now.
I'm curious how you arrived at this conclusion? I know I've only worked
at two different Python-using companies, but neither a
09.05.18 07:25, Steven D'Aprano пише:
If we could look forward to 2028, when we're running Python 3.14 or so
(4.7 if you prefer), how many fantastic language features that we cannot
bear to give up would we be missing out on?
Like tab-delimited tables.
_
09.05.18 14:35, Antoine Pitrou пише:
I proposed the idea in another thread that Python had reached "peak
syntax" and maybe it was time to consider the core language essentially
mature. Of course, we don't know what the future will bring and
perhaps some fundamentally new programming idiom will a
12.05.18 17:48, Steve Holden пише:
It's certainly true that when I split any of those left-hand cells the
bizarre emphasis occurs. Still looking for a workaround.
Remove an extra indentation of the second line.
___
Python-Dev mailing list
Python-Dev@
13.05.18 20:42, Christian Heimes пише:
I was against the approach a good reason. The PR adds additional CPU
instructions and changes memory access pattern in a critical path of
CPython. There is no reason to add additional overhead for the majority
of users or X86 and X86_64 architectures. The m
16.05.18 07:35, Alex Walters пише:
In the spirit of learning why there is a fence across the road before I tear
it down out of ignorance [1], I'd like to know the rationale behind source
only releases of cpython. I have an opinion on their utility and perhaps an
idea about changing them, but I'd
16.05.18 07:35, Alex Walters пише:
[1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
And I wish that every author who suggested the idea for Python was
familiar with the Chesterton's fence principle.
___
Python-Dev mailing list
Pyth
Does anyone has the full copy of the PyXML repository, with the complete
history?
This library was included in Python 2.1 as the xml package and is not
maintained as a separate project since 2004. It's home on SourceForge
was removed. I have found sources of the last PyXML version (0.8.4), but
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
feature fixes, bug fixes, and documentation updates in before
2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
from now. We will then tag and produce the 3.7.0 release candidat
17.05.18 21:43, Elvis Pranskevichus пише:
I'm working on the What's New document. Will start putting PRs in the
next few days.
Great!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
17.05.18 21:39, Brett Cannon пише:
Maybe we should start thinking about flagging PRs or issues as needing
a What's New entry to help track when they need one, or always expect
it in a PR and ignore that requirement when a 'skip whats new' label
is applied. That would at least make it easier to
Please don't forgot to perform the following steps when add a new
public C API:
* Document it in Doc/c-api/.
* Add an entry in the What's New document.
* Add it in Doc/data/refcounts.dat.
* Add it in PC/python3.def.
If you want to include it in the limited API, wrap its declaration with:
21.05.18 16:27, Paul Moore пише:
On 21 May 2018 at 13:41, Serhiy Storchaka wrote:
* Add it in PC/python3.def.
I thought python3.def should only contain symbols in the limited ABI
(it defines the API of python3.dll, doesn't it?)
Thank you for correction. Yes, and only for Windows. Ne
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
feature fixes, bug fixes, and documentation updates in before
2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
from now. We will then tag and produce the 3.7.0 release candidat
24.05.18 10:23, Ned Deily пише:
So this *is* really your last chance: if you know of any true releasing
blocking issues for 3.7.0, you have about 12 more hours to log it in
the bug tracker as a "release blocker". I'll send out an email once we
start the release manufacturing. Any merges to the 3.
24.05.18 19:02, Ned Deily пише:
On May 24, 2018, at 11:35, Serhiy Storchaka wrote:
I have doubts about two issues. I feel the responsibility for them because I
had the opportunity to solve them before, but I lost it.
[...]
Serhiy, what are the bugs.python.org issue numbers for these? Are
25.05.18 05:09, Jan Claeys пише:
On Thu, 2018-05-17 at 15:18 +0300, Serhiy Storchaka wrote:
Does anyone has the full copy of the PyXML repository, with the
complete history?
This library was included in Python 2.1 as the xml package and is
not maintained as a separate project since 2004. It&#
The tp_clear field of PyTypeObject has type inquiry. It is a pointer to
a function that takes PyObject * and return int.
typedef int (*inquiry)(PyObject *);
I'm interesting what the result of this function means. In what cases it
can return non-zero, and can it set an exception?
Currently tp
28.05.18 23:11, Jeremy Kloth пише:
On Thu, May 17, 2018 at 6:18 AM, Serhiy Storchaka wrote:
Does anyone has the full copy of the PyXML repository, with the complete
history?
This library was included in Python 2.1 as the xml package and is not
maintained as a separate project since 2004. It&#
29.05.18 17:15, Steve Dower пише:
Looks like it breaks the 3.7 ABI, which is certainly not allowed at this
time. But it’s not a limited API structure, so no problem for 3.8.
Looks like it breaks only extensions that use private macros
_PyObject_GC_TRACK, _PyObject_GC_UNTRACK and _PyObject_GC_I
02.06.18 00:37, Christian Tismer пише:
I was challenged end of last December to try that, and I succeeded
after a long struggle, because I also needed to convert all of PySide2
to using heaptypes, and that was really hard. Actually, I succeeded
yesterday, after 5 months. And now I know all the su
08.06.18 10:48, Victor Stinner пише:
Yury Selivanov pushed his implementation of the PEP 567 -- Context
Variables at January 23, 2018. Yesterday, 4 months after the commit
and only 3 weeks before 3.7.0 final release, a crash has been found in
the implementation:
https://bugs.python.org/issue33803
08.06.18 11:31, Victor Stinner пише:
Do you suggest to trigger a fake "GC collection" which would just
visit all objects with a no-op visit callback? I like the idea!
Yeah, that would help to detect objects in an inconsistent state and
reuse the existing implemented visit methods of all types.
20.06.18 18:42, INADA Naoki пише:
First of all, thank you Jeroen for writing nice PEPs.
When I read PEP 579, I think "6. METH_FASTCALL is private and undocumented"
should be solved first.
I don't have any idea about changing METH_FASTCALL more.
If Victor and Serhiy think so, and PyPy maintainer
21.06.18 14:25, Jeroen Demeyer пише:
Currently, we have:
>>> [].append == [].append
False
However, with a Python class:
>>> class List(list):
def append(self, x): super().append(x)
>>> List().append == List().append
True
I think this is a bug. These bound methods can't be equal b
22.06.18 00:04, Ivan Pozdeev via Python-Dev пише:
On 21.06.2018 23:40, Guido van Rossum wrote:
I'm with Serhiy here, for mutable values I don't think the methods
should compare equal, even when the values do. For immutables I don't
care either way, it's an implementation detail.
In this light
23.06.18 05:21, Guido van Rossum пише:
A bound method is a fairly complicated object, and for builtin bound
methods, the == comparison has the following definition:
- if the `__self__` objects are not the same object, return False
- otherwise, return True iff it's the same method (i.e. the same
23.06.18 10:27, Jeroen Demeyer пише:
On 2018-06-23 03:50, Steven D'Aprano wrote:
I think it is more important that builtin methods and Python methods
behave the same.
+1
This inconsistency is the *real* problem here. It's one little extra
complication to merging those classes (which was prop
26.06.18 12:11, INADA Naoki пише:
FYI, I don't against general refactoring, when I agree it's really make
code cleaner, readable.
I against your PR because I didn't feel it really make code cleaner,
readable.
I already commented about it on the PR.
https://github.com/python/cpython/pull/7909#
PyObject_IsInstance is not safe when used to check if the object is an
instance of specified builtin type. Typical code:
rc = PyObject_IsInstance(obj, &Someting_Type);
if (rc < 0) return NULL;
if (rc) {
SometingObject *something = (SometingObject *)obj;
something->som
On 18.05.15 15:14, Greg Ewing wrote:
Serhiy Storchaka wrote:
PyObject_IsInstance is not safe when used to check if the object is an
instance of specified builtin type.
The __class__ attribute can be modified and PyObject_IsInstance() can
return true if the object has not layout compatible with
On 26.05.15 08:33, Yury Selivanov wrote:
On 2015-05-26 12:26 AM, Terry Reedy wrote:
+try:
+encoding, lines = detect_encoding(buffer.readline)
+buffer.seek(0)
+text = TextIOWrapper(buffer, encoding, line_buffering=True)
+text.mode = 'r'
+return text
+
On 28.05.15 22:40, benjamin.peterson wrote:
https://hg.python.org/cpython/rev/ac891c518d4e
changeset: 96342:ac891c518d4e
branch: 3.5
parent: 96339:6f05f83c7010
user:Benjamin Peterson
date:Thu May 28 14:40:08 2015 -0500
summary:
remove STORE_MAP, since it's unused
Isn't it a time to assign release manager for 3.6-3.7?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 02.06.15 04:58, ned.deily wrote:
https://hg.python.org/cpython/rev/30da21d2fa4f
changeset: 96458:30da21d2fa4f
branch: 2.7
parent: 96454:5e8fa1b13516
user:Ned Deily
date:Mon Jun 01 18:45:49 2015 -0700
summary:
Issue #24357: Change host in socket.getaddrinfo examp
On 01.06.15 21:07, Barry Warsaw wrote:
On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote:
Isn't it a time to assign release manager for 3.6-3.7?
Indeed! Please welcome Ned Deily as RM for 3.6:
https://www.python.org/dev/peps/pep-0494/
Good news for all us! Ned many times saved me
There are issues with the doctype() method of XMLParser.
1. Using subclass of XMLParser emits a deprecation warning [1].
2. There is behavior difference between Python and C implementations if
implement doctype() [2].
This method was deprecated for long time, and the simplest solution is
to
On 17.06.15 02:26, Larry Hastings wrote:
A quick look through the checkin logs suggests that there's literally
nothing happening in 3.6 right now. All the checkins are merges.
Is anyone expecting to do work in 3.6 soon? Or did the early branch
just create a bunch of make-work for everybody?
M
On 18.06.15 22:34, MRAB wrote:
On 2015-06-18 19:33, Larry Hastings wrote:
On 06/18/2015 11:27 AM, Terry Reedy wrote:
Unicode 8.0 was just released. Can we have unicodedata updated to
match in 3.5?
What does this entail? Data changes, code changes, both?
It looks like just data changes.
On 19.06.15 07:56, Serhiy Storchaka wrote:
May be private table for case-insensitive matching in the re module
should be updated too.
Confirm that the re module doesn't need the update to Unicode 8.0.
___
Python-Dev mailing list
Pytho
On 28.06.15 08:03, raymond.hettinger wrote:
https://hg.python.org/cpython/rev/637e197be547
changeset: 96697:637e197be547
user:Raymond Hettinger
date:Sat Jun 27 22:03:35 2015 -0700
summary:
Minor refactoring. Move reference count logic into function that adds entry.
This l
ializing the
hash table search into a lookup function and an insert function.
- Issue #23955: Add pyvenv.cfg option to suppress registry/environment
lookup for generating sys.path on Windows.
- Issue #15027: The UTF-32 encoder is now 3x to 7x faster.
- Issue #23290: Optimize set_merge() for cases
On 07.07.15 05:08, raymond.hettinger wrote:
https://hg.python.org/cpython/rev/5088f2cd6293
changeset: 96866:5088f2cd6293
user:Raymond Hettinger
date:Mon Jul 06 19:08:49 2015 -0700
summary:
Minor bit of factoring-out common code.
+if (rv < 0)
+goto erro
On 07.07.15 05:03, raymond.hettinger wrote:
https://hg.python.org/cpython/rev/c9782a9ac031
changeset: 96865:c9782a9ac031
user:Raymond Hettinger
date:Mon Jul 06 19:03:01 2015 -0700
summary:
Tighten-up code in the set iterator to use an entry pointer rather than
indexing.
fi
On 07.07.15 10:42, Serhiy Storchaka wrote:
On 07.07.15 05:03, raymond.hettinger wrote:
https://hg.python.org/cpython/rev/c9782a9ac031
changeset: 96865:c9782a9ac031
user:Raymond Hettinger
date:Mon Jul 06 19:03:01 2015 -0700
summary:
Tighten-up code in the set iterator to
On 07.07.15 15:32, Maciej Fijalkowski wrote:
I kind of thought that python does pre-commit reviews (at least seems
to apply to most people), so in case someone is completely exempt from
that, maybe he should read python-dev or wherever the reply is set to?
That also does not explain why a crashin
On 07.07.15 15:14, Guido van Rossum wrote:
FYI, do we have any indication that Raymond even read the comment? IIRC
he doesn't regularly read python-dev. I also don't think code review
comments ought to go to python-dev; the commiters list would seem more
appropriate? (Though it looks like python-
On 07.07.15 17:33, Maciej Fijalkowski wrote:
On Tue, Jul 7, 2015 at 3:08 PM, Serhiy Storchaka wrote:
There is no haste. Only developed branch is affected and we have enough time
to fix it. No buildbots is broken.
Then maybe a good option would be to add the crasher to the test
suite, so the
On 08.07.15 01:45, Raymond Hettinger wrote:
P.S. I don't think python-dev post was necessary or helpful (and I still
haven't had a chance to read the whole thread). It would have been sufficient
to assign the tracker entry back to me.
Well, I'll open new issue and assign it to you for every
On 24.07.15 15:34, lp_benchmark_robot wrote:
Hi Internals,
This is the first message from Intel's language optimization team.
We would like to provide the Python internals developer community
with a daily service which will monitor latest committed patches
performance regressions against well kn
On 08.09.15 05:06, Kerrick Staley wrote:
I noticed that collections.Counter, unlike set, doesn't support the
ordered comparison operators (> < >= <=). I'd like to propose
implementing these operators in an analogous fashion to set: counter1 >=
counter2 if counter1 contains at least as many of eve
On 28.06.15 09:14, nick.coghlan wrote:
https://hg.python.org/devguide/rev/452f840bac9f
changeset: 749:452f840bac9f
user:Nick Coghlan
date:Sun Jun 28 16:13:54 2015 +1000
summary:
Drop myself from issue assignment list
files:
experts.rst | 6 +++---
1 files changed, 3 i
Sorry for the nose. I sent this message to the list I accidentally.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-arc
On 09.09.15 20:33, Serhiy Storchaka wrote:
Sorry for the nose. I sent this message to the list I accidentally.
s/nose/noise/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https
On 10.09.15 10:23, Maciej Fijalkowski wrote:
I would like to know what are the semantics if you subclass something
from itertools (e.g. islice).
Right now it's allowed and people do it, which is why the
documentation is incorrect. It states "equivalent to: a function-or a
generator", but you can
I can't neither post a message to existing issue nor open a new issue.
The irker854 bot on IRC channel #python-dev cites my message and the
tracker updates activity time of existing issue, but doesn't show my
message and doesn't reflect changes of status. Posting via e-mail
doesn't work as well
library section
Patch by Elvis Pranskevichus
io
--
-* New Python implementation of :class:`io.FileIO` to make dependency on
- ``_io`` module optional.
- (Contributed by Serhiy Storchaka in :issue:`21859`.)
+:class:`io.FileIO` has been implemented in Python which makes C implementation
+of
On 08.09.15 19:59, Brett Cannon wrote:
The approaches to module deprecation I have seen are:
1. Nothing changes to the deprecation process; you deprecate a module
and remove it in one to two releases
2. Deprecate the module but with no plans for removal until Python 2.7
reaches its EOL (I have be
On 10.09.15 15:50, Maciej Fijalkowski wrote:
On Thu, Sep 10, 2015 at 10:26 AM, Serhiy Storchaka wrote:
There is another reason why itertools iterators can't be implemented as
simple generator functions. All iterators are pickleable in 3.x.
maybe the documentation should reflect that?
On 15.09.15 04:21, barry.warsaw wrote:
https://hg.python.org/peps/rev/e275c4cd4b44
changeset: 6059:e275c4cd4b44
user:Barry Warsaw
date:Mon Sep 14 21:21:40 2015 -0400
summary:
Move 13 -> 103
files:
pep-0103.rst | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On 19.09.15 14:03, Eric V. Smith wrote:
While finishing up the implementation of PEP 498, I realized that the
PEP has an error. It says that this code:
f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
Is equivalent to:
'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
+
For now the default value of the stacklevel parameter in warnings.warn()
is 1. But in most cases stacklevel=2 is required, sometimes >2, and I
don't know cases that need stacklevel=1. I propose to make the default
value of stacklevel to be 2. I think that unlikely this will break
existing code.
субота, 19-вер-2015 23:55:44 Nathaniel Smith написано:
> OTOH I guess if there is anyone out there who's intentionally using
> stacklevel=1 they might be reasonably surprised at this change.
That is why I ask on Python-Dev instead of just open an issue.
But I doubt that there is such case.
On 20.09.15 16:51, Eric V. Smith wrote:
On 9/20/2015 8:37 AM, Nick Coghlan wrote:
On 19 September 2015 at 21:03, Eric V. Smith wrote:
Instead of calling __format__, I've changed the code generator to call
format(expr1, spec1). As an optimization, I might add special opcodes to
deal with this a
On 21.09.15 10:18, Victor Stinner wrote:
2015-09-20 8:44 GMT+02:00 Serhiy Storchaka :
I propose to make the default value of stacklevel to be 2.
I think that unlikely this will break existing code.
Consider this simple script:
---
import warnings
warnings.warn("here")
---
Currr
On 21.09.15 12:05, Nick Coghlan wrote:
As Victor notes, though, that's not the right default for *scripts*
that are issuing deprecation warnings to end users - there, they
really are deprecating themselves. It's also not the right default for
pretty much any warning other than DeprecationWarning
On 21.09.15 20:00, Serhiy Storchaka wrote:
On 21.09.15 10:18, Victor Stinner wrote:
---
sys:1: UserWarning: here
---
"sys:1" is not really useful :-/
This is not new. The same output we get when run a module that correctly
emits a warning at module level (with explicit st
On 21.09.15 20:32, Brett Cannon wrote:
On Mon, 21 Sep 2015 at 10:15 Serhiy Storchaka mailto:storch...@gmail.com>> wrote:
On 21.09.15 12:05, Nick Coghlan wrote:
> Passing "stacklevel=2" for API deprecations is by no means obvious
> though, so perhaps i
On 02.10.15 10:18, Victor Stinner wrote:
I would like to add an obvious way to check if Python was compiled in
debug mode, instead of having hacks/tips to check it. On the Internet,
I found various recipes to check if Python is compiled is debug mode.
Sadly, some of them are not portable.
I agr
On 16.10.15 09:57, Victor Stinner wrote:
I suggest to raise an error if token_bytes(n) if calls with n < 16
bytes (128 bits). Well, I'm not sure that 16 is the good compromise
between performance and security, but we must enforce users to use a
minimum number of bits of entropy. token_bytes(1) lo
On 16.10.15 19:26, Steven D'Aprano wrote:
On Fri, Oct 16, 2015 at 06:35:14PM +0300, Serhiy Storchaka wrote:
I suggest to add only randrange(). randint() is historical artefact, we
shouldn't repeat this mistake in new module. The secrets module is not
good way to generate dice roll
On 18.10.15 00:45, Eric Snow wrote:
In a recent tracker issue about OrderedDict [1] we've had some
discussion about the use of type(od) as a replacement for
od.__class__. It came up because the pure Python implementation of
OrderedDict uses self.__class__ in 3 different methods (__repr__,
__redu
On 18.10.15 01:20, Eric Snow wrote:
On the tracker he notes another OrderedDict compatibility break:
Backward compatibility related to __class__ assignment was
already broken in C implementation. In 3.4 following code
works:
>>> from collections import *
>>> class foo(O
On 20.10.15 00:00, Guido van Rossum wrote:
Apart from Serhiy's detraction of the 3.5 bug report there wasn't any
discussion in this thread. I also don't really see any specific
questions, so maybe you don't have any. Are you just asking whether it's
okay to merge your code? Or are you asking for
On 18.10.15 00:45, Eric Snow wrote:
So, would it make sense to establish some concrete guidelines about
when to use type(obj) vs. obj.__class__? If so, what would those be?
It may also be helpful to enumerate use cases for "type(obj) is not
obj.__class__".
My conclusion of this discussion. In
On 21.10.15 04:25, Gregory P. Smith wrote:
https://www.python.org/dev/peps/pep-0008/#names-to-avoid
/"Since module names are mapped to file names, and some file systems are
case insensitive and truncate long names, it is important that module
names be chosen to be fairly short -- this won't be a
On 30.10.15 03:22, Terry Reedy wrote:
Leaving IDLE aside, the reason '' is added to sys.path is so that people
can import their own modules. This is very useful. Shadowing is the
result of putting it at the front. I have long thought this a dubious
choice. If '' were instead appended, people
201 - 300 of 1152 matches
Mail list logo
