[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar mistersh...@gmail.com: Added file: http://bugs.python.org/file37821/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Neil Girdhar mistersh...@gmail.com: Removed file: http://bugs.python.org/file37817/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
Chris, On Thu, Jan 22, 2015 at 9:46 PM, Nicholas Cole nicholas.c...@gmail.com wrote: Hang on! The particular example may not make a lot of sense but there are plenty of places in ordinary Python where functions can accept different objects in arguments and return different things. The point here is that that will become rapidly messy and hard to read. Yes; but with proper use of TypeVar can simplify things a lot - have a read of the PEP. ChrisA I agree. TypeVar will help tremendously by removing the need for union in cases of object inheritance. But only on cases of object inheritance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 10:12 PM, Mario Figueiredo mar...@gmail.com wrote: I agree. TypeVar will help tremendously by removing the need for union in cases of object inheritance. But only on cases of object inheritance. Why only inheritance? One of the examples is of str and bytes, which don't have any inheritance relationship (they both just subclass object), and it works just fine for that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23154] MSVC 2013 Express needlessly rebuilds code
Steve Dower added the comment: That change modified pythoncore, so I'd expect to see most projects rebuild. Especially under Release, where we don't have some of the build optimizations enabled (because they hurt runtime performance). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23154 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: By the way, Joshua if you wanted to edit the text of the PEP, it might be nice to point out that this replaces itertools.chain.from_iterable. I know you mention one use of itertools.chain, but I think this nicely replaces all uses of both: itertools.chain(a, b, c) is (*x for x in [a, b, c]) itertools.chain.from_iterable(it) is (*x for x in it) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment:
I've looked at BUILD_MAP(n). It seems to work and has speed improvements but:
- I was wrong about the 16-bit int thing. It turns out CPython is happily
treating them as 32 bit as long as they are prefixed by an EXTENDED_ARG bytecode
https://docs.python.org/3/library/dis.html#opcode-EXTENDED_ARG
This could be used by BUILD_MAP rather than falling back to BUILD_MAP_UNPACK.
- It's probably best to not include it here, since it's a disjoint issue. This
patch wouldn't really be affected by its absence.
Also, if we limit BUILD_MAP_MERGE to 255 dictionaries, this will also apply to
the {**a, **b, **c, ...} syntax, although I really can't see it being a problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23294] A typo in the tutorial
aruseni added the comment: @Eric You’re right. I thought it should be «was» instead of «is», but it’s actually OK. -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23300] An improper change in httplib.py
New submission from Guohua Ouyang: Following the issue 7776, there is a patch for 2.7 version. Which changes the method of class HTTPConnection from _set_hostport to _get_hostport[1], it seems introduce in some incompatibility issues. On my system, the file /usr/lib64/python2.7/site-packages/mercurial/url.py from package mercurial-3.0-2.fc21 still use the old method _set_hostport. I met an error AttributeError: httpsconnection instance has no attribute '_set_hostport' when use this package. I only see this incompatibility issue so far. And in the file httplib.py itself, [2] still use self._conn._set_hostport(host, port), which should be self._conn._get_hostport(host, port) if it's settled to rename _set_hostport to _get_hostport. [1] https://github.com/python/cpython/blob/2.7/Lib/httplib.py#L743 [2] https://github.com/python/cpython/blob/2.7/Lib/httplib.py#L1132 -- components: Library (Lib) messages: 234488 nosy: guohua priority: normal severity: normal status: open title: An improper change in httplib.py type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23300 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7334] ElementTree: file locking in Jython 2.5 (OSError on Windows)
Martijn Pieters added the comment: Indeed, the 2.7 backport was not correctly applied for _elementtree.c, leaving files open because the close_source flag is set to False *again* when opening a filename. Should a new issue be opened or should this ticket be re-opened? -- nosy: +mjpieters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7334 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
Chris, I'd rather see a real-world example that can't be solved with either better design or some simple aliases. (And yes, the type hinting does allow for aliases.) Python is a duck-typing language, Chris. It is in its nature -- and we have been taught -- to ignore types and care only about operators. This means one of the most common design decisions in Python is exactly to code functions that are type ignorant. That is exactly why we need Type Hinting, because duck-typing complicates static analysis. And that is exactly why the Unions factory are a necessary part of the type hinting mechanism in PEP 484. You will be seeing lots and lots of Unions in type annotated code once it gets implemented. And it's not because of the complexity of Unions syntax that I should now care about refactoring my code. That is a no-no. If you don't know of any real-life example of python functions that will eventually force you into annotate them with unions syntax, look no further than your standard library. And also start questioning if you aren't complicating your own code with unnecessary function overloads. -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On Wednesday 21 January 2015 23:46:09 Emil Oppeln-Bronikowski did opine And Gene did reply: On Thu, Jan 22, 2015 at 10:55:27AM +1100, Chris Angelico wrote: Where's REXX today? Still (somehow) alive in neo-Amiga platforms like AmigaOS4.x, MorphOS and AROS. I know that's as good as dead but there are still people writing AREXX glue code. He asked about REXX, not AREXX. There is no comparison between the two as AREXX was a huge superset of REXX. I have co-written some rather widely distributed amiga code in AREXX, then compiled it to standalone with RexxPlus. When I switched platforms to linux in 1998, the first thing I did was to go find an AREXX for linux. But had to settle for IBM's REXX/Regina, which wasn't capable of running any of our AREXX code. AREXX hooked into the OS and there wasn't anything I ever wanted to do that could not be done in AREXX. REXX/Regina is an extremely emasculated language that has zero connection into the os, and I found it completely useless when compared to AREXX. If, when anyone here was using an amiga, and was using EzCron to schedule stuff, Jim Hines and I wrote it as there was no such scheduler for amigados. Everything else we laid our hands on killed time by busywaiting, killing the machines performance. EzCron put itself to sleep intelligently by asking what time it was, and then sleeping until the first second of the next minute. That we published at the time, and then built on that for EzHome, which was a dumber version of what we call heyu today. Trivia bit: William Hawes, who wrote AREXX and sold it thru the commode door sales channels, was never paid a dime for his work. But those 2 guys screwed everybody. He had an account on kernel.org in 1998, might still have, but it was empty then and the last time I looked, probably 5 years ago. So I have no clue what a very talented programmer is doing for a living today. To me, that sad as hell. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Mario Figueiredo wrote:
In article 54c0a571$0$13002$c3e8da3$54964...@news.astraweb.com,
steve+comp.lang.pyt...@pearwood.info says...
The point isn't that there are no other alternative interpretations
possible, or that annotations are the only syntax imaginable, but that
they're not hard to guess what they mean, and if you can't guess, they're
not hard to learn and remember.
Possibly one common use case will be Unions. And that factory syntax is
really awful and long when you look at a function definition with as
little as 3 arguments. The one below has only 2 arguments.
def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
Union[float, Sequence[float]]) - Union[Employee, Sequence[Employee],
None]:
You can't use raise as a parameter name, since that's a keyword. Using
floats for money is Just Wrong and anyone who does so should have their
licence to program taken away. And I really don't understand what this
function is supposed to do, that it returns None, a single Employee, or a
sequence of Employees. (If it's hard to declare what the return type is,
perhaps your function does too much or the wrong thing.)
But putting those aside, let's re-write that with something a little closer
to PEP-8 formatting:
def handle_employees(
emp: Union[Employee, Sequence[Employee]],
pay_raise: Union[int, Sequence[int]]
) - Union[Employee, Sequence[Employee], None]:
pass
That's quite nice and easy to follow. I can think of three improvements:
(1) Allow the return annotation to be on a line on its own rather than force
it to follow the closing bracket;
(2) Support | to make Unions of types;
(3) Have a shorter way to declare Spam or Sequence (tuple?) of Spam.
def handle_employees(
emp: OneOrMore[Employee],
pay_raise: OneOrMore[int])
- OneOrMore[Employee] | None:
pass
(2) has been rejected by Guido, but he may change his mind. The name I've
chosen for (3) is just the first thing I've thought of.
Meanwhile there's quite a few more generics like the Sequence one above
you may want to take a look at and try and remember. And that's just one
factory (the generics support factory). You may also want to take a look
at TypeVar and Callable for more syntactic hell.
Exaggerate, much?
Meanwhile, there's the strange decision to implement type hints for
local variables # comment lines. I have an hard time wrapping my head
around this one. Really, comments!?
Yes, really. There is plenty of prior art for machine-meaningful comments:
- mypy uses it, and it works fine
- Pascal uses {$ ...} compiler directives
- Unix uses a special hash-bang #! comment in the first line to
specify the executable that runs the script
- Python supports a special encoding declaration using #
- doctest uses comments for directives
- HTML puts code (Javascript usually) inside of comments
- JMSAssert for Java uses comments for design-by-contract assertions
But note that the type declarations have *no runtime effect*. They truly are
comments, aimed at the human reader and any compliant type-checker.
Guido has said that he isn't ruling out an explicit syntactic support for
type declarations in the future, but right now there are various
constraints:
- it must be backwards compatible, i.e. something that Python 3.4 and older
will just ignore
- it must be available by lexical analysis, that is, from reading the
source code, which rules out anything that happens at runtime
- it must be human-readable
- and easily parsed by even simple tools
Finally, remember all this is being added to your code just to
facilitate static analysis.
You say just to facilitate static analysis, but let me put it this way. It
is just to facilitate:
- improved correctness of programs
- to assist in finding bugs as early as possible
- reduced need to write tedious, boring unit tests to check things
that an automated type-checker can deal with instead
- to reduce the need for runtime type-checks and isinstance() calls
- to aid in producing documentation
- to give hints to IDEs, editors, linters, code browsers and
similar tools.
Strangely enough though I was taught from
the early beginning that once I start to care about types in Python, I
strayed from the pythonic way. I'm confused now... What is it then?
That's actually a really good question.
Good practice in Python will not change. If anything, explicitly checking
types with isinstance will become even less common: if you can use lexical
analysis to prove that the argument passed to a function is always a float,
there is no need to perform a runtime check that it is a float.
Notice that nearly all the examples in the PEP use abstract classes like
Sequence instead of concrete classes like list? This is a good thing, and
will encourage more flexible code. You don't need a specific type of
sequence, any type of sequence will do -- that's pretty much the definition
of
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: test_asyncio hangs on AMD64 Windows7 SP1 3.x buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5562 The most significant change of this build is the changeset d3804307cce4: IocpProactor.close() must not cancel pending _WaitCancelFuture futures. [391/391] test_asyncio Timeout (1:00:00)! Current thread 0x13f8 (most recent call first): File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py, line 617 in _unregister File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py, line 193 in _unregister_wait_cb File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py, line 209 in _unregister_wait File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py, line 152 in set_result File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py, line 671 in _poll File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py, line 386 in select File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py, line 1081 in _run_once File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py, line 258 in run_forever File C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py, line 286 in run_until_complete File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_events.py, line 1695 in test_subprocess_stderr_redirect_to_stdout File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py, line 577 in run File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py, line 625 in __call__ File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\runner.py, line 168 in run File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py, line 1770 in _run_suite File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py, line 1804 in run_unittest File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py, line 1283 in test_runner File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py, line 1284 in runtest_inner File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py, line 967 in runtest File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py, line 532 in main File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py, line 1568 in main_in_temp_cwd File C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py, line 1593 in module File C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py, line 85 in _run_code File C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py, line 170 in _run_module_as_main -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: A different hang on AMD64 Windows7 SP1 3.4/ buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.4/builds/805/steps/test/logs/stdio This build is also related to the changeset d3804307cce44f7f02e38166daf6d8227aa45021: IocpProactor.close() must not cancel pending _WaitCancelFuture futures. IMO it's not a new bug, it's just that it was not seen before. I may be related to the issue #23293. [390/390/1] test_asyncio Timeout (1:00:00)! Current thread 0x05c8 (most recent call first): File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py, line 620 in _unregister File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py, line 196 in _unregister_wait_cb File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py, line 212 in _unregister_wait File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py, line 152 in set_result File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py, line 674 in _poll File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py, line 389 in select File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\base_events.py, line 1081 in _run_once File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\base_events.py, line 258 in run_forever File C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\base_events.py, line 286 in run_until_complete File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\test_asyncio\test_subprocess.py, line 211 in test_pause_reading File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\case.py, line 577 in run File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\case.py, line 625 in __call__ File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 125 in run File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py, line 87 in __call__ File C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\runner.py, line 168 in run File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\support\__init__.py, line 1769 in _run_suite File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\support\__init__.py, line 1803 in run_unittest File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py, line 1279 in test_runner File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py, line 1280 in runtest_inner File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py, line 967 in runtest File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py, line 532 in main File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py, line 1564 in main_in_temp_cwd File C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py, line 1589 in module File C:\buildbot.python.org\3.4.kloth-win64\build\lib\runpy.py, line 85 in _run_code File C:\buildbot.python.org\3.4.kloth-win64\build\lib\runpy.py, li -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
An improper change in httplib.py
This is my first post to the list, I apologies firstly if I made any mistake.
I was trying to get a package in golang behind the http or https
proxy, and it reports an error AttributeError: httpsconnection
instance has no attribute '_set_hostport', details in the bottom.
After some trace work, I found it caused by the changes in the issue issue7776.
@@ -718,7 +734,7 @@
else:
self._tunnel_headers.clear()
-def _set_hostport(self, host, port):
+def _get_hostport(self, host, port):
First, it changes the method's name, doesn't it break the
compatibility for other packages, on my system,
mercurial-3.0-2.fc21.x86_64 still use _set_hostport as the error
shows.
Second, I found that line 1132 of [2] still use
self._conn._set_hostport(host, port), which should be
_get_hostport, right?
[1] http://bugs.python.org/issue7776
[2] https://github.com/python/cpython/blob/2.7/Lib/httplib.py
$ go get code.google.com/p/go-uuid/uuid
# cd .; hg clone -U https://code.google.com/p/go-uuid
/home/guohua/go/src/code.google.com/p/go-uuid
** unknown exception encountered, please report by visiting
** http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.8 (default, Nov 10 2014, 08:19:18) [GCC 4.9.2 20141101
(Red Hat 4.9.2-1)]
** Mercurial Distributed SCM (version 3.0)
** Extensions loaded:
Traceback (most recent call last):
File /usr/bin/hg, line 38, in module
mercurial.dispatch.run()
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 28, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) 255)
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 69, in dispatch
ret = _runcatch(req)
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 138, in _runcatch
return _dispatch(req)
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 810, in _dispatch
cmdpats, cmdoptions)
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 590, in runcommand
ret = _runcommand(ui, options, cmd, d)
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 901, in _runcommand
return checkargs()
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 872, in checkargs
return cmdfunc()
File /usr/lib64/python2.7/site-packages/mercurial/dispatch.py,
line 807, in lambda
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
File /usr/lib64/python2.7/site-packages/mercurial/util.py, line
518, in check
return func(*args, **kwargs)
File /usr/lib64/python2.7/site-packages/mercurial/commands.py,
line 1298, in clone
branch=opts.get('branch'))
File /usr/lib64/python2.7/site-packages/mercurial/hg.py, line 295, in clone
srcpeer = peer(ui, peeropts, source)
File /usr/lib64/python2.7/site-packages/mercurial/hg.py, line 129, in peer
return _peerorrepo(rui, path, create).peer()
File /usr/lib64/python2.7/site-packages/mercurial/hg.py, line 106,
in _peerorrepo
obj = _peerlookup(path).instance(ui, path, create)
File /usr/lib64/python2.7/site-packages/mercurial/httppeer.py,
line 261, in instance
inst._fetchcaps()
File /usr/lib64/python2.7/site-packages/mercurial/httppeer.py,
line 58, in _fetchcaps
self.caps = set(self._call('capabilities').split())
File /usr/lib64/python2.7/site-packages/mercurial/httppeer.py,
line 172, in _call
fp = self._callstream(cmd, **args)
File /usr/lib64/python2.7/site-packages/mercurial/httppeer.py,
line 119, in _callstream
resp = self.urlopener.open(req)
File /usr/lib64/python2.7/urllib2.py, line 404, in open
response = self._open(req, data)
File /usr/lib64/python2.7/urllib2.py, line 422, in _open
'_open', req)
File /usr/lib64/python2.7/urllib2.py, line 382, in _call_chain
result = func(*args)
File /usr/lib64/python2.7/site-packages/mercurial/url.py, line
372, in https_open
return self.do_open(self._makeconnection, req)
File /usr/lib64/python2.7/site-packages/mercurial/keepalive.py,
line 254, in do_open
self._start_transaction(h, req)
File /usr/lib64/python2.7/site-packages/mercurial/url.py, line
358, in _start_transaction
return keepalive.KeepAliveHandler._start_transaction(self, h, req)
File /usr/lib64/python2.7/site-packages/mercurial/keepalive.py,
line 352, in _start_transaction
h.endheaders()
File /usr/lib64/python2.7/httplib.py, line 991, in endheaders
self._send_output(message_body)
File /usr/lib64/python2.7/httplib.py, line 844, in _send_output
self.send(msg)
File /usr/lib64/python2.7/site-packages/mercurial/url.py, line
144, in _sendfile
orgsend(self, data)
File /usr/lib64/python2.7/site-packages/mercurial/keepalive.py,
line 532, in safesend
self.connect()
File /usr/lib64/python2.7/site-packages/mercurial/url.py, line
342, in connect
_generic_proxytunnel(self)
File /usr/lib64/python2.7/site-packages/mercurial/url.py, line
228, in _generic_proxytunnel
self._set_hostport(self.host, self.port)
AttributeError:
[issue23295] [Windows] asyncio: add UDP support to ProactorEventLoop
Changes by STINNER Victor victor.stin...@gmail.com: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23295 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: BUILD_MAP(n) -- Added file: http://bugs.python.org/file37817/starunpack14.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Thursday, January 22, 2015 at 12:48:46 AM UTC-6, Paul Rubin wrote: Sir Richard Johnson writes: You could write some IDE features to suppress visibility of the hints. Or maybe it could be done with a decorator- like construct: @-spec(Iterable[Real], Real) - Real Yes, YES, *YES* That would be my first choice, or docstrings as a secondary. But to introduce new syntax into the method signatures is SUICIDE! What the hell is this man thinking? For the sake of this community and the many noobs who have not found programming bliss via Python, i implore you to do everything in your power to convince GvR that he is making a grave mistake, for which no recovery will be possible. I've always found Python 3 annoying because it broke compatibility with Python 2, but only by a little bit, not enough to add real benefits. This is a real benefit so IMHO it makes the language more attractive rather than less. Agreed. I'm not against the idea, heck, i want to see Python improve just like anybody who loves this language, but the implementation just plain sucks! Please convince GvR to move this noisy syntax OUTSIDE of the signature! It's too noisy and its going to turn people off. -- https://mail.python.org/mailman/listinfo/python-list
Socket ICMP V6 error
I've made a snniferr for a ICMP socket that works with IPv4. This is the
code:
import sys
import socket
import struct
import select
import time
import signal
import re
HOST = raw_input(Enter the interface to listen: )
s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP)
s.bind((HOST, 0))
s.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)
print Server Started..
for i in range(1,2000):
data = s.recvfrom(65565)
d1 = str(data[0])
data1 = re.search('@@(.*)', d1)
command = data1.group(0)
cmd = command[2:]
if i%2 == 0:
d = data[1]
d1 = str(d)
ip = d1[2:-5]
print cmd
print ip
I have done a modification to adapt it to IPv6:
s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_ICMPV6)
However I recive the next error:
File server.py, line 16, in module
s.bind((HOST, 0))
File /usr/lib/python2.7/socket.py, line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 22] Invalid argument
Could someone please help me?.
Thanks in advance
--
View this message in context:
http://python.6.x6.nabble.com/Socket-ICMP-V6-error-tp5083962.html
Sent from the Python - python-list mailing list archive at Nabble.com.
--
https://mail.python.org/mailman/listinfo/python-list
[issue23009] selectors.EpollSelector.select raises exception when nothing to select.
Roundup Robot added the comment: New changeset d3a27a27e008 by Victor Stinner in branch '3.4': Issue #23009: Skip test_selectors.test_empty_select() on Windows https://hg.python.org/cpython/rev/d3a27a27e008 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23009 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23297] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
STINNER Victor added the comment: I don't understand why do you consider that this issue is a bug. Can you show an example where detect_encoding() raises an exception? -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
In article 54c0a571$0$13002$c3e8da3$54964...@news.astraweb.com, steve+comp.lang.pyt...@pearwood.info says... The point isn't that there are no other alternative interpretations possible, or that annotations are the only syntax imaginable, but that they're not hard to guess what they mean, and if you can't guess, they're not hard to learn and remember. Possibly one common use case will be Unions. And that factory syntax is really awful and long when you look at a function definition with as little as 3 arguments. The one below has only 2 arguments. def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) - Union[Employee, Sequence[Employee], None]: That's for a generic list-like container. Have fun with the Mapping union. Meanwhile there's quite a few more generics like the Sequence one above you may want to take a look at and try and remember. And that's just one factory (the generics support factory). You may also want to take a look at TypeVar and Callable for more syntactic hell. Meanwhile, there's the strange decision to implement type hints for local variables # comment lines. I have an hard time wrapping my head around this one. Really, comments!? Finally, remember all this is being added to your code just to facilitate static analysis. Strangely enough though I was taught from the early beginning that once I start to care about types in Python, I strayed from the pythonic way. I'm confused now... What is it then? -- https://mail.python.org/mailman/listinfo/python-list
[issue23009] selectors.EpollSelector.select raises exception when nothing to select.
Roundup Robot added the comment: New changeset 4f928c70f135 by Victor Stinner in branch '3.4': Issue #23009: Add missing import sys in test_selectors https://hg.python.org/cpython/rev/4f928c70f135 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23009 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
python client call Java server by xmlrpc
Hi all
I have xmlrpc server written in Java, and it has a method like
Fun( vector, vector), the vector is array of user-defined object, which is
a class extends HashMap.
And I call it like:
server = xmlrpclib.ServerProxy(http://myserver;)
server.Fun( [ {0.5:0.1}], [ ] )
It always fails with error
'No method matching arguments: , [Ljava.lang.Object;, [Ljava.lang.Object;
'
Does anyone use this before? It troubles me some days.
Thanks a lot.
Diana
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 22/01/2015 08:24, Rick Johnson wrote: Yes, YES, *YES* That would be my first choice, or docstrings as a secondary. But to introduce new syntax into the method signatures is SUICIDE! What the hell is this man thinking? I take it you mean these men Guido van Rossum guido at python.org, Jukka Lehtosalo jukka.lehtosalo at iki.fi, Łukasz Langa lukasz at langa.pl as they are the authors of PEP484? Agreed. I'm not against the idea, heck, i want to see Python improve just like anybody who loves this language, but the implementation just plain sucks! Please convince GvR to move this noisy syntax OUTSIDE of the signature! It's too noisy and its going to turn people off. What implementation? The PEP is quite clearly marked as draft. The Re-enactment of the Battle of Pearl Harbour is currently ongoing over on python-ideas regarding exactly what should be implemented. There is also nothing to stop you writing another PEP with an alternative proposal, although I suspect there is as much chance of that ever happening as there is of ever seeing RickedPython(3). -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thursday, January 22, 2015 at 1:23:40 AM UTC-6, Steven D'Aprano wrote: The point isn't that there are no other alternative interpretations possible, or that annotations are the only syntax imaginable, but that they're not hard to guess what they mean, and if you can't guess, they're not hard to learn and remember. That's highly subjective. Could you please stop licking Guido's boots long enough to take a whiff of what the hell you're shoveling? Is being teachers pet so important that you're willing to turn off a vast majority of new Python programmers? How much longer can this hemorrhaging go on Steven? Python is the only thing that is pure in the programming world. The only language that offers the cleanest and most intuit-able syntax, AND YOURE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF SATAN? Everybody better listen up, and you'd better listen up good folks. Because we've only got a short time to act before this monstrosity is enacted. You need send Guido emails (and lots of them) and tell him how destructive this is going to be to our community. Stop being cowards, it's time to put the big boy pants on. If you don't act now, then don't bother complaining later. Python is dangling by a thin thread, and this is your last chance to save everything we've worked for. All the lines of code we've written won't mean spit if the language takes a swan dive into obscurity! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 7:10 PM, Mario Figueiredo mar...@gmail.com wrote: Possibly one common use case will be Unions. And that factory syntax is really awful and long when you look at a function definition with as little as 3 arguments. The one below has only 2 arguments. def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) - Union[Employee, Sequence[Employee], None]: Hold on a moment, how often do you really do this kind of thing with might be one of them or a sequence? Do you really have a function that could take an Employee and a float, or a sequence of Employees and a single float, or a single Employee and a sequence of floats, or a sequence of both? Or do you, much more likely, actually have two separate functions: def handle_employee(emp: Employee, raise: float) - Optional[Employee]: def handle_employees(emp: Sequence[Employee], raise: Sequence[float]) - List[Employee]: The union in the return value seems particularly unlikely... and unhelpful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Rick Johnson rantingrickjohn...@gmail.com: Python is the only thing that is pure in the programming world. The only language that offers the cleanest and most intuit-able syntax, AND YOURE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF SATAN? I think the SATAN is in the optional type declarations, not in the particular syntax chosen. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Socket ICMP V6 error
On Thu, Jan 22, 2015 at 7:00 PM, ermanolillo ermanoli...@hotmail.com wrote: s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_ICMPV6) However I recive the next error: File server.py, line 16, in module s.bind((HOST, 0)) File /usr/lib/python2.7/socket.py, line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 22] Invalid argument Could someone please help me?. For a start, what HOST are you using? (Point of style: It's unusual to use an all-uppercase name like HOST for something non-constant - in this case, it's coming from keyboard input.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 9:05 PM, Marko Rauhamaa ma...@pacujo.net wrote: Rick Johnson rantingrickjohn...@gmail.com: Python is the only thing that is pure in the programming world. The only language that offers the cleanest and most intuit-able syntax, AND YOURE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF SATAN? I think the SATAN is in the optional type declarations, not in the particular syntax chosen. So optional type declarations are officially the details now? :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23299] Documentation correction - 5.1.4. List Comprehensions
New submission from Liang Zhang: This was copied from Chapter 5 Data Structure in Python language tutorial. The link I was looking for: https://docs.python.org/2.7/tutorial/datastructures.html Some thing might be incorrect and need you to update them in (5.1.4. List Comprehensions) It should be like this: --start-- vec = [-4, -2, 0, 2, 4] # create a new list with the values doubled [x*2 for x in vec] [-8, -4, 0, 4, 8] # filter the list to exclude negative numbers [x for x in vec if x = 0] [0, 2, 4] # apply a function to all the elements [abs(x) for x in vec] [4, 2, 0, 2, 4] It should be [0, 2, 4] --end-- -- assignee: docs@python components: Documentation messages: 234485 nosy: Liang.Zhang, docs@python priority: normal severity: normal status: open title: Documentation correction - 5.1.4. List Comprehensions type: resource usage versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: An improper change in httplib.py
On 22/01/2015 03:38, Guohua Ouyang wrote: This is my first post to the list, I apologies firstly if I made any mistake. I was trying to get a package in golang behind the http or https proxy, and it reports an error AttributeError: httpsconnection instance has no attribute '_set_hostport', details in the bottom. After some trace work, I found it caused by the changes in the issue issue7776. @@ -718,7 +734,7 @@ else: self._tunnel_headers.clear() -def _set_hostport(self, host, port): +def _get_hostport(self, host, port): First, it changes the method's name, doesn't it break the compatibility for other packages, on my system, mercurial-3.0-2.fc21.x86_64 still use _set_hostport as the error shows. Second, I found that line 1132 of [2] still use self._conn._set_hostport(host, port), which should be _get_hostport, right? [1] http://bugs.python.org/issue7776 [2] https://github.com/python/cpython/blob/2.7/Lib/httplib.py You've found a bug so please raise it on bugs.python.org :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 22/01/2015 04:30, Steven D'Aprano wrote: Occasionally you find people spreading Fear, Uncertainty, Doubt about Python. Python is now over 20 years old and one of the most popular languages in the world no matter how you measure popularity: http://import-that.dreamwidth.org/1388.html so you don't often get FUD these days. When you do, it's usually about whitespace, or Python is too slow, or occasionally Python 3 is killing Python, but the latest FUD is about PEP 484 and type-hinting: https://www.python.org/dev/peps/pep-0484/ Here's a typical example: Python is already headed towards obscurity. ... it seems that GvR intends to drive the final nail in python's coffin with this type hinting crap that will convert Python syntax from a readable pseudo code into a cryptic nightmare. Type hinting violates the very ESSENCE of what Python was meant to be, that is: a clean and intuitive syntax. (Google for it if you care for the source.) So it's doomed again, big deal, it's the third time this week and the dustmen simply won't take it. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 8:10 AM, Mario Figueiredo mar...@gmail.com wrote: In article 54c0a571$0$13002$c3e8da3$54964...@news.astraweb.com, steve+comp.lang.pyt...@pearwood.info says... The point isn't that there are no other alternative interpretations possible, or that annotations are the only syntax imaginable, but that they're not hard to guess what they mean, and if you can't guess, they're not hard to learn and remember. Possibly one common use case will be Unions. And that factory syntax is really awful and long when you look at a function definition with as little as 3 arguments. The one below has only 2 arguments. def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) - Union[Employee, Sequence[Employee], None]: That's for a generic list-like container. Have fun with the Mapping union. To be fair, is it clearer with some kind of formatting? def handle_employees( emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) - Union[Employee, Sequence[Employee], None]: I still find that hard to read, but the line breaks help. Just for fun, I'd like to put out that without all of that noise the function reads: def handle_employees(employees, raise): . return employees And suddenly it looks like what most people who know anything about programming recognise as Python again! With some kind of doc-string or similar syntax it would read something like: def handle_employees(employees, rasie): # employees: Union[Employee, Sequence[Employee]] # raise: Union[float, Sequence[float]] # return: Union[Employee, Sequence[Employee], None] . return employeees There's a reasonable case that this is not all that dissimilar from the function annotation syntax above, but the difference is surely that in the one case you see immediately that there are two arguments, and in the other you can't be sure without parsing some very cluttered punctuation-heavy syntax. Still, it would have been nicer to be able to write something like this (where the Unions are implicit): def handle_employees(employees, rasie): # employees: Employee, Sequence[Employee] # raise: float, Sequence[float] # return: Employee, Sequence[Employee], None Yes, I know that function annotations have been defined for a while, and yes, I know that they are similar to a syntax used in other languages, and yes, I know that they are optional. All the same, either they are going to become the norm or they are not. If they become the norm (as I think they will because type hinting seems to solve many problems that the community cares about) then I think we have to accept that an important part of the language will become much more cluttered, much less intuitive, and much more off-putting to many. I think the fact that the current proposals mix the annotation syntax with an inline comment syntax is also horrible (though I don't see any alternatives). I would much rather have put all of the magic in to comments or none. N. -- https://mail.python.org/mailman/listinfo/python-list
[issue21518] Expose RegUnloadKey in winreg
Claudiu Popa added the comment: Ups, the last patch included an extra file. -- Added file: http://bugs.python.org/file37819/issue21518_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21518 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21518] Expose RegUnloadKey in winreg
Changes by Claudiu Popa pcmantic...@gmail.com: Added file: http://bugs.python.org/file37820/issue21518_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21518 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23078] unittest.mock patch autospec doesn't work on staticmethods
Claudiu Popa added the comment: Here's a patch which does this. One problem could be that staticmethod(some_callable) or classmethod(some_callable) aren't callable per se, but given the fact that users expects Foo.staticmethod or Foo.klassmethod to be callable when patching them, it's something we should consider for fixing. -- components: +Library (Lib) -Tests keywords: +patch nosy: +Claudiu.Popa stage: - patch review Added file: http://bugs.python.org/file37818/issue23078.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23078 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
Rick, Python is the only thing that is pure in the programming world. The only language that offers the cleanest and most intuit-able syntax, AND YOURE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF SATAN? Nonsense. You are just used to it. I can read C with the same feeling of intuitiveness as you do Python. There's nothing inherently more intuitive about python and I just wished that meme died already. Besides it's all in the eye of the beholder. Some people, for intance, aren't all that comfortable about python white space as much as many die-hard pythonists would like to admit. It's not even a feature that gained traction on programming languages that came after python. If you don't act now, then don't bother complaining later. Python is dangling by a thin thread, and this is your last chance to save everything we've worked for. All the lines of code we've written won't mean spit if the language takes a swan dive into obscurity! PEP 484 just becomes silly when it comes to the section where it discusses whether type hints are pythonic. If that ridiculous paragraph reflects how we are looking today at the inclusion of new features, than I agree python is walking a dangerous road. But that also means Type Hints aren't the real problem here. We have a much bigger problem about the programming language principles and phylosophy. In all honesty though, I never cared much about the ideals and zens in programming languages, especially ones want to want to adopt a batteries-included philosophy. Always seemed to me like nonsense talk. My experience taught me that you can't just have the latter without eventually breaking the former. 'import this' always read to me like wishful thinking. Python isn't going anywhere towards obscurity. Not at least until a competiting language comes (it hasn't yet). I agree though that Python complexity has increased greatly over the years and this isn't showing any signs of stopping. And that is exactly the type of thing that promotes the birth of a new and better programming language. And, interestingly enough, that is always a good thing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Chris, Hold on a moment, how often do you really do this kind of thing with might be one of them or a sequence? Is it really that important that I give a more real-life example, or can't you just get the problem from a ad-hoc example? I could replace the variable names with spam, ham and eggs, if you wish. -- https://mail.python.org/mailman/listinfo/python-list
Python is DOOMED! Again!
On Thursday, 22 January 2015, Chris Angelico ros...@gmail.com javascript:_e(%7B%7D,'cvml','ros...@gmail.com'); wrote: On Thu, Jan 22, 2015 at 7:10 PM, Mario Figueiredo mar...@gmail.com wrote: Possibly one common use case will be Unions. And that factory syntax is really awful and long when you look at a function definition with as little as 3 arguments. The one below has only 2 arguments. def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) - Union[Employee, Sequence[Employee], None]: Hold on a moment, how often do you really do this kind of thing with might be one of them or a sequence? Do you really have a function that could take an Employee and a float, or a sequence of Employees and a single float, or a single Employee and a sequence of floats, or a sequence of both? Or do you, much more likely, actually have two separate functions: def handle_employee(emp: Employee, raise: float) - Optional[Employee]: def handle_employees(emp: Sequence[Employee], raise: Sequence[float]) - List[Employee]: The union in the return value seems particularly unlikely... and unhelpful. Hang on! The particular example may not make a lot of sense but there are plenty of places in ordinary Python where functions can accept different objects in arguments and return different things. The point here is that that will become rapidly messy and hard to read. Perhaps the new PEP will discourage this kind of thing and perhaps that is to be welcomed not feared, but I don't think the example itself was particularly contrived. I've seen it in plenty of code in the wild. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 9:46 PM, Nicholas Cole nicholas.c...@gmail.com wrote: Hang on! The particular example may not make a lot of sense but there are plenty of places in ordinary Python where functions can accept different objects in arguments and return different things. The point here is that that will become rapidly messy and hard to read. Yes; but with proper use of TypeVar can simplify things a lot - have a read of the PEP. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 9:37 PM, Mario Figueiredo mar...@gmail.com wrote: Chris, Hold on a moment, how often do you really do this kind of thing with might be one of them or a sequence? Is it really that important that I give a more real-life example, or can't you just get the problem from a ad-hoc example? I could replace the variable names with spam, ham and eggs, if you wish. I'd rather see a real-world example that can't be solved with either better design or some simple aliases. (And yes, the type hinting does allow for aliases.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 22/01/2015 18:14, Skip Montanaro wrote: On Thu, Jan 22, 2015 at 12:03 PM, Sturla Molden sturla.mol...@gmail.com mailto:sturla.mol...@gmail.com wrote: Python will no longer be dynamic, it will just be a slow static language. Yes, Python could still be used as a dynamic language, but nobody will allow you to do it. Even packages in widespread use will be banned because they don't typehint. And then there will be complaint about lack of such packages. FUD? What evidence do you have that this will be the way things shake out? Evidence in completely the opposite direction if I'm reading this correctly https://www.python.org/dev/peps/pep-0484/#usage-patterns The main use case of type hinting is static analysis using an external tool without executing the analyzed program. Existing tools used for that purpose like pyflakes [pyflakes] or pylint [pylint] might be extended to support type checking. New tools, like mypy's mypy -S mode, can be adopted specifically for this purpose. Type checking based on type hints is understood as a best-effort mechanism. In other words, whenever types are not annotated and cannot be inferred, the type checker considers such code valid. Type errors are only reported in case of explicit or inferred conflict. Moreover, as a mechanism that is not tied to execution of the code, it does not affect runtime behaviour. In other words, even in the case of a typing error, the program will continue running. The implementation of a type checker, whether linting source files or enforcing type information during runtime, is out of scope for this PEP. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Fri, Jan 23, 2015 at 5:03 AM, Sturla Molden sturla.mol...@gmail.com wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Remember too that type-hinting will *absolutely* remain *completely* optional for Python. Developers can choose to use it or not, No! Developers have to do what managers and customers tell them to do. They will start to require type hinting everywhere. And then the question is what Python has to offer over Java or Swift. Uhh... if your managers and customers are stipulating non-Pythonic coding styles, then it's time to find new managers/customers. If they're not writing the code, code quality shouldn't be their concern. Of course, if you want to switch to Swift, sure, but I'm going to keep working on Python. Just please don't FUD this list. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue11024] imaplib: Time2Internaldate() returns localized strings
Alessio added the comment: Not working patch, if I use this method on append I've all messages with 1970 year -- nosy: +Pilessio ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11024 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7334] ElementTree: file locking in Jython 2.5 (OSError on Windows)
Berker Peksag added the comment: Should a new issue be opened or should this ticket be re-opened? It's a 3 years old backport, I'd say open a new issue. -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7334 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23300] httplib is using a method that doesn't exist
Demian Brecht added the comment: @Senthil: If you're fixing this today, can you also correct the typo here: https://hg.python.org/cpython/rev/568041fd8090/#l1.27 (s/HTML/HTTP)? Just caught my eye going through the review that Mark linked. -- nosy: +demian.brecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23300 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015, at 13:28, Mark Lawrence wrote: Evidence in completely the opposite direction if I'm reading this correctly https://www.python.org/dev/peps/pep-0484/#usage-patterns The main use case of type hinting is static analysis using an external tool without executing the analyzed program. Existing tools used for that purpose like pyflakes [pyflakes] or pylint [pylint] might be extended to support type checking. New tools, like mypy's mypy -S mode, can be adopted specifically for this purpose. How is that the opposite direction? It's a short jump from there to pylint [or whatever tool] will consider a lack of type hinting to be something to warn for and managers/customers will consider this warning to mean your program has failed and is unacceptable. -- https://mail.python.org/mailman/listinfo/python-list
[issue23300] httplib is using a method that doesn't exist
Senthil Kumaran added the comment: Demian, sure, will do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23300 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: -giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23301] ConfigParser does not handle square brackets in section name
R. David Murray added the comment: This is a duplicate of issue 20923, which was rejected. To argue against the rejection you probably need to provide evidence that this is something that is actually supported by other common ini parsers. And that evidence should be posted to issue 20923. -- nosy: +r.david.murray resolution: - duplicate stage: - resolved status: open - closed superseder: - ConfigParser should nested [] in section names. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23301 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23299] Documentation correction - 5.1.4. List Comprehensions
R. David Murray added the comment: vec has not been changed. The example is correct. Give it a try :) -- nosy: +r.david.murray resolution: - not a bug stage: - resolved status: open - closed type: resource usage - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Socket ICMP V6 error
ermanolillo ermanoli...@hotmail.com writes: HOST is send by the keyboard. It´s the IPv6 address of my interface eth0. For example, FE80::0202:B3FF:FE1E:8329. This is a link-local address, you can't use it just like that (you may have several interfaces with the same link-local addr). Use getaddrinfo on FE80...%eth0 (change eth0 to the name of the interface you want to use) to get a valid 4-tuple. Use that instead of your (HOST,0). You can also try '::' (kind of inaddr6_any), I don't know if that's what you want. But I think you can't bind a raw socket in IPv6. (Not sure, try it and see.) -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: Socket ICMP V6 error
On Fri, Jan 23, 2015 at 2:24 AM, ermanolillo ermanoli...@hotmail.com wrote: HOST is send by the keyboard. It´s the IPv6 address of my interface eth0. For example, FE80::0202:B3FF:FE1E:8329. I can't duplicate the problem. Are you certain that this is indeed an appropriate address? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23301] ConfigParser does not handle square brackets in section name
New submission from Sebastian Bank:
ConfigParser parses section lines containing square brackets like '[spam [eggs]
spam]' up to the first instead of the last occurrence of ']' preventing
roundtrips:
s = StringIO()
c1 = ConfigParser()
c1.add_section('spam [eggs]')
c1.write(s)
s.seek(0)
c2 = ConfigParser()
c2.readfp(s)
assert c1.sections() == c2.sections() # fails
Potential fix: change the second line of SECTCRE from r'(?Pheader[^]]+)' to
r'(?Pheader.+?)'.
If the parsing behaviour cannot be changed, the user should at least be warned
about supplying data that breaks the roundtrip.
--
components: Library (Lib)
messages: 234497
nosy: xflr6
priority: normal
severity: normal
status: open
title: ConfigParser does not handle square brackets in section name
type: behavior
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23301
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 07:26:31AM -0500, Gene Heskett wrote: Still (somehow) alive in neo-Amiga platforms like AmigaOS4.x, MorphOS and AROS. I know that's as good as dead but there are still people writing AREXX glue code. He asked about REXX, not AREXX. There is no comparison between the two as AREXX was a huge superset of REXX. Never seeing a proper REXX I always assumed it's just Amiga port retrofitted to serve as OS' needs as IPC language. You learn everyday. If, when anyone here was using an amiga, and was using EzCron to schedule stuff, Jim Hines and I wrote it as there was no such scheduler for amigados. I used few cron-like daemons and the name rings a bell! Trivia bit: William Hawes, who wrote AREXX and sold it thru the commode door sales channels, was never paid a dime for his work. There are still problems with AREXX copyright/distribution, but as you can guess after few changes of hand Amiga's IP is mess. AROS, begin FOSS reimplementation of AmigaOS API, uses Regina to replace AREXX http://regina-rexx.sourceforge.net/ -- vag·a·bond adjective \ˈva-gə-ˌbänd\ a : of, relating to, or characteristic of a wanderer b : leading an unsettled, irresponsible, or disreputable life -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Rick Johnson rantingrickjohn...@gmail.com: On Thursday, January 22, 2015 at 1:23:11 PM UTC-6, Marko Rauhamaa wrote: Because he's one of the more prevalent boot licking rabbid fanboys of GvR. You are out of line, but then, you never pretended otherwise. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 7:16 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Meanwhile, there's the strange decision to implement type hints for
local variables # comment lines. I have an hard time wrapping my head
around this one. Really, comments!?
Yes, really. There is plenty of prior art for machine-meaningful comments:
- mypy uses it, and it works fine
- Pascal uses {$ ...} compiler directives
- Unix uses a special hash-bang #! comment in the first line to
specify the executable that runs the script
- Python supports a special encoding declaration using #
- doctest uses comments for directives
- HTML puts code (Javascript usually) inside of comments
- JMSAssert for Java uses comments for design-by-contract assertions
Perhaps even more relevant to PEP 484:
- The Closure compiler for Javascript uses JSDoc tags in comments for
static typing and analysis.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 3:08 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Thu, Jan 22, 2015 at 2:56 PM, Emile van Sebille em...@fenx.com wrote:
I've been lightly scanning and following the PEP 484 discussion, and one
point I don't think I've seen mentioned is how you might hint a function
that accepts different types, eg:
def adder(a,b): return a+b
This is one of the pythonic idioms that help with polymorphic functions. Is
there a proposal for providing hinting for these?
You can use TypeVar for that.
T = TypeVar('T')
def adder(a: T, b: T) - T:
return a + b
I'm not thrilled about having to actually declare T in this sort of
situation, but I don't have a better proposal.
Hmm, but also that hinting doesn't cover cases like adder(12, 37.5)
where two different types can be passed, and the return type could be
either. I think for full generality you would just have to forgo
hinting on this function.
--
https://mail.python.org/mailman/listinfo/python-list
[issue21862] cProfile command-line should accept -m module_name as an alternative to script path
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21862 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 2:12 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
def adder(a,b): return a+b
This is one of the pythonic idioms that help with polymorphic functions. Is
there a proposal for providing hinting for these?
You can use TypeVar for that.
T = TypeVar('T')
def adder(a: T, b: T) - T:
return a + b
I'm not thrilled about having to actually declare T in this sort of
situation, but I don't have a better proposal.
Hmm, but also that hinting doesn't cover cases like adder(12, 37.5)
where two different types can be passed, and the return type could be
either. I think for full generality you would just have to forgo
hinting on this function.
Or use Any, which is basically the same thing:
def adder(a: Any, b: Any) - Any:
return a + b
Chris
--
https://mail.python.org/mailman/listinfo/python-list
[issue23303] test_license_exists_at_url() of test_site fails on x86 XP-4 3.4 buildbot
New submission from STINNER Victor: test_license_exists_at_url() of test_site fails on x86 XP-4 3.4 buildbot. I don't understand why the test pass on x86 XP-4 3.x, is it the same server? http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/747/steps/test/logs/stdio == ERROR: test_license_exists_at_url (test.test_site.ImportSideEffectTests) -- Traceback (most recent call last): File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 1182, in do_open h.request(req.get_method(), req.selector, req.data, headers) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py, line 1088, in request self._send_request(method, url, body, headers) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py, line 1126, in _send_request self.endheaders(body) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py, line 1084, in endheaders self._send_output(message_body) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py, line 922, in _send_output self.send(msg) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py, line 857, in send self.connect() File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py, line 1231, in connect server_hostname=server_hostname) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\ssl.py, line 365, in wrap_socket _context=self) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\ssl.py, line 583, in __init__ self.do_handshake() File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\ssl.py, line 810, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600) During handling of the above exception, another exception occurred: Traceback (most recent call last): File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\test\test_site.py, line 426, in test_license_exists_at_url with urllib.request.urlopen(req) as data: File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 161, in urlopen return opener.open(url, data, timeout) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 469, in open response = meth(req, response) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 579, in http_response 'http', request, response, code, msg, hdrs) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 501, in error result = self._call_chain(*args) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 441, in _call_chain result = func(*args) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 684, in http_error_302 return self.parent.open(new, timeout=req.timeout) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 463, in open response = self._open(req, data) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 481, in _open '_open', req) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 441, in _call_chain result = func(*args) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 1225, in https_open context=self._context, check_hostname=self._check_hostname) File D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py, line 1184, in do_open raise URLError(err) urllib.error.URLError: urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600) -- components: Tests keywords: buildbot messages: 234510 nosy: alex, haypo, pitrou priority: normal severity: normal status: open title: test_license_exists_at_url() of test_site fails on x86 XP-4 3.4 buildbot versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23303 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23303] test_license_exists_at_url() of test_site fails on x86 XP-4 3.4 buildbot
STINNER Victor added the comment: The URL is http://www.python.org/psf/license/ wget tells me that the URL is directed to https://www.python.org/psf/license/ which is redirected to https://docs.python.org/license.html which is redirected to https://docs.python.org/2/license.html. According to Firefox, docs.python.org uses a certificate signed by DigiCert Inc with the CN www.python.org (hum, it should not be docs.python.org ?). Same failure on x86 Windows7 3.4: http://buildbot.python.org/all/builders/x86%20Windows7%203.4/builds/713/steps/test/logs/stdio And x86 Ubuntu Shared 3.4: http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.4/builds/795/steps/test/logs/stdio -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23303 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23304] Unused Superclass in calendar.py
New submission from CliffM: calendar.py ( lines 17,18 ) is not used : # Exception raised for bad input (with string parameter for details) error = ValueError This could either be deleted OR used as the superclass in the next two class declarations as the comment suggests. -- components: Library (Lib), Tests messages: 234513 nosy: CliffM priority: normal severity: normal status: open title: Unused Superclass in calendar.py versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23304 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: Why would that simplify things? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Sorry, I don't know enough about how you were planning on using the stack pointer difference to produce good errors. I thought that if you waited for the CALL_FUNCTION to be happening before reporting errors about duplicate parameters it might simplify that code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23304] Unused Superclass in calendar.py
Changes by SilentGhost ghost@gmail.com: -- keywords: +easy versions: +Python 3.5 -Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23304 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 2:56 PM, Emile van Sebille em...@fenx.com wrote:
I've been lightly scanning and following the PEP 484 discussion, and one
point I don't think I've seen mentioned is how you might hint a function
that accepts different types, eg:
def adder(a,b): return a+b
This is one of the pythonic idioms that help with polymorphic functions. Is
there a proposal for providing hinting for these?
You can use TypeVar for that.
T = TypeVar('T')
def adder(a: T, b: T) - T:
return a + b
I'm not thrilled about having to actually declare T in this sort of
situation, but I don't have a better proposal.
--
https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: I phrased that badly. Whilst I can see minor simplifications to BUILD_MAP_UNPACK, the only way to add more information to CALL_FUNCTION_XXX would be through EXTENDED_ARG. This seems like it would outweigh any benefits, and the tiny duplication of error checking removed would be far dwarfed by the unpacking code in CALL_FUNCTION_XXX. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23152] fstat64 required on Windows
STINNER Victor added the comment: Currently test_largefile is failing on the Windows buildbots Oh yes, I just noticed the following bug on AMD64 Windows8 3.x: http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/307/steps/test/logs/stdio [352/391/1] test_largefile Assertion failed: (result != NULL !PyErr_Occurred()) || (result == NULL PyErr_Occurred()), file ..\Objects\abstract.c, line 2095 R6010 - abort() has been called Fatal Python error: Aborted Current thread 0x0ec8 (most recent call first): File D:\buildarea\3.x.bolen-windows8\build\lib\test\test_largefile.py, line 83 in test_lseek File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\case.py, line 577 in run File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\case.py, line 625 in __call__ File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py, line 125 in run File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py, line 87 in __call__ File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py, line 125 in run File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py, line 87 in __call__ File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py, line 125 in run File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py, line 87 in __call__ File D:\buildarea\3.x.bolen-windows8\build\lib\unittest\runner.py, line 168 in run File D:\buildarea\3.x.bolen-windows8\build\lib\test\support\__init__.py, line 1770 in _run_suite File D:\buildarea\3.x.bolen-windows8\build\lib\test\support\__init__.py, line 1804 in run_unittest File D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py, line 1283 in test_runner File D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py, line 1284 in runtest_inner File D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py, line 967 in runtest File D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py, line 763 in main File D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py, line 1568 in main_in_temp_cwd File D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py, line 1593 in module -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23152 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5309] distutils doesn't parallelize extension module compilation
Berker Peksag added the comment: Here's a doc patch. -- nosy: +berker.peksag Added file: http://bugs.python.org/file37824/issue5309-doc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5309 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On 1/21/2015 8:30 PM, Steven D'Aprano wrote: snip Here's an example from PEP 484: def greeting(name: str) - str: return 'Hello ' + name I've been lightly scanning and following the PEP 484 discussion, and one point I don't think I've seen mentioned is how you might hint a function that accepts different types, eg: def adder(a,b): return a+b This is one of the pythonic idioms that help with polymorphic functions. Is there a proposal for providing hinting for these? Thanks, Emile -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: In that case, another option would be to use that to send the number of maps to CALL_FUNCTION and let it do the BUILD_MAP_UNPACK stuff itself. Would that simplify your ideas regarding error handling? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe()
Roundup Robot added the comment: New changeset 1e3a1af0705f by Victor Stinner in branch '3.4': Issue #23293, asyncio: Rewrite IocpProactor.connect_pipe() https://hg.python.org/cpython/rev/1e3a1af0705f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe()
STINNER Victor added the comment: Issue fixed: IocpProactor.connect_pipe() doesn't use blocking operations anymore, it's now implemented as polling with non blocking operations. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
In article 6eb91c4b-92ff-44a8-b5a9-6ef04c71f...@googlegroups.com, rantingrickjohn...@gmail.com says... So if the purpose is static analysis, what is the justification for injecting new syntax into function sigs? 1. Annotations where created exactly for this purpose. So there's some preassure to put them to work on what they were always meant to be used for. 2. Docstrings are meant as source of code documentation and to fill the object's __doc__ attribute, as per PEP 257. As such they aren't good consistent candidates for type hinting for purposes of static analysis tools. 3. Decorators are meant as function transformation tools, as per PEP 318 and, as such, are them too not suitable to include type annotations for the purpose of static analysis. 4. There is no other formal annotation mechanism, other than these potential three. Arguably, you can make a case against 1. And that's my own issue with type hinting as it is being proposed on PEP 484. The real problem is annotations as they were defined are a really bad idea. To couple type annotations so tightly with code, just results in plain ugly and hard to read code. Personally I would love to see the present annotations just go away and a new docstring-like structure to emerge in their place. But that's probably not going to happen. What I agree can't be done though, is to use docstrings or decorators as a source for type annotations. -- https://mail.python.org/mailman/listinfo/python-list
Re: apostrophe not considered with tkinter's wordstart and wordend
Am 05.01.15 um 14:20 schrieb Rick Johnson:
*GASP*! Of course all this could be avoided if those short-
sighted TK folks would have allowed the programmer to define
the pattern!
ಠ_ಠ
Well, it turns out you actually can. We don't have Guido's time machine,
but still there is a configuration option in Tk, albeit a very obscure
one: you have to set the global Tcl variables tcl_wordchars and
tcl_nonwordchars after loading Tk to a regexp which defines the word
boundaries:
http://wiki.tcl.tk/1655
Strangely, there is a different preset for Windows and X11. The Windows
preset - consider everything besides space as part of the word - makes
more sense to me than the Unix default, which only counts letters,
numbers and underscores as part of the word. To set the Windows preset,
do this:
tk.eval('set tcl_wordchars {\S}');
tk.eval('set tcl_nonwordchars {\s}');
(untested in Python, only tested directly from a wish shell)
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 2015-01-22, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: You can't use raise as a parameter name, since that's a keyword. Using floats for money is Just Wrong and anyone who does so should have their licence to program taken away. And I really don't understand what this function is supposed to do, that it returns None, a single Employee, or a sequence of Employees. (If it's hard to declare what the return type is, perhaps your function does too much or the wrong thing.) That makes me think - it seems odd to me that PEP 484 doesn't even mention function overloading (even to say that it's outside the scope). I think overloading should certainly be considered, and unless the consensus is that it is something that should never happen, it should either be explicitly allowed or at least the type-hinting syntax should be checked to ensure it is forward-compatible with it. -- https://mail.python.org/mailman/listinfo/python-list
[issue23300] An improper change in httplib.py
Brett Cannon added the comment: That leading underscore in the method name means it is not a public API and thus changes are allowed without any backwards-compatibility guarantees. Mercurial will need to update their code to handle this if they want to continue to use the method. -- nosy: +brett.cannon resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23300 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
Chris Angelico wrote: Hold on a moment, how often do you really do this kind of thing with might be one of them or a sequence? isinstance(obj, one_class_or_tuple_of_classes) issubclass(cls, one_class_or_tuple_of_classes) mystr.startswith(prefix_or_tuple_of_prefixes) mystr.endswith(suffix_or_tuple_of_suffixes) template % one_string_or_tuple_of_strings # or a dict :-) I'm not suggesting that the specific example is a good one, but the principle is sound. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Fri, Jan 23, 2015 at 1:16 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Mario Figueiredo wrote: def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) - Union[Employee, Sequence[Employee], None]: Using floats for money is Just Wrong and anyone who does so should have their licence to program taken away. But using a float to specify a percentage raise that an employee (or class of employees) gets would be reasonable. You could handle all your problem employees by giving them an across-the-board 3% raise to try to stop them from going on strike (they have a Union, as we can see there, so strikes are clearly possible). Not that that matters to the typing question. If it really is a monetary type, all you need to do is replace 'float' with 'Money' which would be a superclass to USD, AUD, GBP, and RepublicCredits. There's still the question of what it's doing. My best guess about this function is that it has three modes: 1) handle_employee(emp: Employee, pay_raise: float) Give one employee a percentage raise. (Note the different function name.) 2) handle_employees(emp: Sequence[Employee], pay_raise: float) Give all these employees the same percentage raise. 3) handle_employees(emp: Sequence[Employee], pay_raise: Sequence[float]) Equivalent to [handle_employee(e, r) for e, r in zip(emp, pay_raise)] I can't figure out any sane meaning for passing a single employee and a sequence of floats, and I think the one-and-one case should have a different name. That would mean that there's really only one Union involved, and the plural function would look like this: def handle_employees(emp: Sequence[Employee], pay_raise: Union[float, Sequence[float]]): Atomically give many employees raises. If pay_raise is a float, gives each employee that raise; otherwise, it should be a sequence of the same length as emp. if isinstance(pay_raise, collections.Sequence): for e, r in zip(emp, pay_raise): handle_employee(e, r) else: for e in emp: handle_employee(e, pay_raise) But I still have no clue what the return value of either the one-and-one case or the multiple case should be. (3) Have a shorter way to declare Spam or Sequence (tuple?) of Spam. def handle_employees( emp: OneOrMore[Employee], pay_raise: OneOrMore[int]) - OneOrMore[Employee] | None: pass Yes, that would be a reasonable thing. It might even be possible to implement it on top of TypeVar. That said, though, APIs that accept just one, or maybe more have problems; for instance, you can't write a pretty-print function that can take either an arbitrary object, or a sequence of arbitrary objects. Fundamentally not possible. But when you can guarantee that the thing you're getting OneOrMore of is not itself iterable, it would be useful. Meanwhile there's quite a few more generics like the Sequence one above you may want to take a look at and try and remember. And that's just one factory (the generics support factory). You may also want to take a look at TypeVar and Callable for more syntactic hell. Exaggerate, much? Maybe. Callable does get pretty hairy; specifying the arguments and return values of a function is never pretty. Pike is no better: typeof(write); (1) Result: function(array(string) | string, mixed ... : int) That's a function which takes either a single string or an array of strings, followed by any number of additional arguments, and returns an integer. typeof(GTK2.setup_gtk); (2) Result: function(void | array(string) | string, void | int : array(string)) Optional arguments: one or more strings, and maybe an integer. Returns an array of strings. typeof(rm); (3) Result: function(string : int) This one's pretty simple. It takes a string (path name), and returns an integer (success or failure flag). And deletes a file/directory. typeof(asin); (4) Result: function(int | float : float) Could take an integer or a float, and returns a float. The PEP 484 equivalents would be, I think: write = Callable[[Union[str, Sequence[str]], AnyArgs], int] # I have no idea how to do optional args. rm = Callable[[str], int] asin = Callable[[Union[int, float]], float] It's not too bad when the function signature is really simple. And that's going to be the common case. But it is syntactically complicated to type-check a callback's arguments. Imagine, for instance, GUI toolkit callbacks; chances are you can stuff extra args into them (so they need a *args equivalent at the end), and they'll take a variety of different args. They will not be pretty... or else they'll be type-hinted simply as Callable, with nothing else. But ultimately, that's not a fault of the type hinting structure. It's a natural consequence of the complexity of callbacks. You can't get away from it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23298] Add ArgumentParser.add_mutually_dependence_group
Changes by R. David Murray rdmur...@bitdance.com: -- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Fri, Jan 23, 2015 at 1:57 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: Hold on a moment, how often do you really do this kind of thing with might be one of them or a sequence? isinstance(obj, one_class_or_tuple_of_classes) issubclass(cls, one_class_or_tuple_of_classes) mystr.startswith(prefix_or_tuple_of_prefixes) mystr.endswith(suffix_or_tuple_of_suffixes) template % one_string_or_tuple_of_strings # or a dict :-) I'm not suggesting that the specific example is a good one, but the principle is sound. All of your examples are might be one of them or a tuple. Not sequence, tuple. That gets around the problem of recognition, because in no case is a single tuple a valid argument. I suspect it would be possible to use TypeVar to create a nice OneOrMore like you suggested, but for reliability, it should probably be or tuple rather than or sequence. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Socket ICMP V6 error
HOST is send by the keyboard. It´s the IPv6 address of my interface eth0. For example, FE80::0202:B3FF:FE1E:8329. Thanks -- View this message in context: http://python.6.x6.nabble.com/Socket-ICMP-V6-error-tp5083962p5083982.html Sent from the Python - python-list mailing list archive at Nabble.com. -- https://mail.python.org/mailman/listinfo/python-list
[issue23298] Add ArgumentParser.add_mutually_dependence_group
R. David Murray added the comment: Well, it doesn't make much sense in the English language sense. If I got that error message I'd have no idea what was wrong. It sounds like what you want to do is dynamically make some arguments be required, depending on whether or not other arguments are present or not. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
Ian Kelly ian.g.ke...@gmail.com writes:
T = TypeVar('T')
def adder(a: T, b: T) - T: ...
I'm not thrilled about having to actually declare T in this sort of
situation, but I don't have a better proposal.
Oh man, that's ugly. Maybe a decorator would be a bit less awful:
@-typevar T
def adder(a: T, b: T) - T: ...
I'm using @- for a hypothetical decorator that receives the AST for the
stuff on the rest of the line, instead of being evaluated as a function.
The above looks sort of like C++, which would say
template typename T
T addr (T a, T b) { ... }
--
https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment:
We wouldn't actually need to raise it from somewhere else; the line numbering
and frame are already correct. The only difficulty is that the traceback
currently says
# func(a=1, **{'a': 1})
TypeError: func() got multiple values for keyword argument 'arg'
To do this from the UNPACK opcode would require knowing where the function is
in order to print its name. (We also need to know whether to do the check at
all, so we'd be hijacking some bits the UNPACK opcode anyway.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[RELEASE] ‘python-daemon’ version 2.0.4 released
Howdy all, I am pleased to announce the release of version 2.0.4 of the ‘python-daemon’ library. The current release is always available at URL:https://pypi.python.org/pypi/python-daemon/. The project's forums and VCS are hosted at Alioth URL:https://alioth.debian.org/projects/python-daemon/. Significant changes since the previous version == This is a bug fix release, addressing packaging bugs: * Remove custom Setuptools entry points. This addresses a bug reported by many people (thanks!) who found subsequent Setuptools actions impacted by these entry points. * Write version info metadata using Setuptools ‘egg_info’ command. What is the ‘python-daemon’ library? ‘python-daemon’ is a Python library to implement a well-behaved Unix daemon process. -- \ “The way to build large Python applications is to componentize | `\ and loosely-couple the hell out of everything.” —Aahz | _o__) | Ben Finney b...@benfinney.id.au -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: The function object that's on the stack. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Friday, January 23, 2015 at 2:55:38 AM UTC+5:30, Ian wrote:
On Thu, Jan 22, 2015 at 7:16 AM, Steven D'Aprano wrote:
Meanwhile, there's the strange decision to implement type hints for
local variables # comment lines. I have an hard time wrapping my head
around this one. Really, comments!?
Yes, really. There is plenty of prior art for machine-meaningful comments:
- mypy uses it, and it works fine
- Pascal uses {$ ...} compiler directives
- Unix uses a special hash-bang #! comment in the first line to
specify the executable that runs the script
- Python supports a special encoding declaration using #
- doctest uses comments for directives
- HTML puts code (Javascript usually) inside of comments
- JMSAssert for Java uses comments for design-by-contract assertions
Perhaps even more relevant to PEP 484:
- The Closure compiler for Javascript uses JSDoc tags in comments for
static typing and analysis.
I have not studied this carefully... so no opinion
However Peyton Jones is known to have said that for Haskell,
Haskell is on a Damas-Milner cusp -- basically if haskell's type system
becomes any more sophisticated, then automatic type inference becomes
undecidable
http://repository.upenn.edu/cgi/viewcontent.cgi?article=1336context=cis_papers
Personally I find the predecessor of Haskell, gofer, prettier than Haskell
precisely because Haskell's type system has become too 'clever':
See my answer
http://stackoverflow.com/questions/25855507/are-typeclasses-essential
What has all this to do with python?? Dunno
Just that the 'optionality' of type-hinting may not be quite straightforward
PS Ian for a hot thread like this its good to put quotes carefully
You are quoting Steven quoting somebody -- dunno who that somebody is
--
https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: when does that get pushed on the stack? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: Just before any arguments to the function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python Sanity Proposal: Type Hinting Solution
On 1/22/2015 8:15 PM, Rick Johnson wrote:
Okay, i have found a solution to the type hinting problem
that will appease both sides. On one side we have those who
are proposing type hinting annotations within function sigs,
and on the other side, we have those who oppose the
implementation of type hinting via this method because of
the readability concerns. The solution is move the type
hinting syntax completely out of the source file and into
another file -- think of it as a Python Type Hinting Header
File.
This idea is so brilliant that it is already an option in mypy and is
part of the new type-hint proposal. The separate type-hint files are
called 'stub files'. I don't know what the extension is. These will be
used for the stdlib, which will not have annotations in the .py files
(2) Define a spec for writing annotations that will map to
funcs/methods of the same name. I would argue to keep the
spec compact, but i really don't care about the spec at
this point.
It will use the one proposed, with whatever modification still to come.
I believe stub files can also be used for functions defined in C.
Simplistic Example Code utilizing two files:
# scriptA.py
def greeting(name):
return 'Hello ' + name
# scriptA.typehints
greeting{name:str} - str
I believe stub files can also be used for functions defined in C.
Benefits:
(1) Removes the noisy syntax from the source file. Python
code will remain as clean tomorrow as it is today.
This will at least be an option. You are and will be free to advocate
that people always use stub files.
(2) Puts the onerous on the author *NOT* on the reader.
This system utilizes a concept known as Level Of Detail
(or LOD). LOD means that i should not need to see a type
hint unless i *WANT* to see a type hint.
One thing not discussed here (but was in the earlier python-ideas thread
some months ago) is that some groups have standards for using some
functions that is stricter than the function's full duck-typing
generality. A stub file allows a group to specify a restrictive use
annotation for their static checker without putting lies into the code
or doc of the function itself.
(3) If i decide i don't want type hints in my code, all i
have to do is delete or rename a file, which is much less
error prone then editing source code.
If the annotations are in a separate file, deleting will hardly be
necessary since the file will be ignored until one runs software that
uses it.
(4) Has the added benefit of aiding when debugging type hints.
I am not sure what you mean here. It will be easier to temporarily
comment out an incorrect annotation for a function, pending correction,
when in a separate file.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
On 2015-01-23 01:15, Rick Johnson wrote:
Note: This is the closest you're going to get to a PEP from me!
Okay, i have found a solution to the type hinting problem
that will appease both sides. On one side we have those who
are proposing type hinting annotations within function sigs,
and on the other side, we have those who oppose the
implementation of type hinting via this method because of
the readability concerns. The solution is move the type
hinting syntax completely out of the source file and into
another file -- think of it as a Python Type Hinting Header
File.
Summary
(1) Agree on a file extension that python will recognize
as containing type hint specs. Unfortunately we cannot
use .pth, which would be the perfect acronym for Python
Type Hints, so choose something else. :-(
(2) Define a spec for writing annotations that will map to
funcs/methods of the same name. I would argue to keep the
spec compact, but i really don't care about the spec at
this point.
Simplistic Example Code utilizing two files:
#
# scriptA.py
#
def greeting(name):
return 'Hello ' + name
#
# scriptA.typehints
#
greeting{name:str} - str
Benefits:
(1) Removes the noisy syntax from the source file. Python
code will remain as clean tomorrow as it is today.
(2) Puts the onerous on the author *NOT* on the reader.
This system utilizes a concept known as Level Of Detail
(or LOD). LOD means that i should not need to see a type
hint unless i *WANT* to see a type hint. You can think of
it as akin to Java @string resources.
(3) If i decide i don't want type hints in my code, all i
have to do is delete or rename a file, which is much less
error prone then editing source code.
(4) Has the added benefit of aiding when debugging type hints.
You also need to handle methods.
A simple way would be to use indentation:
# scriptA.py
class Greeter:
def __init__(self, name):
self.name = name
def greet(self):
print('Hello,', self.name)
def greeting(name):
return 'Hello ' + name
# scriptA.typehints
Greeter:
__init__(self, name: str)
greeting{name: str} - str
I'm not sure about the best format for functions within functions. This
repeats the function name:
# scriptB.py
def greet(name):
def make_message():
return 'Hello,' + name
print(make_message())
# scriptB.typehints
greet(name: str)
greet:
make_message() - str
But a shorter version might not be clear:
# scriptB.typehints
greet(name: str):
make_message() - str
especially when the outer function has a hint for its return type!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 1/22/2015 7:40 PM, Sturla Molden wrote: On 22/01/15 21:03, Mario Figueiredo wrote: That is fine. But then the problem isn't type hinting, is it? Neither I think you are suggesting we don't introduce language because there are bad project managers out there. The problem is then bad project managers. That has nothing to do with type hinting, or Python for that matter. It has everything to do with Python if we facilitate them. Type hinting will be mandatory because of bad managers. But then someone is going to ask what benefit Python has to offer: Readabiliy? No ... down the drain. Type hints can be put in separate stub files and will be put in separate files for the stdlib. If a client want to pay you to write type stubs, and you cannot stand to do it for even for pay, I am sure you will be able to subcontract the work. I am sure someone will write python probrams to make the process easier. Many Pythonistas would be glad to see more work, not bitch about it. Readability? Unchanged (at least for your own code and much of the rest). Dynamic typing? No ... down the drain. ??? Python objects will still be dynamically typed. For the present, compilation will be completely uneffected. Dynamic typing? unchanged. Speed? No ... still 200x slower than Swift. Sturla, I *know* you must have heard of numpy? cython? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Fri, Jan 23, 2015 at 2:11 PM, Rustom Mody rustompm...@gmail.com wrote: 1. [1,2,3] + [4,5,6] uses the same symbol for an unrelated operation 1 + 4 They're not unrelated operations. Maybe in the purity of mathematics they're distinct, but in the practical world of getting-stuff-done programming, they're the same operation, as is string concatenation. It makes perfect sense to use the same symbol for all of them. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 1/22/2015 3:44 PM, Rick Johnson wrote: On Thursday, January 22, 2015 at 12:28:47 PM UTC-6, Mark Lawrence wrote: Evidence in completely the opposite direction if I'm reading this correctly [snip link] The main use case of type hinting is static analysis using an external tool without executing the analyzed program. Existing tools used for that purpose like pyflakes [pyflakes] or pylint [pylint] might be extended to support type checking. New tools, like mypy's mypy -S mode, can be adopted specifically for this purpose. So if the purpose is static analysis, what is the justification for injecting new syntax into function sigs? The syntax was put there years ago. I'm not *TOTALLY* against the idea of type hints, but i am *TOTALLY* against their proposed location. Unlike other annotations, type annotations can be put in a separate stub file. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment:
No, that happens in CALL_FUNCTION_KW:
import dis
dis.dis(f(x=1, **{'x': 1}))
1 0 LOAD_NAME0 (f)
3 LOAD_CONST 0 ('x')
6 LOAD_CONST 1 (1)
9 LOAD_CONST 1 (1)
12 LOAD_CONST 0 ('x')
15 BUILD_MAP1
18 CALL_FUNCTION_KW 256 (0 positional, 1 keyword pair)
21 RETURN_VALUE
There's no call to BUILD_MAP_UNPACK at all. Namely, it's raised from
update_keyword_args (in turn from ext_do_call).
--- Tangential note: ---
In fact, it seems the only reason we keep the mess of unpacking in two places
rather than just using BUILD_TUPLE_UNPACK and BUILD_MAP_UNPACK unconditionally
is that CALL_FUNCTION_XXX looks to be slightly more efficient by only dealing
with the case of a single unpack at the end. I think I see how to make the
_UNPACKs fast enough for this case, though, so maybe we could remove it and
unify a few things. I'd need to write it up, though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python Sanity Proposal: Type Hinting Solution
On Fri, Jan 23, 2015 at 2:22 PM, Terry Reedy tjre...@udel.edu wrote: This idea is so brilliant that it is already an option in mypy and is part of the new type-hint proposal. The separate type-hint files are called 'stub files'. It's worth pointing out, too, that the idea isn't panaceaic - it's just another tool in the box. Any time you break related things into separate places, especially separate files, the tendency for them to get out of sync grows dramatically. Use of stub files for something that's only occasionally run (the type-checking linter) increases the potential time delay between the error and the fix. Unless you make a git/hg hook that runs type checks, chances are you'll have those issues in your code. Stub files are useful, but they aren't going to magically solve everyone's complaints. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
