What is Application Context and Request Context in Flask and WerkZeug.
Hi, I am developing a web application using flask, Werkzeug and jinja2. I am very much confused with these terms and wanted to know the meaning of the terms and how they are interrelated to the CGI environment variables. What is global variable g and how it is related to the application context and request context. Also since I don't have much knowledge of developing web apps( I am doing it for first time) any another language also so there is another request if someone could give a reference or make me understand that how the requests are handled, i mean what happens when a request arrives to the web application. Also if i am not using any openID providers for logging in the user into my website, how can i make the password secure. Should i use any framework for that? Thanks, Norah Jones -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 07 Apr 2014 07:54:27 +0300, Marko Rauhamaa wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: On Sun, 06 Apr 2014 23:10:47 +0300, Marko Rauhamaa wrote: It is academic because the author, Raymond Smullyan, was a professor of philosophy and, more importantly, my professor selected that as a textbook for us graduate students. Ah. Well they do that, don't they? I've always consider the ability of professors to select their own book as text to be a classic case of conflict of interest. They're supposed to pick the best book, not necessarily the one that earns them money. Note that my professor above was not Raymond Smullyan. Ah! Sorry about that, I misread your post as implying he was your professor. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
In article mailman.8970.1396843004.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Apr 7, 2014 at 1:48 PM, Roy Smith r...@panix.com wrote: There is (or at least, was) another reason. Creating a new process used to be far more expensive than creating a new thread. In modern Unix kernels, however, the cost difference has become much less, so this is no longer a major issue. Unix maybe, but what about Windows? Is it efficient to create processes under Windows? Whether something works well on Windows is really not something I worry about a lot. -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Mon, Apr 7, 2014 at 10:26 PM, Roy Smith r...@panix.com wrote: In article mailman.8970.1396843004.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Apr 7, 2014 at 1:48 PM, Roy Smith r...@panix.com wrote: There is (or at least, was) another reason. Creating a new process used to be far more expensive than creating a new thread. In modern Unix kernels, however, the cost difference has become much less, so this is no longer a major issue. Unix maybe, but what about Windows? Is it efficient to create processes under Windows? Whether something works well on Windows is really not something I worry about a lot. It's a concern for some of us. Maybe one day supporting Windows will be like supporting Python 2.4 is now - something that only a few people do, and knowingly pay the complexity price for it - but for now, it's a fully-supported platform for a lot of Python software, so in a generic discussion, I'd say it's important to note it. Threading has NOT been entirely replaced with multiprocessing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
In article mailman.8974.1396874103.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Apr 7, 2014 at 10:26 PM, Roy Smith r...@panix.com wrote: Whether something works well on Windows is really not something I worry about a lot. It's a concern for some of us. You have my sympathy. it's a fully-supported platform for a lot of Python software, so in a generic discussion, I'd say it's important to note it. In all things technology related, there is an evolutionary path. It goes something like this: * bleeding edge * avant-garde * what the kewl kids are using * modern * mainstream * traditional * corporate standard * legacy * extended support * prehistoric I figure Windows (at least on the desktop) is legacy at this point. Or, in the case of XP (The Release That Wouldn't Die), extended support. I acknowledge it exists, and is still commercially important, and even has certain advantages, in the same way that I acknowledge the continued existence of incandescent light bulbs, POTS, C++, and film photography. I put threading in the same category. There are two major reasons for using threading: as an architectural pattern for doing non-blocking I/O, and to allow a program to take advantage of multiple processors in a single machine. Fortunately, we have figured out better ways to do both of those. The idea that we should continue to use threading just because Windows makes process creation hideously expensive compared to thread creation doesn't impress me as an argument in favor of threading. It impresses me as an argument in favor of ditching Windows. When I started using Python (1.4), it was somewhere around avant-garde. Now, I figure it's mainstream, which probably means it's time for me to move on to something else soon :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On 07/04/2014 14:22, Roy Smith wrote: When I started using Python (1.4), it was somewhere around avant-garde. Now, I figure it's mainstream, which probably means it's time for me to move on to something else soon :-) Python 2.8? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Roy Smith r...@panix.com: The idea that we should continue to use threading just because Windows makes process creation hideously expensive compared to thread creation doesn't impress me as an argument in favor of threading. It impresses me as an argument in favor of ditching Windows. There are many reasons to start processes or threads. One of them is performance (you have more than one CPU core). When performance is the objective, my rough guidelines would be: * Start your processes during initialization. * Start about twice as many processes as there are CPUs. IOW, the processes are there to exercise the CPUs and should not represent individual connections or other dynamic entities. I don't program for Windows, but that's the approach I would take under linux as well. Marko -- https://mail.python.org/mailman/listinfo/python-list
testfixtures 3.0.2 Released!
Hi All, I'm pleased to announce the release of testfixtures 3.0.2. This is a bug fix release featuring the following changes: - Document ShouldRaise.raised and make it part of the official API. - Fix rare failures when cleaning up TempDirectory instances on Windows. If you haven't bumped into it already, testfixtures is a collection of helpers for writing succinct unit tests including help for: - Comparing objects and sequences Better feedback when the results aren't as you expected along with support for comparison of objects that don't normally support comparison. - Mocking out objects and methods Easy to use ways of stubbing out objects, classes or individual methods for both doc tests and unit tests. Special helpers are provided for testing with dates and times. - Testing logging Helpers for capturing logging output in both doc tests and unit tests. - Testing stream output Helpers for capturing stream output, such as that from print statements, and making assertion about it. - Testing with files and directories Support for creating and checking files and directories in sandboxes for both doc tests and unit tests. - Testing exceptions Easy to use ways of checking that a certain exception is raised, even down the to the parameters the exception is raised with. The package is on PyPI and a full list of all the links to docs, issue trackers and the like can be found here: http://www.simplistix.co.uk/software/python/testfixtures Any questions, please do ask on the Testing in Python list or on the Simplistix open source mailing list... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Mon, Apr 7, 2014 at 11:22 PM, Roy Smith r...@panix.com wrote: In all things technology related, there is an evolutionary path. It goes something like this: * bleeding edge * avant-garde * what the kewl kids are using * modern * mainstream * traditional * corporate standard * legacy * extended support * prehistoric I figure Windows (at least on the desktop) is legacy at this point. Or, in the case of XP (The Release That Wouldn't Die), extended support. I acknowledge it exists, and is still commercially important, and even has certain advantages, in the same way that I acknowledge the continued existence of incandescent light bulbs, POTS, C++, and film photography. And technologies can be, at the same time, at different points depending on where you look. To many people, OS/2 is prehistoric; to us, it's legacy. Incandescent light bulbs are legacy in a lot of places, but corporate standard in theatres (the modern replacement is LEDs, but their colors are distinctly different so you can't just pull out an incan and stick in an LED). Same goes for plenty of other technologies. To a lot of people, Windows is mainstream, and Linux is what the non-cool kids are using, which doesn't exactly fit on your scale anywhere :) So if your audience is that sort of person, then to you Windows has to be considered mainstream or at least traditional, with Linux being the modern option that you're trying to push people onto. That's how I am with my MUD client. People use Windows, Mac OS, and Linux (plus various mobile devices, which I don't support); I'd like to push more people to Linux, but as a second-best, I can get them onto the same client that I'm developing on Linux, which minimizes the cross-platform development work. That's unlikely to change any time soon, so Windows support has to be a part of what I do. Doesn't mean I can't look with envy at projects that have dropped Windows support altogether and saved themselves a mess of trouble... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Mon, Apr 7, 2014 at 11:49 PM, Marko Rauhamaa ma...@pacujo.net wrote: Roy Smith r...@panix.com: The idea that we should continue to use threading just because Windows makes process creation hideously expensive compared to thread creation doesn't impress me as an argument in favor of threading. It impresses me as an argument in favor of ditching Windows. There are many reasons to start processes or threads. One of them is performance (you have more than one CPU core). When performance is the objective, my rough guidelines would be: * Start your processes during initialization. * Start about twice as many processes as there are CPUs. IOW, the processes are there to exercise the CPUs and should not represent individual connections or other dynamic entities. That's potentially brutal on a shared system! I hope it's controlled by an option, or that you do this only in something you're writing for yourself alone. There are other reasons for forking per connection, though, such as state cleanup. You can guarantee that each job is done in a consistent state if it's spawned from the exact same point in the master process every time. That can help enormously if you're allowing any sort of foreign code, even from a trusted programmer. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
ANN: Wing IDE 5.0.5 released
Hi, Wingware has released version 5.0.5 of Wing IDE, our cross-platform integrated development environment for the Python programming language. Wing IDE includes a professional quality code editor with vi, emacs, visual studio, and other key bindings, auto-completion, call tips, goto-definition, find uses, refactoring, context-aware auto-editing, a powerful graphical debugger, version control, unit testing, search, and many other features. For details see http://wingware.com/ Changes in this minor release include: * Preference to control auto-spacing inside argument lists * Palette color and preference for changing occurrences color * Detect and flag unit tests that crash before running to completion * Fix Compare to Repository with recent SVN versions * Syntax highlighting for .scss CSS extension language files * Fix scraping extension modules in recent numpy versions * Fixed restarting after patch installation * Fix auto-editor and auto-completion context detection problems in the shells * Correctly show PEP 287 docstrings when indentation causes parse errors * Expand fold points on any edited line to avoid inaccessible folded lines * Improve and clarify validation of Python Executable in Project Properties * Several color adjustment fixes * About 25 other bug fixes For details see http://wingware.com/pub/wingide/5.0.5/CHANGELOG.txt A summary of new features in Wing 5: * Redesigned GUI based on Qt and PySide * Native GUI on OS X (and better overall OS-native look and feel) * Tools and editors can be dragged around * Toolbar and editor and Project context menus are configurable * Optional mode that opens different sets of files in each editor split * Sharable color palettes and syntax highlighting configurations * Auto-editing is on by default (except some operations that have a learning curve) * Named file sets * Sharable launch configurations * Named entry points * More control over unit testing environment * Lockable editor splits * Initial preferences dialog for new users * Support for Python 3.4 * Support for Django 1.6 * Support for matplotlib on Anaconda and with MacOSX backend * Improved Source Assistant with PEP 287 docstring rendering and return types * Improved integrated and PDF documentation For more information on what's new in Wing 5, see http://wingware.com/wingide/whatsnew Free trial: http://wingware.com/wingide/trial Downloads: http://wingware.com/downloads Feature list: http://wingware.com/wingide/features Sales: http://wingware.com/store/purchase Upgrades: https://wingware.com/store/upgrade Questions? Don't hesitate to email us at supp...@wingware.com. Thanks, -- Stephan Deibel Wingware | Python IDE The Intelligent Development Environment for Python Programmers wingware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Chris Angelico ros...@gmail.com: On Mon, Apr 7, 2014 at 11:49 PM, Marko Rauhamaa ma...@pacujo.net wrote: Roy Smith r...@panix.com: IOW, the processes are there to exercise the CPUs and should not represent individual connections or other dynamic entities. That's potentially brutal on a shared system! I hope it's controlled by an option, or that you do this only in something you're writing for yourself alone. I'm thinking of a dedicated system here and exploiting the available CPU resources as efficiently as possible. There are other reasons for forking per connection, though, such as state cleanup. If we are talking about a handful of connections, a single asyncio process will be all you need (and will be gentle to other users of the shared system). When your server has to deal with thousands of simultaneous connections, spawning a process for each connection is probably not the optimal approach. It is precisely the scalability issues that caused Windows and Java go back to event-driven processing (that was prevalent in GUI design from the get-go). A company I used to work for was bitten badly by the multithreaded classic Java I/O, and a NIO overhaul was required when the connection count went to 500 and beyond. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
On Tue, Apr 8, 2014 at 12:51 AM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: On Mon, Apr 7, 2014 at 11:49 PM, Marko Rauhamaa ma...@pacujo.net wrote: Roy Smith r...@panix.com: IOW, the processes are there to exercise the CPUs and should not represent individual connections or other dynamic entities. That's potentially brutal on a shared system! I hope it's controlled by an option, or that you do this only in something you're writing for yourself alone. I'm thinking of a dedicated system here and exploiting the available CPU resources as efficiently as possible. Huh. I don't remember the last time I worked on any system that could be dedicated to one single job. My servers are all carrying multiple services (HTTP, SMTP, IMAP, DNS, database, maybe a MUD or two...), my desktop computer doubles as a router and a VM host and a server for a few internal things (the NIV 1984 translation of the Bible is hosted there, for convenience, as is my RSS reader), etc, etc, etc. Ages since I've had enough physical hardware that I can afford to say You're *just* the XYZ server and nothing else. At very least, I'll usually want to have some spare CPU cycles so I can plop a backup service on there (eg a PostgreSQL replicating clone, or a fail-over HTTP server, or a secondary DNS), but mainly, I've been working for the past however-many years under budget constraints. Oh the luxury of a dedicated application server. But that's why I said writing for yourself alone, or govern it with an option. For any sort of general server software, it should be able to cope with a shared system. (And that should probably be the default - anyone who's running a dedicated system will normally already be aware that most programs need to be tweaked before you get maximum throughput out of them.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
Am 06.04.2014 09:25, schrieb Gary Herron: On 04/05/2014 11:53 PM, John Ladasky wrote: I find this programming pattern to be useful... but can it cause problems? No. What kind of problems are you considering? It won't break Python. It's perfectly legal code. The tuple c is still immutable, consisting of two specific objects, and (as always) without regard to the specifics or contents of those two objects. It seems a tuple's immutability is debatable, or is this another instance of the small-integer-reuse-implementation-detail-artifact? Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. a = ([1,2],[3,4]) b = a a is b True a == b True c = (1,2,3) d = (1,2,3) c is d False c == d True cheers Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On Tue, Apr 8, 2014 at 1:26 AM, Paul Kölle pkoe...@gmail.com wrote: It seems a tuple's immutability is debatable, or is this another instance of the small-integer-reuse-implementation-detail-artifact? Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. a = ([1,2],[3,4]) b = a a is b True a == b True c = (1,2,3) d = (1,2,3) c is d False c == d True That's nothing to do with mutability or reuse. With a and b, you assigned one to be the same as the other, so they are by definition identical (and equal; tuples assume that identity implies equality, even though that may not be true of their elements). With c and d, you assigned separate tuples, so they're allowed to be separate objects. I'm not sure if they're allowed to be constant-folded, but CPython apparently isn't doing so. They are still equal, though; they contain equal elements, ergo they are equal. (Note that (1, 2, 3) and (1.0, 2.0, 3.0) are equal, but they obviously can't be identical any more than 1 is 1.0 can ever be True.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
Am 07.04.2014 17:44, schrieb Chris Angelico: On Tue, Apr 8, 2014 at 1:26 AM, Paul Kölle pkoe...@gmail.com wrote: It seems a tuple's immutability is debatable, or is this another instance of the small-integer-reuse-implementation-detail-artifact? Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. a = ([1,2],[3,4]) b = a a is b True a == b True c = (1,2,3) d = (1,2,3) c is d False c == d True That's nothing to do with mutability or reuse. With a and b, you assigned one to be the same as the other, so they are by definition identical (and equal; tuples assume that identity implies equality, even though that may not be true of their elements). With c and d, you assigned separate tuples, so they're allowed to be separate objects. I'm not sure if they're allowed to be constant-folded, but CPython apparently isn't doing so. They are still equal, though; they contain equal elements, ergo they are equal. (Note that (1, 2, 3) and (1.0, 2.0, 3.0) are equal, but they obviously can't be identical any more than 1 is 1.0 can ever be True.) ChrisA Thanks Chris, stupid error indeed ;) cheers Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On Tue, Apr 8, 2014 at 5:46 AM, Paul Kölle p...@subsignal.org wrote: Thanks Chris, stupid error indeed ;) Error, at least :) This is why we have a mailing list: errors, inaccuracies, and typos, regardless of who makes them or when, are pretty much guaranteed to be caught. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On 4/7/2014 11:26 AM, Paul Kölle wrote: c = (1,2,3) d = (1,2,3) c is d False An implementation would be allowed to make that True, as it does for small ints and short strings that could be identifiers. a = 'one' b = 'one' a == b; a is b True True However, duplicate tuples are much rarer than duplicate identifier strings. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 4/6/14 12:31 PM, Rustom Mody wrote: I think python wins because it (usually) lets people do their thing (includes but not limited to CS-research) and gets out of the way. To say therefore that it is irrelevant to the research is a strange inversion of its advantages. I think so too. I find python useful for modeling (prototyping) constructs that it [python interpreter] was not 'designed' to do. [Or simply just switch to C++ for 3 months and report back with the increment in your white-hair-count] Back in the day I used Rexx to prototype a new language idea, or a new computational technique. Today I use python for prototyping. From a CS standpoint I can use python for research in morphology because of the flexibility and extensibility of the namespace, and the easy ability to create new nouns and verbs through 'def' (as either function or generator) and the iterative process over data types like 'list' and 'dict'. I am playing with neural nets again, using python, and liking the fact that I can put my ideas into practice easily and python gets out of the way. I find it a great research language. I am surprised that others only see it as a problem solving tool. I have another question for y'all, is a function (particularly a generator) a noun or a verb? Does a function (or generator) 'do' something (based on name and parms) or does it 'return' something based on name and parms? Based on name and parms should a function (or generator) function as a noun, or function as a verb, or *both*? --or, are Classes nouns only, and all functions *are* verbs only? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On 2014-04-08 02:33, Mark H Harris wrote: On 4/6/14 12:31 PM, Rustom Mody wrote: I think python wins because it (usually) lets people do their thing (includes but not limited to CS-research) and gets out of the way. To say therefore that it is irrelevant to the research is a strange inversion of its advantages. I think so too. I find python useful for modeling (prototyping) constructs that it [python interpreter] was not 'designed' to do. [Or simply just switch to C++ for 3 months and report back with the increment in your white-hair-count] Back in the day I used Rexx to prototype a new language idea, or a new computational technique. Today I use python for prototyping. From a CS standpoint I can use python for research in morphology because of the flexibility and extensibility of the namespace, and the easy ability to create new nouns and verbs through 'def' (as either function or generator) and the iterative process over data types like 'list' and 'dict'. I am playing with neural nets again, using python, and liking the fact that I can put my ideas into practice easily and python gets out of the way. I find it a great research language. I am surprised that others only see it as a problem solving tool. I have another question for y'all, is a function (particularly a generator) a noun or a verb? Does a function (or generator) 'do' something (based on name and parms) or does it 'return' something based on name and parms? Based on name and parms should a function (or generator) function as a noun, or function as a verb, or *both*? --or, are Classes nouns only, and all functions *are* verbs only? A function is an object (noun) that does stuff (verb). Does that make it clearer? :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Dennis Lee Bieber wlfr...@ix.netcom.com wrote: That's been my experience too... Threading works for me... My attempts at so called asyncio (whatever language) have always led to my having to worry about losing data if some handler takes too long to return. To me, asyncio is closer to a polling interrupt handler, and I still need a thread to handle the main processing. On a 32 bit system, the virtual address space with limit the scalabiliy for multi-threading in parallel i/o. That is, the stack space for each thread can quickly become a problem. Memory is not a problem on 64-bit servers. Multithreading can be used to solve the C10K problem, contrary to common belief. Before you dissmiss threads, take a look at this: http://www.mailinator.com/tymaPaulMultithreaded.pdf http://stackoverflow.com/questions/17593699/tcp-ip-solving-the-c10k-with-the-thread-per-client-approach My personal feeling is that asynchronous i/o is mostly useful on 32-bit systems, and the problem it actually solves is the limited virtual address space. On a 64 bit system we can just throw more RAM at it and threads be fine. Sturla -- https://mail.python.org/mailman/listinfo/python-list
gdb python print truncated string
Hi all,
I have a question regarding gdb python.
I use gdb7.7 and python2.7.6.
Here is snippet that py-print one variable:
(gdb) py-print self
local 'self' = Connection(timer1220182856=_Timeout at remote 0x7f860614b220,
timer513645288=_Timeout at remote 0xb42f760, timer1248840930=_Timeout at
remote 0x7f85f7f4c300, timer1678666863=_Timeout at remote 0x7f85fec0ddf0,
timer888598936=_Timeout at remote 0x7f860579a300, timer1566174556=_Timeout
at remote 0xe69a7d0, timer1307561941=_Timeout at remote 0x7f85e41145a0,
timer1010094072=_Timeout at remote 0xb42af40, to_device={u'sendno':
u'1252682169', u'msg_content': {u'message': {u'command': True}}, u'msg_type':
u'2'}, timer2050775853=_Timeout at remote 0x7f8606ddcb50,
timer1115907467=_Timeout at remote 0x9c02140, timer333587031=_Timeout at
remote 0xbb25450, timer71350378=_Timeout at remote 0x7f85e5e38220,
timer1044716881=_Timeout at remote 0x7f86053094c0, timer2069059536=_Timeout
at remote 0x7f85f3d3b530, timer2139990080=_Timeout at remote 0x8bd5370,
timer1121163931=_Timeout at remote 0x99e5370,
queue=Queue(unfinished_tasks=0, queue=collections.dequ
e at remote 0x7081600, maxsize=0, all_ta...(truncated)
self is instance of Connection class.
So, actually, I wanna check self.status...but you can see the print is
truncated.
I tried py-print self.status but failed.
After a lot google work, somebody mention gdb 'set print elements 0/-1', but
still failed..
So, how to check self.status value?
Thanks.
Wesley
--
https://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects inside tuples - good or bad?
On Mon, 07 Apr 2014 20:16:05 -0400, Terry Reedy wrote: On 4/7/2014 11:26 AM, Paul Kölle wrote: c = (1,2,3) d = (1,2,3) c is d False An implementation would be allowed to make that True, as it does for small ints and short strings that could be identifiers. And indeed, that happens in at least one circumstance in Python 3.3: py a, b = [(1, 2, 3) for _ in range(2)] py a is b True But: py x = 3 py a, b = [(1, 2, x) for _ in range(2)] py a is b False As Terry knows, but for the benefit of others who may not, the re-use of objects leading to object identity (a is b) is an implementation detail which *cannot be relied on*. It can change without notice, and is not a promise of the language. a = 'one' b = 'one' a == b; a is b True True In this case, it is a promise of the language that a will equal b: a and b must be bound to strings with the same value. But an implementation detail whether Python creates two strings, both with value one, or just a single string, and uses it for both a and b. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Tue, Apr 8, 2014 at 11:33 AM, Mark H Harris harrismh...@gmail.com wrote: Does a function (or generator) 'do' something (based on name and parms) or does it 'return' something based on name and parms? If it has no side effects, then it does something, where the 'something' is returning a value. Return is a verb. (It can also be a noun, but in the context of functions, it's a verb.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
change spacing to two instead of four with pep8 or flake8?
Hi, In Pylint you can change the spacing multiplier from 4 spaces to two in its pylintrc, but for the life of me I cannot find a way to do this with the flake8 / pep8 utilities. I want to avoid ignoring E111 altogether if at all possible, because it may catch other spacing problems that are not as obvious. hacky/non-hacky solutions welcome of course. If this is too specific and I should go to the pep8/flake8 MLs that is welcome advice too. Thanks, Dennis -- https://mail.python.org/mailman/listinfo/python-list
Re: Keeping track of things with dictionaries
On Sunday, April 6, 2014 12:44:13 AM UTC-7, Giuliano Bertoletti wrote: obj = brands_seen.get(brandname) if obj is None: obj = Brand() brands_seen[brandname] = obj Would dict.setdefault() solve this problem? Is there any advantage to defaultdict over setdefault() Josh -- https://mail.python.org/mailman/listinfo/python-list
Re: Keeping track of things with dictionaries
On Tue, Apr 8, 2014 at 2:02 PM, Josh English joshua.r.engl...@gmail.com wrote: On Sunday, April 6, 2014 12:44:13 AM UTC-7, Giuliano Bertoletti wrote: obj = brands_seen.get(brandname) if obj is None: obj = Brand() brands_seen[brandname] = obj Would dict.setdefault() solve this problem? Is there any advantage to defaultdict over setdefault() That depends on whether calling Brand() unnecessarily is a problem. Using setdefault() is handy when you're working with a simple list or something, but if calling Brand() is costly, or (worse) if it has side effects that you don't want, then you need to use a defaultdict. I think this is a textbook example of why defaultdict exists, though, so I'd be inclined to just use it, rather than going for setdefault :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: threading
Dennis Lee Bieber wlfr...@ix.netcom.com: That's been my experience too... Threading works for me... My attempts at so called asyncio (whatever language) have always led to my having to worry about losing data if some handler takes too long to return. To me, asyncio is closer to a polling interrupt handler, and I still need a thread to handle the main processing. Yes, asynchronous processing results in complex, event-driven state machines that can be hard to get right. However, my experience is that that's the lesser evil. About a handler taking too long: you need to guard each state with a timer. Also, you need then to handle the belated handler after the timer has expired. The main problems with threads include: * Thread-safety is rarely done right. Also, when it's done wrong, it can be virtually impossible to fix it without a significant rewrite. This is not a theoretical concern: I have had to deal with the resulting nightmares in my work. * There is no accepted, taught, industry-wide discipline on proper thread-safety practices so every developer has to improvise. I have come up with a bullet-proof way of developing with threads, but even that methodology has nasty corner cases. * Thread-safety cannot be abstracted out. IOW, divide and conquer doesn't work. You can't hide the locking inside a class and forget about it. The entire application must be aware low-level thread synchronization needs. * Threads assume each state has one exit event. At a bare minimum, each thread should be prepared to have the blocking event aborted from the outside. Unfortunately, most threading frameworks don't allow for graceful aborts (that goes for Java and Python, too). * If you have made your design around threads and finally decide asynchronous processing would have been a better choice, a complete rewrite is required if it is even possible. Library writers often only provide blocking I/O functions forcing you to insulate the libraries in thread pools. Marko -- https://mail.python.org/mailman/listinfo/python-list
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
STINNER Victor added the comment: Could you please provide bench_translate.py? Oh, I forgot to add it :-( -- Added file: http://bugs.python.org/file34744/bench_translate.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings
New submission from STINNER Victor:
In issue #21118, I optimized str.translate() in Python 3.5 for ASCII 1:1
mapping and ASCII deletion. My optimization is not used if a character is
replaced with a string (ex: abc.translate({ord('a'): xxx})) and for
non-ASCII strings.
translate_script.py is a simple benchmark for 1:1 mapping. It should be
enhanced to benchmark also replacement strings.
--
files: translate_script.py
messages: 215677
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize str.translate() for replacement with substrings and non-ASCII
strings
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file34745/translate_script.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21165
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
STINNER Victor added the comment: Do you plan to backport bug fixes to 3.3 and 2.7? Which commit? 3.3 is no more open to bug fixes, only to security fixes. New changeset 95d4e8124c6a by Victor Stinner in branch 'default': Issue #21118: Fix _PyUnicodeTranslateError_Create(), add missing format http://hg.python.org/cpython/rev/95d4e8124c6a Python 2.7 is not affected by this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21155] asyncio: calling _UnixSelectorEventLoop.create_unix_server(sock=..., path=...) must fail
Roundup Robot added the comment: New changeset a6b764848b20 by Victor Stinner in branch '3.4': Issue #21155: asyncio.EventLoop.create_unix_server() now raises a ValueError if http://hg.python.org/cpython/rev/a6b764848b20 New changeset 34ace7eb67e9 by Victor Stinner in branch 'default': (Merge 3.4) Issue #21155: asyncio.EventLoop.create_unix_server() now raises a http://hg.python.org/cpython/rev/34ace7eb67e9 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21155 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21155] asyncio: calling _UnixSelectorEventLoop.create_unix_server(sock=..., path=...) must fail
Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21155 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
STINNER Victor added the comment: I opened the issue #21165 to discuss a more generic optimization of str.translate(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings
STINNER Victor added the comment: codecs.charmap_build() (PyUnicode_BuildEncodingMap()) creates a C array (a three-level trie) for fast lookup. It is used with codecs.charmap_encode() for 8-bit encodings. We may reuse it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21111] PyLong_AsUnsignedLongAndOverflow does not exist
STINNER Victor added the comment: P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP instead as a PyVarObject of mp_limb_t's? I'll let Victor answer that one. :-) In the mean time, see issue 1814. During the development of Python 3.0, I wrote a large patch to reuse directly GMP for Python int. My conclusion is here: http://bugs.python.org/issue1814#msg77018 (hint: it's not a good idea) IMO the first problem is the memory allocation. GMP type doesn't fit well with Python type. GMP type for int has a fixed size, and then GMP allocates a second structure for digits. It's inefficient for small integers, and almost all Python int are small (smaller than 32 or 64 bits). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21166] Bus error on AMD64 FreeBSD 9.x 3.4 buildbot
New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/44/steps/compile/logs/stdio ./python -E -S -m sysconfig --generate-posix-vars Bus error (core dumped) http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4 -- messages: 215683 nosy: haypo priority: normal severity: normal status: open title: Bus error on AMD64 FreeBSD 9.x 3.4 buildbot versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs
STINNER Victor added the comment:
test_default_ecdh_curve() is still failing on x86 Ubuntu Shared 3.x:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9964/steps/test/logs/stdio
==
ERROR: test_default_ecdh_curve (test.test_ssl.ThreadedTests)
--
Traceback (most recent call last):
File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_ssl.py,
line 2596, in test_default_ecdh_curve
context.set_ciphers(ECDH)
ssl.SSLError: ('No cipher can be selected.',)
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21015
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Serhiy Storchaka added the comment: Do you plan to backport bug fixes to 3.3 and 2.7? Which commit? A fix of _PyUnicode_TranslateCharmap(). 3.3 is no more open to bug fixes, only to security fixes. Oh, I meant 3.4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
STINNER Victor added the comment: A fix of _PyUnicode_TranslateCharmap(). Sorry, I don't see which commit is a bugfix and is not backported to Python 3.4 yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
New submission from Hrvoje Nikšić:
On a Python compiled with Intel C compiler, float('nan') returns 0.0. This
behavior can be reproduced with icc versions 11 and 12.
The definition of Py_NAN in include/pymath.h expects `HUGE_VAL * 0.0` to
compile to a NaN value on IEEE754 platforms:
/* Py_NAN
* A value that evaluates to a NaN. On IEEE 754 platforms INF*0 or
* INF/INF works. Define Py_NO_NAN in pyconfig.h if your platform
* doesn't support NaNs.
*/
#if !defined(Py_NAN) !defined(Py_NO_NAN)
#define Py_NAN (Py_HUGE_VAL * 0.)
#endif
I don't have a copy of the standard, but a simple test shows that the above
does not hold for icc. When compiled with icc without any flags, the following
program outputs inf 0.00 instead of the expected inf nan:
#include stdio.h
#include math.h
int main()
{
double inf = HUGE_VAL;
double nan = HUGE_VAL * 0;
printf(%f %f\n, inf, nan);
return 0;
}
Compiling the same program with gcc yields the expected output of inf nan.
This issue can be fixed (or worked around, if it's an icc bug) by using a
different definition of Py_NAN. On icc, defining Py_NAN as `Py_HUGE_VAL /
Py_HUGE_VAL` produces the intended effect. If this is considered suboptimal on
other compilers, the definition can be conditionally compiled for icc only.
The attached patch fixes the issue, taking the conservative approach of only
modifying the icc definition of Py_NAN.
--
components: Interpreter Core
files: intel-nan.diff
keywords: patch
messages: 215687
nosy: hniksic
priority: normal
severity: normal
status: open
title: float('nan') returns 0.0 on Python compiled with icc
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file34746/intel-nan.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs
Stefan Krah added the comment: FreeBSD 9 is failing as well: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6583/steps/test/logs/stdio -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21015 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Stefan Krah added the comment: Did you compile with -fp-model strict? IIRC icc is not IEEE-754 compliant by default. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by Jurica Bradarić jbrada...@gmail.com: -- nosy: +jbradaric ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1814] Victor Stinner's GMP patch for longs
Hristo Venev added the comment: What about using PyVarObject of mp_limb_t and mpn instead of mpz_t? Addition: - Check signs and allocate. - Possibly compare absolute values. - Call mpn_(add|sub)_n and possibly mpn_(add|sub)_1 if the integers have different sizes. - Overhead for small integers: 1 Python-GMP, 1 if. Subtraction: - Same as addition Multiplication: - Check signs and allocate. - Call mpn_mul. - Overhead for small integers: 1 Python-GMP, 2 GMP-GMP, 3 if. Division: - Check signs and allocate. - Call mpn_div_q. - Overhead for small integers: 1 Python-GMP, 1 GMP-GMP, 1 if, maybe a 3 more ifs in mpn_divrem_1. Pow: - Create mpz_t values using MPZ_ROINIT_N(limbs, size) and call mpz_pow(m?). Copy from mpz_limbs_read(result). * The overhead is after checking if both arguments are integers until going to the right function (mpn_mul - mpn_mul_n - mpn_mul_basecase). Checks for adding integers 1(GMP_NUMB_BITS-1), multiplying 1(GMP_NUMB_BITS/2) and dividing 1GMP_NUMB_BITS can be added. -- nosy: +h.venev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1814] Victor Stinner's GMP patch for longs
STINNER Victor added the comment: What about using PyVarObject of mp_limb_t and mpn instead of mpz_t? FYI this issue is closed, it's not a good practice to comment closed issue (for example, the issue is hidden in the list of recent issues). If you want to learn more about my old patch, you should also read python-dev archives. Another major blocking point was the license: GMP is released under the GNU GPL license, which is incompatible with the Python License. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment:
What's `sys.float_repr_style` for this build? For Python 3.5 and short float
repr, `float('nan')` shouldn't even be using Py_NAN. It should land in
_Py_parse_inf_or_nan in pystrtod.c, which uses `_Py_dg_stdnan` to get the NaN
value directly from a suitable bitpattern.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21164] print unicode in Windows console
STINNER Victor added the comment: Hi, when you say The console is the the old MS-DOS command (Windows console) opened when you run the cmd.exe program? Or IDLE or another console? For the Windows console, see the old issue #1602 which is not fixed yet. On Windows, sys.stdout.encoding is your OEM code page, which is usually different than the ANSI code page (locale.getpreferredencoding()). -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21164 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21168] unicodeobject.c: likely type-punning may break strict-aliasing rules
New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/48/steps/compile/logs/stdio Objects/unicodeobject.c: In function '_PyUnicode_Init': Objects/unicodeobject.c:582: warning: likely type-punning may break strict-aliasing rules: object '*data' of main type 'unsigned int' is referenced at or around Objects/unicodeobject.c:582 and may be aliased to object 'linebreak' of main type 'short unsigned int' which is referenced at or around Objects/unicodeobject.c:14933. According to koobs, it's gcc 4.2.1 on this buildbot. -- messages: 215694 nosy: haypo priority: normal severity: normal status: open title: unicodeobject.c: likely type-punning may break strict-aliasing rules versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21168 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20035] Clean up Tcl library discovery in Tkinter on Windows
Serhiy Storchaka added the comment: TCL_VERSION should be set before call of Tcl_FindExecutable() (for correct Tcl encodings initialization). Tcl_FindExecutable() is called in PyInit__tkinter(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20035 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21168] unicodeobject.c: likely type-punning may break strict-aliasing rules
STINNER Victor added the comment:
The warning comes from the make_bloom_mask() call below. make_bloom_mask() is
called with kind=PyUnicode_2BYTE_KIND (Py_UCS2), whereas the gcc waring is
about Py_UCS4. It looks like a false positive.
static BLOOM_MASK bloom_linebreak = ~(BLOOM_MASK)0;
...
Py_UCS2 linebreak[] = {
...
};
/* initialize the linebreak bloom filter */
bloom_linebreak = make_bloom_mask(
PyUnicode_2BYTE_KIND, linebreak,
Py_ARRAY_LENGTH(linebreak));
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21168
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
New submission from Arfrever Frehtes Taifersar Arahesis: getpass.getpass() fails with non-ASCII characters in prompt. The attached example scripts (for Python 2 and 3) contain non-ASCII unicode prompt (Polish hasło == English password) written in UTF-8. Python-2 version fails always. Python-3 version fails in non-UTF-8 locale. $ ./getpass_test_python2 Traceback (most recent call last): File ./getpass_test_python2, line 5, in module getpass.getpass(uHasło: ) File /usr/lib64/python2.7/getpass.py, line 71, in unix_getpass passwd = _raw_input(prompt, stream, input=input) File /usr/lib64/python2.7/getpass.py, line 128, in _raw_input prompt = str(prompt) UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142' in position 3: ordinal not in range(128) $ LC_ALL=en_US.UTF-8 ./getpass_test_python3 Hasło: $ LC_ALL=C ./getpass_test_python3 Traceback (most recent call last): File ./getpass_test_python3, line 5, in module getpass.getpass(Has\u0142o: ) File /usr/lib64/python3.4/getpass.py, line 78, in unix_getpass passwd = _raw_input(prompt, stream, input=input) File /usr/lib64/python3.4/getpass.py, line 138, in _raw_input stream.write(prompt) UnicodeEncodeError: 'ascii' codec can't encode character '\u0142' in position 3: ordinal not in range(128) $ -- components: Library (Lib) keywords: easy messages: 215697 nosy: Arfrever priority: normal severity: normal stage: needs patch status: open title: getpass.getpass() fails with non-ASCII characters in prompt versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: Added file: http://bugs.python.org/file34747/getpass_test_python2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21169] getpass.getpass() fails with non-ASCII characters in prompt
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: Added file: http://bugs.python.org/file34748/getpass_test_python3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment: sys.float_repr_style is 'short'. I haven't actually tried this in Python 3.5, but I did note the same definition of Py_NAN (which is used elsewhere in the code), so I tagged the issue as likely also present in 3.x. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21166] Bus error on AMD64 FreeBSD 9.x 3.4 buildbot
koobs added the comment: Uploading gdb output at Victors request -- nosy: +koobs Added file: http://bugs.python.org/file34749/gdb.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment: The compilation was performed with the default flags, i.e. without -fp-model strict or similar. If Python requires strict IEEE 754 floating-point, it should probably be mentioned at a prominent place in the documentation. Administrators building Python with alternative compilers or on non-gcc Unix systems might not be aware of the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21166] Bus error on AMD64 FreeBSD 9.x 3.4 buildbot
koobs added the comment: Interestingly, I note the following lines from the gdb log: #5 0x000801ae1e99 in PyModule_Create2 () from /usr/local/lib/libpython3.4m.so.1 #6 0x000801840de8 in PyInit__heapq () from /usr/local/lib/python3.4/lib-dynload/_heapq.so I had installed Python 3.4 just prior to Victor reporting the issue. If its at all relevant, Python 3.4 was built using clang (not gcc, which the buildbots use) Removing Python 3.4 from the system and rebuilding makes the issue go away. The question is, what is ./python from the buildbot build directory doing using, loading or otherwise interacting with the python installation on the system in the first place? Is a lack of isolation the root cause? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment:
I tagged the issue as likely also present in 3.x.
So I believe that this particular issue (float('nan') giving zero) should not
be present on Python 3.4 or above. The bogus definition of Py_NAN will still
cause problems in some math and cmath return values, though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment: If Python requires strict IEEE 754 floating-point, It doesn't (at the moment). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21166] Bus error on AMD64 FreeBSD 9.x 3.4 buildbot
koobs added the comment: Clarification: a) I had just installed Python 3.4 (at the system level, via ports) a) Removing Python 3.4 from the system and (forcing a rebuild of the buildbot) makes the issue go away. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Changes by Mark Dickinson dicki...@gmail.com: -- versions: -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Hrvoje Nikšić added the comment: Mark: If Python requires strict IEEE 754 floating-point, It doesn't (at the moment). Does this imply that my patch is a better fix than requiring the builder to specify -fp-model strict to icc? For our use case either solution is valid. For administrators and users testing or using Python with icc, it might be more convenient for Py_NAN to do the right thing with the default icc flags. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Mark Dickinson added the comment: It doesn't (at the moment). Sorry; that was an unhelpful kneejerk reply. There are two aspects to this. (1) Currently, at least in theory, CPython doesn't require IEEE 754 *at all*: in theory, it should work with whatever floating-point format the platform's double type happens to provide. In practice I suspect there's a lot more IEEE 754 dependence in the codebase than we realize, and I'd expect to see a fair amount of test breaking if Python were ever to meet a non-IEEE 754 platform. (Reports of any *recent* occurrences of Python in the wild meeting non-IEEE 754 platforms would be welcomed.) (2) If CPython *does* figure out that it's running on an IEEE 754 platform then yes, care should be taken with compiler flags to ensure that we're not using compiler optimisations that have the potential to break IEEE semantics. Without this there's a significant danger of float to string conversions getting messed up; there are also a few odds and ends in the math and cmath libraries that depend on careful IEEE semantics. (The implementations of fsum and log1p, for example.) I think the right fix here is to add the relevant compiler flag to the build. That said, I'd *also* love to see remaining uses of Py_NAN fixed to use _Py_dg_stdnan where available. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Stefan Krah added the comment: I agree we should add -fp-model strict to the icc build flags, provided that there is a way that it does not show up in the distutils flags. Apparently icc users want unsafe fast math by default, so this flag should probably not be enforced in extension module builds. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191964] asynchronous Subprocess
Giampaolo Rodola' added the comment: Some initial comments here: http://bugs.python.org/review/1191964/#msg1. Also, if I think about integrating this into an IO loop it seems natural to me to think about timeouts. How complicated would it be to do this? data = proc.read_nonblocking(timeout=0) data = proc.read_stderr_nonblocking(timeout=0) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191964] asynchronous Subprocess
akira added the comment: Also, Richard Oudkerk's claims above about not needing to use fcntl to swap flags is not correct. It's necessary to not block on reading, even if select is used. Select just guarantees that there is at least 1 byte or a closed handle, not that your full read will complete. On Linux, `fcntl` is not necessary if you use `os.read(pipe, bufsize)` after `select` instead of `pipe.read(bufsize)`. `os.read` may just return less than `bufsize` bytes if they are not available. -- nosy: +akira ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21170] Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun()
New submission from Volodymyr Sapsai: Steps to reproduce: 1. Open docs for unittest.TestResult class. 2. Look at startTestRun() and stopTestRun() methods signatures (https://docs.python.org/3.4/library/unittest.html#unittest.TestResult.startTestRun) Actual result: It is stated that aforementioned methods accept 1 argument 'test'. Expected result: These methods don't accept any arguments, it should be stated so in the docs. -- assignee: docs@python components: Documentation messages: 215710 nosy: Volodymyr.Sapsai, docs@python priority: normal severity: normal status: open title: Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun() versions: Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21170 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21168] unicodeobject.c: likely type-punning may break strict-aliasing rules
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21168 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191964] asynchronous Subprocess
akira added the comment: Could `read_nonblocking()`, `write_nonblocking()` raise OSError(EAGAIN) (it could be named `ResourceTemporarilyUnavailableError`) if read/write would block? It would allow to distinguish EOF (permanent condition) from read/write would block (temporarily condition) without additional API calls. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14373] C implementation of functools.lru_cache
Changes by Patrick Westerhoff patrickwesterh...@gmail.com: -- nosy: +poke ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14373 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21171] Outdated usage str.encode('rot-13') in rot13 codec
New submission from Михаил Мишакин:
Function rot13 in file encodings/rot_13.py throws exception:
LookupError: 'rot-13' is not a text encoding; use codecs.encode() to handle
arbitrary codecs
--
messages: 215712
nosy: Pix
priority: normal
severity: normal
status: open
title: Outdated usage str.encode('rot-13') in rot13 codec
type: enhancement
versions: Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21171
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21171] Outdated usage str.encode('rot-13') in rot13 codec
Changes by Михаил Мишакин pixzi...@gmail.com: -- components: +Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21171 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21172] Unexpected behaviour with logging.LogRecord first arg is dict case
New submission from Alan Briolat: The logging.LogRecord class is more restrictive with its first arg is dict case than the formatting operator it uses requires. As far as I can tell, for %(foo)s % bar, the minimum contract is that bar.__getitem__(foo) succeeds, not that bar is an instance of dict. However, fulfilling only this minimum contract results in LogRecord raising an exception at the point of applying the string format, which is confusing considering the same expression succeeds outside of logging. See the attached file for how 2 equivalent expressions behave completely differently. For resolution, I wonder if checking for hasattr(..., '__getitem__') instead of isinstance(..., dict) would be sufficient? -- components: Library (Lib) files: logging_format_bug.py messages: 215713 nosy: alan.briolat priority: normal severity: normal status: open title: Unexpected behaviour with logging.LogRecord first arg is dict case type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34750/logging_format_bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21172 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21172] Unexpected behaviour with logging.LogRecord first arg is dict case
Changes by Benjamin Peterson benja...@python.org: -- assignee: - vinay.sajip nosy: +vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21172 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21139] Idle: change default reformat width from 70 to 72
Terry J. Reedy added the comment: Changing the default in the default configuration file is trivial. In test_formatparagraph.FormatEventTest, test_comment_block and test_long_line currently fail if the reformat width is changed on the General tab of the configuration dialog. These tests will need to be altered when the default is changed. Also, the tests should temporarily change the reformat width to the presumed default in the class setup and teardown methods. If this is not possible, the tests should be skipped if it is not what the test requires. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15968] Incorporate Tcl/Tk/Tix into the Windows build process
Terry J. Reedy added the comment:
I reran external.bat in all three versions and compile runs better.
Test_idle with -ugui fails to find _tkinter after another test that runs tk
(including itself) *in the same process*. Adding -j2 to run in separate process
eliminates the problem.
F:\Python\dev\5\py35pcbuild\python_d -m test -j2 -ugui test_tcl test_idle
So does not using test.test_support to run the tests. The following runs fine
either at a command line or within Idle. (Does unittest run tests in a
subprocess?)
from test import support; support.use_resources = ['gui']
import unittest
unittest.main('test.test_tcl', exit=False)
unittest.main('test.test_idle', exit=False)
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15968
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21173] WeakKeyDictionary.__len__ fragile w/ _IterationGuards
New submission from Philip Jenvey: len() on WeakKeyDictionarys can fail with ValueErrors when _IterationGuards are kept alive Attached is a test showing this: == ERROR: test_weak_keys_len_destroy_while_iterating (__main__.MappingTestCase) -- Traceback (most recent call last): File Lib/test/test_weakref.py, line 1336, in test_weak_keys_len_destroy_while_iterating self.assertEqual(len(dict), 0) ValueError: __len__() should return = 0 One probably shouldn't keep them alive like this, but __len__ shouldn't be blowing up either. On non ref counting GC platforms this situation is easier to trigger unintentionally -- components: Library (Lib) messages: 215716 nosy: pitrou, pjenvey priority: normal severity: normal status: open title: WeakKeyDictionary.__len__ fragile w/ _IterationGuards type: behavior versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21173 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21173] WeakKeyDictionary.__len__ fragile w/ _IterationGuards
Changes by Philip Jenvey pjen...@underboss.org: -- keywords: +patch Added file: http://bugs.python.org/file34751/issue21173-test.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21173 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings
Changes by Josh Rosenberg shadowranger+pyt...@gmail.com: -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21174] A typo in the docs for exception GeneratorExit
New submission from Boštjan Mejak: The docs for the exception GeneratorExit starts like this: Raise when a generator‘s close() method is called. The sentece should start with the first word Raise to say Raised. You can find this particular doc sentence on this link: https://docs.python.org/2/library/exceptions.html#exceptions.GeneratorExit This is a small fix. Just add the letter d. -- assignee: docs@python components: Documentation messages: 215717 nosy: Zvezdoslovec, docs@python priority: normal severity: normal status: open title: A typo in the docs for exception GeneratorExit type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21175] Refcounting error in str.translate fastpath
New submission from Josh Rosenberg: Py_None is not being properly decref-ed in the str.translate fast path. I've attached a simple patch that fixes this (also corrects some comments and types in the same function). No idea is Py_None ref leaks are considered a serious problem, but I figure it's better to be safe than sorry. -- files: fix_translate_none.patch keywords: patch messages: 215718 nosy: haypo, josh.rosenberg priority: normal severity: normal status: open title: Refcounting error in str.translate fastpath type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34752/fix_translate_none.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21175] Refcounting error in str.translate fastpath
Josh Rosenberg added the comment: For reference, bug introduced by fix for #21118. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21175] Refcounting error in str.translate fastpath
Josh Rosenberg added the comment: Also, just to be clear, I submitted the contributor form earlier this evening (using the online submission tool), so as soon as that propagates, it should be possible to accept my code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21174] A typo in the docs for exception GeneratorExit
Roundup Robot added the comment: New changeset aff368b58a98 by Benjamin Peterson in branch '2.7': fix verb (closes #21174) http://hg.python.org/cpython/rev/aff368b58a98 New changeset 33528b9520e6 by Benjamin Peterson in branch '3.4': fix verb (closes #21174) http://hg.python.org/cpython/rev/33528b9520e6 New changeset c48164710ed5 by Benjamin Peterson in branch 'default': merge 3.4 (#21174) http://hg.python.org/cpython/rev/c48164710ed5 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21175] Refcounting error in str.translate fastpath
Roundup Robot added the comment: New changeset fa6debebfe8b by Benjamin Peterson in branch 'default': fix reference leaks in the translate fast path (closes #21175) http://hg.python.org/cpython/rev/fa6debebfe8b -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1887] Document that distutils doesn't support out-of-source builds
Alba Magallanes added the comment: hi, here is a second version of the patch. Please review it. -- keywords: +patch Added file: http://bugs.python.org/file34753/bug1887_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1887 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21176] Implement matrix multiplication operator (PEP 465)
New submission from Alexander Belopolsky: [Nathaniel Smith at numpy-discussion] Guido just formally accepted PEP 465: https://mail.python.org/pipermail/python-dev/2014-April/133819.html http://legacy.python.org/dev/peps/pep-0465/#implementation-details Yay. The next step is to implement it, in CPython and in numpy. I have time to advise on this, but not to do it myself, so, any volunteers? Ever wanted to hack on the interpreter itself, with BDFL guarantee your patch will be accepted (if correct)? The todo list for CPython is here: http://legacy.python.org/dev/peps/pep-0465/#implementation-details There's one open question which is where the type slots should be added. I'd just add them to PyNumberMethods and then if someone objects during patch review it can be changed. -- assignee: belopolsky components: Interpreter Core messages: 215724 nosy: belopolsky priority: normal severity: normal stage: needs patch status: open title: Implement matrix multiplication operator (PEP 465) type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21176 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20035] Clean up Tcl library discovery in Tkinter on Windows
Zachary Ware added the comment: Serhiy Storchaka wrote: TCL_VERSION should be set before call of Tcl_FindExecutable() (for correct Tcl encodings initialization). Tcl_FindExecutable() is called in PyInit__tkinter(). I assume you mean TCL_LIBRARY (since TCL_VERSION is #defined in Tcl.h)? You are correct though, I missed that part of the comment at the top of tkinter._fix. However, I don't know what issues arise from not having TCL_LIBRARY set before Tcl_FindExecutable() (I haven't seen any problems, but I live in an ASCII world). Also, I have tried stepping through the Tcl_FindExecutable() call in PyInit__tkinter() with the VS debugger, and didn't see anything that looked like it was trying to read TCL_LIBRARY or hit the filesystem at all, which makes me suspect that it may not actually need TCL_LIBRARY prior to Tcl_FindExecutable(). Can you give me steps to reproduce problems with not having TCL_LIBRARY set that early? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20035 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21176] Implement matrix multiplication operator (PEP 465)
Benjamin Peterson added the comment: Here's a first patch. It works, but needs more tests (associativity, precedence, __rmatmul__, etc...) and also docs. I can work on that tomorrow. -- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file34754/mat-mult1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21176 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21059] idle_test.test_warning failure
Roundup Robot added the comment: New changeset c507da0b573f by Zachary Ware in branch 'default': Issue #21059: Temporary measure to make the Windows buildbots useful again. http://hg.python.org/cpython/rev/c507da0b573f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21059 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list.
Josh Rosenberg added the comment: Any news on this? I was about to open a bug of my own for this, since the docs and code are still out of sync. -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16395 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list.
Josh Rosenberg added the comment: As far as performance goes, presumably the length hinting API reduces the number of cases in which we're working with completely unsized iterables, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16395 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21176] Implement matrix multiplication operator (PEP 465)
Benjamin Peterson added the comment: Here are changes to the operator module... -- Added file: http://bugs.python.org/file34755/mat-mult2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21176 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21176] Implement matrix multiplication operator (PEP 465)
Alexander Belopolsky added the comment:
I've got to the point where I can do
import ast
ast.dump(ast.parse('a @ b'))
Module(body=[Expr(value=BinOp(left=Name(id='a', ctx=Load()), op=MatMult(),
right=Name(id='b', ctx=Load(])
I'll post a link to my bitbucket clone shortly.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21176
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21171] Outdated usage str.encode('rot-13') in rot13 codec
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21171 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21176] Implement matrix multiplication operator (PEP 465)
Benjamin Peterson added the comment: Here is a nearly complete patch... -- Added file: http://bugs.python.org/file34756/mat-mult3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21176 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21171] Outdated usage str.encode('rot-13') in rot13 codec
Berker Peksag added the comment: Here's a patch. I tested it with the following command: $ cat LICENSE | ./python -m encodings.rot_13 -- keywords: +patch nosy: +berker.peksag stage: - patch review type: enhancement - behavior Added file: http://bugs.python.org/file34757/issue21171.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21171 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21176] Implement matrix multiplication operator (PEP 465)
Alexander Belopolsky added the comment: Wow! That was quick. And I am still fighting with bitbucket. Maybe I should stop duplicating the effort at this point. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21176 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
