[issue23452] Build errors using VS Express 2013 in win32 mode
Zachary Ware added the comment: Unfortunately, I don't have any ideas. Mark, is this still happening? If so, I think your real solution is going to be to install VS2015 CTP 6 (and later the real thing, in whatever the free flavor is). Same for #23449. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23452 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: try..except with empty exceptions
On Saturday, April 11, 2015 at 9:47:36 AM UTC+5:30, Rustom Mody wrote: On Saturday, April 11, 2015 at 9:17:16 AM UTC+5:30, Dave Angel wrote: On 04/10/2015 10:38 PM, Rustom Mody wrote: On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote: On 04/10/2015 09:42 PM, Steven D'Aprano wrote: On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote: It isn't document because it is expected. Why would the exception get caught if you're not writing code to catch it? If you write a function and pass it a tuple of exceptions to catch, I'm not sure why you would expect it to catch an exception not in the tuple. Just because the tuple is empty doesn't mean that it should catch *everything* instead. That would be counter-intuitive. Really? I have to say, I expected it. I'm astounded at your expectation. That's like saying a for loop on an empty list ought to loop on all possible objects in the universe. To work, this analogy should also have two python syntaxes like this: Normal for-loop: for var in iterable: suite Empty for-loop: for: suite That tells me nothing about your opinions. What did you mean by the phrase to work? Your analogy is for loop on an empty list ought to loop on all possible objects in the universe This seemingly works as a demo of a ridiculous expectation because there is only one pattern of for-loop for var in iterable: In the case of exceptions we have two patterns except e-tuple: and except: with the second having a wildly different semantics from the first IOW: OP is surprised that except (): is a no-op The real surprise is that except: is valid syntax with questionable semantics -- https://mail.python.org/mailman/listinfo/python-list
Re: Exception Handling
Palpandi palpandi...@gmail.com writes: Thanks for your responses. And I have one more question. This is the situation. A python application which reads data from one .xml file and generates some other file. Here what kind of exceptions occur? Ideally, you would not get any exceptions. In the not ideal case, you may get exceptions from the XML parser (in case, your XML input file is not valid), the os module (for permission or filesystem related problems) and potentially exceptions (such as AttributeError) from your own program logic (in case it would be faulty). I support Chris' recommendation to not care about exceptions intially (as they are exceptions - and do not occur frequently) and decide what to do should they really occur. -- https://mail.python.org/mailman/listinfo/python-list
[issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files
Serhiy Storchaka added the comment: Updated to the tip. -- Added file: http://bugs.python.org/file38895/io_clinic_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23887] HTTPError doesn't have a good repr representation
Martin Panter added the comment: Perhaps it would be more appropriate to set the BaseException.args attribute, or chain to its __init__() method, then you wouldn’t need a custom __repr__(). -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23887 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: find all multiplicands and multipliers for a number
Dario Alpern has written a program that uses the Elliptic Curve Method (ECM) for factorising a number. ECM is one of the _very_ fast methods for finding the prime factors of a number. He has even offered the code for his program. You could have a go at using or converting his code to do what you are wanting to do. The URL for this is http://www.alpertron.com.ar/ECM.HTM This program found the prime factors of 2^111+1 in less than 1 second on my computer. (And that is the string I gave it.) What has been said by previous contributors about the difficulty of factorising numbers is all true. However, there are some relatively fast algorithms out there. Try searching for Number Field Sieve Quadratic Number Field Sieve and see where they take you. On Sat, Apr 11, 2015 at 3:04 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 11 Apr 2015 11:06 am, Dave Angel wrote: But the real place to get improvement is to only divide by primes, rather than every possible integer. And once you've done the division, let q be the next value for dividend. So you'll get a list like [3, 3, 3, 37] for the value 999 Prime factorization is a *hard* problem. If it wasn't, most of modern technology that relies on encryption (like https, ssh, internet banking etc.) would be trivially broken. But for what it is worth, my pyprimes library can return the prime factorization of numbers: py import pyprimes.factors py pyprimes.factors.factorise(1234567890) [2, 3, 3, 5, 3607, 3803] py pyprimes.factors.factorise(9753124680) [2, 2, 2, 3, 3, 3, 5, 13, 191, 3637L] It may be a bit slow for very large numbers. On my computer, this takes 20 seconds: py pyprimes.factors.factorise(2**111+1) [3, 3, 1777, 3331, 17539, 25781083, 107775231312019L] but that is the nature of factorising large numbers. http://code.google.com/p/pyprimes/source/browse/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
[issue23910] C implementation of namedtuple (WIP)
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: try..except with empty exceptions
On 04/10/2015 10:38 PM, Rustom Mody wrote:
On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote:
It isn't document because it is expected. Why would the exception get
caught if you're not writing code to catch it? If you write a function
and pass it a tuple of exceptions to catch, I'm not sure why you would
expect it to catch an exception not in the tuple. Just because the tuple
is empty doesn't mean that it should catch *everything* instead. That
would be counter-intuitive.
Really? I have to say, I expected it.
I'm astounded at your expectation. That's like saying a for loop on an
empty list ought to loop on all possible objects in the universe.
To work, this analogy should also have two python syntaxes like this:
Normal for-loop:
for var in iterable:
suite
Empty for-loop:
for:
suite
That tells me nothing about your opinions. What did you mean by the
phrase to work? My analogy already works. The for loop on an empty
list loops zero times. Just like try/except on an empty tuple catches
zero exception types.
As for the separate syntax, that might be an acceptable extension to
Python. But it already has a convention for an infinite loop, which is
while True:
I'm pretty sure do{} works as an infinite loop in C, but perhaps I'm
remembering some other language where you could omit the conditional.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Re: try..except with empty exceptions
On Saturday, April 11, 2015 at 9:17:16 AM UTC+5:30, Dave Angel wrote: On 04/10/2015 10:38 PM, Rustom Mody wrote: On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote: On 04/10/2015 09:42 PM, Steven D'Aprano wrote: On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote: It isn't document because it is expected. Why would the exception get caught if you're not writing code to catch it? If you write a function and pass it a tuple of exceptions to catch, I'm not sure why you would expect it to catch an exception not in the tuple. Just because the tuple is empty doesn't mean that it should catch *everything* instead. That would be counter-intuitive. Really? I have to say, I expected it. I'm astounded at your expectation. That's like saying a for loop on an empty list ought to loop on all possible objects in the universe. To work, this analogy should also have two python syntaxes like this: Normal for-loop: for var in iterable: suite Empty for-loop: for: suite That tells me nothing about your opinions. What did you mean by the phrase to work? Your analogy is for loop on an empty list ought to loop on all possible objects in the universe This seemingly works as a demo of a ridiculous expectation because there is only one pattern of for-loop for var in iterable: In the case of exceptions we have two patterns except e-tuple: and except: with the second having a wildly different semantics from the first -- https://mail.python.org/mailman/listinfo/python-list
[issue23899] HTTP regression in distutils uploads to chishop
Donald Stufft added the comment: I wonder if it's this? https://github.com/python/cpython/commit/453f86c6977bab18fe4a9c58a4155253375adc8e#diff-ff7dba04c5ad252aa440598d6c88067a -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23899 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
New submission from Joe Jevnik: I am working on implementing nameduple in C; I am almost there; however, on the path of moving to full compatibility, I ran into a refcount issue somewhere. Hopefully someone can help me work this out. To describe the issue, When I run the collections tests I most frequently segfault in a non namedtuple test; however, sometimes it runs (and passes) however that probably means I am using an unowned obect somewhere. I am new to the CPython API so I would love to go through this with someone to learn more about how it all works. I am currently at PyCon and would absolutly love to speak to someone in person. I will be at CPython sprints for at least one day. -- components: Extension Modules files: namedtuple.patch keywords: patch messages: 240447 nosy: ll priority: normal severity: normal status: open title: C implementation of namedtuple (WIP) type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38892/namedtuple.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Eric V. Smith added the comment: What's the motivating use case for this? -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Joe Jevnik added the comment: Ideally, namedtuple is used to make your code cleaner, using magic indecies is less clear than using a named index in a lot of cases. Because namedtuple is mainly to make the code more readable, I don't think that it should have an impact on the runtime performance of the code. This means that namedtuple should be a very thin wrapper around tuple. Currently, namedtuple named item access is much slower than elementwise access. I have this as a standalone package (there are some changes in the diff I posted to acheive full backwards compat) here https://pypi.python.org/pypi/cnamedtuple/0.1.5 that show some profiling runs of this code. The notable one to me is named item access being around twice as fast. Another issue we ran into at work is that we found ways to get the exec call in nametuple to execute arbitrary code; while this would not be a concern for most people by the nature of the way we got this to happen, we wanted to look at other ways of writing namedtuple. I looked through some older discussion and found that non-exec solutions were rejected in the past for perfomance reasons. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Eric V. Smith added the comment: Have you thought of just exposing Object/structseq.c? Before you put much time into this, I'd get Raymond's acceptance of whatever approach you want to take. It might be best to raise it on python-ideas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Joe Jevnik added the comment: would the idea be to deprecate namedtuple in favor of a public structseq that is exposed through collections, or change structseq to fit the namedtuple API? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21859] Add Python implementation of FileIO
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21859 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Eric V. Smith added the comment: I haven't seen thought it through, just that it seems very similar to a C namedtuple. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23528] Limit decompressed data when reading from GzipFile
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - duplicate stage: patch review - resolved status: open - closed superseder: - Limit decompressed data when reading from LZMAFile and BZ2File ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23528 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23529] Limit decompressed data when reading from LZMAFile and BZ2File
Roundup Robot added the comment: New changeset 62723172412c by Antoine Pitrou in branch 'default': Issue #23529: Limit the size of decompressed data when reading from https://hg.python.org/cpython/rev/62723172412c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23529 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23529] Limit decompressed data when reading from LZMAFile and BZ2File
Antoine Pitrou added the comment: Thank you very much for being so perseverant! The patch is now pushed into the default branch. -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23529 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23909] highlight query string does not work on docs.python.org/2
Roundup Robot added the comment: New changeset 89d47911209b by Benjamin Peterson in branch '2.7': highlight is now highlighted (closes #23909) https://hg.python.org/cpython/rev/89d47911209b -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20693] Sidebar scrolls down 2x as fast as page content
Zachary Ware added the comment: Is this still a problem? I haven't noticed it on docs.python.org in quite some time. Ezio, can you still reproduce? -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20693 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23911] Move path-based bootstrap code to a separate frozen file.
New submission from Eric Snow: The bootstrap code has a clear division between the core import functionality and the path-based import machinery. The attached patch makes that division explicit by moving the latter into its own module. The module is also frozen, necessarily. In addition to clearly distinguishing the two parts, this division will help with some later work that I'd like to do later with an encapsulated import system abstraction. The patch uses the name pathy throughout, which I'll change to something more descriptive later. I'll also add the news entry then. -- assignee: eric.snow components: Interpreter Core files: path-based-importlib.diff keywords: patch messages: 240457 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: patch review status: open title: Move path-based bootstrap code to a separate frozen file. type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38893/path-based-importlib.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21416] argparse should accept bytes arguments as originally passed
Changes by Zachary Ware zachary.w...@gmail.com: -- resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23912] Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup
New submission from James Edwards: There's inconsistent leading whitespace between the two classes in the 4th code snippet of the Special Method Lookup section. https://docs.python.org/3/reference/datamodel.html#special-method-lookup The (very substantial :) included patch makes both classes use consistent leading whitespace, that is PEP-8 conformant. (This issue also exists in the Python 2 documentation[1], but since other things have changed -- e.g. print statement - function, metaclass declaration -- the same patch won't apply cleanly.) [1] https://docs.python.org/2/reference/datamodel.html#special-method-lookup-for-new-style-classes -- assignee: docs@python components: Documentation files: datamodel.rst.diff keywords: patch messages: 240458 nosy: docs@python, jedwards priority: normal severity: normal status: open title: Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup versions: Python 3.6 Added file: http://bugs.python.org/file38894/datamodel.rst.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23912 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9740] Client support for HTTP 1.1 persistent connections throughout the standard library
Martin Panter added the comment: Tweaking the title to exclude servers. Persistent connections have apparently been supported in the low-level server for ages, since Issue 430706, and now that the close_connection flag is documented (Issue 23410), someone implementing a server should be able to use that to implement HTTP 1.0 keep-alive connections, etc as well. For the client aspect, this bug is rather vague about exactly what should be added. Issue 3566 has been committed and closed, meaning now we should have an easier way to detect when a persistent connection has been dropped by the server. Here is a list of other things that come to mind: 1. Allow a way of polling for an unsolicited disconnection or 408 response without sending a request, either by: * exposing the sock attribute or adding a fileno() method, so that select() can be called, or * adding a new poll_response() or similar method 2. Poll if disconnected before sending a request, to avoid in 99% of cases the problem with non-idempotent requests (like POST) where you do not know if they were accepted or not 3. Change urlopen() to reuse the same connection when retrying a request (e.g. for redirects, authentication) 4. A urllib.request.PersistentConnectionHandler class or other urlopen() level API where the caller can reuse the same connection for multiple requests to the same host. Like HTTPConnection mainly does, but with the extra redirect, error, etc handling of urlopen(). I think the first point is important to do, because I have had to work around this by relying on the undocumented “HTTPConnection.sock” attribute. Once point 1 is done, point 2 might be easy to do in user code. The last two points I currently don’t have so much personal interest in seeing in the standard library, unless others also want something like them. -- title: Support for HTTP 1.1 persistent connections throughout the standard library - Client support for HTTP 1.1 persistent connections throughout the standard library ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: try..except with empty exceptions
On 04/10/2015 04:48 AM, Pavel S wrote: Hi, I noticed interesting behaviour. Since I don't have python3 installation here, I tested that on Python 2.7. Well known feature is that try..except block can catch multiple exceptions listed in a tuple: exceptions = ( TypeError, ValueError ) try: a, b = None except exceptions, e: print 'Catched error:', e However when exceptions=(), then try..except block behaves as no try..except block. exceptions = () try: a, b = None # --- the error will not be catched except exceptions, e: print 'Catched error:', e I found use case for it, e.g. when I want to have a method with 'exceptions' argument: def catch_exceptions(exceptions=()): try: do_something() except exceptions: do_something_else() catch_exceptions() # catches nothing catch_exceptions((TypeError,)) # catches TypeError I believe that behaviour is not documented. What you think? It's no more surprising than a for loop over an empty tuple or empty list. There's nothing to do, so you do nothing. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Sudoku solver
In article 87iodoakft@elektro.pacujo.net, Marko Rauhamaa ma...@pacujo.net wrote: Ian Kelly ian.g.ke...@gmail.com: The test puzzle that you posted has 23 values already filled in. How does it perform on harder puzzles with only 17 clues (the proven minimum)? One would expect it to be around a million times slower. Just try it. The example had a minimum of clues (drop one clue and you'll get multiple solutions). URL: http://www.telegraph.co.uk/news/science/science-news/9359579/W orlds-hardest-sudoku-can-you-crack-it.html mentions this puzzle: 8 . . . . . . . . . . 3 6 . . . . . . 7 . . 9 . 2 . . . 5 . . . 7 . . . . . . . 4 5 7 . . . . . 1 . . . 3 . . . 1 . . . . 6 8 . . 8 5 . . . 1 . . 9 . . . . 4 . . It takes about 2 seconds for my Python program to find the answer but it spends a total of 110 seconds to exhaust the problem space. The analogous C program finished the whole thing in 200 milliseconds. That is a more reasonable time for a realistic algorithm. This puzzle takes 255 ms in a program that I wrote in 2008 in Forth. Marko Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
find all multiplicands and multipliers for a number
def m_and_m(dividend): rlist = [] dm = divmod end = (dividend // 2) + 1 for divisor in range(1, end): q, r = dm(dividend, divisor) if r is 0: rlist.append((divisor, q)) return rlist print(m_and_m(999)) --- output: [(1, 999), (3, 333), (9, 111), (27, 37), (37, 27), (111, 9), (333, 3)] --- How do we describe this function? Does it have an established name? What would you call it? Does 'Rosetta Code' have it or something that uses it? Can it be written to be more efficient? What is the most efficient way to exclude the superfluous inverse tuples? Can it be written for decimal numbers as input and/or output? Thank you! -- https://mail.python.org/mailman/listinfo/python-list
Re: find all multiplicands and multipliers for a number
On 04/10/2015 07:37 PM, ravas wrote: def m_and_m(dividend): rlist = [] dm = divmod end = (dividend // 2) + 1 for divisor in range(1, end): q, r = dm(dividend, divisor) if r is 0: rlist.append((divisor, q)) return rlist print(m_and_m(999)) --- output: [(1, 999), (3, 333), (9, 111), (27, 37), (37, 27), (111, 9), (333, 3)] --- How do we describe this function? Does it have an established name? What would you call it? Does 'Rosetta Code' have it or something that uses it? Can it be written to be more efficient? What is the most efficient way to exclude the superfluous inverse tuples? Can it be written for decimal numbers as input and/or output? Thank you! I'd call those factors of the original number. For completeness, I'd include (999,1) at the end. If it were my problem, I'd be looking for only prime factors. Then if someone wanted all the factors, they could derive them from the primes, by multiplying all possible combinations. The program can be sped up most obviously by stopping as soon as you get a tuple where divisor q. At that point, you can just repeat all the items, reversing divisor and q for each item. Of course, now I notice you want to eliminate them. So just break out of the loop when divisor q. You can gain some more speed by calculating the square root of the dividend, and stopping when you get there. But the real place to get improvement is to only divide by primes, rather than every possible integer. And once you've done the division, let q be the next value for dividend. So you'll get a list like [3, 3, 3, 37] for the value 999 See: http://rosettacode.org/wiki/Factors_of_an_integer#Python -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: find all multiplicands and multipliers for a number
On 04/10/2015 09:06 PM, Dave Angel wrote: On 04/10/2015 07:37 PM, ravas wrote: def m_and_m(dividend): rlist = [] dm = divmod end = (dividend // 2) + 1 for divisor in range(1, end): q, r = dm(dividend, divisor) if r is 0: rlist.append((divisor, q)) return rlist print(m_and_m(999)) --- output: [(1, 999), (3, 333), (9, 111), (27, 37), (37, 27), (111, 9), (333, 3)] --- How do we describe this function? Does it have an established name? What would you call it? Does 'Rosetta Code' have it or something that uses it? Can it be written to be more efficient? What is the most efficient way to exclude the superfluous inverse tuples? Can it be written for decimal numbers as input and/or output? Thank you! I'd call those factors of the original number. For completeness, I'd include (999,1) at the end. If it were my problem, I'd be looking for only prime factors. Then if someone wanted all the factors, they could derive them from the primes, by multiplying all possible combinations. The program can be sped up most obviously by stopping as soon as you get a tuple where divisor q. At that point, you can just repeat all the items, reversing divisor and q for each item. Of course, now I notice you want to eliminate them. So just break out of the loop when divisor q. You can gain some more speed by calculating the square root of the dividend, and stopping when you get there. But the real place to get improvement is to only divide by primes, rather than every possible integer. And once you've done the division, let q be the next value for dividend. So you'll get a list like [3, 3, 3, 37] for the value 999 See: http://rosettacode.org/wiki/Factors_of_an_integer#Python And http://rosettacode.org/wiki/Prime_decomposition#Python There the function that you should grok is decompose() -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: find all multiplicands and multipliers for a number
ravas ra...@outlook.com writes: for divisor in range(1, end): q, r = dm(dividend, divisor) if r is 0: rlist.append((divisor, q)) Use r == 0 instead of r is 0 there. r is 0 is object identity that might happen to work but that's an implementation detail in the interpreter. output: [(1, 999), (3, 333), (9, 111), (27, 37), (37, 27), (111, 9), (333, 3)] How do we describe this function? Listing the divisors of n Does it have an established name? It's closely related to factoring. The number of factors as a function of n is called the Euler totient function, What would you call it? Enumerating the divisors. Easier to do if you know the factors. Does 'Rosetta Code' have it or something that uses it? Don't know. Try their search function looking for factoring. Can it be written to be more efficient? Yes, definitely. Simplest is make a list of the factors and then generate combinations of them. Factor the number by trial division, dividing out each factor as you find it, stopping when you get above the square root of whatever is left. There are fancier methods to factor even more efficiently and whole books have been written about them, but the above is a start. You might like www.projecteuler.net which has lots more of these math-oriented exercises, though the later ones get pretty hard. -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except with empty exceptions
On Sat, 11 Apr 2015 05:31 am, sohcahto...@gmail.com wrote: It isn't document because it is expected. Why would the exception get caught if you're not writing code to catch it? If you write a function and pass it a tuple of exceptions to catch, I'm not sure why you would expect it to catch an exception not in the tuple. Just because the tuple is empty doesn't mean that it should catch *everything* instead. That would be counter-intuitive. Really? I have to say, I expected it. try: spam() except This, That: # Implicitly a tuple of two exceptions. pass Compare: try: spam() except: # Implicitly an empty tuple. pass I'm not surprised that it fails, especially in Python 2 before the except ... as err syntax was available, but the OP is not alone in thinking that an empty tuple should catch everything. I'm fairly dubious about catching everything, that sounds like a good way to hide bugs, but if you need to catch everything, using Exception is the usual way to do it. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
wikipedia data sets
anyone know anything about downloading wikipedia data sets? are there any data field descriptions? am searching for table of all government organizations. While there may not be specific wikipedia fields indicating whether an organization is a government entity or not, there may be a URL field that ends .gov or other indicators. thanks, Alex Glaros -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except with empty exceptions
On Friday, April 10, 2015 at 2:18:22 PM UTC+5:30, Pavel S wrote: Hi, I noticed interesting behaviour. Since I don't have python3 installation here, I tested that on Python 2.7. Well known feature is that try..except block can catch multiple exceptions listed in a tuple: exceptions = ( TypeError, ValueError ) try: a, b = None except exceptions, e: print 'Catched error:', e However when exceptions=(), then try..except block behaves as no try..except block. exceptions = () try: a, b = None # --- the error will not be catched except exceptions, e: print 'Catched error:', e I found use case for it, e.g. when I want to have a method with 'exceptions' argument: def catch_exceptions(exceptions=()): try: do_something() except exceptions: do_something_else() catch_exceptions() # catches nothing catch_exceptions((TypeError,)) # catches TypeError I believe that behaviour is not documented. What you think? As others have pointed out: You asked for it; you got it; what's the issue? Nevertheless a tentative +1 from me on the suggestions ∵ except : catches everything except (): catches nothing --- which is brittle to say the least. Also given this sort of lines in the docs (2.7 tutorial): - ... except (RuntimeError, TypeError, NameError): ... pass Note that the parentheses around this tuple are required, because except ValueError, e: was the syntax used for what is normally written as except ValueError as e: in modern Python (described below). The old syntax is still supported for backwards compatibility. This means except RuntimeError, TypeError is not equivalent to except (RuntimeError, TypeError): but to except RuntimeError as TypeError: which is not what you want. there's already some versioning related brittleness around except. -- https://mail.python.org/mailman/listinfo/python-list
Re: find all multiplicands and multipliers for a number
On Sat, 11 Apr 2015 11:06 am, Dave Angel wrote: But the real place to get improvement is to only divide by primes, rather than every possible integer. And once you've done the division, let q be the next value for dividend. So you'll get a list like [3, 3, 3, 37] for the value 999 Prime factorization is a *hard* problem. If it wasn't, most of modern technology that relies on encryption (like https, ssh, internet banking etc.) would be trivially broken. But for what it is worth, my pyprimes library can return the prime factorization of numbers: py import pyprimes.factors py pyprimes.factors.factorise(1234567890) [2, 3, 3, 5, 3607, 3803] py pyprimes.factors.factorise(9753124680) [2, 2, 2, 3, 3, 3, 5, 13, 191, 3637L] It may be a bit slow for very large numbers. On my computer, this takes 20 seconds: py pyprimes.factors.factorise(2**111+1) [3, 3, 1777, 3331, 17539, 25781083, 107775231312019L] but that is the nature of factorising large numbers. http://code.google.com/p/pyprimes/source/browse/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: wikipedia data sets
alexgla...@gmail.com writes: anyone know anything about downloading wikipedia data sets? They are at dumps.wikimedia.org are there any data field descriptions? I think there is some old and light documentation on that site, but mostly you can just look at the files and see where stuff is. am searching for table of all government organizations. Try wikidata.org rather than wikipedia, but even that might not get you quite what you want. -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except with empty exceptions
On 04/10/2015 09:42 PM, Steven D'Aprano wrote: On Sat, 11 Apr 2015 05:31 am, sohcahto...@gmail.com wrote: It isn't document because it is expected. Why would the exception get caught if you're not writing code to catch it? If you write a function and pass it a tuple of exceptions to catch, I'm not sure why you would expect it to catch an exception not in the tuple. Just because the tuple is empty doesn't mean that it should catch *everything* instead. That would be counter-intuitive. Really? I have to say, I expected it. I'm astounded at your expectation. That's like saying a for loop on an empty list ought to loop on all possible objects in the universe. The tuple lists those exceptions you're interested in, and they are tried, presumably in order, from that collection. If none of those match, then the logic will advance to the next except clause. If the tuple is empty, then clearly none will match. try: spam() except This, That: # Implicitly a tuple of two exceptions. pass Compare: try: spam() except: # Implicitly an empty tuple. No, an omitted item is not the same as an empty tuple. If it were, then we wouldn't have the problem of bare excepts, which are so tempting to novices. There's plenty of precedent in many languages for a missing item being distinct from anything one could actually supply. When there's no tuple specified, it's a different syntax, and the semantics are specified separately. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: try..except with empty exceptions
On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote: On 04/10/2015 09:42 PM, Steven D'Aprano wrote: On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote: It isn't document because it is expected. Why would the exception get caught if you're not writing code to catch it? If you write a function and pass it a tuple of exceptions to catch, I'm not sure why you would expect it to catch an exception not in the tuple. Just because the tuple is empty doesn't mean that it should catch *everything* instead. That would be counter-intuitive. Really? I have to say, I expected it. I'm astounded at your expectation. That's like saying a for loop on an empty list ought to loop on all possible objects in the universe. To work, this analogy should also have two python syntaxes like this: Normal for-loop: for var in iterable: suite Empty for-loop: for: suite [Sorry Steven… didn't notice you were agreeing with me… a rare privilege ] -- https://mail.python.org/mailman/listinfo/python-list
