Jimmy Girardet schrieb am 04.03.19 um 10:12:
> I'm not old on this list but every time there is a proposal, the answer
> is "what are you trying to solve ?".
>
> Since
>
> |z ={**x,**y} and z.update(y) Exists, I can"t find the answer.
I think the main intentions is to close a gap in the language
James Lu schrieb am 04.03.19 um 03:28:
> I propose that the + sign merge two python dictionaries such that if there
> are conflicting keys, a KeyError is thrown.
Please, no. That would be really annoying.
If you need that feature, it can become a new method on dicts.
Stefan
__
Rémi Lapeyre schrieb am 01.03.19 um 16:44:
> Le 1 mars 2019 à 16:04:47, Stefan Behnel a écrit:
>> I think the behaviour makes sense when you know how it's implemented (keys
>> are stored separately from values).
>
> Is a Python user expected to know the implementati
Eric V. Smith schrieb am 01.03.19 um 15:49:
> I understand Inada to be saying that each value on the LHS (as shown above)
> affects the result on the RHS. That's the case with addition of ints and
> other types, but not so with the proposed dict addition. As he says, the
> {a:1} doesn't affect the
Rémi Lapeyre schrieb am 01.03.19 um 15:50:
> Le 1 mars 2019 à 15:41:52, Stefan Behnel a écrit:
>
>> Rémi Lapeyre schrieb am 01.03.19 um 15:06:
>>> I’m having issues to understand the semantics of d1 + d2.
>>>
>>> I think mappings are more complicated than
Rémi Lapeyre schrieb am 01.03.19 um 15:06:
> I’m having issues to understand the semantics of d1 + d2.
>
> I think mappings are more complicated than sequences it some things
> seems not obvious to me.
>
> What would be OrderedDict1 + OrderedDict2, in which positions would be
> the resulting keys
Anthony Flury via Python-list schrieb am 28.02.19 um 10:18:
> I am trying to write an extension module with a function (actually an
> __init__ method, but I am not sure that matters) where the function can be
> called as either :
>
> my_func()
>
> or
>
> my_func( a, b, c, d) - where a,b,
Stefan Behnel added the comment:
> We already have a syntax for dict merging: {**d1, **d2}.
Which doesn't mean that "d1 + d2" isn't much more intuitive than this
special-character heavy version. It takes me a while to see the dict merge
under that heap of stars.
Steve Dower schrieb am 19.02.19 um 21:40:
> On 19Feb2019 1212, Stefan Behnel wrote:
>> Then it's up to the users to decide
>> how much work they want to invest into keeping up with C-API changes vs.
>> potentially sub-optimal but stable C-API usage.
> [...]
> And it
Nick Coghlan schrieb am 19.02.19 um 15:00:
> On Tue, 19 Feb 2019 at 20:41, Antoine Pitrou wrote:
>> On Mon, 18 Feb 2019 19:04:31 -0800 Steve Dower wrote:
>>> If you always rebuild your extension for every micro version (3.x.y) of
>>> CPython, then sure, go ahead and use this.
>>
>> Usually we would
Stefan Behnel added the comment:
Well … yes.
The exception fields are performance critical, and we try hard to make them
visible to the C compiler so that swapping around exception state eats up as
little CPU time as possible.
You could argue that profiling and tracing are less critical
Stefan Behnel added the comment:
It turns out that "update_slot()" is always called, even when we are not
updating a slot name (which is always a special dunder-name). The linear search
for names in "update_slots()" is a huge waste of time here, and
short-circuiting out
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +11932
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36012>
___
___
Py
Change by Stefan Behnel :
--
pull_requests: +11931
___
Python tracker
<https://bugs.python.org/issue35884>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel schrieb am 16.02.19 um 22:39:
> - The list append/pop optimisations seem to slow down non-lists
> unproportionally, for deques by 3x compared to CPython. That seems worth
> improving.
>
> CPython 3.8 (63fa1cfece)
>
> Stack (or queue) op
Hi,
Raymond Hettinger wrote a micro benchmark script for comparing the
performance of basic attribute and item access patterns across Python
versions and build configurations, so I tested the initially committed
version with Cython.
https://github.com/python/cpython/blob/master/Tools/scripts/var_
Robert Bradshaw schrieb am 11.02.19 um 16:54:
> On Fri, Feb 8, 2019 at 12:45 PM Stefan Behnel wrote:
>> Robert Bradshaw schrieb am 06.02.19 um 10:37:
>>> Realistically, I think that if we don't support 2.7 in the 3.0
>>> release, we're signing up for maintaini
Stefan Behnel added the comment:
Oh, and I forgot the new trashcan support. Cython will also start to use that
in its next release, so that adds the trashcan related attributes to the list.
https://github.com/cython/cython/pull/2842/files
Stefan Behnel added the comment:
>From Cython's point of view, the important fields in PyThreadState are the
>tracing/profiling and exception related ones. We're not using anything else.
>Users can explicitly opt out of the access to the exception fields by defining
Stefan Behnel added the comment:
Adding Christian Tismer to the nosy list since he might be able to elaborate on
the impact on PySide (which IIRC uses the stable ABI, and thus, heap types).
--
components: +Extension Modules, Interpreter Core -Library (Lib)
nosy: +Christian.Tismer
Stefan Behnel added the comment:
Victor asked me for a review, so, well, what should I say? The intention seems
right, and the patch also looks good to me.
>From the top of my head, I wouldn't know any problems this would produce with
>Cython specifically, although it's wort
Stefan Behnel added the comment:
The overhead of calling PyErr_Occurred() is definitely negligible in something
as involved as PyDict_GetItemStringWithError(), where a mere key lookup first
has to fire up the string decoder on a C character buffer to create a new
string object and then
Barry Scott schrieb am 10.02.19 um 13:08:
> After calling PyObject_GetAttrString() I expected to get a PyObject string
> back but I found that I had been given a instead.
>
> (gdb) p *args_o
> $4 =
>
> What is going on and how do I get from the to the object
> I
> want?
Phil is right abou
Hi everyone,
Cython 0.29.5 was released with an important bug fix for extension types
that have "cpdef" methods. If they get subclassed by Python classes that do
not define additional attributes (or anything that would require them to
have an instance `__dict__`), then calling the cpdef-methods re
Eric V. Smith schrieb am 03.02.19 um 23:41:
>> On Feb 3, 2019, at 5:31 PM, James Lu wrote:
>> https://www.python.org/download/alternatives/ should possibly mention:
>> - Mention the possibility of compiling Python to WASM
>>- WASM allows Web and Mobile use of Python at possibly native speed.
Chris Angelico schrieb am 03.02.19 um 02:23:
> Of course, you can also precompute this:
>
> day_ordinal = mapper(
> [1, 21, 31], "st",
> [2, 22], "nd",
> [3, 23], "rd",
> )
> def f(x): return day_ordinal.get(x, "th")
… in which case I would also 'precompute' the ".get" and
Stefan Behnel schrieb am 02.02.19 um 12:22:
> We currently support Py3.3+ for Py3. Py3.4 is expected to reach its EOL
> in March, but still seems worth supporting for another while. Not sure
> about 3.3, probably an "as long as it doesn't hurt" case.
Actually, I just
[CC-ing cython-devel, but please keep the discussion on cython-users]
Hi all,
we were recently asked on the bug tracker [1] when Cython is planning to
end its support for Python 2.x, so I'd like to get some more user opinions
on this.
We are planning to release Cython 3.0 this year [2], with som
James Lu schrieb am 01.02.19 um 17:40:
> A lot of the traffic on this email list is people saying “I don’t understand”
> or “that’s not what I meant” or trying to re-explain. A lot of “-1”s are
> really “I don’t see the usefulness of this”.
>
> So I want an open discussion on: How can we communi
Hi all,
I just released Cython 0.29.4 with an important bug fix(*) for division
operations that involve constant numerators. If the denominator turns out
to be zero at runtime, it could happen that no ZeroDivisionError gets
raised, and instead an arbitrary result returned.
https://github.com/cyth
MRAB schrieb am 29.01.19 um 19:55:
> On 2019-01-29 13:44, Nick Coghlan wrote:
>> FWIW, we have pretty decent evidence that error messages don't have to
>> provide a wonderful explanation on their own in order to be helpful:
>> they just need to be distinctive enough that a web search will
>> reliab
Stefan Behnel added the comment:
I think the REPL could, when it formats a stack trace for printing, check every
referenced source file if it's newer than its compiled .pyc (bytecode) file,
and insert a warning into the stack trace if that is the case.
I don't see any use in doin
Stefan Behnel added the comment:
It seems right that a heap allocate object owns a reference to its (non-static)
type. But the mere fact that you had to adapt stdlib code makes it obvious that
this will also break existing user code out there. And such breakage is very
likely to remain
Hi all,
there is currently a discussion on python-dev about letting the compiler
generate more SyntaxWarnings for "obviously unintended" code.
https://mail.python.org/pipermail/python-dev/2019-January/156113.html
Serhiy Storchaka has written a proof-of-concept patch for CPython here:
https://bu
Cameron Simpson schrieb am 23.01.19 um 00:21:
> from __future__ import absolute_imports, print_function
>
> gets you a long way.
... and: division.
Stefan
--
https://mail.python.org/mailman/listinfo/python-list
Change by Stefan Behnel :
--
title: XML.etree bug -> iterparse does not return the full subtree on "start"
events
type: performance -> behavior
___
Python tracker
<https://bugs.py
Stefan Behnel added the comment:
This is not a bug, it's normal, documented behaviour. The children are not
guaranteed to be available during the "start" event. Only the tag itself is
guaranteed to be there. The guarantee that the subtree is complete is only
given for the &q
Stefan Behnel added the comment:
Nice! Well done, Serhiy!
--
___
Python tracker
<https://bugs.python.org/issue35582>
___
___
Python-bugs-list mailing list
Unsub
Stefan Behnel added the comment:
It might be worth inlining a fast path of "_PyArg_CheckPositional()" that only
tests "nargs < min || nargs > max" (even via a macro), and then branches to the
full error checking and reporting code only if that fails. Determining
Change by Stefan Behnel :
--
nosy: +scoder -scode
___
Python tracker
<https://bugs.python.org/issue35582>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer schrieb am 09.01.19 um 15:43:
> (reviving this thread after I thought about it some more...)
>
> As I mentioned in the original post, I want something like __dealloc__ but
> with access to a particular cdef attribute (representing a Python object).
> Since Python attributes of cdef
Stefan Behnel added the comment:
> maybe this can be changed in Python 4.0
Well, if you find a *very* good reason for changing it, as I said. Py4 won't be
special in that regard, I suppose.
--
___
Python tracker
<https://bugs
Stefan Behnel added the comment:
> why bytes and str generates the same hash value for ASCII sequence
Probably mostly for historical Py2 reasons. These days, both are somewhat
unlikely to appear in the same dict. But still, I'd advise against changing the
hash function without a v
Stefan Behnel added the comment:
Unlikely to get changed in Py3.4/5 anymore, since this is not even a bug fix. I
wouldn't even fight for backporting, although 3.7 seems ok for it.
I agree that this code duplication is worth removing. I don't consider hashing
the empty string
Ma Lin schrieb am 31.12.18 um 14:02:
> On 18-12-31 19:47, Antoine Pitrou wrote:
>> The complaint is that the global cache is still too costly.
>> See measurements in https://bugs.python.org/issue35559
>
> In this issue, using a global variable `_has_non_base16_digits` [1] will
> accelerate 30%.
>
Hi!
Nice idea.
Prakhar Goel schrieb am 29.12.18 um 15:02:
> I wanted to test the waters on this idea.
>
> The idea is to allow debugging Cython programs with PDB. This relies
> on making call-backs to trigger the sys.trace functionality every now
> and then. It is very similar to how profiling i
Stefan Behnel added the comment:
I have no doubts that the code is right. However, your expectations might not
be.
Try to print the values inside of the loop, for each iteration, as well as
their type. You'll likely be surprised what that gives.
(In any case, this is not a bug. If you
Ma Lin schrieb am 27.12.18 um 14:15:
>> It'd be good to know just how much benefit this precompilation actually
> grants.
>
> As far as I know, Pattern objects in regex module can be pickled, don't
> know if it's useful.
>
import pickle
import regex
That's from the external regex packa
Stefan Behnel added the comment:
I agree with Antoine. After all, we are optimising a safety check here that
runs in linear time. If people want speed, they should consider methods that do
not do this check in the first place.
--
___
Python
Stefan Behnel added the comment:
Thanks for your review and ideas, Serhiy. I added a couple of test cases, but
failed to find any case where the new implementation is not much faster.
I also tried "divmod(n_div, d_div)" for implementing __divmod__(), and the
results are
Stefan Behnel added the comment:
Sure, I can add tests, but I wonder what kind of regression you expect. The
algorithm is still the same as before, it's just implemented more efficiently.
It does trade a bit of memory for the speed, though, since there is no longer
an interme
Stefan Behnel added the comment:
Motivation for the latter:
$ ./python -m timeit -s 'from fractions import Fraction as F; a = F(-7, 3); b =
F(3, 2)' 'a // b'
10 loops, best of 5: 3.7 usec per loop
$ ./python -m timeit -s 'from fractions import Fraction as F;
Stefan Behnel added the comment:
Similarly, I think "//" (__floordiv__) should be implemented using integer
operations rather than math.floor():
(a.numerator * b.denominator) // (b.numerator * a.denominator)
Thoughts?
--
___
Pyth
Change by Stefan Behnel :
--
nosy: +mark.dickinson, serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue35588>
___
___
Python-bugs-list mailin
Change by Stefan Behnel :
--
keywords: +patch, patch, patch
pull_requests: +10582, 10583, 10584
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
keywords: +patch, patch
pull_requests: +10582, 10583
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +10582
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35588>
___
___
Py
New submission from Stefan Behnel :
Spelling out the numerator/denominator calculation in the __mod__ special
method, and actually implementing __divmod__, speeds up both operations by
2-3x. This is due to avoiding repeated Fraction instantiation and
normalisation, as well as less arithmetic
Avi Gross schrieb am 17.12.18 um 01:00:
> SHORT VERSION: a way to automatically run multiple algorithms in parallel
> and kill the rest when one returns an answer.
One (somewhat seasonal) comment on this: it doesn't always have to be about
killing (processes or threads). You might also consider a
Anthony Flury via Python-list schrieb am 21.12.18 um 09:06:
> I thought I would look at a side by side comparison of CPython, nuitka and
> PyPy
Interesting choice. Why nuitka?
> *The functionality under test*
>
> I have a library (called primelib) which implements a Sieve of Erathoneses
> in pu
Paulo da Silva schrieb am 22.12.18 um 19:26:
> Sorry if this is OT.
>
> I decided to give cython a try and cannot run a very simple program!
>
> 1. I am using kubuntu 18.04 and installe cython3 (not cython).
>
> 2. My program tp.pyx:
>
> # cython: language_level=3
> print("Test",2)
>
> 3. setu
Nikolai Weibull schrieb am 24.12.18 um 12:00:
> Stefan Behnel, 2018-12-24 11:43:
>> Nick Wellnhofer schrieb am 19.12.18 um 17:02:
>>> On 30/11/2018 11:41, Nikolai Weibull via xml wrote:
>>>> OK, now I understand why it was working in my copy of the repository and
Nick Wellnhofer schrieb am 19.12.18 um 17:02:
> On 30/11/2018 11:41, Nikolai Weibull via xml wrote:
>> OK, now I understand why it was working in my copy of the repository and
>> not yours. Something went wrong when you applied the patch, Daniel, as a
>> line was elided. Here’s a fix. We want to
Stefan Behnel added the comment:
One regex related code pattern that I generally like is to assign bound methods
to good names and use those. In this case, I would write
_has_non_base16_digits = re.compile(b'[^0-9A-F]').search
...
if _has_non_base16_digits(s):
raise ...
-
Ricardo Dias schrieb am 11.12.18 um 23:16:
> On 11/12/18 19:39, Stefan Behnel wrote:
>> Ricardo Dias schrieb am 10.12.18 um 14:42:
>>> In the recent Cython 0.29 version was introduced a commit [1] that
>>> hinders the usage of python subinterpreters.
>>>
>
Ricardo Dias schrieb am 10.12.18 um 14:42:
> In the recent Cython 0.29 version was introduced a commit [1] that
> hinders the usage of python subinterpreters.
>
> I discovered this the hard way when suddenly a component I was working
> on started to crash. The component in question is the ceph-mgr
Stefan Behnel added the comment:
If this is really just about debugging, then I would suggest to not break
existing code at all.
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue35
Stefan Behnel added the comment:
What exactly is the problem here? encoding='unicode' will never appear in the
XML declaration, and thus will never be "presented to XML processors". It is up
to the user to deal with encodings in this case, which I think is fine. It'
Daniel Veillard schrieb am 29.11.18 um 21:20:
> On Mon, Nov 26, 2018 at 11:48:37AM +0100, Nikolai Weibull via xml wrote:
>> Stefan Behnel, 2018-11-25 15:37:
>>> Nikolai Weibull schrieb am 24.11.18 um 00:12:
>>>> Yes, it seems that my patch for data in interleaves was
Armin Rigo schrieb am 26.11.18 um 06:37:
> On Sun, 25 Nov 2018 at 10:15, Stefan Behnel wrote:
>> Overall, this seems like something that PyPy could try out as an
>> experiment, by just taking a simple extension module and replacing all
>> increfs with newref assignments. And o
Nikolai Weibull schrieb am 24.11.18 um 00:12:
> Yes, it seems that my patch for data in interleaves was added and this may
> be the cause of these issues. The regression tests didn’t display them, so
> this is something different. Could we perhaps get a minimal test that breaks?
Here is what I c
Nikolai Weibull schrieb am 24.11.18 um 00:12:
> Yes, it seems that my patch for data in interleaves was added and this may
> be the cause of these issues. The regression tests didn’t display them, so
> this is something different. Could we perhaps get a minimal test that breaks?
It's a bit trick
Hi Armin,
Armin Rigo schrieb am 25.11.18 um 06:15:
> On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote:
>> Couldn't this also be achieved via reference counting? Count only in C
>> space, and delete the "open object" when the refcount goes to 0?
>
> The point
Armin Rigo schrieb am 23.11.18 um 14:15:
> In PyPy we'd have a global table of
> "open objects", and a handle would be an index in that table; closing
> a handle means writing NULL into that table entry. No emulated
> reference counting needed: we simply use the existing GC to keep alive
> objects
Salut Daniel!
Daniel Veillard via xml schrieb am 22.11.18 um 18:32:
> I have just tagged the Release Candidate 1 in git and pushed a signed
> tarball and signed rpms to the usual place:
>
> ftp://xmlsoft.org/libxml2/
I think something changed in the RelaxNG code. When I try to validate a
sim
Gregory P. Smith schrieb am 15.11.18 um 01:03:
> From my point of view: A static inline function is a much nicer modern code
> style than a C preprocessor macro.
It's also slower to compile, given that function inlining happens at a much
later point in the compiler pipeline than macro expansion. T
Neil Schemenauer schrieb am 17.11.18 um 00:10:
> I think making PyObject an opaque pointer would help.
... well, as long as type checks are still as fast as with "ob_type", and
visible to the C compiler so that it can eliminate redundant ones, I
wouldn't mind. :)
> - Borrowed references are a pr
Stefan Behnel added the comment:
Making _PyGC_FINALIZED() internal broke Cython
(https://github.com/cython/cython/issues/2721). It's used in the finaliser
implementation
(https://github.com/cython/cython/blob/da657c8e326a419cde8ae6ea91be9661b9622504/Cython/Compiler/ModuleNode.py#L1442-
Stefan Behnel added the comment:
> Maybe some people prefer sorting to get a more deterministic output
Note that those people are much better off with C14N. It is the one tool
designed for all of these use cases, even usable for cryptographic signatures.
And it's trivial to use, it&
Robert Bradshaw schrieb am 24.10.2018 um 01:44:
> On Tue, Oct 23, 2018 at 10:22 PM Stefan Behnel wrote:
>> My guess is that MinGW is just fairly rarely used to build CPython
>> extensions overall.
>>
>>> but perhaps we should even consider releasing bugfixes fo
Robert Bradshaw schrieb am 22.10.2018 um 11:03:
> Given that https://bugs.python.org/issue4709 results in extension
> modules that seem to work, but silently produce completely incorrect
> answers, I'm thinking we should either disable our long-unpacking code
> on these platforms, or at the very le
Stefan Behnel added the comment:
The relevant macro seems to be "__MINGW64__". I have neither a Windows
environment nor MinGW-64 for testing, but the logic should be the same as for
the "_WIN64" macro, i.e.
#if defined(_WIN64) || defined(__MINGW64__)
#define MS_WI
Jeroen Demeyer schrieb am 21.10.2018 um 12:47:
> On 2018-10-16 20:30, Stefan Behnel wrote:
>> Difficult to say why this would fail to find the package. Could it be an
>> import path problem? Current directory missing from the PYTHONPATH or
>> something like that?
>
> Th
Stefan Behnel added the comment:
> There's PyLong_GetInfo ...
Thanks, I understand that this information can be found at runtime. However, in
order to correctly compile C code against a given CPython runtime, there needs
to be a guarantee that extension module builds use
Stefan Behnel added the comment:
Some more information. CPython uses this code snippet to decide on the PyLong
digit size:
#ifndef PYLONG_BITS_IN_DIGIT
#if SIZEOF_VOID_P >= 8
#define PYLONG_BITS_IN_DIGIT 30
#else
#define PYLONG_BITS_IN_DIGIT 15
#endif
#endif
In MinGW, "SIZEOF_VOID
New submission from Stefan Behnel :
I see reports from Cython users on Windows-64 that extension modules that use
"longintrepr.h" get miscompiled by MinGW. A failing setup looks as follows:
Stock 64 bit CPython on Windows, e.g.
Python 3.6.3 (v3.6.3:2c5fed8, Oct 3 2017, 18:11:49) [
Serhiy Storchaka schrieb am 20.10.2018 um 13:06:
> 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 UT
Stefan Behnel added the comment:
Well, if that's what it takes, then that's what it takes. I'm fine with the
change. The (unaccelerated) ET doesn't strictly require it, but a) I can't
really see a use case for non-Element classes in the tree, b) pretty much
no
Hi,
after half a year of development, many community pull requests and a lot of
feedback and good ideas in online discussions and at conferences, I'm proud
to announce the release of Cython 0.29.
What is Cython?
In case you didn't hear about Cython before, it's the most widely used
statically opt
Jeroen Demeyer schrieb am 16.10.2018 um 12:42:
> I'm getting various reports of the test reimport_from_subinterpreter
> failing (within Sage, Cython 0.29, Python 2.7.15).
>
> Annoyingly, the problem can only be reproduced when running the full Cython
> testsuite, not when running the test in isola
Dear Cythonistas,
after half a year of development, many community pull requests and a lot of
feedback and good ideas in online discussions and at conferences, I'm proud
to release Cython 0.29. This is a major feature release that comes with
many great improvements and several important bug fixes.
Stefan Behnel added the comment:
If I understand the code right, "PY_SSIZE_T_MAX/sizeof(Py_UCS4)" would not be
correct since it would unnecessarily limit the length of ASCII-only unicode
strings.
I think the initial check avoids the risk of integer overflow in the
calculations
https://github.com/cython/cython/archive/0.29rc2.tar.gz
Updated changelog:
https://github.com/cython/cython/blob/0.29rc2/CHANGES.rst
Stefan
Stefan Behnel schrieb am 16.09.2018 um 17:48:
> Hi all,
>
> after half a year of development, many community pull requests and a lot of
>
Stefan Behnel schrieb am 21.09.2018 um 09:38:
> There are two parts of
> information here, so maybe we should actually split them internally (in
> "Main.Context.set_language_level() ?) and keep the language_level = 3 but
> just avoid the "unicode_literals" part.
I t
Change by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue34776>
___
___
Python-bugs-list mailing list
Unsubscribe:
John Ehresman schrieb am 25.09.2018 um 16:27:
> On 9/25/18 1:24 AM, Stefan Behnel wrote:
>> I started off with "unicode_literals=False", and then renamed it because
>> this name didn't cover the change of "str" to "unicode" (i.e. renaming the
>
Daniele Nicolodi schrieb am 25.09.2018 um 00:28:
> On 24-09-2018 14:05, Stefan Behnel wrote:
>> I added a new directive "str_is_str=True" which can be combined with
>> "language_level=3" to get the desired behaviour. It keeps the 'str' builtin
>>
S.rst
Stefan
Stefan Behnel schrieb am 16.09.2018 um 17:48:
> Hi all,
>
> after half a year of development, many community pull requests and a lot of
> feedback and good ideas in online discussions and at conferences, I'm proud
> to release the first beta of Cython 0.29. This i
Stefan Behnel schrieb am 21.09.2018 um 17:46:
> Robert Bradshaw schrieb am 21.09.2018 um 17:30:
>> I agree that this doesn't really feel like a language-level thing.
>>
>> There seem three desired behaviors here:
>>
>> language_level=2 where cu
Guido van Rossum schrieb am 21.09.2018 um 19:35:
> Though now I start worrying about interned strings. That's a concept that's
> a little closer to being a feature.
True. While there's the general '"ab"+"cd" is (not) "abcd"' caveat, I'm
sure quite a bit of code out there assumes that parsed identi
601 - 700 of 8264 matches
Mail list logo
