[issue23771] Timeouts on x86 Ubuntu Shared 3.x buildbot
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23771 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Sudoku solver
On Sun, Mar 29, 2015 at 10:50 AM, BartC b...@freeuk.com wrote: Using the OP's algorithm, and testing with the 'hard' puzzle posted by Ian Kelly, I got these approximate results: Python 3.1: 1700 seconds (normal Python interpreter) PyPy: 93 seconds C unoptimised: 17 seconds (gcc -O0 32-bit) C optimised:3.3 seconds (gcc -O3 32-bit) (X: 170 seconds) Nice stats. Any chance you can add CPython 3.4 or 3.5 to that? That's a pretty old CPython you're using. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23771] Timeouts on x86 Ubuntu Shared 3.x buildbot
Davin Potts added the comment: @haypo: Could you please take a look at applying my patches from issue23713 to address an intermittent multiprocessing test failure? I don't know that it is the sole cause, but it is indeed one potential source of the misbehavior. -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23771 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23797] Mac OS X locale setup in thread happens sometime after run() is called
Ned Deily added the comment: The behavior noted in Issue18378 isn't an Apple bug; it's a GNU vs BSD difference. Can you avoid the problem by calling locale.getlocale() in the main program before creating any threads? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23799] Join started threads in tests
New submission from Serhiy Storchaka: When a test starts many threads in a loop, there is a chance that the starting thread will fail due to lack of memory. In this case all started threads left dangling and make MemotyError even more probably. They also can provoke dim error messages in this and in following tests. Proposed patch adds new helper function test.support.start_threads() that starts threads and then join started threads. Some tests even hang without this patch. -- components: Tests files: test_support_start_threads.patch keywords: patch messages: 239465 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Join started threads in tests type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38720/test_support_start_threads.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23799 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23800] Support POSIX uselocale interface for thread-specific locale settings
New submission from Ned Deily: POSIX 2008 provides a system interface, uselocale, to set locales individually on a thread basis rather than just process global, as currently supported with locale.setlocale(). uselocale is supported in most current GNU libc, BSD, and OS X releases. While there is currently a third-party package available in PyPI, it currently doesn't claim to support Python 3 and it would be good to have uselocale as part of the standard library where available. http://pubs.opengroup.org/stage7tc1/functions/uselocale.html https://github.com/wichert/xlocale -- components: Library (Lib) messages: 239467 nosy: lemburg, loewis, ned.deily priority: normal severity: normal status: open title: Support POSIX uselocale interface for thread-specific locale settings type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23800 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23771] Timeouts on x86 Ubuntu Shared 3.x buildbot
Davin Potts added the comment: @haypo: I didn't think that one through -- the consequences of that fragile test are not a hang. It's unrelated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23771 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23550] Add to unicodedata a function to query the Quick_Check property for a character
Hammerite added the comment: For good measure, here is a patch that makes all of Berker's suggested stylistic changes, but applies them to the pre-existing code in makeunicodedata.py and unicodedata.c. So all of the existing docstrings are converted from '...\n\' to '...\n' form, and the other property name arrays that were non-static are made static. -- Added file: http://bugs.python.org/file38719/quick_check_4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23550 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Ryan, For now I'll make the edits to pyconfig.h manually after downloading the zip from the tip and running configure with necessary params. I'll do my best to get this done this weekend, but it may have to wait until next. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23787] sum() function docstring lists arguments incorrectly
Wolfgang Maier added the comment:
This implies sum() should accept str, unicode, list, tuple, bytearray, buffer,
and xrange.
and in fact it *does* accept all these as input. It just refuses to add the
elements of the sequence if these elements are of certain types. Of course, the
elements of a string are strings themselves so this does not work:
sum('abc', '')
Traceback (most recent call last):
File pyshell#88, line 1, in module
sum('abc', '')
TypeError: sum() can't sum strings [use ''.join(seq) instead]
compare with a bytes sequence in Python3, where the elements are ints:
sum(b'abc', 0)
294
but strings are also perfectly accepatble as input if you do not try to add
their str elements, but something else:
class X (int):
def __add__(self, other):
return X(ord(other) + self)
sum('abc', X(0))
294
= the docs are right and there is no issue here.
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23787
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A simple single line, triple-quoted comment is giving syntax error. Why?
Aditya Raj Bhatt adityarajbh...@gmail.com wrote: On Wednesday, March 18, 2015 at 1:04:39 PM UTC-5, Laurent Pointal wrote: Can someone also provide a sort of a 'guide' to triple-quoted comments in general? A triple ' or string is a Python string, allowing line-return in string. What do you mean by line-return in string? Is it newline? Does it mean I can write - '''first part second part''' ? If it is in an expression (like a = 5 '''a comment'''), then it must be a valid expression (and here it is not). What is not a valid expression here? Were you ever able to extract the Real Answer to your original question from the froth that resulted? Your basic misunderstanding is that the triple-quote thing is NOT a comment marker. It is a string literal, exactly like a single-quoted string, except that it allows embedded newlines. So, your statement a = 5 '''a comment''' is invalid for exactly the same reason that the statement a = 5 a comment is invalid. Neither one of those statement have any comments. There is a CONVENTION to embed a literal string as the first line in a function, to allow for automatic documentation. Whether the literal string is single-quoted or triple-quoted is irrelevant. That is, these two things are equivalent: def func(a): This is a function return a*2 def func(a): This is a function return a*2 -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 27-Mar-2015 15:09, Dave Angel wrote: On 03/27/2015 09:56 AM, Marko Rauhamaa wrote: Frank Millman fr...@chagford.com: So what I am talking about is called a satisfactory puzzle, which is a subset of a proper puzzle. That is impossible to define, though, because some people are mental acrobats and can do a lot of deep analysis in their heads. What's satisfactory to you may not be satisfactory to me. Besides, looking for satisfactory patterns can involve a truckload of trial and error. I know, let's use regular expressions g If you are interested, I have written a python (wxPython GUI) for solving Sudoku problems. It even has a hint mode that can be used to lead you to a solution. I have tested it on the world's hardest Sudoku (published by a Finish mathematician) and it solves it very fast. I have also written another version that finds ALL the solutions to any Sudoku problem (that has a solution) using an LP approach --- this is non-trivial. However, I have not been able to give a strict mathematical proof that it does indeed find all solutions. If you wish to really understand the mathematics behind Sudoku then I suggest the book Taking Sudoku Seriously by Jason Rosenhouse and Laura Taalman (Oxford University Press, 2011). Unfortunately, they do not consider the LP approach in this book (an oversight IMHO). --V. Stokes -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2/3 versus Perl 5/6
On Sat, 28 Mar 2015 21:32:31 +1100, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The famous Perl coder Allison Randal writes about why Perl is not dead (it's just pining for the fjords *wink* ) and contrasts the Perl 5/6 split to Python 2/3: A shame Allison doesn't frequent these groups. I would have a few questions for her. Perl 6 is in fact a bit like Python 3. Perl 6 is an attempt to recreate the language, addressing (by throwing away or heavily changing) all the things that gave an indication the language would stiffle and die and bring in new ideas to address the demands of modern software design and implementation... But that's not the thing that confuses me most about Allison's post. The whole conversation about Rakudo not being Perl was. Perl 6 is Perl. It is part of the Perl family. And Perl 6 has been developed exclusively as a language specification. Which means it is not a language implementation. Rakudo is one such implementation, for the JVM, of the language specification known as Perl 6. Therefore Rakudo is Perl 6, which means Rakudo is also Perl. I mean, we can all agree Jython is Python. Maybe not CPython, but Python. Maybe not pythonic in all its body, but Python. Rakudo is no different. It's a shame(?) it is gaining no traction (and I think Alisson optimism is either misplaced of whishful thinking). But Rakudo is a reminder to everyone about the design principles and motivations behind Perl 6. For good or bad, because no other implementation of Perl 6 exists yet that can produce working code, which after all this years can only mean that Perl 6 is in deep trouble. The attempt at an analysis of Perl decline seemed to me also largely unable to touch the real spot of why Perl has been declining over the eyars (or rather, why it has declined into a stable but unconfortable low). It doesn't help to try and come up with elaborate, albeit sterile, language constructs. The Cookie Slap! Effect, Singularity Paradox, or the Awkward Adolescent Fallacy are not only vain, but fail to address what I believe is a much simpler explanation. Simply, Perl did come at the right time. But Perl came with a grammar and set of semantics that couldn't survive for long as soon as other languages started to follow on its footsteps. Perl wasn't designed to be a language of the future, rather to be a language that could solve the present problems without much regard to how painful that solution could be to maintain in the future. And Perl solved a whole lot of problems. But now others are doing it too. And in a way more in accordance to the requirements of modern software development. It was simply necessary that languages like Python or Ruby showed up or we would be knee-deep in maintenance hell. Perl also addressed the problems of the so-called Web 1.0. But the Web 2.0 didn't present many of those problems anymore. Suddenly Perl powerful text parsing features weren't so important as other non-generic and more specialized languages started to address the server and client side of web programming. Maybe Perl has a future. I wouldn't count on it though. I think Perl is really dying. I don't say this as a language advocate. That's something I am not. At all. I don't defend or attack programming languages, period. And that's because I find the exercise of programming language advocacy one of the most tragic things to have ever happened to computer science. Objective analysis is a dying art. And if Perl eventually dies. It is no tragedy. It's the loss of a programming language with no real place in the problem domain of modern computing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On 28/03/2015 03:39, Sayth wrote: Good test for pypy to see where it's speed sits between C and Python. I've spent the last hour or so doing such tests. Using the OP's algorithm, and testing with the 'hard' puzzle posted by Ian Kelly, I got these approximate results: Python 3.1: 1700 seconds (normal Python interpreter) PyPy: 93 seconds C unoptimised: 17 seconds (gcc -O0 32-bit) C optimised:3.3 seconds (gcc -O3 32-bit) (X: 170 seconds) All running on Windows on x64. (X is my own interpreted language, which is where my interest in this is. This had been generally faster than Python until PyPy came along. It does however use a pure byte-code interpreter, so the result is not too bad. But using X *and* my own brute-force algorithm, the same puzzle took 2 seconds to solve - faster than C! However it doesn't matter that the OP's algorithm is not great, as it makes an interesting new benchmark.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sun, 29 Mar 2015 10:50 am, BartC wrote: (X is my own interpreted language, which is where my interest in this is. This had been generally faster than Python until PyPy came along. It does however use a pure byte-code interpreter, so the result is not too bad. But using X *and* my own brute-force algorithm, the same puzzle took 2 seconds to solve - faster than C! I'm not one of those people who think that C is by definition the fastest language conceivable. (People who believe this sometimes make an exception for hand-crafted assembly, which is ironic since these days the best C optimizing compilers can generate faster, tighter code than human assembly programmers.) I know that program speed depends on the implementation of the language, not necessarily the language itself. I know that Fortran can beat C for numeric work, and that with a tiny fraction of the work put into optimization that C has seen, modern languages like Scala, Eiffel, Haskell and D can get to a factor of 2-6 times as slow as C. And I know that PyPy has managed to beat C in some (quite restrictive, but not completely unrealistic) benchmarks: http://morepypy.blogspot.com.au/2011/02/pypy-faster-than-c-on-carefully-crafted.html http://morepypy.blogspot.com.au/2011/08/pypy-is-faster-than-c-again-string.html So beating C is not impossible. But, when you tell me that your very own personal interpreted language, which I assume nobody else has worked on, is 40% faster than optimized C, my first reaction is to expect that you've probably made a mistake somewhere. I would have the same reaction if somebody casually dropped into a conversation that they happened to beat Usain Bolt's 100m personal best of 9.58 seconds by almost four seconds. While carrying a 20kg backpack. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
On Sun, Mar 29, 2015 at 2:06 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 29 Mar 2015 10:50 am, BartC wrote: (X is my own interpreted language, which is where my interest in this is. This had been generally faster than Python until PyPy came along. It does however use a pure byte-code interpreter, so the result is not too bad. But using X *and* my own brute-force algorithm, the same puzzle took 2 seconds to solve - faster than C! But, when you tell me that your very own personal interpreted language, which I assume nobody else has worked on, is 40% faster than optimized C, my first reaction is to expect that you've probably made a mistake somewhere. I would have the same reaction if somebody casually dropped into a conversation that they happened to beat Usain Bolt's 100m personal best of 9.58 seconds by almost four seconds. While carrying a 20kg backpack. I think you're misreading the stats. The first table compares languages, all using the same algorithm, and in that, C beat X ten to one, unoptimized. The second figure, when X took only 2 seconds, was demonstrating the massive improvement that the algorithmic change (from the OP's algorithm to [BartC's] own brute-force algorithm) achieved. For comparison, that's like casually dropping into conversation that you happened to drive a car faster than Usain Bolt's personal best. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2/3 versus Perl 5/6
Perl 6 tried to acheive to much, and by delay and confusion lost the enthusiasm of the community behind it Perl 6 and the at that time robust Perl 5 community who saw it as the future, when that future waned so did their's. Perl 6 should have just done what the community wanted at that time, introduce class::mop for a proper oop implementation abs tidy a few edge cases and pull in a few key modules into core. They would now be talking Perl 7 and how to implement functional design into the new release with a larger community. It would be interesting to see how Ruby would have progressed of Perl hadn't stuffed progress up so badly. To me Ruby has always looked like a tidy Perl. -- https://mail.python.org/mailman/listinfo/python-list
Proposal for new minor syntax
Sounds like you want to implement nim special dot syntax in python. http://nim-lang.org/manual.html#special-operators -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On Sunday, March 29, 2015 at 9:47:00 AM UTC+5:30, Ian wrote: On Sat, Mar 28, 2015 at 9:05 AM, Mario Figueiredo wrote: Neiter the language. The dot symbol is a delimiter in the python grammar. Not an operator. And also defined as a delimiter in the official documentation, right after operators. What does it matter? How '.' is lexed when it appears on its own should make no difference to the lexing of '.='. Some circularity here: How sth is lexed sth appears on its own [except for 1-char/1-token programs!!] -- https://mail.python.org/mailman/listinfo/python-list
[issue23801] cgi.FieldStorage has different (wrong?) behavior on Python3 than Python2
New submission from Donald Stufft: While working on PyPI 2.0 (which is currently running Python 3) I discovered that ``setup.py upload`` was causing an exception. After tracing things I determined that the reason for this is that Python 3 fails to handle leading whitespace in a multipart body. I've attached a minimum reproducer that runs without error on Python 2.6 and Python 2.7 which fails on Python 3.2, 3.3, and 3.4. If I go into the cgi.py module and add a print() statement that will print the header of each part, I get output that looks like: b'GHSKFJDLGDS7543FJKLFHRE75642756743254\r\nContent-Disposition: form-data; name=protcol_version\r\n\r\n' b'Content-Disposition: form-data; name=summary\r\n\r\n' b'Content-Disposition: form-data; name=home_page\r\n\r\n' b'Content-Disposition: form-data; name=filetype\r\n\r\n' b'Content-Disposition: form-data; name=content; filename=jasmin-13.13.13.tar.gz\r\n\r\n' The first line of that is obviously suspicious since it includes the inner boundary marker. Looking at the Python 3.x code it throws away the first line off the fp and then proceeds to process the rest of the fp. However in this case the first line is just a blank b'\r\n'. Looking at the Python 2.7 code it throws away an entire first part, not just the first line. I'm guessing that the read first line and throw it away code needs to continue reading lines until it's read enough lines to get to the boundary marker. -- files: reproduce.py messages: 239471 nosy: dstufft priority: normal severity: normal status: open title: cgi.FieldStorage has different (wrong?) behavior on Python3 than Python2 type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38721/reproduce.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23801 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23801] cgi.FieldStorage has different (wrong?) behavior on Python3 than Python2
Donald Stufft added the comment: Added a patch that fixes this issue by reading lines until we find the line that is our expected boundary marker. -- keywords: +patch Added file: http://bugs.python.org/file38722/cgi-read-until-boundary.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23801 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Proposal for new minor syntax
On Sat, Mar 28, 2015 at 9:05 AM, Mario Figueiredo mar...@gmail.com wrote: Neiter the language. The dot symbol is a delimiter in the python grammar. Not an operator. And also defined as a delimiter in the official documentation, right after operators. What does it matter? How '.' is lexed when it appears on its own should make no difference to the lexing of '.='. Meanwhile augmented assignment is governed by the `augassign` nonterminal. An addition to its list would result in a non backwards compatible new syntactic sugar feature. This would mabe not be a big issue between 3.X and 2.X, but would, I reckon, be against the compatibility rules between 3.X versions. How would it not be backwards compatible? I'm not able to come up with any situation where the character sequence '.=' is currently legal outside of string literals and comments. The counter-proposed '=.' could be an issue, since this is currently legal Python: x=.3 But I believe even that is still unambiguous since you couldn't currently follow the =. with an identifier. -- https://mail.python.org/mailman/listinfo/python-list
Re: VB/Pascal with statement [was Re: Proposal for new minor syntax]
On 28/03/2015 06:26, Steven D'Aprano wrote:
On Sat, 28 Mar 2015 03:18 pm, Rustom Mody wrote:
One thing that is a bit laborious in python are object initializers:
self.attr1 = field1
self.attr2 = field2
In VB one can do:
with self
.attr1 = field1
.attr2 = field2
(or something like that -- dont exactly remember the syntax)
Pascal is another language with a construct like that, and there's a FAQ for
it:
https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
c:\cpython\PCbuildpython
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64
bit (AMD64)] on win32
Type help, copyright, credits or license for more information.
help(FAQ)
Traceback (most recent call last):
File stdin, line 1, in module
NameError: name 'FAQ' is not defined
help('FAQ')
no Python documentation found for 'FAQ'
Less than useless, now what?
--
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: VB/Pascal with statement [was Re: Proposal for new minor syntax]
On Sat, 28 Mar 2015 11:26 pm, Mark Lawrence wrote:
On 28/03/2015 06:26, Steven D'Aprano wrote:
Pascal is another language with a construct like that, and there's a FAQ
for it:
https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
help('FAQ')
no Python documentation found for 'FAQ'
Less than useless, now what?
Did you try googling?
help(google)
Or you could read the URL I gave earlier.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
[issue23794] http package should support HTTP/2
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23794 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Proposal for new minor syntax
On 28/03/2015 09:53, Steven D'Aprano wrote: On Sat, 28 Mar 2015 10:08 am, BartC wrote: An alternate syntax might be: hello = .string() That should have been .strip() loop_node =. next Why propose that? Every other augmented assignment has the operator on the left hand side of the equals. Greater-than, less-than, and not-equal all have the symbol on the left hand side of the equals: += -= *= **= /= //= %= |= ^= = = = != =. ... and I'm dubious about pretending that . is an operator I see where you're coming from now. You're thinking that it is . that is the operator, but I'm looking at strip() as the operator that is being applied. I see the . as just a bit of necessary syntax that introduces this style of operator as a /unary/ operation, not a binary operation like all those examples. Maybe that's just the way Python does it. However, take this example using negation: a = -a which is clearly applying a unary operator, and imagine there existed a method (if that's the word) called neg, that also returned the negative value of its operand: a = a.neg() This does exactly the same thing. But suddenly you're now applying a binary operator . instead of a unary one! (I'm not sure how this all applies to the loop_node.next example, but even here I don't count the . as an operator, but syntax. In the languages I'm used to, the right-hand-side cannot be a conventional operand.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: VB/Pascal with statement [was Re: Proposal for new minor syntax]
On 28/03/2015 12:58, Steven D'Aprano wrote:
On Sat, 28 Mar 2015 11:26 pm, Mark Lawrence wrote:
On 28/03/2015 06:26, Steven D'Aprano wrote:
Pascal is another language with a construct like that, and there's a FAQ
for it:
https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
help('FAQ')
no Python documentation found for 'FAQ'
Less than useless, now what?
Did you try googling?
help(google)
Fails in just the same way. Do I raise a bug report on the issue tracker?
Or you could read the URL I gave earlier.
I don't want to read URLs, I prefer the interactive help. Besides which
you could be trying to lure me to a site where I'd catch a cold, or
virus, or whatever it's called.
--
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
[issue17515] Add sys.setasthook() to allow to use a custom AST optimizer
Brett Cannon added the comment: The closing of this issue inspired me to think of a better way to do this, and I think providing something in importlib.util that accepted a NodeTransformer as an argument to a function that compiled source files to bytecode files would fill this issue thanks to PEP 488. It would mean that nothing is done dynamically and everything is done offline, but that also means startup costs are gone in regards to bytecode generation and it gets people to actually think about optimizations of Python instead of it just being an afterthought. importlib.util.compile(path: Union[str, pathlib.Path], transformer: ast.NodeTransformer = None, *, optimization: Union[str, int] = None) - pathlib.Path -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17515 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: To Change A Pdf Ebook To Kindle
David H. Lipman wrote in message news:qecdnrkftl6qpy_inz2dnuu7-xmdn...@giganews.com... They must be treated as spam. ab...@sourceforge.net No doubts now. They are on a spam campaign and has been found spamming Web Forums such as Malwarebytes. All Usenet users and Listserver recipients, please file spam complaints; ab...@sourceforge.net -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- https://mail.python.org/mailman/listinfo/python-list
[issue22672] float arguments in scientific notation not supported by argparse
Changes by Evgeny Kapun abacabadabac...@gmail.com: -- nosy: +abacabadabacaba ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
X-ray vision into Mobestream Media's candidates?
Hi Ross, Hiring is easy. Hiring well is hard. Job boards produce lots of applicants, especially for sales, marketing, customer service, and admin roles. But then what? Hundreds of resumes isn't the solution. It's part of the problem. Recruiters are great at surfacing solid candidates, but their services come at a steep price. ClearFit offers a better way. Know instantly who's a good fit BEFORE you decide who to interview. Enter each interview armed with the right questions, specific to each candidate. Know, objectively, who's built for success in each role (and who isn't). If this sounds like it could be of value, check out some fo the links below and give me a call or shoot me an email. I'm here to help. Mike Zaslavsky Business Development ClearFit http://track.clearfitmail.com/?xtl=1une88t593npnga5t1hqisuul4mdz7ja8axm6umno5mb5dv496ea4e4fncarycrjsevasigb9rpya53cc0sjdeyf48vse8tsejupwaxv8ivw3j86xdqjrv63jpxtplmf2yotsr1a413rm4d8g7ej8gtlvamqw3dge2ifpgmwucu4cc33gzatuuzpxerrphuz07qk6j9uyjbww7dl99jvcdh3ntzpxs5kmmb264jt63dc24sm70ykgmw4jzeqlhwd0wphb6nju0u7pgf0llxibwprcbi524f1beucbl4v29meld6bkyikneznmn8vu4y8bptiwsalkpzvqrfkk2yd8dr2t7bv2cb5kbwpeq1n9npwlfgk8s1hsxi=python-list@python.org 647-776-0344 ClearFit in Fortune http://track.clearfitmail.com/?xtl=h7onvs748smglnkum0oqlmym3zwogftum48jf8s9r8auagyi48k9whlgwlegs38bj4c43z7mymzdggpi5z92iyyqqcyfh8htrde95oyohmxi=python-list@python.org WSJ, Forbes, and more coverage http://track.clearfitmail.com/?xtl=2gpl6eg0dos9118t9500ob6o8b8g6g3mg0b8n6o5qpm6qskww2vluroni525ant9t6f3gywojowax0z4q7o5yve5x5mxxzcacnvsm5jple2q34qaf0w9r19zux4k3mk31waa9292w0sd47nedhmj1byqrez8enj8r00he6vo8zozbuwwcr241tvwggxq5jnsfl7uvoewmqb13ipbqaxwr6akocl46ir98w7t5bmjxwvsz1r2goj19bks7qwo2j2s04cnsbcuj3hwxeyugppyvyt6635zng2qftn1cluoyxi=python-list@python.org Blog Post: ClearFit for Startups http://track.clearfitmail.com/?xtl=y60c2q78bo9izfo38jm38s8o259j8d261aa6rr33fu1yb5kcbi4p2kycbf1wdfz6lp8va07lu7xubcffh2x4vpp8wzad771rc75e1r15jttbyktq3jj1cf0byj51nyjjeyzv5l1sriy6pfhlvf0xe4kx4hq2u23rgmas2zwy5u9lcbi8dijyqmjcjozixq7is1smwm7m3l0ssa5tu7f5sfvn1eebszmis9a1e02om4fzxbir696sk1kup3hrjgb52qlcs0bbjuztdt86ameh9dj49jsb79xlo6jfhwedr0llj61uvrfl4ryaglcrp4hock5obglmmfkzm6uwe3p0387icu4iwqjojabxm73x7b9p0d2hvwfd6t72payhqhmtyiwfmnwrla1mlmkxvydlg37ne9lo0hd6gehxx207ygaju2zkzw1obdt7gi3usvrbq862ptjlvnjtrpxi=python-list@python.org Startup Webinar http://track.clearfitmail.com/?xtl=uqhbhqqa8m2z24t8ybudhyrqjaiy9jn2doqr6sk30fgox4yh321fe1hzarshllk41zlmpct93pxv3hopwifbql90ltr6cs3cj2v7gl7i4zjo3azr36i1yw4770dulxlkagrontzflykgp6lpsq39cby65sok0tw97rhfprxkrov957vbz90exs4z7k5fcfltb8ytxnftdisomo81ddvpsvjoflwqewaewcj25stj8dx0wvt3908arrv0h6foiprtsdarvap5ya5m3b2skyav9kelduh7ygo1q3wc4vm1y8h20aot0z67pfd90d1jubnm7mluuqy41iy6yj7uxc55q0qqhvqipzka5s0va9im7fgb2y9fs145yc8gzh5m08fmyh7xj7b2s3nqw7aazgl5il6mx1om51dm1qbwcyqyno3x0tj5hwsa18bktijkfojnau0pls0h0zjrkaaa2f4bgf3xen0b8gviig1n0u97rmpr3xi=python-list@python.org In order to unsubscribe from this mailing list, please click here http://track.clearfitmail.com/?xul=88a5ptgwcn4h2zkdgvb03lp5zd378exrq8vxi=python-list@python.org -- https://mail.python.org/mailman/listinfo/python-list
Re: VB/Pascal with statement [was Re: Proposal for new minor syntax]
On Saturday, March 28, 2015 at 11:56:39 AM UTC+5:30, Steven D'Aprano wrote: On Sat, 28 Mar 2015 03:18 pm, Rustom Mody wrote: One thing that is a bit laborious in python are object initializers: self.attr1 = field1 self.attr2 = field2 In VB one can do: with self .attr1 = field1 .attr2 = field2 (or something like that -- dont exactly remember the syntax) Pascal is another language with a construct like that, and there's a FAQ for it: https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments This is not my baby so I am not going to pursue this argument beyond here. However that FAQ addresses Object Pascal, Delphi, C++ and their respective static type disciplines. The VB syntax OTOH does not exploit any typing info https://msdn.microsoft.com/en-us/library/wc500chb.aspx because attributes are prefixed with a dot -- unlike Pascal and unlike the examples in the FAQ. So if the VB model is followed, it is purely a syntactic (ie not type-related) question whether an identifier is an adorned variable or an attribute of something else. The preceding dot is the disambiguator. Anyways... As I said, this feature is not v important to me one way or other... -- https://mail.python.org/mailman/listinfo/python-list
Re: VB/Pascal with statement [was Re: Proposal for new minor syntax]
On Saturday, March 28, 2015 at 9:51:50 PM UTC+5:30, Rustom Mody wrote: So if the VB model is followed, it is purely a syntactic (ie not type-related) question whether an identifier is an adorned variable or an attribute of something else. The preceding dot is the disambiguator. Uh... UN-adorned is what I meant -- https://mail.python.org/mailman/listinfo/python-list
[issue23792] help crash leaves terminal in raw mode
R. David Murray added the comment: SIGINT *is* keyboard interrupt. Since less at least seems to ignore SIGQUIT I suppose also ignoring that would be reasonable, since the user (should) by analogy expect that behavior while the pager is active. Note, however, that the signals we are ignoring are in the parent process, not the child as is the case for system. So one can argue that letting the python process die when SIGQUIT is received would also be reasonable, and arguably is the less surprising option. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23792 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23797] Mac OS X locale setup in thread happens sometime after run() is called
R. David Murray added the comment: This is probably related to or effectively a duplicate of issue 18378, which looks to be an Apple bug. Do you have the problem if you remove the getlocale() call? -- components: +Macintosh nosy: +ned.deily, r.david.murray, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Proposal for new minor syntax
On Sat, 28 Mar 2015 13:38:20 +, BartC b...@freeuk.com wrote: (I'm not sure how this all applies to the loop_node.next example, but even here I don't count the . as an operator, but syntax. Neiter the language. The dot symbol is a delimiter in the python grammar. Not an operator. And also defined as a delimiter in the official documentation, right after operators. Meanwhile augmented assignment is governed by the `augassign` nonterminal. An addition to its list would result in a non backwards compatible new syntactic sugar feature. This would mabe not be a big issue between 3.X and 2.X, but would, I reckon, be against the compatibility rules between 3.X versions. -- https://mail.python.org/mailman/listinfo/python-list
[issue23798] NameError in the encode fixer
New submission from Serhiy Storchaka: == ERROR: test_all_project_files (lib2to3.tests.test_all_fixers.Test_all) -- Traceback (most recent call last): File /home/serhiy/py/cpython/Lib/lib2to3/tests/test_all_fixers.py, line 25, in test_all_project_files self.refactor.refactor_file(filepath) File /home/serhiy/py/cpython/Lib/lib2to3/refactor.py, line 354, in refactor_file tree = self.refactor_string(input, filename) File /home/serhiy/py/cpython/Lib/lib2to3/refactor.py, line 386, in refactor_string self.refactor_tree(tree, name) File /home/serhiy/py/cpython/Lib/lib2to3/refactor.py, line 460, in refactor_tree new = fixer.transform(node, results) File /home/serhiy/py/cpython/Lib/lib2to3/fixes/fix_encode.py, line 50, in transform if negation: NameError: name 'negation' is not defined -- Variable 'negation' is never set. -- components: 2to3 (2.x to 3.x conversion tool) messages: 239462 nosy: benjamin.peterson, serhiy.storchaka priority: normal severity: normal status: open title: NameError in the encode fixer type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23798 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A simple single line, triple-quoted comment is giving syntax error. Why?
Gregory Ewing wrote: Ian Kelly wrote: What I mean is that if you construct a parse tree of foo bar using that grammar, it looks like this: expr | STRING+ / \ STRING STRING Not quite -- STRING+ is not a symbol in the grammar, it's a shorthand for a combination of symbols. The parse tree is actually just expr / \ STRING STRING Or if there is a single STRING, expr | STRING AISB. Not like this: expr | STRING+ / \ expr expr | | STRING STRING […] To get a parse tree like the above, there would need to be a production like this in the grammar: expr ::= expr+ There is no such production, so that parse tree is impossible. QED. Correct. What you seem to be doing in your mind Who is “you” here? You appear to be confused, probably supported by your unconventional quotation style, who made which statement. is taking this production: expr ::= STRING and using it backwards to justify expanding any occurrence of STRING into expr. No. But grammars don't work that way. You're committing a logical fallacy: just because some exprs are STRINGs doesn't mean that all STRINGs are exprs. The fallacy – a straw man – is yours here. Nobody – in particular not me – claimed that “STRING” can *only* be produced by “expr” in the first place. Production rules in a formal grammar of the form expr → … | any_goal | … any_goal → … | any_other_goal | … any_other_goal → … | STRING+ | … where the steps in-between are optional, mean *exactly* that (*all*) “STRING”s are “expr”s – but that not all “expr”s are “STRING”s. Because it follows from the rules above that these production chains – *but not _only_ these* – are possible: a) expr ⇒ … ⇒ STRING b) expr ⇒ … ⇒ STRING STRING c) expr ⇒ … ⇒ STRING STRING STRING and so on. The truth of the statement “(All) STRING( literal)s are expr(ession)s” is what follows from the possibility of the first production chain. (That does not preclude the possibility that “STRING”s are also an element of another set.) -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail. -- https://mail.python.org/mailman/listinfo/python-list
Re: To Change A Pdf Ebook To Kindle
On Saturday 28 March 2015 07:27:54 David H. Lipman wrote: David H. Lipman wrote in message news:qecdnrkftl6qpy_inz2dnuu7-xmdn...@giganews.com... They must be treated as spam. ab...@sourceforge.net No doubts now. They are on a spam campaign and has been found spamming Web Forums such as Malwarebytes. All Usenet users and Listserver recipients, please file spam complaints; ab...@sourceforge.net Done. 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: A simple single line, triple-quoted comment is giving syntax error. Why?
Ian Kelly wrote: […] Thomas 'PointedEars' Lahn […] wrote: Ian Kelly wrote: What I mean is that if you construct a parse tree of foo bar using that grammar, it looks like this: expr | STRING+ / \ STRING STRING […] There is only one expr node, and it contains both STRING tokens. Prove it. I'm not going to expend the effort that would be required to go through the entire Python grammar step-by-step and exhaustively prove that foo bar can unambiguously only be produced as a single expr. And why should you? That is not what you claimed. If you believe otherwise, show a parse tree that parses these as separate expressions. Fallacies: Straw man, shifting the burden of proof. But be warned: Neither would prove that a string literal is not an expression. I've not claimed that a string literal is not an expression. Yes, you did. You debated my statement which says that. Let me refresh your memory. I said: | As I showed, string literals and consecutive tokens of string literals | (“STRING+”) so as to do implicit concatenation *are* expressions of the | Python grammar. To which you replied: | What the grammar that you quoted from shows is that STRING+ is an | expression. The individual STRINGs of a STRING+ are not expressions, […] ^^^ ^^^ You continued with | except to the extent that they can be parsed in isolation as a STRING+. but that is nothing more than a backdoor, contradictory to what you said before (and, as it has been showed, nonsensical). My claim is that a literal consisting of the implicit concatenation of more than one string token is can only be parsed as one expression, not several. Then you must have fundamentally misunderstood my statement and this whole discussion. Parsing foo bar Because you did not consider the most simple variant of an AST (or subtree) according to this grammar: expr | STRING Of course I did. This is again *exactly* what I was talking about in reference to parsing the individual strings in isolation. Actually, you were arguing against my statement that string literals are expressions (that a string literal is an expression). You claimed, rather explicitly, that they were not. See above. Again, “STRING+” does _not_ mean “STRING STRING STRING*”; it means “STRING STRING*”. The second and following STRINGs are *optional*. Please stop speaking down to me. I am not speaking down to you. But the fact needed to be emphasized that you could not have been reading carefully what I wrote. I'm quite familiar with basic concepts of EBNF. But apparently not logic. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail. -- https://mail.python.org/mailman/listinfo/python-list
[issue23731] Implement PEP 488
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23731 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
VB/Pascal with statement [was Re: Proposal for new minor syntax]
On Sat, 28 Mar 2015 03:18 pm, Rustom Mody wrote: One thing that is a bit laborious in python are object initializers: self.attr1 = field1 self.attr2 = field2 In VB one can do: with self .attr1 = field1 .attr2 = field2 (or something like that -- dont exactly remember the syntax) Pascal is another language with a construct like that, and there's a FAQ for it: https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On Sat, Mar 28, 2015 at 6:32 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: | Methods defined here: This is the usual guff that help() prints when you pass it a class or type. Occasionally it is useful. Often it is not, especially the dunder methods. Unfortunately help's UI is rather primitive. It would be nice if it provided a menu of commands whereby you could hide/show dunders (hidden by default, perhaps), but that's an order of magnitude more complexity. It might make a nice third-party tool though. This is why I would never point someone to help() as a means of primary learning. It's great for quickly checking a function's parameters (especially their order) when you already know what it does. Otherwise, how do you know what to call help() on? Much more useful to start with the online module docs, which are searchable (unlike help(modulename), broadly speaking), and which omit all the dunders. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23794] http package should support HTTP/2
Cory Benfield added the comment: I'm happy to talk about bringing hyper's HTTP/2 layer into http.client. It's worth noting that at this point I have no current plans to build a server into hyper, though if there was interest in using hyper as a baseline then I could take a swing at it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23794 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: VB/Pascal with statement [was Re: Proposal for new minor syntax]
On Sat, Mar 28, 2015 at 5:26 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 28 Mar 2015 03:18 pm, Rustom Mody wrote: One thing that is a bit laborious in python are object initializers: self.attr1 = field1 self.attr2 = field2 In VB one can do: with self .attr1 = field1 .attr2 = field2 (or something like that -- dont exactly remember the syntax) Pascal is another language with a construct like that, and there's a FAQ for it: https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments While I don't advocate the proposal, it does have an important difference from the one cited in the FAQ - albeit a Tim-grit difference: the Pascal version has implicit attribute notation, where the proposed has a leading dot. This eliminates the ambiguity, though without majorly improving readability. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Save session Selenium PhantomJS
Issue resolved. My code was working, the problem was PhantomJS 2.0, used 1.9.8 and now I have the 'cookies.txt' file as expected! -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
Larry Hudson org...@yahoo.com: Highlight the selection you want copied, move the mouse cursor to the location you want it copied to and middle-click with the mouse. Works between programs as well as within a single program. And it copies directly without going through the clipboard. Unfortunately, Linux nowadays employs both schemes. They just couldn't resist the lure of the clipboard. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On Sat, 28 Mar 2015 07:48 am, Ian Kelly wrote:
On Fri, Mar 27, 2015 at 2:24 PM, Jamie Willis
jw14896.2...@my.bristol.ac.uk wrote:
I would like to propose a new piece of syntax for the python language; .=
In short, the operator is form of syntactic sugar, for instance consider
the following code:
hello = hello world
hello = hello.strip()
This could be written as:
hello = hello world
hello .= strip()
In this slightly contrived example, the programmer saved (a small amount
of) time when writing the code. With code with longer variable names, or
lots of similar statements all in a row, this helps to keep code more
concise.
The operator would be constricted to one method or field on the
right-hand side, which must belong to the object on the left hand side.
Do you mean that this would not be legal?
hello .= strip().upper().encode('utf-8')
Is there a reason you want to disallow that?
Another example could be when using Linked Lists, instead of writing
something like:
loop_node = loop_node.next
you could write:
loop_node .= next
I realize this is just an example, but does anybody actually use
linked lists in Python outside of class assignments? It seems hard to
justify performance-wise since list is written in C, and if you need
to beat it, then you probably shouldn't be doing so in Python.
https://www.safaribooksonline.com/library/view/python-cookbook/0596001673/ch14s05.html
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
[issue23720] __del__() order is broken since 3.4.0
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: -terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23720 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: pycurl.error: (55, 'select/poll returned error')
Nagy László Zsolt gand...@shopzeus.com writes: When calling curl.perform() on a curl instance I get this: pycurl.error: (55, 'select/poll returned error') This error happens only if the file to be POST-ed is big enough. Last week files were under 1GB and everything went fine. Files above about 1GB cannot be sent over with curl. Web services sometimes have limits about the allowed size of uploaded files. I know about one web server application framework (Zope/ZServer) that simply shuts down its communication channel when it receives a too large file - such a behaviour can confuse the client. Maybe, in your case, the server side, too, does something unexpected when it receives large files? select/poll by itself has nothing to do with the size of files. It is used to get informed when one out a set of communication channels is ready (again) for interaction. In principle, it should not fail -- unless something strange happens to the communication channels. -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
By the way, you're not alone in recognising that Python 3 may be a little harder to teach to beginners than Python 2. Raymond Hettinger, one of the most respected Pythonistas around, has pointed out the same thing. More below. On Sat, 28 Mar 2015 12:48 am, Rustom Mody wrote: On Friday, March 27, 2015 at 10:05:21 AM UTC+5:30, Steven D'Aprano wrote: On Fri, 27 Mar 2015 01:21 pm, Rustom Mody wrote: Anyway my point is that in python (after 2.2??) saying something is an object is a bit of a tautology -- ie verbiage without information. Er, it's *always* been a tautology. Every value in Python is an object, including classes, and that has been always the case. However, just because it's a tautology doesn't mean it isn't useful to know. (Tautologies are also known as *facts* and knowing facts is usually a good thing.) For the majority of programming languages, it is not the case that all values are objects, and not all people reading the documentation should be expected to know that this applies to Python. I am making a point of pedagogy not semantics. I'm also making a point of pedagogy. You cannot possibly understand Python without understanding the words Python programmers use to discuss Python code, and that includes object, a word with multiple meanings. How can you talk about teaching people to use filter without discussing the semantics of filter? What are you teaching them then, the way the word looks when written down using calligraphy? Any meaningful discussion about pedagogy cannot avoid semantics. You cannot teach people about filter without expressing what filter is and does and what sort of thing it returns. This is all semantics. In my opinion, once somebody is reduced to dismissing an argument as that's just semantics, they've already lost, they just don't know it. This is help(filter) for python 2 and 3. Python2: Help on built-in function filter in module __builtin__: filter(...) filter(function or None, sequence) - list, tuple, or string Return those items of sequence for which function(item) is true. If function is None, return the items that are true. If sequence is a tuple or string, return the same type, else return a list. Right. filter is Python 2 is a function, and it returns a list, tuple or string. Python 3 Help on class filter in module builtins: class filter(object) | filter(function or None, iterable) -- filter object | | Return an iterator yielding those items of iterable for which | function(item) is true. If function is None, return the items that are | true. Right. filter in Python 3 is a class (a.k.a. a type). Calling a type normally returns an instance of that type, in this case a filter object in the same way that calling str(x) returns a str object or list(x) returns a list object. Are we learning yet? :-) filter is *more powerful* in Python 3, because it is no longer eager. It is lazy, and returns an iterator. What sort of iterator? A *filter instance*. We have to call it something, and Python wouldn't be improved if filter was a function which returned a pimwit instance. That helps neither beginners nor experts. | Methods defined here: This is the usual guff that help() prints when you pass it a class or type. Occasionally it is useful. Often it is not, especially the dunder methods. Unfortunately help's UI is rather primitive. It would be nice if it provided a menu of commands whereby you could hide/show dunders (hidden by default, perhaps), but that's an order of magnitude more complexity. It might make a nice third-party tool though. Try and put yourself in the place of a noob: Knows some C, not much else. Why C? Why not somebody who knows Java and not much else, or PHP, or Ruby, or no other programming language at all? People can come to Python from all sorts of backgrounds. C is not and never has been a prerequisite for learning Python. Not every programmer, or programming beginner, knows C. Coming to Python from C is possibly the worst place to start from. Coming from another OOP language like Ruby or Java is better, since the basic concepts will be more familiar, although you will have to unlearn many of the idioms and details. Having no preconceptions is even better. Instead of a C programmer, how about a Scheme or Lisp programmer reading help(filter) in Python 2: I know what Python lists, tuples and strings are, this sounds just like the filter I know from Scheme. Easy! By the way, why is there no car and cdr function for processing lists? The point being that preconceptions often need to be unlearned. If the C programmer needs to learn what an object is, the Scheme programmer needs to unlearn what a list is. Should we therefore decide that Python's use of the word list is harmful? (I'm hoping that you will agree that it is not, but if you wish to debate it, I'm game.) It's 2015, not 1990, and our imaginary student would have to have been
Re: Sudoku solver
On Fri, Mar 27, 2015 at 7:40 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Excluding that, the consensus seems to be that Perl's regexes are stronger than Chomsky regular expressions, but nobody quite knows how much stronger. It's likely that they are at least as powerful as context-free grammars, but not as powerful as a Turing machine (excluding embedded Perl code), but that covers a lot of ground in the hierarchy of language power: Intuitively, I should think that the combination of recursive subpatterns and assertions would make them able to generate at least the context-sensitive languages. So it's an open question as to whether or not you could prove a Sudoku grid solvable using a Perl regex. Python regexes are less powerful than Perl's, so if you can't do it in Perl, you can't do it in Python. As somebody else in the thread pointed out, the set of all valid Sudoku grids is a finite language, and all finite languages are regular. QED. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new minor syntax
On Sat, 28 Mar 2015 10:08 am, BartC wrote: An alternate syntax might be: hello = .string() loop_node =. next Why propose that? Every other augmented assignment has the operator on the left hand side of the equals. Greater-than, less-than, and not-equal all have the symbol on the left hand side of the equals: += -= *= **= /= //= %= |= ^= = = = != =. All together now, let's sing: One of these things is not like the other... [That song is from Sesame Street, for anyone who doesn't get the reference.] It doesn't even solve the grit on Tim's monitor test, it just moves the whitespace from one side to the other: hello .= strip() hello =. strip() Moving the dot to the other side just makes it an arbitrary change for people to get confused by. With flexible white space either side of . unless it is important that .= or =. is a single token. py x = 2 py x + = 1 File stdin, line 1 x + = 1 ^ SyntaxError: invalid syntax I think that being able to write: x + = 1 adds complexity for no benefit. If we don't allow spaces between + = we shouldn't allow them between . and = in this proposal. I'm assuming that an isolated . is not a valid starter symbol for anything else, other than a floating point constant such as hello =.3 On the minus side it seems marginal in utility to me, as all it does is save a bit of typing. The +=, etc. operators are backed by special methods named __iadd__ etc. which allows the class author to provide for the operation to be performed in-place, or to change the meaning entirely use the operator as part of a DSL. This proposal doesn't have any room that I can see for that sort of benefit. It needn't require that sort of support. It does just save typing in the same way that A += B does, and makes it a little clearer what is being expressed. Except that with A = .B, A will be evaluated twice. It saves typing. It might even allow a micro-optimization in the generated bytecode (see below). But I don't think it's clearer -- the opposite, really, I think it's a bit unclear. You can't be any clearer than the explicit: greeting = greeting.strip() This tells you explicitly what's being evaluated on the right hand side, and explicitly what it's being bound to. greeting .= strip() requires you to learn yet another special piece of syntax, after which you can fill in the implicit attribute lookup: greeting .= strip() # greeting.strip() Personally, I'm not a huge fan of augmented assignment += etc. There is no doubt that it has the advantage of saving typing, but it leads to more complexity: (1) `x += y` *is not* semantically equivalent to `x = x + y` (2) augmented assignment involving tuples can be awkward: t = ([1, 2, 3], None, spam) t[0] += [4] The problem isn't that the second line raises an exception, but that the second line raises an exception and yet the addition succeeded. So I am fairly dubious about extending a mixed blessing like augmented assignment even further. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Python 2/3 versus Perl 5/6
The famous Perl coder Allison Randal writes about why Perl is not dead (it's just pining for the fjords *wink* ) and contrasts the Perl 5/6 split to Python 2/3: [quote] The single biggest thing we didn’t anticipate is that the “community rewrite of Perl” has, in fact, turned out to be a community fork. Perl 6 is not like Python 3, which really is a continuation of Python 2, with the same developers, same users, and same community values. (Sometime I’ll write about my interest and contributions toward the Python 3 migration effort, with its own unique successes and challenges.) What grew out of the Perl 6 idea is a new community, a new group of developers, and even a new identity, “Rakudo” rather than Perl (with a phase of “Pugs” along the way). The core Perl developers still work on Perl 5, and have little or no interest in Rakudo. Some of the Rakudo developers have a background in Perl, but many of them have a background in PHP, Java, C#, or other languages. Rakudo is not an “upgrade” from Perl. It’s revolutionary and exciting, just like Perl was in 1987, but it is not Perl. Please note that I’m not commenting on the similarity or difference of syntax between Perl and Rakudo. If you take a long view over the history of programming languages, syntax is about as relevant to the success of a language as the color of the bike shed. And if you really, really get down to the nuts and bolts, the syntax and functionality of Perl, Python, Ruby, PHP, and Lua are all fundamentally quite similar. That doesn’t make them the same language, and more importantly it doesn’t make them the same community. [end quote] Read the rest here: http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-love-perl/ By the way, although Allison is not active here, she is an active Python programmer and member of the PSF, that's the Python Software Foundation, not the PSU, the Python Secret Underground, which most definitely does not exist. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
[issue23796] BufferedReader.peek() crashes if closed
Serhiy Storchaka added the comment: Do you want provide a patch Martin? -- assignee: - serhiy.storchaka nosy: +serhiy.storchaka stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23796 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Supply condition in function call
On Sat, Mar 28, 2015 at 1:50 AM, Marko Rauhamaa ma...@pacujo.net wrote: Larry Hudson org...@yahoo.com: Highlight the selection you want copied, move the mouse cursor to the location you want it copied to and middle-click with the mouse. Works between programs as well as within a single program. And it copies directly without going through the clipboard. As I understand it, the primary selection and the clipboard selection both work the same way under the hood: a client that wishes to paste the selection requests it from the client that owns it. The clipboard selection may be called the clipboard but it does not refer to an OS-level buffer as in Windows. Unfortunately, Linux nowadays employs both schemes. They just couldn't resist the lure of the clipboard. For good reason. Anything that can only be done with a mouse is not accessible. I've never been a fan of the primary selection style anyway. Copying text is conceptually an action. Selecting text is how one indicates the target of an action; conceptually it is not an action itself and shouldn't cause an action to be performed. It leads to muddled processes like highlight this text, paste it there, highlight that text, delete it, paste in the replacement text from before -- oops, I accidentally pasted back in the text that I just deleted instead. -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On Sat, 28 Mar 2015 06:50 pm, Marko Rauhamaa wrote: Larry Hudson org...@yahoo.com: Highlight the selection you want copied, move the mouse cursor to the location you want it copied to and middle-click with the mouse. Works between programs as well as within a single program. And it copies directly without going through the clipboard. Unfortunately, Linux nowadays employs both schemes. They just couldn't resist the lure of the clipboard. Unfortunately? The only unfortunately I have with two copy/paste schemes are: - When I am forced to use a Windows application, middle-click *never* pastes :-( - Certain Linux applications like OpenOffice seem to have buggy implementations of middle-click, and sometimes fail to recognise when you've copied something in another application. But only sometimes. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Supply condition in function call
On Sat, 28 Mar 2015 08:19 pm, Ian Kelly wrote: I've never been a fan of the primary selection style anyway. Copying text is conceptually an action. Selecting text is how one indicates the target of an action; conceptually it is not an action itself and shouldn't cause an action to be performed. It leads to muddled processes like highlight this text, paste it there, highlight that text, delete it, paste in the replacement text from before -- oops, I accidentally pasted back in the text that I just deleted instead. Everything you say is absolutely correct. And yet middle-click paste is so convenient when it works that I all but cry from frustration when I find an application that doesn't support it. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
[issue23797] Mac OS X locale setup in thread happens sometime after run() is called
New submission from Barry Alan Scott:
I'm seeing a random traceback when starting a new thread on Mac OS X 10.10.2
with python 3.4.3 final.
Exception in thread Thread-1:
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py,
line 920, in _bootstrap_inner
self.run()
File
/Users/barry/wc/svn/pysvn-phoenix/WorkBench/Source/wb_background_thread.py,
line 40, in run
self.app.log.info( 'BackgroundThread locale %r' % (locale.getlocale(),) )
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/locale.py,
line 575, in getlocale
return _parse_localename(localename)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/locale.py,
line 484, in _parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: UTF-8
Adding a time.sleep( 5 ) prevents the traceback.
Using _locale.setlocale( locale.LC_ALL, None ) to see the state with locale.py
interfering it looks like the locale is being initialised in the thread after
run() is called. (Make no sense to me, but I can reproduce).
I have failed to create a small script to show this bug.
--
messages: 239458
nosy: barry-scott
priority: normal
severity: normal
status: open
title: Mac OS X locale setup in thread happens sometime after run() is called
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23797
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Proposal for new minor syntax
On Sat, 28 Mar 2015 08:53 pm, Steven D'Aprano wrote: It saves typing. It might even allow a micro-optimization in the generated bytecode (see below). Oops, I forgot to include the see below bit. Comparing a = a.spam() a .= spam() the Python compiler could perhaps optimize the second form and avoid needing two references to a (once for the attribute lookup, once for the binding). That's not very exciting when it comes to a simple expression like the above, but consider: a[b][c].d.e[f].g = a[b][c].d.e[f].g.spam() *If* that could be optimized, and I'm not certain it can be, that would be an argument in favour of the proposal. Still, I'm not entirely convinced that augmented assignments += *= etc are a good idea or entirely Pythonic, and I'm dubious about pretending that . is an operator, so I think that overall the proposal would need more justification than merely save a bit of typing and allow a micro-optimization. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
