Re: try/except/finally
Mark Lawrence breamore...@yahoo.co.uk: A return statement inside a finally block is code smell. Not to my nose. It seems like a perfectly reasonable thing to do. I agree, the code smell is the return in the except block. Here's a regular pattern that I use for nonblocking I/O: def poll(self): try: message = self.sock.recv(0x1) except IOError as e: if e.errno == errno.EAGAIN: return if errcode == errno.EINTR: self.trigger() return self.handle_io_error(e.errno) return self.trigger() self.handle_recv(message) Does anyone have an example motivating a return from finally? It seems to me it would always be a bad idea as it silently clears all unexpected exceptions. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Thanks for the extensive feedback. Here's my thoughts on how to address these
issues.
On Saturday, 7 June 2014 20:20:48 UTC+1, Ian wrote:
It's a nice feature in a statically typed language, but I'm not sure
how well it would work in a language as dynamic as Python. There are
some questions that would need to be addressed.
1) Where should the function (or perhaps callable) be looked for? The
most obvious place is the global scope. I think it would be a bit too
far-reaching and inconsistent with other language features to reach
directly inside imported modules (not to mention that it could easily
get to be far too slow in a module with lots of imports). As a result
it would have to be imported using the from module import function
syntax, rather than the somewhat cleaner import module syntax.
While there's nothing wrong with such imports, I'm not sure I like the
thought of the language encouraging them any more than necessary.
It would only work on functions in scope. x.len() would only work if len(x)
would work. I actually think this would work better in Python than in D. In
D, import module; imports all the symbols from the module, so it is easier to
invoke a function unexpectedly. In Python, import module does not fill the
namespace with lots of callable symbols, so UFCS would generally work with
built-ins, local functions, or functions explicitly imported with from module
import In this case, the need to use the from module import fname form
can document that something unusual is happening.
2) What about getattr and hasattr? If I call hasattr(x,
some_method), and x has no such attribute, but there is a function
in the global scope named some_method, should it return True?
If we instead have hasattr return False though, and have getattr raise
an exception, then we have this very magical and confusing
circumstance where getattr(x, 'method') raises an exception but
x.method does not. So I don't think that's really a good scenario
either.
AS you suggest, the preferable route is that hasattr should return False. The
object clearly does not have that attribute. It is a property of the current
module that the object can use instance.fname. While the behaviour that
hasattr(fname) returns False, but instance.fname works is an exception, and a
function could be added to test this quickly, so new code that cares could use:
if hasattr(instance, fname) or inscopecallable('fname'):
The bigger problem I find is reading other code that uses UFCS and not
realising that a method is not actually a method of the class, but requires
importing a module. That can cause confusion when trying to use it in your own
code. However, the need to use from module import fname would at least link
the method name and the module.
Also the idea makes me nervous in the thought that an incorrect
attribute access could accidentally and somewhat randomly pick up some
object from the environment.
As before, I think the limited number of strange callable objects in most
modules in Python protects against this. Of course, from module import *
might cause problems, but that is already true. You need to be extra careful
doing this, and should only do it for modules when you have a reasonable
understanding of their exported names.
But if you want to experiment with the idea, here's a (lightly tested)
mixin that implements the behavior:
Thanks for the headstart! I'll need to read up on descriptors to understand
that last bit fully (when a function has a __get__ method).
One problem with your untested code, the superclasses would need to be checked
before using UFCS, so the structure is:
try:
return super().__getattr__(attr)
except AttributeError:
# resolve using UFCS
--
https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote: Also it doesn't sit well with Python's one obvious way to do it guideline, because it means there are *two* equally obvious ways to call a function. This provides a way to do something new (add class-optimized implementations for existing general-purpose functions). It also adds significant readability improvements by putting function-call chains in order. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote: Also it doesn't sit well with Python's one obvious way to do it guideline, because it means there are *two* equally obvious ways to call a function. Actually, one of the best arguments against introducing UFCS is that Python currently provides two equivalent ways to check if an instance has an attribute: ask-permission using hasattr and ask-forgiveness using AttributeError. On the negative side, these currently equivalent (aside from performance) techniques could give different results using UFCS, potentially breaking some code. On the positive side, that means the proposal would add one two ways to do something and eliminate another two ways to do something, giving a net Zen of Python effect of zero. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Hello, On Sun, 8 Jun 2014 01:15:43 -0700 (PDT) jongiddy jongi...@gmail.com wrote: Thanks for the extensive feedback. Here's my thoughts on how to address these issues. On Saturday, 7 June 2014 20:20:48 UTC+1, Ian wrote: It's a nice feature in a statically typed language, but I'm not sure how well it would work in a language as dynamic as Python. There are some questions that would need to be addressed. 1) Where should the function (or perhaps callable) be looked for? The most obvious place is the global scope. I think it would be a bit too far-reaching and inconsistent with other language features to reach directly inside imported modules (not to mention that it could easily get to be far too slow in a module with lots of imports). As a result it would have to be imported using the from module import function syntax, rather than the somewhat cleaner import module syntax. While there's nothing wrong with such imports, I'm not sure I like the thought of the language encouraging them any more than necessary. It would only work on functions in scope. x.len() would only work if len(x) would work. In other words, you propose you add yet another check for each function call. But what many people has to say about Python is that it's slow. There should be lookout for how to make it faster, not yet slower. [] The bigger problem I find is reading other code that uses UFCS and not realising that a method is not actually a method of the class, but requires importing a module. That can cause confusion when trying to use it in your own code. Indeed, this UFCS idea adds inefficiency and confusion, but doesn't appear to solve any reasonable problem or add any firm benefit. -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Hello, On Sun, 8 Jun 2014 01:26:04 -0700 (PDT) jongiddy jongi...@gmail.com wrote: On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote: Also it doesn't sit well with Python's one obvious way to do it guideline, because it means there are *two* equally obvious ways to call a function. This provides a way to do something new (add class-optimized implementations for existing general-purpose functions). Python already has that - like, len(x) calls x.__len__() if it's defined (for objects where it makes sense for it to be defined). Many builtin functions have such behavior. For your custom functions, you can add similar conventions and functionality very easily (if you'll want to apply it to not your types, you'll need to subclass them, as expected). Getting x.foo() to call foo(x) is what's bigger problem, which has serious performance and scoping confusion implications, as discussed in other mails. It also adds significant readability improvements by putting function-call chains in order. Not sure what exactly you mean, but the order is usually pretty obvious - Python follows mathematical notation for function calls, and OO standard notation for method calls, one known from primary school, another from secondary (hopefully). They can be reordered with parentheses, which is also well-known basic math technique. -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 2014-06-07 17:18, Marko Rauhamaa wrote: Roy Smith r...@panix.com: The original MacOS was written in Pascal (both applications and kernel). Being able to touch memory locations or registers requires no more than a few short glue routines written in assembler. Pascal is essentially equivalent to C, except Pascal has a cleaner syntax. I like the fact that the semicolon is a separator. Also, the variable declaration syntax is done more smartly in Pascal. And the pointer/array confusion in C is silly. I also like the fact that the semicolon is a separator, but, in practice, misplaced semicolons can cause problems, so languages descended of Pascal prefer to have explicit terminators. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article 5393dd6a$0$29988$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 07 Jun 2014 20:09:37 -0400, Roy Smith wrote: We've also got machines that are so fast, it's not longer critical that we squeeze out every last iota of performance. Oh, but wait, now we're trying to do absurd things like play full-motion video games on phones, where efficiency equates to battery life. Sigh. That's where there needs to be a concerted push to develop more efficient CPUs and memory, in the engineering sense of efficiency (i.e. better power consumption, not speed). In desktop and server class machines, increasing speed has generated more and more waste heat, to the point where Google likes to build its server farms next to rivers to reduce their air conditioning costs. You can't afford to do that on a battery. Even for desktops and servers, I'd prefer to give up, say, 80% of future speed gains for a 50% reduction in my electricity bill. For desktops, I'm more concerned about physical size. On my desk at work, I have a Mac Mini. It's about 8 inches square, by an inch and a half high. It sits in a corner of my desk and doesn't take up much room. The guy that sits next to me has a Dell running Linux. It's about 8 inches wide, 15 inches deep, and 24 inches high. In terms of CPU, memory, disk, video, networking, etc, they have virtually identical specs. I've never compared the power consumption, but I assume his eats many time the electricity mine does (not to mention makes more noise). -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
In article 1dd863ba-09e5-439b-8669-db65f3e99...@googlegroups.com, jongiddy jongi...@gmail.com wrote: On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote: Also it doesn't sit well with Python's one obvious way to do it guideline, because it means there are *two* equally obvious ways to call a function. Actually, one of the best arguments against introducing UFCS is that Python currently provides two equivalent ways to check if an instance has an attribute: ask-permission using hasattr and ask-forgiveness using AttributeError. On the negative side, these currently equivalent (aside from performance) techniques could give different results using UFCS, potentially breaking some code. Why? I assume a language which promoted the global namespace to be in the attribute search path (which, as far as I can tell, is what we're talking about here) would implement hasattr and raising AttributeError in a consistent way. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sunday, 8 June 2014 15:59:14 UTC+1, Roy Smith wrote:
Why? I assume a language which promoted the global namespace to be in
the attribute search path (which, as far as I can tell, is what we're
talking about here) would implement hasattr and raising AttributeError
in a consistent way.
It's slightly different. Although I used len() as an example, the idea is to
allow any function to be used in this way, including local symbols.
e.g. I could define:
def squared(x):
return x * x
i = 3
i.squared() = 9
j = AClassThatImplements__mul__()
j.squared() = whatever j * j returns
but also:
class AnotherClass:
def __mul__(self, other):
...
def squared(self):
return specialised_method_for_calculating_squares()
k = AnotherClass()
k.squared() = calls method, not function
In this case, there is a problem with letting hasattr('squared') return True
for these first two instances. See Ian's post for a description of the problem.
--
https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Sunday 08 June 2014 10:51:24 Roy Smith did opine And Gene did reply: In article 5393dd6a$0$29988$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 07 Jun 2014 20:09:37 -0400, Roy Smith wrote: We've also got machines that are so fast, it's not longer critical that we squeeze out every last iota of performance. Oh, but wait, now we're trying to do absurd things like play full-motion video games on phones, where efficiency equates to battery life. Sigh. That's where there needs to be a concerted push to develop more efficient CPUs and memory, in the engineering sense of efficiency (i.e. better power consumption, not speed). In desktop and server class machines, increasing speed has generated more and more waste heat, to the point where Google likes to build its server farms next to rivers to reduce their air conditioning costs. You can't afford to do that on a battery. Even for desktops and servers, I'd prefer to give up, say, 80% of future speed gains for a 50% reduction in my electricity bill. For desktops, I'm more concerned about physical size. On my desk at work, I have a Mac Mini. It's about 8 inches square, by an inch and a half high. It sits in a corner of my desk and doesn't take up much room. The guy that sits next to me has a Dell running Linux. It's about 8 inches wide, 15 inches deep, and 24 inches high. In terms of CPU, memory, disk, video, networking, etc, they have virtually identical specs. I've never compared the power consumption, but I assume his eats many time the electricity mine does (not to mention makes more noise). You may want to reconsider that statement after the first fan failure in your mini. We've had quite a few Mac's in the tv station, as video servers, graphics composers, etc. The airflow for cooling in them is controlled by baffles to get the maximum air flow past the hot spots, but a fan failure usually cooks the whole thing. And at that time, Macs warranty did not cover collateral damage from a fan failure. Cooked cpu? Too bad, so sad. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Paul Sokolovsky pmis...@gmail.com: Python already has that - like, len(x) calls x.__len__() if it's defined In fact, what's the point of having the duality? len(x) == x.__len__() x y == x.__lt__(y) str(x) == x.__str__() etc. I suppose the principal reason is that people don't like UFCS. Plus some legacy from Python1 days. Lisp co. rigorously follow its UFCS. I think it works great, but that is what people most ridicule Lisp for. What do you think? Would you rather write/read: if size + len(data) = limit: or UFCS-ly: if size.__add__(data.__len__()).__le__(limit): Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
In article mailman.10878.1402242019.18130.python-l...@python.org, Gene Heskett ghesk...@wdtv.com wrote: You may want to reconsider that statement after the first fan failure in your mini. We've had quite a few Mac's in the tv station, as video servers, graphics composers, etc. The airflow for cooling in them is controlled by baffles to get the maximum air flow past the hot spots, but a fan failure usually cooks the whole thing. And at that time, Macs warranty did not cover collateral damage from a fan failure. Cooked cpu? Too bad, so sad. The CPU (or maybe I'm thinking of the video card?) in the Dell has some huge heat sink, a bunch of funky ductwork, and a dedicated fan. I suspect if that fan were to fail, the chip it's cooling would fry itself pretty quickly too. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sunday, 8 June 2014 13:06:08 UTC+1, Paul Sokolovsky wrote: Getting x.foo() to call foo(x) is what's bigger problem, which has serious performance and scoping confusion implications, as discussed in other mails. The performance hit will only occur when the attribute access is about to throw an AttributeError. Successful attribute accesses would be just as fast as before. And the cost of a symbol lookup is usually considered cheap compared to a thrown exception, so I don't believe there is a serious performance implication. As to the scoping confusion, I repeat that Python benefits from the fact that most modules will only have the builtins and local functions to worry about. This is a small enough space for users to manage. There's no surprises waiting to occur when the user adds or removes normal imports (a problem that can occur in D). It also adds significant readability improvements by putting function-call chains in order. Not sure what exactly you mean, but the order is usually pretty obvious - Python follows mathematical notation for function calls, and OO standard notation for method calls, one known from primary school, another from secondary (hopefully). They can be reordered with parentheses, which is also well-known basic math technique. A contrived example - which of these is easier to understand? from base64 import b64encode # works now print(b64encode(str(min(map(int, f.readlines()), key=lambda n: n % 10)), b'?-')) # would work with UFCS f.readlines().map(int).min(key=lambda n: n % 10).str().b64encode(b'?-').print() You can read the second form left to right, and arguments like b64encode's b'?-' are near the function call, making it a lot more obvious with which function this obscure argument is used. Note, I'm not suggesting either of these examples is good programming, but the same problem does occur in more reasonable scenarios - I just made this example a little extreme to emphasise the readability benefits. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sunday, 8 June 2014 17:24:56 UTC+1, jongiddy wrote: # would work with UFCS f.readlines().map(int).min(key=lambda n: n % 10).str().b64encode(b'?-').print() Ooops - map is the wrong way round to support UFCS in this case. However, with UFCS, I could fix this by changing it to smap, and defining: def smap(seq, func): return map(func, seq) -- https://mail.python.org/mailman/listinfo/python-list
Python Team(...)
Hi ... Here I'm seeking for my team of developers/programmers in Python ... I'd like to ask you to provide me contacts of people interested ... I'm sending you one script attachment(...) ... I'll manage them naturally knowing that the detail is wide ... programming languages, Databases, Shell Script, Linux, etc ... and the complexity is present ... main sections, sub sections, client apis, etc ... (...) If this was poetry (...) Big Data, web services, cache's management with perfection and remote subtlety, Hashed Systems, Client Apis, Web Analytics, Complex Logs, Management(Manipulation) of the search string, etc ... you'd be one poet(...) A poet's work can be literal, meaning that his work is derived from a specific event, or metaphorical, meaning that his work can take on many meanings and forms. Poets have existed since antiquity, in nearly all languages, and have produced works that vary greatly in different cultures and time periods. *Final customer/consumer/client(...)* Projects technically different I'd write even in the particularity but naturally similar in the concept of how the information should be organized towards the concept of client api ,etc ... identification of (including the user) in different contexts ... ecommerce ,etc ... with focus in the proximity when available ... *Registered Clients/Bookings/Vouchers of Discount/etc (...)* Each client api(...) has the possibility of managing the bookings/vouchers of discount I'd write ... even each registered client is allowed to use the vouchers of discount taking in consideration the limits(technical, localization/geographics,etc) or no limits of it's(voucher of discount) usage ... And here appears the concept of white-label I'd write ... and this will allow to track efficiently and towards analytical methods all the business models derived from each client api defined ... The concept is wide, the examples are countless ... even the possibilities ... but the technical complexity remains ... we'll try to make it simple ... *Segmented Replication Networks - SRN (...)* The SRN(Segmented Replication Network) ... basically are trustable machines that are placed in the client(cloud environment,etc) ... that will allow to update the masters networks(...) ... and to trigger the execution(exponentially) of processes (through the SRN) of all the necessary updates of the particularity of management of the circumstances ... This might look complicated or somehow difficult to understand, etc ... well ... it's my summarized explanation ... *Management(manipulation) of the search string(...)* Basically it's the solution that provides the best answer taking in consideration what people/enterprises are seeking (...) ... integrated in the concept of client api(...) ... with one scope/range of multi-device ... etc ... Assuming that each client api has the possibility to choose what fits better in it's business(...) and the final costumer/consumer has always the final decision taking in consideration the available possibilities ... Trying to summarize(...) *Setting the focus(...)* We'll set our focus in the 'Personalized Location with(/)in Mobility' ... integration in all the maps worldwide ... and the problematic/management of 'circumstances' with perfection(...) ... etc ... example: someone driving by car,etc looking for one restaurant with one specific meal (filters) ...chooses the destination ... arrives and the restaurant is closed, from this pont users should not be sent until the restaurant is open ... 'circumstances' ... and the circumstances for us are wide, integrated in the concept of client api,etc ... and this technically is not easy I'd write ... My english is not perfect (...) ... but I guess that you've capabilities to understand(...) *I'm finishing with(...)* Example: We start one process of analyze over Big Data ,etc to conclude about something, I'm seeking the conclusion, not the the predictable ... it's like knowing the number of bookings with vouchers of discount(per period(s)) and seek the conclusion with filters to decide after about how to expand it better, priorities of, optimize it ... business analytics,model of decision, etc and we achieve it or not and it's not easy and sometimes depends of technical linkage, analyze of information(individual,group), etc. (...) Looking at social like we will(...) our universe of social is wide and it's definition particular and from this way/interpretation we'll develop the technical component that will allow this approach - the word 'wide' represents all the social networks that exist and 'it's definition particular' means the user defined in one social network, etc - ... Ecommerce are all the ecommerce websites and the user defined in one website of ecommerce with one voucher of discount for example ... *I finished(...)* I did not mention: - Membership (let's say that the complexity of is what makes it interesting)
Re: Uniform Function Call Syntax (UFCS)
On Sun, Jun 8, 2014 at 9:56 AM, Marko Rauhamaa ma...@pacujo.net wrote: Paul Sokolovsky pmis...@gmail.com: Python already has that - like, len(x) calls x.__len__() if it's defined In fact, what's the point of having the duality? len(x) == x.__len__() x y == x.__lt__(y) str(x) == x.__str__() Python prefers having functions for operations that are common to a lot of types rather than methods. This allows for consistency of interface -- think of len() as the interface and .__len__() as the implementation. If .len() were the interface then it would be easy (and probably all too common) for Python programmers to change those interfaces in subclasses. It also means that if you want to pass the len function itself around, you just pass around len and know that it will work generally -- instead of passing around list.len and hoping that whatever it gets applied to is a list. This is a fair point against UFCS -- if x.len() comes to mean len(x) then it both makes it easy to change that interface (at least for the x.len() spelling) and makes it easier to pass around the function's implementation rather than its interface. What do you think? Would you rather write/read: if size + len(data) = limit: or UFCS-ly: if size.__add__(data.__len__()).__le__(limit): You may be misunderstanding the proposal. The UFCS style of that would be: if size + data.len() = limit: -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Hello, On Sun, 08 Jun 2014 18:56:47 +0300 Marko Rauhamaa ma...@pacujo.net wrote: Paul Sokolovsky pmis...@gmail.com: Python already has that - like, len(x) calls x.__len__() if it's defined In fact, what's the point of having the duality? len(x) == x.__len__() x y == x.__lt__(y) str(x) == x.__str__() etc. I suppose the principal reason is that people don't like UFCS. Plus some legacy from Python1 days. I personally don't see it as duality. There're few generic operators - the fact that they are really generic (apply to wide different classes of objects) is exactly the reason why the're defined in global namespace, and not methods. And yep, I see things like len as essentially an operator, even though its name consists of letters, and it has function call syntax. Then, there's just a way to overload these operators for user types, that's it. You *can* use x.__len__() but that's not how Python intends it. And like with any idea, one should not forget implementation side and efficiency - these operators are really core and expected to be used in performance-tight contexts, so they are implemented specially (optimized). Extending that handling to any function would cost either high memory usage, or high runtime cost. Lisp co. rigorously follow its UFCS. I think it works great, but that is what people most ridicule Lisp for. Exactly my thinking - there're bunch of languages which follow that UFCS-like idea, likely most homoiconic (or -like) do. Or you can use plain old C ;-). So, I don't see why people want to stuff this into Python - there're lot of ready alternatives. And Python provides very intuitive and obvious separation between generic functions and object methods IMHO, so there's nothing to fix. What do you think? Would you rather write/read: if size + len(data) = limit: How else could it be? or UFCS-ly: if size.__add__(data.__len__()).__le__(limit): OMG! Marko -- https://mail.python.org/mailman/listinfo/python-list -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Mon, Jun 9, 2014 at 1:39 AM, jongiddy jongi...@gmail.com wrote:
e.g. I could define:
def squared(x):
return x * x
i = 3
i.squared() = 9
j = AClassThatImplements__mul__()
j.squared() = whatever j * j returns
but also:
class AnotherClass:
def __mul__(self, other):
...
def squared(self):
return specialised_method_for_calculating_squares()
k = AnotherClass()
k.squared() = calls method, not function
In this case, there is a problem with letting hasattr('squared') return True
for these first two instances. See Ian's post for a description of the
problem.
class Circle:
def squared(self):
raise NotImplementedError(Proven impossible in 1882)
The trouble is that logically Circle does have a 'squared' attribute,
while 3 doesn't; and yet Python guarantees this:
foo.squared()
# is equivalent [1] to
func = foo.squared
func()
Which means that for (3).squared() to be 9, it has to be possible to
evaluate (3).squared, which means that hasattr (which is defined by
attempting to get the attribute and seeing if an exception is thrown)
has to return True.
Except that it's even more complicated than that, because hasattr
wasn't defined in your module, so it has a different set of globals.
In fact, this would mean that hasattr would become quite useless.
(Hmm, PEP 463 might become a prerequisite of your proposal...) It also
means that attribute lookup becomes extremely surprising any time the
globals change; currently, x.y means exactly the same thing for any
given object x and attribute y, no matter where you do it.
The only way I can think of for all this to make sense is actually
doing it the other way around. Instead of having x.y() fall back on
y(x), have y(x) attempt x.y() first. To pull this off, you'd need a
special bouncer around every global or builtin... which may be tricky.
class MagicDict(dict):
def __getitem__(self, item):
# If this throws, let the exception propagate
obj = super().__getitem__(item)
if not callable(obj): return obj
def bouncer(*a, **kw):
if len(a)==1 and not kw:
try: return getattr(a[0], item)()
except AttributeError: pass
return obj(*a, **kw)
return bouncer
import __main__
# Except that this bit doesn't work.
__main__.__dict__ = MagicDict(__main__.__dict__)
It's theoretically possible, along these lines, I think. Whether it's
actually any good or not is another question, though!
ChrisA
[1] Modulo performance. CPython, AFAIK, does this exactly as written,
but other Pythons may and do optimize the actual foo.squared() form
to reduce heap usage. But in terms of visible effects, equivalent.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sun, Jun 8, 2014 at 10:24 AM, jongiddy jongi...@gmail.com wrote: A contrived example - which of these is easier to understand? from base64 import b64encode # works now print(b64encode(str(min(map(int, f.readlines()), key=lambda n: n % 10)), b'?-')) # would work with UFCS f.readlines().map(int).min(key=lambda n: n % 10).str().b64encode(b'?-').print() I prefer not making it a one-liner: data = map(int, f.readlines()) min_data = min(data, key=lambda n: n % 10) print(b64encode(str(smallest_data), b'?-')) Python's standard of having in-place methods return None also forces this to an extent. Whenever you want to tack on something like .append(), that's the end of your chain and it's time to start a new line anyway. Of course, you could always define something like: def appended(iterable, x): result = list(iterable) result.append(x) return result and use that in your chain. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sun, Jun 8, 2014 at 2:15 AM, jongiddy jongi...@gmail.com wrote: One problem with your untested code, the superclasses would need to be checked before using UFCS, so the structure is: try: return super().__getattr__(attr) except AttributeError: # resolve using UFCS And then if UFCS finds nothing, make sure the AttributeError gets reraised. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sun, Jun 8, 2014 at 10:48 AM, Chris Angelico ros...@gmail.com wrote: Except that it's even more complicated than that, because hasattr wasn't defined in your module, so it has a different set of globals. In fact, this would mean that hasattr would become quite useless. hasattr is a builtin, so it has no globals at all. It would have to use the calling scope for UFCS resolution as in my example implementation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Mon, Jun 9, 2014 at 2:24 AM, jongiddy jongi...@gmail.com wrote: A contrived example - which of these is easier to understand? from base64 import b64encode # works now print(b64encode(str(min(map(int, f.readlines()), key=lambda n: n % 10)), b'?-')) # would work with UFCS f.readlines().map(int).min(key=lambda n: n % 10).str().b64encode(b'?-').print() You can read the second form left to right Actually, this is something that I've run into sometimes. I can't think of any Python examples, partly because Python tends to avoid unnecessary method chaining, but the notion of data flow is a very clean one - look at shell piping, for instance. Only slightly contrived example: cat foo*.txt | gzip | ssh other_server 'gunzip | foo_analyze' The data flows from left to right, even though part of the data flow is on a different computer. A programming example might come from Pike's image library [1]. This definitely isn't what you'd normally call good code, but sometimes I'm working at the interactive prompt and I do something as a one-liner. It might look like this: Stdio.write_file(foo.png,Image.PNG.encode(Image.JPEG.decode(Stdio.read_file(foo.jpg)).autocrop().rotate(0.5).grey())); With UFCS, that could become perfect data flow: read_file(foo.jpg).JPEG_decode().autocrop().rotate(0.5).grey().PNG_encode().write_file(foo.png); I had to solve the syntactic ambiguity here by importing all the appropriate names, which does damage readability a bit. But you should be able to figure out what this is doing, with only minimal glancing at the docs (eg to find out that rotate(0.5) is rotating by half a degree). So the proposal does have some merit, in terms of final syntactic readability gain. The problem is the internal ambiguity along the way. ChrisA [1] http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Image/Image.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Mon, Jun 9, 2014 at 3:08 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Jun 8, 2014 at 10:48 AM, Chris Angelico ros...@gmail.com wrote: Except that it's even more complicated than that, because hasattr wasn't defined in your module, so it has a different set of globals. In fact, this would mean that hasattr would become quite useless. hasattr is a builtin, so it has no globals at all. It would have to use the calling scope for UFCS resolution as in my example implementation. Same difference. It can't simply look for the name in globals(), it has to figure out based on the caller's globals. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Sunday 08 June 2014 12:09:41 Roy Smith did opine And Gene did reply: In article mailman.10878.1402242019.18130.python-l...@python.org, Gene Heskett ghesk...@wdtv.com wrote: You may want to reconsider that statement after the first fan failure in your mini. We've had quite a few Mac's in the tv station, as video servers, graphics composers, etc. The airflow for cooling in them is controlled by baffles to get the maximum air flow past the hot spots, but a fan failure usually cooks the whole thing. And at that time, Macs warranty did not cover collateral damage from a fan failure. Cooked cpu? Too bad, so sad. The CPU (or maybe I'm thinking of the video card?) in the Dell has some huge heat sink, a bunch of funky ductwork, and a dedicated fan. I suspect if that fan were to fail, the chip it's cooling would fry itself pretty quickly too. Probably. I have lost several nvidia video cards over the years from fan failures. My phenom in this box has a 75C shutdown that has not been tested. Best fan sink assembly I could buy at the time. And I have gotten into the habit of replacing the 45 cent fans on the video card with bigger, ball bearing fans at the first hint of a squall. A lot of this stuff has more engineering time in assuring it will die 2 weeks out of warranty, than in giving top performance. And that goes double for stuff wearing an Antec label. I'm on the 4th psu in this box, its a $12.65 in 10 packs 350 watter, Chinese of course, running 4 terrabyte drives and a USB tree that looks like a weeping willow plus the original 2.1Mhz Phenom. 165 watts IIRC. I run gkrellm and watch its voltages. Now about 3 years old, the 5 volt line is still 5.08 volts. Whats not to like? The 2 Antecs I was dumb enough to try, had 5 volt lines down to 4.75 volts and doing random resets at the end of the 1 year warranty. Thats not an excusable failure in my book. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Mon, Jun 9, 2014 at 3:14 AM, Gene Heskett ghesk...@wdtv.com wrote: I have lost several nvidia video cards over the years from fan failures. From a discussion on one of Threshold RPG's out-of-character channels: Kurdt: I wouldn't disturb the fan controller. Kurdt: Ever seen an AMD without a fan? ;) Leshrak: heh, yeah Leshrak: actually. it's not a pretty smell Kurdt: Especially when it's overclocked. It goes FT in under two seconds. I think that's about right. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sun, Jun 8, 2014 at 11:13 AM, Chris Angelico ros...@gmail.com wrote: On Mon, Jun 9, 2014 at 3:08 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Jun 8, 2014 at 10:48 AM, Chris Angelico ros...@gmail.com wrote: Except that it's even more complicated than that, because hasattr wasn't defined in your module, so it has a different set of globals. In fact, this would mean that hasattr would become quite useless. hasattr is a builtin, so it has no globals at all. It would have to use the calling scope for UFCS resolution as in my example implementation. Same difference. It can't simply look for the name in globals(), it has to figure out based on the caller's globals. But that would all be done in getattr, so I don't think it affects hasattr's implementation at all. Since hasattr doesn't push anything onto the stack, getattr doesn't have to care whether it was called directly from Python or indirectly via getattr; either way the scope it needs is just the top frame of the stack. Could be a different matter in other implementations, though. -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On 8 June 2014 08:12, Marko Rauhamaa ma...@pacujo.net wrote: Does anyone have an example motivating a return from finally? It seems to me it would always be a bad idea as it silently clears all unexpected exceptions. In a general sense: try: something_that_can_break() return foo() # before clean_up finally: clean_up() if default: return default() # after clean_up() What's the best replacement? Note: I've never done this. --- I do sometimes use try: return x finally: x += 1 over ret = x x += 1 return ret now-a-days. -- https://mail.python.org/mailman/listinfo/python-list
Re: os.startfile hanging onto the launched app, or my IDE?
On Fri, Jun 6, 2014 at 2:34 PM, Josh English joshua.r.engl...@gmail.com wrote: I have been using os.startfile(filepath) to launch files I've created in Python, mostly Excel spreadsheets, text files, or PDFs. When I run my script from my IDE, the file opens as I expect. But if I go back to my script and re-run it, the external program (either Excel, Notepad, or Acrobat Reader) closes all windows and restarts the program. This can, unfortunately, close other files I am working on and thus I lose all my changes to those files. This is happening on Windows 7. I am not sure if it is Python (2.7.5) or my IDE (PyScripter 2.5.3). It seems like Python or the IDE is keeping track of things created by the os.startfile call, but the docs imply this doesn't happen. Is this a quirk of os.startfile? Is there a cleaner way to get Windows to open files without tying back to my program? That sounds unusual. Do you see the same behavior with the shell start command? My first guess would be that this is due to some registry setting rather than Python, which pretty much just calls ShellExcecute. -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On 6 June 2014 18:39, Roy Smith r...@panix.com wrote: The only way I can think of to bypass a finally block would be to call os._exit(), or send yourself a kill signal. If you're willing to use implementation details... --- # BreakN.py import sys # Turn tracing on if it is off if sys.gettrace() is None: sys.settrace(lambda frame, event, arg: None) def break_n(n): frame = sys._getframe().f_back for _ in range(n): frame.f_trace = skip_function_tracer frame = frame.f_back def skip_function_tracer(frame, event, arg): try: # Skip this line while True: frame.f_lineno += 1 except ValueError as e: # Finished tracing function; remove trace pass --- # Thing_you_run.py from BreakN import break_n def foo(): try: print(I am not skipped) break_n(1) print(I am skipped) ... finally: print(I am skipped) ... foo() # I am not skipped -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On Sun, Jun 8, 2014 at 12:02 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Jun 8, 2014 at 11:57 AM, Joshua Landau jos...@landau.ws wrote: On 8 June 2014 08:12, Marko Rauhamaa ma...@pacujo.net wrote: Does anyone have an example motivating a return from finally? It seems to me it would always be a bad idea as it silently clears all unexpected exceptions. In a general sense: try: something_that_can_break() return foo() # before clean_up finally: clean_up() if default: return default() # after clean_up() What's the best replacement? Note: I've never done this. Why not just move the default out of the finally block? try: something_that_can_break() return foo() # before clean_up finally: clean_up() if default: return default() # after clean_up() Never mind, that doesn't work. But you could do this: try: something_that_can_break() return foo() # before clean_up except ExpectedException: if default: return default() # after clean_up() else: raise finally: clean_up() And then anything unexpected will be propagated instead of silenced. -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On Sun, Jun 8, 2014 at 11:57 AM, Joshua Landau jos...@landau.ws wrote: On 8 June 2014 08:12, Marko Rauhamaa ma...@pacujo.net wrote: Does anyone have an example motivating a return from finally? It seems to me it would always be a bad idea as it silently clears all unexpected exceptions. In a general sense: try: something_that_can_break() return foo() # before clean_up finally: clean_up() if default: return default() # after clean_up() What's the best replacement? Note: I've never done this. Why not just move the default out of the finally block? try: something_that_can_break() return foo() # before clean_up finally: clean_up() if default: return default() # after clean_up() -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Chris Angelico ros...@gmail.com wrote: Kurdt: I wouldn't disturb the fan controller. Kurdt: Ever seen an AMD without a fan? ;) Leshrak: heh, yeah Leshrak: actually. it's not a pretty smell Kurdt: Especially when it's overclocked. It goes FT in under two seconds. I think that's about right. One would think that in 2014, a device called a thermostat would shut down the power before expensive equipent goes up in a ball of smoke. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorating one method of a class C with another method of class C?
On 6/6/14, Ben Finney b...@benfinney.id.au wrote: Dan Stromberg drsali...@gmail.com writes: Is there a way of decorating method1 of class C using method2 of class C? Can you give a concrete example (i.e. not merely hypothetical) where this would be a useful feature (i.e. an actual improvement over the absence of the feature), and why? I have a class that's operating on a socket. I'd like to have simple operations on that socket like list configured hosts, allow connection to host, etc. And I'd like them to be decorated with reconnected_to_server_if_needed. I'll probably end up putting a try/except in each simple operation, making them a bit less simple. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Mon, Jun 9, 2014 at 4:09 AM, Sturla Molden sturla.mol...@gmail.com wrote: Chris Angelico ros...@gmail.com wrote: Kurdt: I wouldn't disturb the fan controller. Kurdt: Ever seen an AMD without a fan? ;) Leshrak: heh, yeah Leshrak: actually. it's not a pretty smell Kurdt: Especially when it's overclocked. It goes FT in under two seconds. I think that's about right. One would think that in 2014, a device called a thermostat would shut down the power before expensive equipent goes up in a ball of smoke. That exchange actually happened back in 2005 (wow! ages ago now), but same difference. However, I think there are very few thermostats that can cut the power quickly enough for an overclocked chip that loses its heat sink. MAYBE if the heat sink is still on and the fan isn't, but not if the hs falls off. Under two seconds might become the blink of an eye. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorating one method of a class C with another method of class C?
On Mon, Jun 9, 2014 at 4:04 AM, Dan Stromberg drsali...@gmail.com wrote: I have a class that's operating on a socket. I'd like to have simple operations on that socket like list configured hosts, allow connection to host, etc. And I'd like them to be decorated with reconnected_to_server_if_needed. I'll probably end up putting a try/except in each simple operation, making them a bit less simple. Can you have the decorator outside the class, calling a regular method to do its main work? def recon_if_needed(f): def inner(self, *a, **kw): if self.disconnected: self.connect() return f(self, *a, **kw) return inner class SocketWorker: @recon_if_needed def send_packet(self, packet): assert not self.disconnected ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 06/08/2014 06:14 PM, Gene Heskett wrote: On Sunday 08 June 2014 12:09:41 Roy Smith did opine And Gene did reply: In article mailman.10878.1402242019.18130.python-l...@python.org, Gene Heskett ghesk...@wdtv.com wrote: You may want to reconsider that statement after the first fan failure in your mini. We've had quite a few Mac's in the tv station, as video servers, graphics composers, etc. The airflow for cooling in them is controlled by baffles to get the maximum air flow past the hot spots, but a fan failure usually cooks the whole thing. And at that time, Macs warranty did not cover collateral damage from a fan failure. Cooked cpu? Too bad, so sad. The CPU (or maybe I'm thinking of the video card?) in the Dell has some huge heat sink, a bunch of funky ductwork, and a dedicated fan. I suspect if that fan were to fail, the chip it's cooling would fry itself pretty quickly too. Probably. I have lost several nvidia video cards over the years from fan failures. My phenom in this box has a 75C shutdown that has not been tested. Best fan sink assembly I could buy at the time. And I have gotten into the habit of replacing the 45 cent fans on the video card with bigger, ball bearing fans at the first hint of a squall. A lot of this stuff has more engineering time in assuring it will die 2 weeks out of warranty, than in giving top performance. And that goes double for stuff wearing an Antec label. I'm on the 4th psu in this box, its a $12.65 in 10 packs 350 watter, Chinese of course, running 4 terrabyte drives and a USB tree that looks like a weeping willow plus the original 2.1Mhz Phenom. 165 watts IIRC. I run gkrellm and watch its voltages. Now about 3 years old, the 5 volt line is still 5.08 volts. Whats not to like? The 2 Antecs I was dumb enough to try, had 5 volt lines down to 4.75 volts and doing random resets at the end of the 1 year warranty. Thats not an excusable failure in my book. Cheers, Gene Heskett Reading this reminds me the hypothetical dilemma of (...) If one solution based in n dependencies(client apis) would need to optimize it's system(in dependencies too) to face the massive hits of search engines in the indexation of n millions of pages with tracking integrated at several levels(...) ... how would it be solved? ... It would turn at n volts(...) and it would need to decrease the voltage(...) This is somehow integrated in what I wrote in the post with the subject 'python team(...)' To put this working and optimized is really fascinating (...) Regards, Carlos -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sunday, 8 June 2014 18:24:28 UTC+1, Ian wrote: But that would all be done in getattr, so I don't think it affects hasattr's implementation at all. Since hasattr doesn't push anything onto the stack, getattr doesn't have to care whether it was called directly from Python or indirectly via getattr; either way the scope it needs is just the top frame of the stack. Could be a different matter in other implementations, though. In CPython, the UFCS would not be done in PyObject_GetAttr() as that would affect hasattr() as well. Instead, it would be implemented in the bytecode for LOAD_ATTR. If LOAD_ATTR was about to return an AttributeError, e.g. for [].len, it would perform the equivalent of a LOAD_NAME operation, with the difference that if the name is not found or is not callable, it returns AttributeError instead of NameError. If the name is found, then it would return something: for [].len, it would return the len() function wrapped to know that it's first argument was the list, which might be done by creating a fake Method object, as shown in Ian's code. But getattr([], 'len') and hasattr([], 'len') would both return False. I'm beginning to think it is too un-Pythonic - too much implicitness, unless it can be spelt differently, something like [].len(_) or [].len(...) to explicitly indicate that it plans to call a function, but might call a method if one is available. -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorating one method of a class C with another method of class C?
Dan Stromberg drsali...@gmail.com writes: I'd like to have simple operations on that socket like list configured hosts, allow connection to host, etc. And I'd like them to be decorated with reconnected_to_server_if_needed. The ‘reconnected_to_server_if_needed’ method, if I understand your original post correctly, does not need the class nor the class instance. So you can define that function outside the class, and use it for decorating methods within the class. -- \ “Teach a man to make fire, and he will be warm for a day. Set a | `\ man on fire, and he will be warm for the rest of his life.” | _o__) —John A. Hrastar | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Chris Angelico ros...@gmail.com wrote: Kurdt: I wouldn't disturb the fan controller. Kurdt: Ever seen an AMD without a fan? ;) Leshrak: heh, yeah Leshrak: actually. it's not a pretty smell Kurdt: Especially when it's overclocked. It goes FT in under two seconds. I think that's about right. One would think that in 2014, a device called a thermostat would shut down the power before expensive equipent goes up in a ball of smoke. That exchange actually happened back in 2005 (wow! ages ago now), but same difference. However, I think there are very few thermostats that can cut the power quickly enough for an overclocked chip that loses its heat sink. MAYBE if the heat sink is still on and the fan isn't, but not if the hs falls off. Under two seconds might become the blink of an eye. If the heat sinks falls off, yes, that is really bad news... But if the fan fails the warm up shouldn't be that rapid. I thought we were taking about fan failure, not detached heat sink. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Mon, 09 Jun 2014 04:16:24 +1000, Chris Angelico wrote: On Mon, Jun 9, 2014 at 4:09 AM, Sturla Molden sturla.mol...@gmail.com wrote: Chris Angelico ros...@gmail.com wrote: Kurdt: I wouldn't disturb the fan controller. Kurdt: Ever seen an AMD without a fan? ;) Leshrak: heh, yeah Leshrak: actually. it's not a pretty smell Kurdt: Especially when it's overclocked. It goes FT in under two seconds. I think that's about right. One would think that in 2014, a device called a thermostat would shut down the power before expensive equipent goes up in a ball of smoke. That exchange actually happened back in 2005 (wow! ages ago now), but same difference. However, I think there are very few thermostats that can cut the power quickly enough for an overclocked chip that loses its heat sink. MAYBE if the heat sink is still on and the fan isn't, but not if the hs falls off. Under two seconds might become the blink of an eye. The fact that CPUs need anything more than a passive heat sink is *exactly* the problem. A car engine has to move anything up to a tonne of steel around at 100kph or more, and depending on the design, they can get away with air-cooling. In comparison, a CPU just moves around a trickle of electric current. (No currently designed car with an internal combustion engine uses air- cooling. The last mass market car that used it, the Citroën GS, ceased production in 1986. The Porsche 911 ceased production in 1998, making it, I think, the last air-cooled vehicle apart from custom machines. With the rise of all-electric vehicles, perhaps we will see a return to air- cooling?) CPU technology is the triumph of brute force over finesse. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Monday, June 9, 2014 7:14:24 AM UTC+5:30, Steven D'Aprano wrote: On Mon, 09 Jun 2014 04:16:24 +1000, Chris Angelico wrote: wrote: Chris Angelico wrote: Kurdt: I wouldn't disturb the fan controller. Kurdt: Ever seen an AMD without a fan? ;) Leshrak: heh, yeah Leshrak: actually. it's not a pretty smell Kurdt: Especially when it's overclocked. It goes FT in under two seconds. I think that's about right. One would think that in 2014, a device called a thermostat would shut down the power before expensive equipent goes up in a ball of smoke. That exchange actually happened back in 2005 (wow! ages ago now), but same difference. However, I think there are very few thermostats that can cut the power quickly enough for an overclocked chip that loses its heat sink. MAYBE if the heat sink is still on and the fan isn't, but not if the hs falls off. Under two seconds might become the blink of an eye. The fact that CPUs need anything more than a passive heat sink is *exactly* the problem. A car engine has to move anything up to a tonne of steel around at 100kph or more, and depending on the design, they can get away with air-cooling. In comparison, a CPU just moves around a trickle of electric current. Trickle? Ok... only its multiplied by a billion: http://en.wikipedia.org/wiki/Transistor_count (No currently designed car with an internal combustion engine uses air- cooling. The last mass market car that used it, the Citroën GS, ceased production in 1986. The Porsche 911 ceased production in 1998, making it, I think, the last air-cooled vehicle apart from custom machines. With the rise of all-electric vehicles, perhaps we will see a return to air- cooling?) CPU technology is the triumph of brute force over finesse. If you are arguing that computers should not use millions/billions of transistors, I wont argue, since I dont know the technology. Only pointing out that billion is a large number in pragmatic terms - So is million for that matter - Actually not so sure even on that count [Never counted beyond hundred!] -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Monday, June 9, 2014 5:04:05 AM UTC+5:30, Sturla Molden wrote: Chris Angelico wrote: Kurdt: I wouldn't disturb the fan controller. Kurdt: Ever seen an AMD without a fan? ;) Leshrak: heh, yeah Leshrak: actually. it's not a pretty smell Kurdt: Especially when it's overclocked. It goes FT in under two seconds. I think that's about right. One would think that in 2014, a device called a thermostat would shut down the power before expensive equipent goes up in a ball of smoke. That exchange actually happened back in 2005 (wow! ages ago now), but same difference. However, I think there are very few thermostats that can cut the power quickly enough for an overclocked chip that loses its heat sink. MAYBE if the heat sink is still on and the fan isn't, but not if the hs falls off. Under two seconds might become the blink of an eye. If the heat sinks falls off, yes, that is really bad news... But if the fan fails the warm up shouldn't be that rapid. I thought we were taking about fan failure, not detached heat sink. Dont know about 'fall off' However one day I tried to 'clean' my 'dirty' computer - which included removing the CPU fan, dusting it and fitting it back - didnt know about thermal paste Machine shut down in a minute (if I remember right) with a message about overheating When the (new!) thermal paste was applied it started again I vaguely remember that the bios remembered the untoward event and some resetting was required though dont remember what -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Monday, June 9, 2014 7:14:24 AM UTC+5:30, Steven D'Aprano wrote: On Mon, 09 Jun 2014 04:16:24 +1000, Chris Angelico wrote: wrote: The fact that CPUs need anything more than a passive heat sink is *exactly* the problem. A car engine has to move anything up to a tonne of steel around at 100kph or more, and depending on the design, they can get away with air-cooling. In comparison, a CPU just moves around a trickle of electric current. (No currently designed car with an internal combustion engine uses air- cooling. The last mass market car that used it, the Citroën GS, ceased production in 1986. The Porsche 911 ceased production in 1998, making it, I think, the last air-cooled vehicle apart from custom machines. With the rise of all-electric vehicles, perhaps we will see a return to air- cooling?) CPU technology is the triumph of brute force over finesse. BTW people are going this way: http://www.silentpcreview.com/ http://www.endpcnoise.com/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Mon, 09 Jun 2014 03:10:03 +1000, Chris Angelico wrote: [...] Actually, this is something that I've run into sometimes. I can't think of any Python examples, partly because Python tends to avoid unnecessary method chaining, but the notion of data flow is a very clean one - look at shell piping, for instance. Only slightly contrived example: cat foo*.txt | gzip | ssh other_server 'gunzip | foo_analyze' The data flows from left to right, even though part of the data flow is on a different computer. A programming example might come from Pike's image library [...] Stdio.write_file(foo.png,Image.PNG.encode(Image.JPEG.decode( Stdio.read_file(foo.jpg)).autocrop().rotate(0.5).grey())); With UFCS, that could become perfect data flow: read_file(foo.jpg).JPEG_decode().autocrop().rotate(0.5).grey() .PNG_encode().write_file(foo.png); As far as I am concerned, the biggest problem with chained method calls is that it encourages long one-liners. But I think chained calls are quite natural to read, and rather similar to the postfix notation used by Forth: foo.jpg read_file JPEG_decode autocrop 0.5 rotate grey PNG_encode foo.png write_file Although Forth has a (justified) reputation for being hard to read, postfix notation is not the cause. The above can be understood easily as a chain of function calls: read the file, then decode, then autocrop, then rotate, they grey, then encode, then write the file. You read and write the calls in the same first-to-last order as you would perform them. The equivalent prefix notation used by function calls is unnaturally backwards and painful to read: write_file(PNG_encode(grey(rotate(autocrop(JPEG_decode( read_file(foo.jpg))), 0.5))), foo.png); I had to solve the syntactic ambiguity here by importing all the appropriate names I'm not sure how this is *syntactic* ambiguity. As I see it, the only syntactic ambiguity occurs when you have functions of two arguments. Using shell notation: plus(1, 2) | divide(2) Assuming divide() takes two arguments, does that give 3/2 or 2/3? I would expect that the argument being piped in is assigned to the first argument. But I'm not sure how this sort of design ambiguity is fixed by importing names into the current namespace. (Note that Forth is brilliant here, as it exposes the argument stack and gives you a rich set of stack manipulation commands.) While we're talking about chaining method and function calls, I'll take the opportunity to link to this, in case anyone feels like adapting it to UFCS: http://code.activestate.com/recipes/578770 -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Mon, Jun 9, 2014 at 1:20 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Mon, 09 Jun 2014 03:10:03 +1000, Chris Angelico wrote: [...] Stdio.write_file(foo.png,Image.PNG.encode(Image.JPEG.decode( Stdio.read_file(foo.jpg)).autocrop().rotate(0.5).grey())); With UFCS, that could become perfect data flow: read_file(foo.jpg).JPEG_decode().autocrop().rotate(0.5).grey() .PNG_encode().write_file(foo.png); I had to solve the syntactic ambiguity here by importing all the appropriate names I'm not sure how this is *syntactic* ambiguity. The ambiguity I'm talking about here is with the dot. The original version has Stdio.read_file as the first function called; for a Python equivalent, imagine a string processing pipeline and having re.sub in the middle of it. You can't take re.sub as the name of an attribute on a string without some fiddling around that completely destroys the point of data-flow syntax. So I cheated, and turned everything into local (imported) names (adorning the ones that needed it). This is a bad idea in Pike for the same reason it's a bad idea in Python - you end up with a massively polluted global namespace. This could be solved, though, by having a completely different symbol that means the thing on my left is actually the first positional parameter in the function call on my right, such as in your example: plus(1, 2) | divide(2) This would be absolutely identical to: divide(plus(1, 2), 2) Maybe you could even make it so that: plus(1, 2) x=| divide(y=2) is equivalent to divide(x=plus(1, 2), y=2) for the sake of consistency, and to allow the pipeline to inject something someplace other than the first argument. I'm not sure whether it'd be as useful in practice, though. It would depend partly on the exact syntax used. Obviously the pipe itself can't be used as it already means bitwise or, and this needs to be really REALLY clear about what's going on. But a data-flow notation would be of value in theory, at least. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
In article 53952807$0$29988$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: (Note that Forth is brilliant here, as it exposes the argument stack and gives you a rich set of stack manipulation commands.) As does PostScript (which, despite its reputation as a printer format, is really a full-fledged programming language). I suspect that people who didn't grow up with RPN (i.e. H/P calculators) find it amazingly obtuse. In much the same way I find Objective-C amazingly obtuse. Oh, wait, that's the other thread. -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Mon, 09 Jun 2014 02:48:13 +1000, Chris Angelico wrote: class Circle: def squared(self): raise NotImplementedError(Proven impossible in 1882) The trouble is that logically Circle does have a 'squared' attribute, while 3 doesn't; and yet Python guarantees this: foo.squared() # is equivalent [1] to func = foo.squared func() Which means that for (3).squared() to be 9, it has to be possible to evaluate (3).squared, Given UFCS, that ought to return the global squared function, curried with 3 as its first (and only) argument. UFCS would be a pretty big design change to Python, but I don't think it would be a *problem* as such. It just means that x.y, hasattr(x, y) etc. would mean something different to what they currently mean. which means that hasattr (which is defined by attempting to get the attribute and seeing if an exception is thrown) has to return True. Yes. And this is a problem why? Obviously it would mean that the semantics of hasattr will be different than they are now, but it's still a coherent set of semantics. In fact, one can already give a class a __getattr__ method which provides UFCS functionality. (Hmmm, you need a way to get the caller's globals. You know, this keeps coming up. I think it's high-time Python offered this as a supported function.) That's no more a problem than any other dynamically generated attribute. Stick that __getattr__ in object itself, and UFCS is now language wide. That would make an awesome hack for anyone wanting to experiment with this! Except that it's even more complicated than that, because hasattr wasn't defined in your module, so it has a different set of globals. hasattr doesn't care about globals, nor does it need to. hasattr behaves like the equivalent to: def hasattr(obj, name): try: obj.name except AttributeError: return False return True give or take. And yes, if accessing your attribute has side effects, using hasattr does too: py class Spam(object): ... @property ... def spam(self): ... print(Spam spam spam spam LOVERLY SPM) ... return spam ... py x = Spam() py hasattr(x, spam) Spam spam spam spam LOVERLY SPM True If that's a worry to you, you can try inspect.getattr_static. In fact, this would mean that hasattr would become quite useless. (Hmm, PEP 463 might become a prerequisite of your proposal...) It also means that attribute lookup becomes extremely surprising any time the globals change; currently, x.y means exactly the same thing for any given object x and attribute y, no matter where you do it. *cough* class Example: def __getattr__(self, name): if name == 'module_name': if __name__ == '__main__': return NOBODY expects the Spanish Inquisition! else: return __name__ raise AttributeError(no attribute %r % name) :-) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Sun, 08 Jun 2014 19:24:52 -0700, Rustom Mody wrote: On Monday, June 9, 2014 7:14:24 AM UTC+5:30, Steven D'Aprano wrote: The fact that CPUs need anything more than a passive heat sink is *exactly* the problem. A car engine has to move anything up to a tonne of steel around at 100kph or more, and depending on the design, they can get away with air-cooling. In comparison, a CPU just moves around a trickle of electric current. Trickle? Ok... only its multiplied by a billion: http://en.wikipedia.org/wiki/Transistor_count A typical desktop computer uses less than 500 watts for *everything* except the screen. Hard drives. DVD burner. Keyboard, mouse, USB devices, network card, sound card, graphics card, etc. (Actually, 350W is more typical.) Moore's Law observes that processing power has doubled about every two years. Over the last decade, processing power has increased by a factor of 32. If *efficiency* had increased at the same rate, that 500W power supply in your PC would now be a 15W power supply. Your mobile phone would last a month between recharges, not a day. Your laptop could use a battery half the size and still last two weeks on a full charge. In practice, hard drives are not likely to get more efficient, since you have to spin up a lump of metal. (Solid state drives tend to be either slow and unreliable, or blindingly fast and even more unreliable. Let me know how they are in another ten years.) Network cards etc. are relatively low-power. It's only the CPU and some of the bigger graphics cards that really eat electrons. Moore's Law for power efficiency is probably asking too much, but is it too much to ask that CPUs should double their efficiency every five years? I don't think so. CPU technology is the triumph of brute force over finesse. If you are arguing that computers should not use millions/billions of transistors, I wont argue, since I dont know the technology. No. I'm arguing that they shouldn't convert 90% of their energy input into heat. Only pointing out that billion is a large number in pragmatic terms - So is million for that matter - Actually not so sure even on that count [Never counted beyond hundred!] Not really. A single grain of salt contains billions of billions of atoms. A billion transistors is still a drop in the ocean. Wait until we get the equivalent of an iPhone's processing power in a speck of dust that can float in the air. http://www.technovelgy.com/ct/content.asp?Bnum=245 -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Mon, Jun 9, 2014 at 11:44 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The fact that CPUs need anything more than a passive heat sink is *exactly* the problem. A car engine has to move anything up to a tonne of steel around at 100kph or more, and depending on the design, they can get away with air-cooling. In comparison, a CPU just moves around a trickle of electric current. So, let me get this straight. A CPU has to have a fan, but a car engine doesn't, because the car's moving at a hundred kays an hour. I have a suspicion the CPU fan moves air a bit slower than that. *dives for cover* ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Sun, 08 Jun 2014 18:56:47 +0300, Marko Rauhamaa wrote: Paul Sokolovsky pmis...@gmail.com: Python already has that - like, len(x) calls x.__len__() if it's defined In fact, what's the point of having the duality? len(x) == x.__len__() x y == x.__lt__(y) str(x) == x.__str__() Interface on the left, implementation on the right. That's especially obvious when you consider operators like + - * etc. Consider x + y. What happens? #1 First, Python checks whether y is an instance of a *subclass* of x. If so, y gets priority, otherwise x gets priority. #2 If y gets priority, y.__radd__(x) is called, if it exists. If it returns something other than NotImplemented, we are done. #3 However if y.__radd__ doesn't exist, or it returns NotImplemented, then Python continues as if x had priority. #3 If x has priority, then x.__add__(y) is called, if it exists. If it returns something other than NotImplemented, we are done. #4 However if it doesn't exist, or it returns NotImplemented, then y.__radd__(x) is called, provided it wasn't already tried in step #2. #5 Finally, if neither object has __add__ or __radd__, or both return NotImplemented, then Python raises TypeError. That's a lot of boilerplate if you were required to implement it yourself in every single operator method. Better, Python handles all the boiler plate, all you have to do is just handle the cases you care about, and return NotImplemented for everything else. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
On Mon, Jun 9, 2014 at 1:53 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: which means that hasattr (which is defined by attempting to get the attribute and seeing if an exception is thrown) has to return True. Yes. And this is a problem why? Obviously it would mean that the semantics of hasattr will be different than they are now, but it's still a coherent set of semantics. Coherent perhaps, but in direct opposition to the OP's statement about how hasattr should return False even if there's a global to be found. A coherent meaning for this kind of thing would almost certainly not be possible within the OP's requirements, although it's entirely possible something sensible could be put together. (By the way, would (3).squared return a curried reference to squared as of when you looked it up, or would it return something that late-binds to whatever 'squared' is in scope as of when you call it? If the latter, then hasattr would have to always return True, and getattr would have to return something that does the late-bind lookup and turns NameError into AttributeError.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue21666] Argparse exceptions should include which argument has a problem
paul j3 added the comment: In http://bugs.python.org/file30010/nargswarn.patch adding the '_expand_help(action)' line should test the help string (during add_argument). def _check_argument(self, action): # check action arguments # focus on the arguments that the parent container does not know about # check nargs and metavar tuple try: self._get_formatter()._format_args(action, None) except ValueError as e: raise ArgumentError(action, str(e)) except TypeError: #raise ValueError(length of metavar tuple does not match nargs) raise ArgumentError(action, length of metavar tuple does not match nargs) # check the 'help' string try: self._get_formatter()._expand_help(action) except (ValueError, TypeError, KeyError) as e: raise ArgumentError(action, 'badly formed help string') The 'except' clause may need to be changed to capture all (or just most?) of the possible errors in the format string. Besides your error I can imagine '%(error)s` (a KeyError). We also need to pay attention to the differences between Py2 and Py3 errors. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21666 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9849] Argparse needs better error handling for nargs
paul j3 added the comment: http://bugs.python.org/issue21666 raises the possibility of testing the 'help' parameter in the same way. By adding (to _check_argument): # check the 'help' string try: self._get_formatter()._expand_help(action) except (ValueError, TypeError, KeyError) as e: raise ArgumentError(action, 'badly formed help string') -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20578] BufferedIOBase.readinto1 is missing
Roundup Robot added the comment: New changeset b1e99b4ec374 by Benjamin Peterson in branch 'default': backout 0fb7789b5eeb for test breakage (#20578) http://hg.python.org/cpython/rev/b1e99b4ec374 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20578 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20699] Behavior of ZipFile with file-like object and BufferedWriter.
Martin Panter added the comment: I have a related issue in Python 3.4. I suspect it is the same underlying problem as Henning’s. BufferedWriter is trying to write memoryview() objects, but the documentation for RawIOBase.write() implies it only has to accept bytes() and bytearray() objects. from io import BufferedWriter, RawIOBase class Raw(RawIOBase): ... def writable(self): return True ... def write(self, b): print(b.startswith(b\n)) ... b = BufferedWriter(Raw()) b.write(babc) 3 b.close() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in write AttributeError: 'memoryview' object has no attribute 'startswith' -- nosy: +vadmium versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20699 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20578] BufferedIOBase.readinto1 is missing
Changes by Benjamin Peterson benja...@python.org: -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20578 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1559298] test_popen fails on Windows if installed to Program Files
eryksun added the comment: This is fixed for subprocess.Popen in 2.7, 3.1, and 3.2; see issue 2304. In 2.7, nt.popen still has this problem. As mentioned above, it can be worked around by using subprocess.Popen as described here: https://docs.python.org/2/library/subprocess.html#replacing-os-popen-os-popen2-os-popen3 -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1559298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21691] set() returns random output with Python 3.4.1, in non-interactive mode
New submission from Jackson Cooper:
The set() built-in returns random output, only when Python 3 is being used, and
in non-interactive mode (executing a file).
Steps to reproduce:
1. Create file with only print(set(['A', 'B'])) inside it.
2. Execute file with Python 3.4.1 numerous times (10+) over 10+ seconds. The
output will vary (randomly?) between {'B', 'A'} and {'A', 'B'}.
I can only reproduce this with Python 3.4.1 (have not tried 3.5). It cannot be
reproduced in Python 2 (2.7.6) interactive or non-interactive mode, or Python
3.4.1 in interactive mode. Only in Python 3 when executing a file.
Tested on OS X 10.9.3, Python installed via Homebrew.
--
components: Interpreter Core
messages: 220021
nosy: Jackson.Cooper
priority: normal
severity: normal
status: open
title: set() returns random output with Python 3.4.1, in non-interactive mode
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21691
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21691] set() returns random output with Python 3.4.1, in non-interactive mode
Benjamin Peterson added the comment: Yep, set order like dictionary order is arbitrary. -- nosy: +benjamin.peterson resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21691 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21691] set() returns random output with Python 3.4.1, in non-interactive mode
Ned Deily added the comment:
To expand a bit, this is by design, a consequence of the hash randomization
feature; see
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
As noted there, if necessary, it is possible to disable hash randomization.
But tests with set values or dict keys should not depend on a particular order
as even disabling hash randomization would not guarantee the same results on
different platforms or builds of Pythons.
$ python3.4 -c print(set(['A', 'B']))
{'B', 'A'}
$ python3.4 -c print(set(['A', 'B']))
{'A', 'B'}
$ python3.4 -c print(set(['A', 'B']))
{'B', 'A'}
$ PYTHONHASHSEED=0 python3.4 -c print(set(['A', 'B']))
{'B', 'A'}
$ PYTHONHASHSEED=0 python3.4 -c print(set(['A', 'B']))
{'B', 'A'}
$ PYTHONHASHSEED=0 python3.4 -c print(set(['A', 'B']))
{'B', 'A'}
--
nosy: +ned.deily
stage: - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21691
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21691] set() returns random output with Python 3.4.1, in non-interactive mode
Jackson Cooper added the comment: Ah, gotcha. I was assuming the output was consistent across environments, even though ordering of set() is arbitrary. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21691 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21692] Wrong order of expected/actual for assert_called_once_with
New submission from Fei Long Wang:
m=mock.Mock()
m.some_method('foo', 'bar')
Mock name='mock.some_method()' id='140353787504656'
m.some_method.assert_called_once_with('foo', 'bar')
m.some_method.assert_called_once_with('foo', 'baz')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.7/dist-packages/mock.py, line 846, in
assert_called_once_with
return self.assert_called_with(*args, **kwargs)
File /usr/local/lib/python2.7/dist-packages/mock.py, line 835, in
assert_called_with
raise AssertionError(msg)
AssertionError: Expected call: some_method('foo', 'baz') #
Actual call: some_method('foo', 'bar') #
--
components: Tests
messages: 220025
nosy: flwang
priority: normal
severity: normal
status: open
title: Wrong order of expected/actual for assert_called_once_with
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21692
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21692] Wrong order of expected/actual for assert_called_once_with
Changes by Ned Deily n...@acm.org: -- nosy: +michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21692 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21685] zipfile module doesn't properly compress odt documents
SilentGhost added the comment: Whether for reasons of slightly different setup or due to something else, I'm not able to reproduce the issue. What I do see, is that the field is not automatically updated, so on opening of the document I have to hit F9 to get the answer field updated. That doesn't, however, seem at all related to the compression method (that is I do get the same behaviour for any combination of compression level values). Perhaps someone else would have a better idea. -- nosy: +alanmcintyre ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21693] Broken link to Pylons in the HOWTO TurboGears documentation
New submission from Yann Lebel: The link to the Pylons framework present at the end of theHOWTO - HOWTO Use Python in the web - TurboGears documentation section redirect to a domain that does not exists anymore. I believe it should be replaced by http://www.pylonsproject.org/ Here is the link to the documentation section https://docs.python.org/3/howto/webservers.html#turbogears -- assignee: docs@python components: Documentation messages: 220027 nosy: Yann.Lebel, docs@python priority: normal severity: normal status: open title: Broken link to Pylons in the HOWTO TurboGears documentation type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21693 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21693] Broken link to Pylons in the HOWTO TurboGears documentation
Yann Lebel added the comment: I just noticed that the same broken link exists in the Other notable frameworks as well. Here is the link to the section https://docs.python.org/3/howto/webservers.html#other-notable-frameworks -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21693 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21692] Wrong order of expected/actual for assert_called_once_with
Michael Foord added the comment: What specifically are you saying is in the wrong order? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21692 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules
Michael Foord added the comment: That looks great - thanks! I'll get it committed shortly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21600 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15286] normpath does not work with local literal paths
Mark Lawrence added the comment: As Antoine's pathlib made it into 3.4 is the patch here now obsolete or what? Also note the reference to issue15275. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15286 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18141] tkinter.Image.__del__ can throw an exception if module globals are destroyed in the wrong order
Jan Kanis added the comment: I tested 2.7 tip (6dfbe504f659), which does not show the problem, as expected. I think there was a real bug in that the tkinter.TclError global was being set to None on exit, but a TclError being raised is expected if I go by the comment in tkinter. The bug was fixed in commit 79e2f5bbc30c. -- resolution: - out of date status: open - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15275] isinstance is called a more times that needed in ntpath
Mark Lawrence added the comment: @Manuel do you intend picking this up? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21694] IDLE - Test ParenMatch
New submission from Saimadhav Heblikar: Adding test for idlelib.ParenMatch for 3.4 Will backport to 2.7 when this patch is OK. 3 lines could not be tested in this patch. -- components: IDLE files: test-parenmatch.diff keywords: patch messages: 220034 nosy: jesstess, sahutd, terry.reedy priority: normal severity: normal status: open title: IDLE - Test ParenMatch versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35536/test-parenmatch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21694 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17822] Save on Close windows (IDLE)
Mark Lawrence added the comment: Using 3.4.1 on Windows I can't reproduce the AttributErrors given in msg187674 -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17822 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12274] Print window menu on IDLE aborts whole application
Mark Lawrence added the comment: Can this be closed as a patch has been committed and the unittest framework was created on issue15392 ? -- nosy: +BreamoreBoy, terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
Arfrever Frehtes Taifersar Arahesis added the comment: Minor inconsistency in Lib/tempfile.py: # Set flag to None to not try again. _O_TMPFILE_WORKS = False s/None/False/ -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21515 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21476] Inconsitent behaviour between BytesParser.parse and Parser.parse
Vajrasky Kok added the comment: Here is the patch based on R. David Murray's nitpick. -- Added file: http://bugs.python.org/file35537/bytes_parser_dont_close_file_v5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21476 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4765] IDLE fails to Delete Custom Key Set properly
Mark Lawrence added the comment: This is still a problem on Windows 7 with 3.4.1 but the patch file fixes it. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4765 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4765] IDLE fails to Delete Custom Key Set properly
Changes by Nicholas Allevato nicholas.allev...@gmail.com: -- nosy: +nicholas.allevato ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4765 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17822] Save on Close windows (IDLE)
Terry J. Reedy added the comment: When writing the human-verified tests in idle_test.htest.py, we discovered that there is a different between Windows and Linux in focus shifting when opening an editor window from a visible root window. On Widows, I have to click on the editor window to enter anything. Saimadhav reports that on Linux, the editor already has the focus and is live. Similarly, when I open Idle from console interpreter with import idlelib.idle the focus stay with the console and I have to click on the shell to enter code there. I suspect that this is also different on *nix. Can someone check? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17822 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18910] IDle: test textView.py
Zachary Ware added the comment:
The changeset Benjamin backed out is pretty much fine, just needs the
requires('gui') to be at the top of setUpModule instead of at toplevel. That
does mean the whole module is constructed and then thrown away without doing
anything, but it at least runs properly even with no Tk available.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18910
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21682] Refleak in idle_test test_autocomplete
Zachary Ware added the comment: Terry, did you mean to push Saimadhav's patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21682 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21671] CVE-2014-0224: OpenSSL upgrade to 1.0.1h on Windows required
Zachary Ware added the comment: So installers are out for 3.1-3.3; should we still update the externals script and pyproject properties for those branches anyway? If not, this issue should be ready to close. -- stage: - commit review status: open - pending type: - security ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21671 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21682] Refleak in idle_test test_autocomplete
Roundup Robot added the comment: New changeset b8f33440cd5e by Terry Jan Reedy in branch '2.7': Issue #21682: Replace EditorWindow with mock to eliminate memory leaks. http://hg.python.org/cpython/rev/b8f33440cd5e New changeset e6cc02d32957 by Terry Jan Reedy in branch '3.4': Issue #21682: Replace EditorWindow with mock to eliminate memory leaks. http://hg.python.org/cpython/rev/e6cc02d32957 New changeset 30c2f65a6346 by Terry Jan Reedy in branch '2.7': Issue #21682: Replace EditorWindow with mock to eliminate memory leaks. http://hg.python.org/cpython/rev/30c2f65a6346 New changeset 7f14a2c10c09 by Terry Jan Reedy in branch '3.4': Issue #21682: Replace EditorWindow with mock to eliminate memory leaks. http://hg.python.org/cpython/rev/7f14a2c10c09 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21682 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21671] CVE-2014-0224: OpenSSL upgrade to 1.0.1h on Windows required
Steve Dower added the comment: The only reason to do it is to help out those who build from source, which I suspect is an incredibly small group on Windows. We'd also be signing up to keep doing it, and implying that it's been tested. I say don't bother. From: Zachary Waremailto:rep...@bugs.python.org Sent: 6/8/2014 11:57 To: Steve Dowermailto:steve.do...@microsoft.com Subject: [issue21671] CVE-2014-0224: OpenSSL upgrade to 1.0.1h on Windows required Zachary Ware added the comment: So installers are out for 3.1-3.3; should we still update the externals script and pyproject properties for those branches anyway? If not, this issue should be ready to close. -- stage: - commit review status: open - pending type: - security ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21671 ___ -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21671 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21671] CVE-2014-0224: OpenSSL upgrade to 1.0.1h on Windows required
Zachary Ware added the comment: Good enough for me. -- resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21671 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17822] Save on Close windows (IDLE)
Mark Lawrence added the comment: Using 3.4.1 and 3.5.0 on Windows 7 I always get the focus set to the edit window or shell as appropriate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17822 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21683] Add Tix to the Windows buildbot scripts
Changes by Zachary Ware zachary.w...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file35538/issue21683.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21683 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21669] Custom error messages when print exec are used as statements
Glyph Lefkowitz added the comment: Just my 2¢ here: rather than debating cases in the abstract, it would be interesting to 'pip install' a couple of popular 2.x-only packages and see if the error message is an improvement. My experience is that learners don't hit this so much by writing their own code wrong, but by loading a dependency with incorrect metadata on the wrong Python. (Which suggests to me that a URL in the error message telling you how to download a different version of Python would be very helpful as well.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21683] Add Tix to the Windows buildbot scripts
New submission from Roundup Robot: New changeset 31dbdd7596aa by Zachary Ware in branch '3.4': Issue #21683: Add Tix build to the Windows buildbot scripts. http://hg.python.org/cpython/rev/31dbdd7596aa New changeset 8bafb707d549 by Zachary Ware in branch '2.7': Issue #21683: Add Tix build to the Windows buildbot scripts. http://hg.python.org/cpython/rev/8bafb707d549 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21683 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21683] Add Tix to the Windows buildbot scripts
Zachary Ware added the comment: Tix should be built on the 2.7 and 3.4 buildbots now; it already has been on 3.x. -- resolution: - fixed stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21683 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21569] PEP 466: Python 2.7 What's New preamble changes
Arfrever Frehtes Taifersar Arahesis added the comment:
These changes caused this warning (at least on default branch) from Sphinx:
${cpython_working_copy}/Doc/whatsnew/2.7.rst:442: WARNING: undefined label:
argparse-from-optparse (if the link has no caption the label must precede a
section header)
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21569
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21695] Idle 3.4.1-: closing Find in Files while in progress closes Idle
New submission from Terry J. Reedy: Reproducer: On Windows, Open Idle and editor. In editor grep (alt-f3), for instance, 'print' in /Lib/*.py. While hits are flashing by, close the output window with [x] 2.7.6 or .7: Output window closes, Idle continues as desired. 3.3.5 or 3.4.1: All Idle windows - shell, editor, output 3.4.1+, 3.5.0a, debug builds run from console interpreter: Output window closes, Idle continues, as desired. console window displays exception ending with File F:\Python\dev\5\py35\lib\idlelib\GrepDialog.py, line 90, in grep_it (fn, lineno, line)) File F:\Python\dev\5\py35\lib\idlelib\OutputWindow.py, line 40, in write self.text.insert(mark, s, tags) AttributeError: 'NoneType' object has no attribute 'insert' The specific fix is to wrap the text insert with try: except: break. The immediate mystery is why 2.7 did not shutdown with nowhere to print the traceback. -- assignee: terry.reedy messages: 220052 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle 3.4.1-: closing Find in Files while in progress closes Idle type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21695 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21696] Idle: test syntax of configuration files
New submission from Terry J. Reedy: Spinoff of #12274 and a dependency thereof: new test_configurations.py should statically test that configparser, called from idlelib.configHandler, can process all the configuration.def files without error. -- assignee: terry.reedy messages: 220053 nosy: sahutd, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: test syntax of configuration files type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21696 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20147] multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available
Changes by Richard Oudkerk shibt...@gmail.com: -- assignee: - sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20147 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12274] Print window menu on IDLE aborts whole application
Terry J. Reedy added the comment: This issue needs a unittest test added within the framework. I opened #21696 as a dependency. Since configx.def files can be edited, and, I believe, at least one is intended to be edited, configHandler should perhaps catch exceptions and display in a messagebox. But unless Idle could continue after that, that might wait for the general fix, which is another issue. -- dependencies: +Idle: test syntax of configuration files ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12274 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15780] IDLE (windows) with PYTHONPATH and multiple python versions
Mark Lawrence added the comment: Something on Windows configuration here https://docs.python.org/3/using/windows.html#excursus-setting-environment-variables -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15780 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21372] multiprocessing.util.register_after_fork inconsistency
Richard Oudkerk added the comment: register_after_fork() is intentionally undocumented and for internal use. It is only run when starting a new process using the fork start method whether on Windows or not -- the fork in its name is a hint. -- resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21372 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4765] IDLE fails to Delete Custom Key Set properly
Terry J. Reedy added the comment: Add to my list of patches to review. -- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4765 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
Roundup Robot added the comment: New changeset 8b93cdccd872 by Victor Stinner in branch 'default': Issue #21515: Fix typo in a comment, thanks Arfrever for the report http://hg.python.org/cpython/rev/8b93cdccd872 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21515 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
