cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
jcea has joined #pypy
edd[m] has quit [Write error: Connection reset by peer]
bendlas has quit [Write error: Connection reset by peer]
<cfbolz>
hard to say without investigating in detail
BPL has quit [Quit: Leaving]
<Dejan>
the_drow, are you a Celery contributor?
rubdos has quit [Ping timeout: 252 seconds]
<Dejan>
the nickname seems familiar, there is a Celery contributor with the same/similar nickname
dddddd has joined #pypy
<arigato>
the_drow: yes, you can open an issue but please make sure there is a complete step-by-step guide about how to reproduce the problem (e.g. not assuming we know anything about pyo3 for example)
<cfbolz>
anyway, it's not like the resulting suggestion is that good
<cfbolz>
Did you mean "print(<message>, file=<output_stream>)"?
<arigato>
right, but it's good to get such a suggestion from ``print >> sys.stderr, "bar"``, which is valid syntax in python 3
<arigato>
of course I wouldn't mind if we don't emit a special message for any ``f >> g`` where f is any built-in function that happens to be called "print"
<cfbolz>
arigato: too many negations error
<arigato>
I'm not not sorry :-)
<cfbolz>
You'd like us to have it?
<arigato>
if we run in python 3 ``print >> sys.stderr, 42`` we get a slightly obscure TypeError, so this cpython line gives it a better message, which is probably a good thing
rubdos has joined #pypy
<cfbolz>
arigato: OK, on it
<cfbolz>
arigato: I am not going to use the name though, but just "is", ok?
<arigato>
of course
<arigato>
and ideally you'd append the "did you mean" part to the existing message about unsupported operands, instead of making it again here
<cfbolz>
arigato: right, good idea
<cfbolz>
arigato: for the Syntax errors, CPython will happily give nonsense suggestions, like 'did you mean print(1 1 1 1 1 1)?
<cfbolz>
'
<arigato>
uh ok
<arigato>
``Did you mean print(1))))?``
<cfbolz>
I changed it in pypy to parse the suggestion before giving it
<cfbolz>
Yes
<arigato>
of course ``print -1`` still gives no syntax error and no hint at runtime either
ekaologik has joined #pypy
<cfbolz>
Of course
<cfbolz>
But if we want that, we should define our own class for print that overrides some operators
<cfbolz>
Not randomly hack descroperation
<arigato>
or just hack at more operators like cpython...
<cfbolz>
arigato: can you think of more than +-
<arigato>
even "+" is obscure
<cfbolz>
OK
<arigato>
so really I can only think about "-"
<cfbolz>
Makes sense
marky1991 has quit [Read error: Connection reset by peer]
marky1991_2 has quit [Remote host closed the connection]
marky1991_2 has joined #pypy
marky1991_2 has quit [Read error: Connection reset by peer]
marky1991_3 has joined #pypy
marky1991 has quit [Ping timeout: 245 seconds]
toad_poloer has joined #pypy
<toad_poloer>
pypy folks: How much of a problem is it if the pure Python implementation of a function uses `collections.namedtuple` if Python's C implementation uses a structseq?
<arigato>
I think they are similar, but clearly not perfectly equal
<toad_poloer>
I think the biggest impact will be on PyPy, who seems to be the most major consumer of `datetime.py`.
<toad_poloer>
If any pypy maintainers want to weigh in I think that would be appreciated, I do not want to ignorantly make changes that will make y'alls lives harder.
<arigato>
I think we're used to CPython pretending that datetime.py and the C version are equal when they are not fully, and so we're already patching things anyway
<arigato>
I wouldn't take this as an argument for why a function shouldn't return a structseq when it makes sense that it would
<arigato>
er
<toad_poloer>
Sure. There's PEP 399 which basically says "the tests define the public interface and they need to pass in both C and Python"
<arigato>
I mean: it makes sense that this function returns a structseq in CPython
<toad_poloer>
The sprit of which is that the C and Python implementations should do the same thing.
<arigato>
so go ahead with that, and then write some version using e.g. namedtuple in the Python implementation, and hope they are close enough
<toad_poloer>
And adding an additional import on `collections.namedtuple` won't be a problem?
<arigato>
I know about this PEP, I'm just saying it's never completely equal anyway
<arigato>
if it turns out to be a problem because things are different, we'll just make our own "C" version of the structseq and return that from datetime.py
<toad_poloer>
OK.
<arigato>
and probably complain a bit, but please understand that such complains are not directed at people making improvements to the datetime API but instead to the general mess of Python and C types
<toad_poloer>
Sure ;)
<arigato>
(PEP 399 is already a myth for datetime, e.g. you can't use PyDateTime_Xxx() from the objects built by datetime.py in CPython---though you can in PyPy)
<mattip>
our version of lib-python/3/datetime.py has diverged from cpython's Lib/datetime.py since our types inherit from __pypy__.pypydatetime classes
<arigato>
(note that PEP 399 is still useful for PyPy! we need to fix such issues, but the bulk of the code is still working fine)
<toad_poloer>
Technically PEP 399 is actually a very minor requirement in that the test suite needs to pass in both versions.
<toad_poloer>
And that's almost tautologically true because the test suite must pass in order to get a commit merged and hte test suite runs against both versions :P
<toad_poloer>
But you're right that the spirit of the thing is violated when you need to heavily patch datetime.py to use it.
<mattip>
s/heavily/lighty
<arigato>
yes, patches have been light, so it's still fine
<arigato>
if you can convince people that namedtuple and structseq should not be two different types, that would be appreciated, but I heavily doubt it :-)
<toad_poloer>
Heh, yeah, one battle at a time I guess.
<arigato>
(ah, space.nonzero(..) does exactly this too)
Rhy0lite has quit [Quit: Leaving]
ajlawrence has joined #pypy
speeder39_ has joined #pypy
alexge50 has quit [Ping timeout: 245 seconds]
alexge50 has joined #pypy
plluksie has quit [Quit: leaving]
ajlawrence has quit [Remote host closed the connection]
<cfbolz>
arigato: in theory there's also print ~x
<cfbolz>
but it's getting a bit obscure
<cfbolz>
ah no
<cfbolz>
sorry, that's not a binary operator of course
<kenaan>
cfbolz py3.6 c0b2526268ab /pypy/: more print error message work, this one requiring a change to descroperation (in CPython it's done in abstract.c)
<cfbolz>
arigato: if you have a moment, I'd appreciate a look
BPL has joined #pypy
marky1991_3 has quit [Ping timeout: 258 seconds]
ionelmc has joined #pypy
the_drow has quit [Remote host closed the connection]
the_drow has joined #pypy
dddddd has quit [Remote host closed the connection]
jcea has joined #pypy
jcea has quit [Remote host closed the connection]
mattip has quit [Ping timeout: 246 seconds]
the_drow has quit [Remote host closed the connection]