05.06.14 01:04, Terry Reedy написав(ла):
PS. You do not seem to be aware of how well the current PEP393
implementation works. If you are going to write any more about it, I
suggest you run Tools/Stringbench/stringbench.py for timings.
AFAIK stringbench is ASCII-only, so it likely is compatible
05.06.14 00:21, Terry Reedy написав(ла):
On 6/4/2014 3:41 AM, Jeff Allen wrote:
Jython uses UTF-16 internally -- probably the only sensible choice in a
Python that can call Java. Indexing is O(N), fundamentally. By
"fundamentally", I mean for those strings that have not yet noticed that
they con
05.06.14 03:08, Greg Ewing написав(ла):
Serhiy Storchaka wrote:
A language which doesn't support O(1) indexing is not Python, it is
only Python-like language.
That's debatable, but even if it's true, I don't think
there's anything wrong with MicroPython being only a
&
05.06.14 03:03, Greg Ewing написав(ла):
Serhiy Storchaka wrote:
html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize don't
use iterators. They use indices, str.find and/or regular expressions.
Common use case is quickly find substring starting from current
position using str.fi
04.06.14 23:50, Glenn Linderman написав(ла):
3) (Most space efficient) One cached entry, that caches the last
codepoint/byte position referenced. UTF-8 is able to be traversed in
either direction, so "next/previous" codepoint access would be
relatively fast (and such are very common operations, e
05.06.14 05:25, Terry Reedy написав(ла):
I mentioned it as an alternative during the '393 discussion. I more than
half agree that the FSR is the better choice for CPython, which had no
particular attachment to UTF-16 in the way that I think Jython, for
instance, does.
Yes, I remember. I thing t
11.06.14 05:28, Antoine Pitrou написав(ла):
close() should indeed be idempotent on all bundled IO class
implementations (otherwise it's a bug), and so should it preferably on
third-party IO class implementations.
There are some questions about close().
1. If object owns several resources, shou
I like programming languages in which all are expressions (including
function declarations, branching and loops) and you can use an
assignment at any point, but Python is built on other ways, and I like
Python too. PEP 572 looks violating several Python design principles.
Python looks simple la
04.07.18 00:51, Chris Angelico пише:
On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka wrote:
I believe most Python users are not
professional programmers -- they are sysadmins, scientists, hobbyists and
kids --
[citation needed]
I don't understand what citation do you need.
04.07.18 03:24, INADA Naoki пише:
I feel PEP 572 breaks border between expression and statement, and it makes
readability of dirty code worse.
Thank you, this is what I meant.
On the other hand, I understand PEP 572 allows clever code simplifies
tedious
code. It may increase readability of
04.07.18 04:26, Tim Peters пише:
I really don't know what Guido likes best about this, but for me it's
the large number of objectively small wins in `if` and `while`
contexts. They add up. That conclusion surprised me. That there are
occasionally bigger wins to be had is pure gravy.
Could
04.07.18 04:54, Terry Reedy пише:
Would (f(x),) be faster?
No. Both "for y in [f(x)]" and "for y in (f(x),)" are compiled to the
same bytecode. Run your microbenchmarks again, the difference is a small
random variation.
https://bugs.python.org/issue32925
stuff = [[y := f(x), x/y] for x in
04.07.18 05:42, Steven D'Aprano пише:
On Tue, Jul 03, 2018 at 09:54:22PM -0400, Terry Reedy wrote:
results = [(x, y, x/y) for x in input_data for y in [f(x)] if y > 0]
Would (f(x),) be faster?
There is a deferred feature request to optimize "for x in [item]" as
equivalent to "for x in (
gt; occasionally bigger wins to be had is pure gravy.
[Serhiy Storchaka]
> Could you please show me several examples in real code? I
> have not seen any win yet.
My PEP Appendix was derived entirely from looking at real code. If you
don't believe the examples I showed there are win
05.07.18 01:51, Victor Stinner пише:
== Pattern 1, straighforward ==
while True:
line = input.readline()
if not line:
break
...
IMHO here assingment expression is appropriate here. The code remains
straighfoward to read.
while (line := input.readline()):
...
We a
05.07.18 03:03, Victor Stinner пише:
+labels = [slabel for label
+ in self._file.readline()[1:].split(b',')
+ if (slabel := label.strip())]
labels = [slabel for label
in self._file.readli
04.07.18 15:05, Nick Coghlan пише:
So my guess would be that this is a test suite error where we're not
handling the "running in a reproducible build environment with
SOURCE_DATE_EPOCH already set" case.
Should SOURCE_DATE_EPOCH be documented together with
PYTHONDONTWRITEBYTECODE?
__
05.07.18 17:53, Jeroen Demeyer пише:
In other words: I see nothing to improve in the calling convention of
METH_FASTCALL. I suggest to keep it and make it public as-is.
You have considered the bytecode for calling functions, but this
actually is not directly related to the calling convention.
12.07.18 08:43, INADA Naoki пише:
I'm working on making pyc stable, via stablizing marshal.dumps()
https://bugs.python.org/issue34093
This is not enough for making pyc stable. The order in frozesets still
is arbitrary.
Sadly, it makes marshal.dumps() 40% slower.
Luckily, this overhead is sm
Recently Barry shown an example:
assert len(subdirs := list(path.iterdir())) == 0, subdirs
It looks awful to me. It looks even worse than using asserts for
validating the user input. The assert has a side effect, and it depends
on the interpreter option (-O). Even if subdirs is not used ou
17.07.18 17:59, Guido van Rossum пише:
The PEP has no specific opinion except it is not forbidden.
Personally I like Barry's example just fine -- assuming `subdirs` is not
used later, this feels like a good use case.
Shouldn't this problem be solved in the same way as for comprehensions?
Shou
17.07.18 18:48, Guido van Rossum пише:
On Tue, Jul 17, 2018 at 8:28 AM, Serhiy Storchaka <mailto:storch...@gmail.com>> wrote:
Should not the assert statement introduce an implicit lexical scope
for preventing leaking variables?
I don't see why. As Chris said, side effects
17.07.18 19:25, Tim Peters пише:
It is a win (to my eyes) if the code it replaced was
if __debug__:
subdirs = list(path.iterdir())
assert len(subdirs) == 0, subdirs
in which case the semantics are the same in either spelling, with or
without -O, but the spelling at the t
25.07.18 18:07, Tim Golden пише:
I'm just easing back into core development work by trying to get a
stable testing environment for Python development on Windows.
One problem is that certain tests use support.TESTFN (a local directory
constructed from the pid) for output files etc. However this
Currently C API is not completely covered by tests. Tests for particular
parts of C API are scattered through different files. There are files
completely purposed for testing C API (like test_capi.py,
test_getargs2.py), there are classes (usually having "CAPI" in the name)
in different files fo
29.07.18 15:39, Steve Dower пише:
On 29Jul2018 1253, Serhiy Storchaka wrote:
The benefit is that it will be easier to run all C API tests at once,
and only them, and it will be clearer what C API is covered by tests.
The disadvantage is that you will need to run several files for
testing
30.07.18 09:46, Raymond Hettinger пише:
I prefer the current organization that keeps the various tests together with
the category being tested. I almost never need to run the C API tests all at
once, but I do need to see all the tests for an object in one place. When
maintaining something li
06.08.18 08:13, Stephen McDowell пише:
I've looked at the C code for a while and it is entirely non-obvious
what would lead to python *2* /allowing/ >255 arguments. Anybody happen
to know how / why the python *2* versions *succeed*?
The error message is misleading. It should be "more than 255
11.08.18 23:08, Santiago Basulto пише:
Hello folks! I'm using the `concurrent.futures.ProcessPoolExecutor` with
a couple of functions that have been decorated with a class decorator.
Both `concurrent.futures` and `multiprocessing` breaks because "the
object's can't be pickled". There's a really
20.08.18 18:18, Paul Moore пише:
I expect that PR suggesting some improvements to the documentation
would be very welcome - in particular, the section would almost
certainly benefit from some examples. If that's something you'd feel
comfortable doing, that would be great.
There is an open docum
05.09.18 13:10, Evpok Padding пише:
According to the [doc][1], `collections.Counter` convenience
intersection and union functions are meant to help it represent
multisets. However, it currently lacks comparisons, which would make
sense and seems straightforward to implement.
Am I missing somet
12.09.18 01:23, Victor Stinner пише:
But then Petr Viktorin asked me to open a thread on python-dev to get
a wider discussion. So here I am.
Thank you for opening this discussion Victor. I wanted to do it myself,
but you have wrote much better description of the problem. See also
related issu
12.09.18 01:34, Miss Islington (bot) пише:
https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56
commit: d13e59c1b512069d90efe7ee9b613d3913e79c56
branch: master
author: Benjamin Peterson
committer: Miss Islington (bot)
<31488909+miss-isling...@users.noreply.github.co
04.10.18 11:56, Steven D'Aprano пише:
While keyword arguments have to be identifiers, using **kwargs allows
arbitrary strings which aren't identifiers:
py> def spam(**kwargs):
print(kwargs)
py> spam(**{"something arbitrary": 1, '\n': 2})
{'something arbitrary': 1, '\n': 2}
There
10.10.18 05:12, Benjamin Peterson пише:
On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote:
On Oct 9, 2018, at 16:21, Steven D'Aprano wrote:
On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote:
My feeling is that limiting it to strings is fine, but checking those
strings for rese
Currently the PyUnicode object contains two caches: for UTF-8
representation and for wchar_t representation. They are needed not for
optimization but for supporting C API which returns borrowed references
for such representations.
The UTF-8 cache always was in unicode objects (but in Python 2
20.10.18 04:08, Victor Stinner пише:
Le ven. 19 oct. 2018 à 19:01, Stephane Wirtel a écrit :
total: 49 PRs
is:open is:pr review:approved status:success label:"awaiting merge" -label:"DO-NOT-MERGE"
label:""LA signed""
I merged many PRs and closed a few (2 if I recall correctly). Your
query no
20.10.18 16:01, Stefan Behnel пише:
But regarding the use under Windows, I
wonder if there's interest in keeping it as a special Windows-only feature,
e.g. to speed up the data exchange with the Win32 APIs. I guess it would
have to provide a visible (performance?) advantage to justify such specia
22.10.18 11:09, Victor Stinner пише:
+1 to remove wchar_t cache. IMHO it wastes memory for no real performance gain.
By the way, can we start to schedule the *removal* of the Py_UNICODE
API? For example, decide when Py_DEPRECATED is used in the C API?
Should we start to deprecate when Python 2 r
22.10.18 16:24, Steve Dower пише:
Yes, that's true. But "should reduce ... footprint" is also an
optimisation that deserves a benchmark by that standard. Also, I'm
proposing keeping the 'kind' as UCS-2 when the string is created from
UCS-2 data that is likely to be used as UCS-2. We would not c
22.10.18 23:41, Steve Dower пише:
That said, I didn't remove the wchar_t cache (though I tried some tricks
to avoid it), so it's possible that once that's gone we'll see an
avoidable regression here, but on its own this doesn't contribute much.
Could you please test PR 2599 on Windows? It make
When you try to to pickle or copy a non-pickleable object, you will get
an error. In most cases this will be a TypeError with one of few
similar, but different variants:
"can't pickle XXX objects" (default)
"Cannot serialize XXX object" (socket, BZ2Compressor, BZ2Decompressor)
"can not se
29.10.18 23:17, MRAB пише:
1. If you're pickling, then saying "pickle" is more helpful.
2. In English the usual long form is "cannot". Error messages tend to
avoid abbreviations, and also tend to have lowercase after the colon, e.g.:
"ZeroDivisionError: division by zero"
"ValueErro
04.11.18 17:00, Julien Palard via Python-Dev пише:
Considering feedback from Ned, what about building this as an independent
service? We don't really need to interface with python.org at all, we just need
some hardware, a domain, some code to interface with github API and... to start
it's prob
09.11.18 13:05, Steven D'Aprano пише:
py> x = cast_int2float(0x7ff1)
py> x
nan
py> hex(cast_float2int(x))
'0x7ff80001'
I got '0x7ff1'.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
04.12.18 21:13, Chris Withers пише:
I'd like to see if I can help with unittest.mock, but don't have a huge
amount of bandwidth and can't even parse let alone process the whole
firehose of bpo and GH PRs.
Is there any way I can get bugs.python.org and github PRs to only tell
me about things,
04.12.18 10:42, Ned Deily пише:
A reminder: as previously announced, 3.6.8 is planned to be the last bugfix release of the 3.6
series. Python 3.6.0 was released on 2016-12-23, so by the time 3.6.8 is released, 3.6.x will have
been in bugfix mode almost exactly 2 years. When a new feature rele
19.12.18 19:01, Chris Barker - NOAA Federal via Python-Dev пише:
3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several
important syntax features it can be a minimal required version for long time.
Which is a good argument for why we may not need longer term support
for 3
06.01.19 13:10, Paul Sokolovsky пише:
Storing None looks superfluous. For example, DELETE_FAST explicitly
stores NULL on delete.
https://github.com/python/cpython/blob/master/Python/ceval.c#L2249
Likewise, for DELETE_NAME/DELETE_GLOBAL, PyObject_DelItem() is
called which translates to:
m->mp_as
06.01.19 17:35, Chris Angelico пише:
On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka wrote:
Because there is a reason for such code.
What reason though??
I added references and excerpts in the previous message.
In short, the code
try:
1/0
except Exception as e
06.01.19 18:05, Chris Angelico пише:
Which I read, and they do not explain the assignment of None. The only
reference is that the tracker issue mentions having a test case to
ensure that it's happening, which is further proof that it's
intentional, but still fails to explain *why*.
This is expl
10.01.19 18:54, Kuhl, Brian пише:
The changes to Python are not large, I've kept the pull request from last
year's POC active. The changed files provide a good summary of the scope.
https://github.com/python/cpython/pull/4184/files
To prepare this PR for review the following changes are requir
I have virtually completely lost the sight of my right eye (and the loss
is quickly progresses) and the sight of my left eye is weak. That is why
my activity as a core developer was decreased significantly at recent
time. My apologies to those who are waiting for my review. I will do it
slowly.
Thank you very match, all who have expressed compassion here and
privately. I am very touched. It at least helped me feel a little better
psychologically.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
20.02.19 17:01, Stephane Wirtel пише:
As you know, Python 3.4 and 3.5 are in security mode and the EOL for
these versions are respectively 2019-03-16 and 2020-09-13.
Number of issues
3.4: 1530 issues
3.5: 1901 issues
But some issues are not related to the security.
Could we update these issue
18.02.19 18:16, Rémi Lapeyre пише:
The documentation mentions at
https://docs.python.org/3/reference/datamodel.html#object.__index__
the need to always define both __index__ and __int__:
Note: In order to have a coherent integer type class, when
__index__() is defined __int__() should als
PEP 530 introduced support for asynchronous comprehensions.
Comprehensions are implemented as local functions. To make a function
asynchronous you should to add "async" before "def", and after that you
can use "async for", "async with" and "await" in a function. But you can
to do this with com
07.03.19 11:18, Inada Naoki пише:
So what should we do about optionxform?
a) Document "optionxform must be idempotent".
b) Ensure all APIs calls optionxform exactly once, and document
"When you get option name from section objects, it is already
optionxform-ed. You can not reuse the
19.03.19 00:41, Raymond Hettinger пише:
3) Add a standards compliant canonicalization tool (see
https://en.wikipedia.org/wiki/Canonical_XML ). This is likely to be the
right-way-to-do-it but takes time and energy.
4) Fix the tests in the third-party modules to be more focused on their actual
19.03.19 13:53, Ned Batchelder пише:
Option 4 is misleading. Is anyone here really offering to "fix the
tests in third-party modules"? Option 4 is actually, "do nothing, and
let a multitude of projects figure out how to fix their tests, slowing
progress in those projects as they try to suppor
19.03.19 14:50, Antoine Pitrou пише:
2). Go into every XML module and add attribute sorting options to each function
that generate xml.
What do you mean with "every XML module"? Are there many of them?
ElementTree and minidom. Maybe xmlrpc. And perhaps we need to add
arguments in calls at h
19.03.19 15:10, Tim Delaney пише:
Now Calibre is definitely in the wrong here - it should be able to
import regardless of the order of attributes. But the fact is that there
are a lot of tools out there that are semi-broken in a similar manner.
Is not Calibre going to seat on Python 2 forever?
19.03.19 15:03, Stéphane Wirtel пише:
Suggestion and timeline:
3.8, we raise a PendingDeprecationWarning
* update the code
* update the documentation
* update the tests
(check a PendingDeprecationWarning if sys.version_info == 3.8)
3.9, we change PendingDeprecationWarning
19.03.19 20:55, Raymond Hettinger пише:
I'm working on ways to make improve help() by giving docstrings to member
objects.
One way to do it is to wait until after the class definition and then make
individual, direct assignments to __doc__ attributes.This way widely the
separates docstrings f
19.03.19 16:21, Paul Ganssle пише:
I'm not sure the relationship with mkdir and mktemp here. I don't see
any uses of tempfile.mktemp in pip or setuptools, though they do use
os.mkdir (which is not deprecated).
Both pip and setuptools use pytest's tmpdir_factory.mktemp() in their
test suites, but
19.03.19 15:39, Antoine Pitrou пише:
The fact that many projects, including well-maintained ones such Sphinx
or pip, use mktemp(), may be a hint that replacing it is not as easy as
the people writing the Python documentation seem to think.
Sorry, it was my mistake (searching mkdir instead of mk
22.03.19 04:41, Inada Naoki пише:
I'm thinking about removing PendingDeprecationWarning.
(previous discussion:
https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038)
It was added "not be printed by default" version of DeprecationWarning.
But DeprecationWarning is not print
22.03.19 09:31, Greg Ewing пише:
A poster on comp.lang.python is asking about array.array('u').
He wants an efficient mutable collection of unicode characters
that can be initialised from a string.
According to the docs, the 'u' code is deprecated and will be
removed in 4.0, but no alternative i
22.03.19 09:45, Victor Stinner пише:
Internally, CPython has a _PyUnicodeWriter which is an efficient way
to create a string but appending substrings or characters.
_PyUnicodeWriter changes the internal storage format depending on
characters code points (ascii or latin1: 1 byte/character, BMP: 2
22.03.19 12:51, Jeroen Demeyer пише:
On 2019-03-22 11:33, Serhiy Storchaka wrote:
What is wrong with PendingDeprecationWarning?
It serves the same purpose as DeprecationWarning: it indicates that a
feature is planned to be removed in the future. There is no point in
having two warnings with
22.03.19 13:23, Inada Naoki пише:
On Fri, Mar 22, 2019 at 7:36 PM Serhiy Storchaka wrote:
What is wrong with PendingDeprecationWarning? What problem do you want
to solve at the cost of removing this feature?
The main problem is complexity. In other words, learning cost.
Do you have
22.03.19 13:33, Antoine Pitrou пише:
On Fri, 22 Mar 2019 13:27:08 +0200
Serhiy Storchaka wrote:
Making it always 32 bits would be compatibility breaking change.
Currently array('u') represents the wchar_t string, and many API on
Windows require it.
The question is: why would
05.04.19 09:07, Jeroen Demeyer пише:
On 2019-04-05 00:57, Greg Ewing wrote:
If it's designed for use by things outside of CPython, how
can you be sure nothing is using it?
Of course I'm not sure. However:
1. So far, nobody in this thread knows of any code using it.
2. So far, nobody in this
05.04.19 14:27, Jeroen Demeyer пише:
On 2019-04-05 14:10, Serhiy Storchaka wrote:
it can be used to
implement accelerated versions of separate methods instead of the whole
class.
Could you elaborate? I'm curious what you mean.
It is easy to implement a function in C. But there
05.04.19 15:33, Jeroen Demeyer пише:
On 2019-04-05 15:13, Serhiy Storchaka wrote:
It is easy to implement a function in C.
Why does it need to be a PyCFunction? You could put an actual method
descriptor in the class. In other words, use PyDescr_NewMethod() instead
of PyCFunction_New
05.04.19 20:56, Jeroen Demeyer пише:
On 2019-04-05 19:53, Serhiy Storchaka wrote:
At Python level we can monkeypatch __gt__, but not tp_richcompare.
Sure, but you're planning to use C anyway so that's not really an argument.
total_ordering monkeypatches the decorated class. I
10.04.19 14:01, Victor Stinner пише:
Disabling Py_TRACE_REFS by default in debug mode reduces the Python
memory footprint. Py_TRACE_REFS costs 2 pointers per PyObject: 16
bytes on 64-bit platforms.
Does not the memory allocator in debug mode have even larger cost per
allocated block?
___
11.04.19 12:28, Victor Stinner пише:
Le jeu. 11 avr. 2019 à 07:49, Serhiy Storchaka a écrit :
10.04.19 14:01, Victor Stinner пише:
Disabling Py_TRACE_REFS by default in debug mode reduces the Python
memory footprint. Py_TRACE_REFS costs 2 pointers per PyObject: 16
bytes on 64-bit platforms
12.04.19 17:40, Guido van Rossum пише:
So let's leave it off
by default even in debug builds. But let's not delete the macros.
Maybe switch it on (together with other disabled by default options) on
some fast buildbot?
___
Python-Dev mailing list
P
12.04.19 16:44, Inada Naoki пише:
When creating many dicts with same keys, dict need to
lookup internal hash table while inserting each keys.
It is costful operation. If we can reuse existing keys of dict,
we can skip this inserting cost.
Additionally, we have "Key-Sharing Dictionary (PEP 412)
12.04.19 19:17, Inada Naoki пише:
Maybe, collections.DictBuilder may be another option. e.g.
from collections import DictBuilder
builder = DictBuilder(tuple("abc"))
builder.build(range(3))
{"a": 0, "b": 1, "c": 2}
Nitpicking: this is rather a factory than a builder. The difference
between
01.05.19 00:24, Chris Withers пише:
I have a crazy idea of getting unittest.mock up to 100% code coverage.
I noticed at the bottom of all of the test files in testmock/, there's a:
if __name__ == '__main__':
unittest.main()
...block.
How would people feel about these going away? I don't
01.05.19 10:09, Chris Withers пише:
Right, but that's not the documented way of running individual suites in
the devguide.
I'm happy to remove these on the basis that there should be one and only
one way of doing things like this.
This principle is not applicable here because the Python test
04.05.19 05:46, Eric V. Smith пише:
Is there a policy against using Unicode identifiers in test files?
As part of adding !d to f-strings, there's a code path that's only
executed if the text of the expression is non-ascii. The easiest way to
exercise it, and the way I found a bug, is by using
16.05.19 04:23, Victor Stinner пише:
The first implementation of my API used sys.unraisablehook(exc_type,
exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
to add a new error message field which breaks the API: the API is not
future-proof.
I modified my API to create an
16.05.19 13:12, Victor Stinner пише:
I came to the UnraisableHookArgs structseq idea because of my bad
experience with extension warnings "hooks". Let me tell you this story
:-)
I know this story, because I followed these issues.
For unraisable hook, it's not hard to imagine other useful para
20.05.19 16:25, Eric V. Smith пише:
I added an optional "expr_text" field to the FormattedValue node, which
represents the text of the expression in a "debug" f-string expression.
So in f'{x=}', expr_text would be "x=".
This strictly speaking isn't necessary. I could have added another
Consta
31.05.19 11:46, Petr Viktorin пише:
PEP 570 (Positional-Only Parameters) changed the signatures of
PyCode_New() and types.CodeType(), adding a new argument for "posargcount".
Our policy for such changes seems to be fragmented tribal knowledge. I'm
writing to check if my understanding is reasonab
05.06.19 12:08, Victor Stinner пише:
Our kind postmasters Mark Sapiro and Abhilash Raj migrated
python-ideas and python-dev mailing lists from Mailman 2 to Mailman 3
(running on Python 3 ;-))!
You can now enjoy HyperKitty, the new web UI to access the mailing lists:
https://mail.python.org/a
05.06.19 13:52, Serhiy Storchaka пише:
05.06.19 12:08, Victor Stinner пише:
Our kind postmasters Mark Sapiro and Abhilash Raj migrated
python-ideas and python-dev mailing lists from Mailman 2 to Mailman 3
(running on Python 3 ;-))!
You can now enjoy HyperKitty, the new web UI to access the
20.06.19 19:28, Victor Stinner пише:
Le jeu. 20 juin 2019 à 11:15, Inada Naoki a écrit :
Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII?
How would a developer detect a mistake (non-ASCII) character? Does
_PyUnicode_FromASCII() raise an exception, even in release mode?
The functi
22.06.19 01:08, Daniel Holth пише:
Thanks. I think I might like an option to disable str(bytes) without
disabling str != bytes. Unless the second operation would also corrupt
output.
Came across this kind of set in the hyper http library which uses a set
to accept certain headers with either
I thought that the name in a module is in the public interface if:
* It doesn't start with an underscore and the module does not have __all__.
* It is included in the module's __all__ list.
* It is explicitly documented as a part of the public interface.
help() uses more complex rules, but it be
14.07.19 05:09, Raymond Hettinger пише:
On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka wrote:
Could we strictly define what is considered a public module interface in Python?
The RealDefinition™ is that whatever we include in the docs is public,
otherwise not.
Beyond that, there is a
17.07.19 03:26, Brett Cannon пише:
I agree with Raymond that if the calendar module was following the leading
underscore practice (which we should probably encourage all new modules to
follow for consistency going forward) then I think the module should be updated
to keep the practice going.
Usually the order of operands of the == operator does not matter. bool(a
== b) should return the same as bool(b == a). Correct __eq__ should look
like:
def __eq__(self, other):
if not know how to compare with other:
return NotImplemented
return the result of comp
20.07.19 09:03, Kyle Stanley пише:
Rather than it being on a case-by-case basis, would it be reasonable to
establish a universal standard across stdlib for defining modules as public to
apply to older modules as well? I think that it would prove to be quite
beneficial to create an explicit def
20.07.19 18:26, Guido van Rossum пише:
In an ideal world, needle is on the right. Let's replace needle with a
constant: which of the following looks more natural?
for x in sequence:
if x == 5: return True
or
for x in sequence:
if 5 == x: return True
For me, 'x == 5' wins
22.07.19 11:04, Kyle Stanley пише:
Serhiy Storchaka wrote:
Thank you. The majority of the code uses needle on the right. There are
just 6 places where it is on the left, and the half of them look
copy-pasted, and in one place the C code differs from the corresponding
Python implementation
23.07.19 23:59, Kristian Klette пише:
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d = {'a': 1234}
d.keys() == d.keys()
d.items() == d.items()
```
but `d.values(
501 - 600 of 1152 matches
Mail list logo
