Hi Jonathan,
On 12/27/19 3:16 PM, Jonathan Fine wrote:
> Summary: dict.update(self, other) corresponds to 'merge-right'. Perhaps add
> dict.gapfill(self, other), which corresponds to 'merge-left'. This post
> defines dict.gapfill, and discusses update and gapfill in the context of
> PEP 584.
IMHO
On 3/15/19 11:09 PM, Chris Angelico wrote:
> And, are you going to run this function on every single code snippet
> before you try it?
If just trying, may be not. But yes, if I care to know where the
applicability limits are (interpreter versions) before integrating it.
IMHO I don't think it's a
On 3/15/19 11:09 PM, Chris Angelico wrote:
> Python 3.5 introduced the modulo operator for bytes objects. How are
> you going to write a function that determines whether or not a piece
> of code depends on this?
I'm not sure I understand the question. Isn't *a piece of code* that
does a modulo
On 3/15/19 9:02 PM, francismb wrote:
> And the operator is the function.exactly, function application/call
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/
Hi Nick,
On 3/12/19 3:57 PM, Nick Timkovich wrote:
> The onus is on you
> to positively demonstrate you require both directions, not him to
> negatively demonstrate it's never required.
>From Calvin I just wanted to have some examples where he sees a use for
swapping operands (nothing to be
Thanks!
On 3/15/19 8:56 PM, Chris Angelico wrote:
> The same is true of books that discuss the language, blog posts giving
> tips and tricks, Stack Overflow answers, and everything else that
> incorporates code that people might want to copy and paste. What
> version of Python do you need? What's
On 3/13/19 7:44 PM, David Teresi wrote:
> `->` would not be ambiguous in the proposed cases, but it does already
> mean something elsewhere in the language as of 3.5:
>
> def concat(a: str, b: str) -> str:
> return a + b
>
> This could potentially cause confusion (as with the % operator being
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> The thing about "within 3" upgrades is that that kind of project-wide
> annoyance is going to be minimal, because the language is mostly
> growing in power, not changing the semantics of existing syntax. Such
> changes are very rare, and
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> Not really. For example, addition of syntax like "async" and "yield"
> fundamentally changes the meaning of "def", in ways that *could not*
> be fully emulated in earlier Pythons. The semantics simply were
> impossible to produce -- that's why
Hi Greg,
On 3/15/19 5:33 AM, Greg Ewing wrote:
> Not really. Having to translate all your source every time a
> minor version update occurs would be a huge hassle.
PythonUAAS: upload the sources (zipped or packaged) and get them updated
back ;-)
Regards,
--francis
On 3/14/19 9:47 PM, Chris Angelico wrote:
> What happens when someone wants to support multiple Python versions?
> "Requires Python 3.5 or newer" is easy. Forcing people to install the
> correct one for each version isn't.
What are the reasons why people want to support multiple Python
Hi Paul,
On 3/12/19 12:21 AM, Paul Moore wrote:
> That sounds very similar to 2to3, which seemed like a good approach to
> the Python 2 to Python 3 transition, but fell into disuse because
> people who have to support multiple versions of Python in their code
> found it *far* easier to do so with
Hi Steven,
On 3/12/19 12:25 AM, Steven D'Aprano wrote:
> I don't know who you expect is using this: the Python core developers
> responsible for adding new language features and changing the grammar,
> or Python programmers.
Python core devs should write the 'python_next' and 'is_python_code'
Hi,
I would like to discuss on the idea of a code (minor) version
evolver/re-writer (or at least a change indicator). Let's see one wants
to add a feature on the next version and some small grammar change is
needed, then the script upgrades/evolves first the current code and then
the new version
Hi Greg,
On 3/9/19 1:42 AM, Greg Ewing wrote:
> Do you really want
> to tell them that all their code is now wrong?
Of course not, at least not so promptly. But, would it be still a
problem if the update to a new version (let say from 3.X to next(3.X))
is done through some kind of
Hi Oleg,
On 3/3/19 4:06 PM, Oleg Broytman wrote:
>You cannot create operator ``<-`` because it's currently valid
> syntax:
>
> 3 <- 2
>
> is equivalent to
>
> 3 < -2
Yes, its a good point, but for me it's not the same '<-' and '< -' due
(n)blanks in between. It is may be how now it
Hi fhsxfhsx,
On 3/4/19 5:56 AM, fhsxfhsx wrote:
> Could you explain why do you prefer this operator than `+`?
Well yes, because of the asymmetric operation done underneath (merging
dicts is not symmetric). The asymmetry is explicit in the symbol. Not
implicit from the documentation you need to
Hi Calvin,
On 3/4/19 2:09 PM, Calvin Spealman wrote:
> I don't like the idea of arrows in both directions when you can just swap
> the operands instead
Well you saw just to examples of contexts (dict and bool). Could you
imagine a context where swapping cannot be done and thus there is a need
for
Hi Todd,
On 3/4/19 2:18 PM, Todd wrote:
> What is the operator supposed to do?
this should depend on what you want to do, the type, the context.
How to you would want to use it ? do you see a context where the symbols
make meaning to you?
Thanks in advance!
--francis
Hi,
the idea here is just to add the __larrow__ and __rarrow__ operators for
<- and ->.
E.g. of use on dicts :
>>> d1 = {'a':1, 'b':1 }
>>> d2 = {'a':2 }
>>> d3 = d1 -> d2
>>> d3
{'a':1, 'b':1 }
>>> d1 = {'a':1, 'b':1 }
>>> d2 = {'a':2 }
>>> d3 = d1 <- d2
>>> d3
{'a':2, 'b':1 }
Or on bools as
On 2/27/19 7:14 PM, MRAB wrote:
> Are there any advantages of using '+' over '|'?
or '<-' (d1 <- d2) meaning merge priority (overriding policy for equal
keys) on the right dict, and may be '->' (d1 -> d2) merge priority on
the left dict over '+' (d1 + d2) ?
E.g.:
>>> d1 = {'a':1, 'b':1 }
>>> d2
On 3/2/19 11:11 PM, MRAB wrote:
> '<=' is for comparison, less-than-or-equal (in the case of sets, subset,
> which is sort of the same kind of thing). Using it for anything else in
> Python would be too confusing.
Understandable, so the the proposed (meaning) overloading for <= is also
too
On 2/27/19 7:14 PM, MRAB wrote:
> Are there any advantages of using '+' over '|'?
or for e.g. '<=' (d1 <= d2) over '+' (d1 + d2)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of
On 3/2/19 8:14 PM, Raymond Hettinger wrote:
> Lastly, I'm still bugged by use of the + operator for replace-logic instead
> of additive-logic. With numbers and lists and Counters, the plus operator
> creates a new object where all the contents of each operand contribute to the
> result.
On 03/26/2018 10:35 AM, Roberto MartÃnez wrote:
> Hi,
>
> sometimes I need to use contextlib.close but over methods with a different
> name, for example stop(), halt(), etc. For those cases I have to write my
> own contextlib.close specialized version with a hard-coded method name.
>
> I think
Hi,
On 03/31/2018 09:47 PM, Terry Reedy wrote:
> With no padding, I would not argue with someone who prefers
> textwrap.dedent, but dedent cannot add the leading space.
Couldn't one use use the 'indent' method on the 'textwrap' module for
that purpose?
Thanks,
--francis
Hi Victor,
On 10/13/2017 04:12 PM, Victor Stinner wrote:
> I would like to add:
>
> * time.time_ns()
> * time.monotonic_ns()
> * time.perf_counter_ns()
> * time.clock_gettime_ns()
> * time.clock_settime_ns()
due nano vs. pico vs. ...
why not something like (please change '_in' for what you
Hi!,
> Core concept
>
>
> A context-local variable is represented by a single instance of
> ``contextvars.Var``, say ``cvar``. Any code that has access to the
``cvar``
> object can ask for its value with respect to the current context. In the
> high-level API, this value is given by
Hi,
>>>
>>> For large archives, I want to display a progress bar while the archive
>>> is being extracted with:
>>>
>>>
>>> The callback can receive the tarinfo object and where it's being
>>> extracted. This is enough to plug a progress bar
>>> and avoid reinventing .extractall()
>>
>>What
Hi Chris, Hi Steven,
> Have you measured it, eg by replacing the message with a constant? By
> what percentage does it speed up a successful test run?
How far is significant for `one` test? Please exchange the zip method
against `itertools.product` and some message creation with concatenation
Hi all,
while using `unittest` I see the pattern of creating an error message
with the test context for the case that some `assert...` methods fails
(to get a good error message). On the lines:
class Test...(unittest.TestCase):
longMessage = True
def test_(self):
...
for a, b, c ...
31 matches
Mail list logo
