Re: How to wow someone new to Python
On Sat, 17 Jan 2015 02:03:57 +1100, Chris Angelico ros...@gmail.com wrote: Scenario: You're introducing someone to Python for the first time. S/he may have some previous programming experience, or may be new to the whole idea of giving a computer instructions. You have a couple of minutes to show off how awesome Python is. What do you do? I was thinking along the lines of a simple demo in the REPL, showing off some of Python's coolest features. But then I got stuck on the specifics. What are Python's best coolnesses? What makes for a good demo? Ideally, this should be something that can be demo'd quickly and easily, and it should be impressive without going into great details of and see, this is how it works on the inside. So, how would you brag about this language? I can only say what made me sit up and take notice. 1. I found it already on my computer. 2. It seemed to be used to run the Gramps genealogy program, which is quite complex. I was impressed. 3. When I started to look at it, I found that strings could be any length and were not limited to swomething arbitrary, like 256 characters. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: How to wow someone new to Python
On 21-1-2015 18:59, Steve Hayes wrote: 3. When I started to look at it, I found that strings could be any length and were not limited to swomething arbitrary, like 256 characters. Even more fun is that Python's primitive integer type (longs for older Python versions) has no arbitrary limitation either. That amazed me at the time I discovered python :) Irmen -- https://mail.python.org/mailman/listinfo/python-list
Re: How to wow someone new to Python
On Friday, 16 January 2015 11:04:20 UTC-4, Chris Angelico wrote: Scenario: You're introducing someone to Python for the first time. S/he may have some previous programming experience, or may be new to the whole idea of giving a computer instructions. You have a couple of minutes to show off how awesome Python is. What do you do? I was thinking along the lines of a simple demo in the REPL, showing off some of Python's coolest features. But then I got stuck on the specifics. What are Python's best coolnesses? What makes for a good demo? Ideally, this should be something that can be demo'd quickly and easily, and it should be impressive without going into great details of and see, this is how it works on the inside. So, how would you brag about this language? ChrisA If you are willing to install an older version of Python (because the program I am going to mention has not been updated in years ... but it *should* work with 2.6), I'm going to suggest an odd one: Crunchy! (ok, I'm biased :-). The home page is at https://code.google.com/p/crunchy/ where you can find a link to some screencasts (based on an even older version ...) So, before you install anything, just have a quick look at the screencast to see if it's worthwhile. A demo using Crunchy seems to be even more impressive if the person knows some programming. (Here is what was said about an even older version of Crunchy by people at the Omaha Python group: Jeff gave a presentation on Crunchy ([WWW] http://crunchy.sourceforge.net/) Talk about a gee whiz app. [https://mail.python.org/pipermail/omaha/2007-July/65.html]) In a nutshell, I would open the official Python tutorial in my browser, showing the official Python tutorial. (boring) Then, I would open the exact same page using a browser tab served by Crunchy: magically some text-input boxes would have been inserted allowing you to try out the code in the REPL provided by Crunchy. Then I'd use Crunchy to launch an external app (perhaps a tkinter program), etc. As I said at the beginning, Crunchy has not been updated in *years* ... more or less since the IPython and Sage notebooks came along... André -- https://mail.python.org/mailman/listinfo/python-list
Re: How to wow someone new to Python
On Wednesday, 21 January 2015 15:06:33 UTC-4, Chris Angelico wrote: On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong wrote: On 21-1-2015 18:59, Steve Hayes wrote: 3. When I started to look at it, I found that strings could be any length and were not limited to swomething arbitrary, like 256 characters. Even more fun is that Python's primitive integer type (longs for older Python versions) has no arbitrary limitation either. That amazed me at the time I discovered python :) I hadn't worked with length-limited strings in basically forever (technically BASIC has a length limit, but I never ran into it; and I never did much with Pascal), but you're right, arbitrary-precision integers would have impressed me a lot more if I hadn't first known REXX. So... is there a way to show that off efficiently? How about: def fac(n): ... ans = 1 ... while n 1: ... ans *= n ... n -= 1 ... return ans ... a = fac(100) a 9332621544394415268169923885626670049071596826438162146859296389521753229915608941463976156518286253697920827223758251185210916864 b = fac(102) b 961446671503512660926865558697259548455355905059659464369444714048531715130254590603314961882364451384985595980362059157503710042865532928 b//a 10302 b//a == 102 * 101 True André Normally, any calculation that goes beyond 2**32 has already gone way beyond most humans' ability to hold the numbers in their heads. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to wow someone new to Python
Chris, Scenario: You're introducing someone to Python for the first time. S/he may have some previous programming experience, or may be new to the whole idea of giving a computer instructions. You have a couple of minutes to show off how awesome Python is. What do you do? Some ideas where given by others already. I especially liked the variable swap one liner by Emile van Sebille. That's a little simple gem that will impress any seasoned developer of other programming languages. But speaking about impressing more experient programmers, I personally don't think Python has a wow factor in any of its features and syntax. At least in the way I understand the word wow. Python shares its own brand of idiosyncracies with any other programming languages. Little gotchas and caveats that have you scratch your head and sometimes annoy you slightly. Python is it too cropped here and there with things worth criticizing. Meanwhile some of its interesting language features, like Comprehensions and Generators, aren't really that impressive to a seasoned developer of functional programming languages or programming languages like C# with its highly powerful and expressive LINQ. This means that, alone, Python won't really standout. But this is ok. No language does it on the merits of its syntax or feature set. What does make Python standout in my opinion -- what gave me the wow -- is its interoperability. Here we have a general purpose scripting language with more hooks to other systems that any other programming language in existence. With just Python, I can build a modern GUI interface on any of the most popular operating systems, use it on PostgreSQL to build stored procedures and move most of my business rules to the database server and attach dynamic behavior to a system developed in some other programming language. I apologize if my post was to long, but I lacked the time to make it shorter. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to wow someone new to Python
On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong irmen.nos...@xs4all.nl wrote: On 21-1-2015 18:59, Steve Hayes wrote: 3. When I started to look at it, I found that strings could be any length and were not limited to swomething arbitrary, like 256 characters. Even more fun is that Python's primitive integer type (longs for older Python versions) has no arbitrary limitation either. That amazed me at the time I discovered python :) I hadn't worked with length-limited strings in basically forever (technically BASIC has a length limit, but I never ran into it; and I never did much with Pascal), but you're right, arbitrary-precision integers would have impressed me a lot more if I hadn't first known REXX. So... is there a way to show that off efficiently? Normally, any calculation that goes beyond 2**32 has already gone way beyond most humans' ability to hold the numbers in their heads. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23292] Enum doc suggestion
Mark Summerfield added the comment: Georg said to assign this to Ethan Furman but I don't seem to have that facility. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On 2015-01-21, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. But does he answer the more important question and can we use it to kill PHP?. -- Grant Edwards grant.b.edwardsYow! What UNIVERSE is this, at please?? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
[issue23291] Documentation about Py_Finalize(): Freeing objects
New submission from Albert Zeyer: The documentation about Py_Finalize() about freeing objects is not exactly clear. Esp., when I have called Py_INCREF somewhere, those objects will always have ob_refcnt 0 unless I call Py_DECREF somewhere, what about these objects? Will they be freed in Py_Finalize() or not? If not, what can I do? I guess calling Py_DECREF after Py_Finalize() is not allowed. I studied the Py_Finalize() code but I'm not exactly sure. It looks like such objects would not get freed (unless some implicit magic is happening somewhere). The comment about the last commented-out PyGC_Collect() call is also insightful and somewhat unsatisfying. Maybe PyObject_Free() still works, although that would not free any further referenced objects, I guess. Also, I'm not exactly sure about the pymalloc arenas. With pymalloc, maybe we could just free all pymalloc arenas and it would free all memory allocated by Python objects? Of course, that would not call any advanced tp_dealloc functions which might be important to be called, but we would never ever call those anyway anymore, or would we (how?)? So, maybe it would be good to do that? -- components: Interpreter Core messages: 234441 nosy: Albert.Zeyer priority: normal severity: normal status: open title: Documentation about Py_Finalize(): Freeing objects versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23291 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
Hi Steven, you wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. I've yet to watch the video, I'll do that later tonight, but I also remember what DHH said about Smalltalk in his FLOSS interview about Rails, with Randal Schwartz, in July 2009: [...] Smalltalk in itself... I tried a few times with some of the images, but it's too much of a different world. It's too idealistic for me in some senses. It's too much “throw out everything you know and I will show you a new world”. I haven't been ready to take that red pill. I really like that Ruby is sort of, lets extract 80, 90 percent of what awesome about that and inject it with some real-world pragmatic approaches, like: You can use the text editor you like; You can save files on the file system; You can all these things in tracks with the real world. You don't have to leave everything behind to jump into this Smalltalk world. To me the whole thing about the Smalltalk images which is always just too confusing to me. Why? There's all this different distributions, they're not really compatible, it just seems like a hassle. I just didn't have the patience to wade through all that. But I'm glad somebody else did. I'm glad that all that wisdom is available mostly to people using Ruby. So, yeah, again: Not really. Source: http://www.transcribed-interview.com/dhh-rails-david-heinemeier-hansson-interview-randal-schwartz-floss.html Disclosure: I'm the one who made that transcription, and I recognized it from memory. Greetings, -- You can't actually make computers run faster, you can only make them do less. - RiderOfGiraffes -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On 2015-01-22 03:34, Steven D'Aprano wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. Holy pacing, Batman. Watching it at 2x leaves me wondering how much of the stage was worn off during the presentation. And now it's all but dead. Why did it die, and how can Python (or Ruby for that matter) avoid the same fate? In my experience, most Python has a particularly low WTF-per-minute score. But mostly Michael's reply addresses my biggest pain points the last couple times I tried Smalltalk: The whole images thing impeded me from easily using my development preferred environment. With Python, I can just install it and then either fire up the REPL, or type some code into a file and run it (same I suppose would go for Ruby). I fought for over an hour trying to figure out how to just get ANYTHING to run in Smalltalk. I installed Squeak on Debian and yet I couldn't get any code examples to run. I had to go find some environments on the web, download them, modify them, and eventually something ran. Eventually I just gave up and returned to a world where everything made sense. -tkc -- https://mail.python.org/mailman/listinfo/python-list
[issue23292] Enum doc suggestion
New submission from Mark Summerfield: I think it would be worth documenting globals().update(MyEnumeration.__members__) in the Interesting Examples section of the enum docs. I suspect that most people will find that importing enums is annoying because they'll get import A print(A.MyEnumeration.MAX) when they're more used to import A print(A.MAX) Of course the latter is easily achieved using the globals().update() trick (as used in signals.py in 3.5). Georg suggested I add this to the tracker. -- assignee: docs@python components: Documentation files: py-enum.tar.gz messages: 234442 nosy: docs@python, mark priority: normal severity: normal status: open title: Enum doc suggestion type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37809/py-enum.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: python traceroute
On Jan 21, 2015, at 12:06 AM, Denis McMahon denismfmcma...@gmail.com wrote: On Tue, 20 Jan 2015 19:37:26 -0800, Chandrakant Tiwari wrote: in the program below i want it to make it work the same way as TRACERT command. As an observation, you're re-inventing a wheel that already works perfectly well, in that any failings of tracert tend to be more down to the way routers are configured to handle icmp than the tracert application itself. Unless you're doing this purely as an exercise in socket programming with python, it might be better to find a new problem to solve. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list I’d further add that as a security measure these days, many (soon to be most) hosts are configured to throw icmp packets away without acknowledging them in any way. Bill -- https://mail.python.org/mailman/listinfo/python-list
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: To wait for the exit of the subprocess, we use RegisterWaitForSingleObject(). To cancel this wait, we can use UnregisterWait() which returns immediatly. Problem: UnregisterWait() doesn't tell us if the wait was cancelled or not, the cancellation is asynchronous. Second problem: the wait may have been signaled to the IOCP... or not. The wait may be signaled after the call to UnregisterWait(), since the cancellation is asynchronous (I'm not sure of that, but it doesn't change everything). This can be explained by the implementation: RegisterWaitForSingleObject() is implemented with a pool of threads. Windows XP introduced UnregiterWaitEx() which can be used to be notified when the wait has been cancelled. Cool. But the notification requires an Event object. And how can we asynchronously wait for this Event? Using RegisterWaitForSingleObject()! Wait, what? We were cancelling another RegisterWaitForSingleObject(). To be fully asynchronous (no performance impact), cancelling a RegisterWaitForSingleObject() wait requires a new Event object and call RegisterWaitForSingleObject() on it. -- In Python, we must ensure that the Overlapped object used by RegisterWaitForSingleObject() is kept alive until the wait is signalled, or until we are sure that the wait was cancelled. Otherwise, the program may crash. To keep the Overlapped object alive, we keep indirectly in a _WaitHandleFuture object, and this future is registered in IocpProactor._cache. I'm working on a change to use UnregiterWaitEx(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Trees
On Wednesday, January 21, 2015 at 6:06:06 PM UTC+5:30, Chris Angelico wrote:
On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody wrote:
I would like a set to be {1,2,3} or at worst ⦃1,2,3⦄
and a bag to be ⟅1,2,3⟆
Apart from the unicode niceness that Ive described here
http://blog.languager.org/2014/04/unicoded-python.html
Its a bit of a nuisance that we have to write set([1,2,3]) for the first
Wait, what?
rosuav@sikorsky:~$ python
Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
type({1,2,3})
type 'set'
rosuav@sikorsky:~$ python3
Python 3.5.0a0 (default:4709290253e3, Jan 20 2015, 21:48:07)
[GCC 4.7.2] on linux
Type help, copyright, credits or license for more information.
type({1,2,3})
class 'set'
Looks like {1,2,3} works for me.
ChrisA
Ah thank you -- forgot -- mea culpa.
--
https://mail.python.org/mailman/listinfo/python-list
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Unfortunately, I have little or no experience with Python C code and I even don't have a C compiler installed so I cannot experiment. I'll just put my ideas how to solve this here. • Add sys.__readlinehook__ attribute, which can be set to a function taking a prompt string and returing a line. • Add C function PyOS_UnicodeReadline (possibly with a better name) which has the same signature as sys.__readlinehook__ (in contrast with the signature of PyOS_Readline). If sys.__readlinehook__ is set, call it; otherwise encode the prompt string using stdout encoding and delegate to PyOS_Readline and decode the string returned using stdin encoding. • Change the tokenizer and the implementation of input() so it uses PyOS_UnicodeReadline rather than PyOS_Readline. This would solve the problem that utf-16 encoded string cannot be given to the tokenizer and also would bypass the silent assumption that stdin and stdout encodings are the same. Also, readline hook could be easily set from Python code – no need for ctypes. The package pyreadline could use this. Also, the issue #1602 could be then solved just by changing sys.std* streams and providing a trivial sys.__readlinehook__ delegating to sys.stdout.write and sys.stdin.readline. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Trees
On Wed, Jan 21, 2015 at 9:15 AM, Ian Kelly ian.g.ke...@gmail.com wrote: class MultiSet(MutableSet): In retrospect this probably shouldn't derive from MutableSet, since that carries the expectation that all elements are unique (much like how bool shouldn't be subclassed). For instance, collections.Set includes some operators that aren't compatible with the second operand being a multiset. -- https://mail.python.org/mailman/listinfo/python-list
Re: Trees
On Wed, Jan 21, 2015 at 7:47 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
More irksome that for the second we've to preface with
from collections import Counter
And still more a PITA that a straightforward standard name like bag (or
multiset) is called by such an ungoogleable misleading name as counter.
It is not misleading. collections.Counter is a class for counting (i.e. a
counter), not a bag. It is merely *similar* to a bag, but the API is not
the same as the usual bag API because the motivating design is not the same
as for bags.
To expand on this, Counter does provide a few multiset operations like
union and intersection. But there are a number of cases where it falls
short or does not perform as expected. To name a few:
* There are no subset or superset comparison operations provided.
* len(counter) returns the number of keys, not the number of elements.
* Unlike a multiset, Counters can have negative or zero counts; one
curious consequence of this is that an empty Counter can have a
non-zero length and evaluate as true in boolean contexts.
A while back I fiddled around with creating a true MultiSet class
using a Counter as the underlying implementation. Here's what I came
up with:
from collections import Counter
from collections.abc import MutableSet, Set
__all__ = ['MultiSet']
class MultiSet(MutableSet):
Multiset class containing hashable items.
# Class invariants:
# * self._counter is a Counter s/t all values are positive ints denoting
# multiplicity.
# * set(self) == self._counter.keys()
def __init__(self, iterable_or_mapping=()):
Create a new, empty MultiSet. If passed an iterable argument, initialize
the MultiSet with items from the iterable. If passed a mapping argument,
initialize the MultiSet with the keys of the mapping, each repeated a number
of times equal to the associated value.
self._counter = +Counter(iterable_or_mapping)
@classmethod
def _from_counter(cls, counter):
self = cls.__new__(cls)
self._counter = counter
return self
def __contains__(self, item):
return item in self._counter
def __hash__(self):
raise TypeError('unhashable type: %s' % type(self))
def __iter__(self):
return self._counter.elements()
def __len__(self):
# TODO: consider caching the length.
return sum(self._counter.values())
def __repr__(self):
if self:
return 'MultiSet(%r)' % list(self)
return 'MultiSet()'
def add(self, item):
Add an element to the MultiSet.
self._counter[item] += 1
def clear(self):
Remove all elements from the MultiSet, leaving it empty.
self._counter.clear()
def count(self, item):
Return the number of occurrences of the element.
return self._counter[item]
def discard(self, item):
Remove an element from the MultiSet.
If there are multiple occurrences, remove only one such occurrence. If the
element is not a member, do nothing.
if item not in self._counter:
return
if self._counter[item] == 1:
del self._counter[item]
else:
self._counter[item] -= 1
def __or__(self, other):
Return the union of the MultiSet and another set.
if not isinstance(other, Set):
return NotImplemented
return self._from_counter(self._counter | _get_counter(other))
__ror__ = __or__
def __ior__(self, other):
Perform the in-place union of the MultiSet and another set.
if not isinstance(other, Set):
return NotImplemented
self._counter |= _get_counter(other)
return self
def __and__(self, other):
Return the intersection of the MultiSet and another set.
if not isinstance(other, Set):
return NotImplemented
return self._from_counter(self._counter _get_counter(other))
__rand__ = __and__
def __iand__(self, other):
Perform the in-place intersection of the MultiSet and another set.
if not isinstance(other, Set):
return NotImplemented
self._counter = _get_counter(other)
return self
def __sub__(self, other):
Return the difference of the MultiSet and another set.
if not isinstance(other, Set):
return NotImplemented
return self._from_counter(self._counter - _get_counter(other))
def __rsub__(self, other):
Return the difference of another set and the MultiSet.
if not isinstance(other, Set):
return NotImplemented
return self._from_counter(_get_counter(other) - self._counter)
def __isub__(self, other):
Perform the in-place set difference of the MultiSet and another set.
if not isinstance(other, Set):
return NotImplemented
self._counter -= _get_counter(other)
return self
def __xor__(self, other):
Return the symmetric difference of the MultiSet and another set.
if not isinstance(other, Set):
return NotImplemented
# X ^ Y == (X - Y) | (Y - X)
other_counter = _get_counter(other)
counter = (self._counter - other_counter) |
What killed Smalltalk could kill Python
In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. (No cheering, that sort of attitude is one of the things that killed Smalltalk.) Although Martin discusses Ruby, the lessons could also apply to Python. Video is available here: http://www.youtube.com/watch?v=YX3iRjKj7C0 Youngsters may not be aware of Smalltalk. It was the language which popularised object oriented programming. Technically, Simula was the first OOP language, but Smalltalk popularised it. For a decade or two in the 80s and 90s, Smalltalk was *the* killer language, the one everybody wanted to use if only their boss would let them. It was amazingly innovative: Smalltalk introduced unit testing, test driven development, and it had powerful refactoring IDEs back in the 1990s. And now it's all but dead. Why did it die, and how can Python (or Ruby for that matter) avoid the same fate? Martin is a very entertaining speaker, funny and knowledgeable. It is a very entertaining talk, and he covers not just Smalltalk and Ruby but the nature of professionalism, how fear makes code worse, how to make code better, Ward Cunningham, the hormonal characteristics of various languages, the language wars of the 1990s, what is clean code, and more. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Changes by Claudiu Popa pcmantic...@gmail.com: -- priority: normal - high stage: - patch review versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23292] Enum doc suggestion
Changes by Georg Brandl ge...@python.org: -- assignee: docs@python - ethan.furman nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
On 01/21/2015 02:06 PM, Chris Angelico wrote: On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong irmen.nos...@xs4all.nl wrote: On 21-1-2015 18:59, Steve Hayes wrote: 3. When I started to look at it, I found that strings could be any length and were not limited to swomething arbitrary, like 256 characters. Even more fun is that Python's primitive integer type (longs for older Python versions) has no arbitrary limitation either. That amazed me at the time I discovered python :) I hadn't worked with length-limited strings in basically forever (technically BASIC has a length limit, but I never ran into it; and I never did much with Pascal), but you're right, arbitrary-precision integers would have impressed me a lot more if I hadn't first known REXX. So... is there a way to show that off efficiently? Normally, any calculation that goes beyond 2**32 has already gone way beyond most humans' ability to hold the numbers in their heads. ChrisA Yes, length-unlimited strings are *extremely* useful in some applications. I remember bitterly cursing Java's string length limit of 2 ** 31 (maybe - 1) on multiple occasions. Python's strings seem to behave like integers in that their size is limited only by available memory. MMR... -- https://mail.python.org/mailman/listinfo/python-list
Re: How to wow someone new to Python
Chris Angelico ros...@gmail.com writes: ..., and I would guess a 64-bit Java would also raise the limit. Even in a 64-bit Java, the _type_ returned by String.length() is 'int', and is thus at most (2**31 - 1). This isn't a problem for strings, which never get that long in practice, but for some other Java datatypes (e.g., Buffer) it is a real problem. Score one for untyped languages. -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: I think I've fixed the memory leaks (plural). There were also a host of other problems with the _UNPACK opcodes in ceval. Here are the things I remember fixing, although I think I did slightly more: - Not throwing an error when PyDict_New or PyDict_Update fails. - Not doing Py_DECREF on stack items being popped. - Not checking if intersection is non-NULL. - Not doing Py_DECREF on intersection. Now the primary problem is giving good errors; I don't know how to make them look like they came from the function call. I'm not sure I want to, either, since these opcodes are used elsewhere. I do need to check something about this (what requirements are there on how you leave the stack when you goto error?), but that's an easy fix if my current guess isn't right. -- Added file: http://bugs.python.org/file37811/starunpack13.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
In article w2dsif33j2k@scooby-doo.csail.mit.edu, alan@scooby- doo.csail.mit.edu says... Even in a 64-bit Java, the _type_ returned by String.length() is 'int', and is thus at most (2**31 - 1). This isn't a problem for strings, which never get that long in practice, but for some other Java datatypes (e.g., Buffer) it is a real problem. Score one for untyped languages. Still, assuming you have enough heap size, you can still create a 500 million character string buffer. That's one of a heck large buffer. Nearly twice the online encyclopedia Britannica(1), and roughly 50 times the longest novel ever produced (2). And considering you can always flush the buffer, I'm finding an hard time looking at unlimited string length in Python as wow factor. Even if we consider unicode strings. (1) http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons#Comparison_of_en cyclopedias (2) http://en.wikipedia.org/wiki/List_of_longest_novels -- https://mail.python.org/mailman/listinfo/python-list
[issue23166] urllib2 ignores opener configuration under certain circumstances
Enrico Tröger added the comment: I got the same error suddenly with Python 2.7.9. I think this is quite unfortunate because it somewhat breaks existing behaviour, especially that SSL certificate verification is enabled by default. Don't get me wrong, this is the right thing in general and it is important. Still, adding this feature in a 2.7 patch level release and enabling it by default feels quite hard. I guess this will break many scripts and applications which rely on non-verification of SSL certs (which is bad but it was the exisiting behaviour). Anyway, attached is my use case where I use a HTTPS request coupled with HTTP basic authentication and disabled SSL cert verification. As described above, passing a context to urlopen() will override previously configured handlers, unfortunately. In the attached script there is also a workaround which works for me by not using urlopen() but instead calling opener.open() manually after adding the necessary handlers myself. Not nice but works for the moment. -- nosy: +eht16 Added file: http://bugs.python.org/file37810/urllib_ssl_auth_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
Alan Bawden a...@scooby-doo.csail.mit.edu writes: ... Score one for untyped languages. Drat. I should have writted dynamically typed languages. The language has changed. When I was a novice Lisp hacker, we were comfortable saying that Lisp was untyped. But nowadays we always say that Lisp is dynamically typed. I could write an essay about why... -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Guido van Rossum added the comment: Python 3's exception chaining allows us to do the second (easier to catch without resorting to except Exception: or even except:) while still showing the original exception in the traceback. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
On Thu, Jan 22, 2015 at 8:20 AM, Matthew Ruffalo mm...@case.edu wrote: Yes, length-unlimited strings are *extremely* useful in some applications. I remember bitterly cursing Java's string length limit of 2 ** 31 (maybe - 1) on multiple occasions. Python's strings seem to behave like integers in that their size is limited only by available memory. Hmm, I don't know that you'll get much beyond 2**31 characters (even all-ASCII characters in PEP 393) on a 32-bit Python, simply because available memory is capped at 2**32 bytes minus other stuff. You'd need a 64-bit Python to do that, and I would guess a 64-bit Java would also raise the limit. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Claudiu Popa added the comment: Here's a patch which uses ast.literal_eval instead. This doesn't get code executed, since literal_eval will fail loudly for anything other than a literal. There are some issues to consider: - let the current ast.literal_eval call bubble out with a lot of different exceptions - normalize the exception to dbm.dumb.error. I'm leaning towards the first, since it clearly shows that something bad happened in the module and it's a first indicator that someone tampered with the data file. -- keywords: +patch nosy: +Claudiu.Popa Added file: http://bugs.python.org/file37812/issue22885.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
On Thu, Jan 22, 2015 at 8:46 AM, Matthew Ruffalo mm...@case.edu wrote: No, Java's String.length returns an int and Strings are limited to ~2 ** 31 characters even in 64-bit Java. Huh, annoying. In Python, the length of a string (in characters) is stored in a Py_ssize_t (if I recall correctly), which is, I believe, a pointer-sized integer. So it'd be 64-bit on a 64-bit build. I do seem to have encountered some strange behavior, though: creating very large strings with str.__mul__ seems to enter an allocation loop in Python 3.4. With a single-character string 's', I can create the following new strings quickly: s * 2 ** 33 s * 2 ** 34 s * 2 ** 35 s * 2 ** 36 but s * 2 ** 38 shows some odd memory usage. I'm watching the memory usage of a Python process steadily increase to 256GB, drop to a few MB, climb back to 256GB, drop to a few MB, and so on. It takes a half-dozen cycles of allocation and deallocation before the interactive interpreter gives me another prompt. That sounds like you're blooping through your page file. The exact behaviour will depend on how much physical memory you have, how your page file is implemented (which depends on your OS), the phase of the moon, and what you had for breakfast three weeks ago. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23294] A typo in the tutorial
New submission from aruseni: https://docs.python.org/3/tutorial/controlflow.html In many ways the object returned by range() behaves as if it is a list, but in fact it isn’t. -- messages: 234449 nosy: aruseni priority: normal severity: normal status: open title: A typo in the tutorial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
Alan Bawden a...@scooby-doo.csail.mit.edu writes: The language has changed. When I was a novice Lisp hacker, we were comfortable saying that Lisp was untyped. But nowadays we always say that Lisp is dynamically typed. I could write an essay about why... I'd be interested in seeing that. Lisp of course descends from Church's untyped lambda calculus but I didn't realize Lisp terminology about its (runtime) type system had changed historically. PL theorists sometimes like to refer to runtime types as tags rather than types. -- https://mail.python.org/mailman/listinfo/python-list
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
Roundup Robot added the comment: New changeset fb8a093db8b1 by Victor Stinner in branch '3.4': Issue #23095, asyncio: Rewrite _WaitHandleFuture.cancel() https://hg.python.org/cpython/rev/fb8a093db8b1 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
In article 873873ae91@jester.gateway.sonic.net, no.email@nospam.invalid says... Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby... http://www.youtube.com/watch?v=YX3iRjKj7C0 That's an hour-long video; could someone who's watched it give a brief summary? In a nutshell, he argues, along with Ward Cunningham, that what killed Smalltalk was how easy you could create unclean code with it. Unclean in this context means Smalltalk didn't punish bad software design decisions that would eventually lead into complex code and unmanageable systems with zero options of code maintenance. I don't have an opinion. I didn't know Smalltalk. I started my programming carrer around the early nineties as a Dbase and later Clipper programmer. -- https://mail.python.org/mailman/listinfo/python-list
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
Roundup Robot added the comment: New changeset d3804307cce4 by Victor Stinner in branch '3.4': Issue #23095, asyncio: IocpProactor.close() must not cancel pending https://hg.python.org/cpython/rev/d3804307cce4 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe()
Changes by STINNER Victor victor.stin...@gmail.com: -- title: [Windows] asyncio: race condition related in IocpProactor.connect_pipe() - [Windows] asyncio: race condition related to IocpProactor.connect_pipe() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
On 21-1-2015 20:06, Chris Angelico wrote: On Thu, Jan 22, 2015 at 5:20 AM, Irmen de Jong irmen.nos...@xs4all.nl wrote: On 21-1-2015 18:59, Steve Hayes wrote: 3. When I started to look at it, I found that strings could be any length and were not limited to swomething arbitrary, like 256 characters. Even more fun is that Python's primitive integer type (longs for older Python versions) has no arbitrary limitation either. That amazed me at the time I discovered python :) I hadn't worked with length-limited strings in basically forever (technically BASIC has a length limit, but I never ran into it; and I never did much with Pascal), but you're right, arbitrary-precision integers would have impressed me a lot more if I hadn't first known REXX. So... is there a way to show that off efficiently? Normally, any calculation that goes beyond 2**32 has already gone way beyond most humans' ability to hold the numbers in their heads. ChrisA Something silly that I just thought about (Python 3): number = 2 * 3 * 5 * 103# okay. number = number * 3120937 * 6977407 * 8431103# hmm... number = number * 70546381234168412430433268433712277793053956898109255590133639943 print(I know a huge number, it is:, number) secret_message = number.to_bytes(37, big) print(secret_message) Or perhaps: (after pip install pyprimes) number = 1402811054100763300785480817886711606823329164566977593890 # wow? import pyprimes.factors print(pyprimes.factors.factorise(number)) [2, 3, 5, 557, 1559, 3413, 6991, 27799, 41333, 52999, 104681, 247001, 992441, 211, 1299689] Irmen -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby... http://www.youtube.com/watch?v=YX3iRjKj7C0 That's an hour-long video; could someone who's watched it give a brief summary? Meanwhile, there's this: http://prog21.dadgum.com/203.html Retiring Python as a Teaching Language tl;dr: he's switched to recommending Javascript as a first language instead of Python, since JS makes it easier to write graphics and games, which is what lots of beginners are interested in now. -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On Wednesday, January 21, 2015 at 11:18:54 AM UTC-8, Grant Edwards wrote: On 2015-01-21, Steven D'Aprano st...@pearwood.info wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. But does he answer the more important question and can we use it to kill PHP?. LOL! Seriously, I did. -- https://mail.python.org/mailman/listinfo/python-list
Re: Trees
Rustom Mody rustompm...@gmail.com writes: Thats not bfs. That's inorder traversal Oops, you're right. How's this: bfs x = go [x] where go [] = [] go (L x:ts) = x:go ts go (B x lst rst:ts) = x : go (ts ++ [lst, rst]) *Main bfs t [6,2,8,1,4,7,9,3,5] -- https://mail.python.org/mailman/listinfo/python-list
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: It took me several months to understand this issue. For the beginning of the story, see: https://code.google.com/p/tulip/issues/detail?id=196 But I think that *this* issue can be closed: UnregisterWaitEx() really do what we need in asyncio. I don't like the complex IocpProactor._unregister() function and _WaitCancelFuture class, but it looks that it's how we are supposed to wait until a wait for a handle is cancelled... Windows IOCP API is much complex that what I expected. It's probably because some parts (especially RegisterWaitForSingleObject()) are implemented with threads in user land, not in the kernel. In short, I'm very happy that have fixed this very complex but also very annoying IOCP bug in asyncio. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 10:19 AM, Anthony Papillion anth...@cajuntechie.org wrote: To be fair, PHP has come a long way in the last few years and, I hear, there's movements within the community to make it better. Namespaces were a bit deal as were a few other things. Personally, while I am LOVING Python, I'd be sad to see PHP die. It's got a lot of potential if the community can get its crap together and take off the ruby coloured glasses. The huge advantage of PHP over other languages is that it comes free with any cheap web host. That's also a huge *dis*advantage when it comes to movements... to make it better, because you can't know when the new version will become sufficiently prevalent to depend on it. I've seen PHP 4 compatibility code in current versions of some big frameworks, although I've no idea whether that implies actual support or just that nobody's removed it yet. But there are a few fundamental problems with PHP, which are derived directly from its philosophies. One of them is that any file in some directory tree is automatically an entry point - specifically, an *executable* entry point. PHP frameworks that accept file uploads have to go to great lengths to ensure that malicious users can't upload code and run it. Every web framework I've seen for Python, Ruby, Pike, etc, has URL routing defined by the application, not the file system, and if you define a readable uploads directory, all you're going to do is allow people to re-download the same file. Even old CGI scripts, where file system presence defined entry points, weren't as bad as PHP - firstly because they were usually restricted to /cgi-bin/ (and you simply wouldn't allow world writing to that directory), and secondly because the scripts had to be marked executable, which PHP scripts don't. Maybe PHP will grow true Unicode support in a future version. Maybe it'll gain a nice object model that compares well to Python's or Ruby's or whichever other you want to look at. Maybe there'll be a complete reworking of string comparisons so that 12e2 is no longer equal to 1200. But I doubt it'll ever shift away from file-system entry points. And that's why I will continue to push people to Python+Flask rather than PHP. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 10:37 AM, Tim Daneliuk tun...@tundraware.com wrote: I find these kinds of discussions sort of silly. Once there is a critical mass of installed base, no language EVER dies. Not sure about that. Back in the 1990s, I wrote most of my code in REXX, either command-line or using a GUI toolkit like VX-REXX. Where's REXX today? Well, let's see. It's still the native-ish language of OS/2. Where's OS/2 today? Left behind. REXX has no Unicode support (it does, however, support DBCS - useful, no?), no inbuilt networking support (there are third-party TCP/IP socket libraries for OS/2 REXX, but I don't know that other REXX implementations have socket services; and that's just basic BSD sockets, no higher-level protocol handling at all), etc, etc. Sure, it's not technically dead... but is anyone developing the language further? I don't think so. Is new REXX code being written? Not a lot. Yet when OS/2 was more popular, REXX definitely had its installed base. It was the one obvious scripting language for any OS/2 program. Languages can definitely die, or at least be so left behind that they may as well be dead. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
In article mailman.17933.1421884677.18130.python-l...@python.org, ros...@gmail.com says... Bad idea. Better to pick a language that makes it easy to get things right, and then work on the fun side with third-party libraries, than to tempt people in with hey look how easy it is to do X and then have them stuck with an inferior or flawed language. Too many people already don't know the difference between UTF-16 and Unicode. Please, educators, don't make it worse. ChrisA Indeed. If games and funnies is what drive beginners into programming, that's fine. But the educational principles of programming shouldn't be trashed in the process. We need serious developers in today's complex application systems. Not uneducated programmers with nary a knowledge of Software Engineering. Besides if games and funnies are the only thing that can drive someone into programming, I'd rather not see that person become a developer. I want to become a programmer so I can make games is, on the vast majority of cases, the quote of someone who will never become a programmer. Why should teachers reward that kind of thought? -- https://mail.python.org/mailman/listinfo/python-list
[issue23293] [Windows] asyncio: race condition related in IocpProactor.connect_pipe()
New submission from STINNER Victor: Currently, IocpProactor.connect_pipe() is implemented with QueueUserWorkItem() which starts a thread that cannot be interrupted. Because of that, this function requires special cases in _register() and close() methods of IocpProactor. While fixing the issue #23095, I saw that IocpProactor.connect_pipe() causes GetQueuedCompletionStatus() returned an unexpected event messages to be logged, but also to hang the test suite. I propose a solution to reimplement IocpProactor.connect_pipe() without a thread: https://code.google.com/p/tulip/issues/detail?id=197 It should fix this issue. -- components: Windows, asyncio messages: 234448 nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: [Windows] asyncio: race condition related in IocpProactor.connect_pipe() versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23293 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Trees
On Tue, Jan 20, 2015 at 6:23 PM, Rustom Mody rustompm...@gmail.com wrote: The Haskell is bullseye¹ in capturing the essense of a tree because conceptually a tree of type t is recursive in the sense that it can contain 2 subtrees -- (B x lst rst) -- or its a base case -- L x. How do you create a tree containing an even number of elements under this constraint? -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On 2015-01-21, Chris Angelico ros...@gmail.com wrote: On Thu, Jan 22, 2015 at 6:18 AM, Grant Edwards invalid@invalid.invalid wrote: On 2015-01-21, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. But does he answer the more important question and can we use it to kill PHP?. PHP won't die so long as there are people willing to apologize for its every flaw and defend it on the basis that huge sites X, Y, and Z all use it. But we don't need it to die. All we need is for Python to live, and we can ignore PHP and write Unicode-aware web sites with simple, trustworthy entry points, and not worry about the rest. I happily ignored PHP until a couple years back when we decided to use PHP for the web site on a small embedded Linux system. The reasoning was that we didn't have any significant internal web site development skills, and using PHP on Linux would make it easy to contract out the web site design using an off-the-shelf light-weight framework. [At the time, a couple of us could stumble around with HTML enough to generate web pages that looked fresh out of 1995, but that was about it. The web pages in our older devices looked rather retro and had pretty limited functionality.] At a certain point we couldn't afford the contractors any longer and somebody had to take over maintenance and development of the web stuff. The JavaScript and jQuery part of it isn't bad. Both have had some thought put into them: they have their quirks but there's a certain internal consistency and elegence. PHP, on the other hand makes me want to scream. It's all just a random mess -- it's nothing _but_ quirks. As one of the contractors once said: PHP is like a combination of all the worst features of bash, perl, and C. I briefly considered trying to switch to Python, but the Python footprint is just too big... -- Grant Edwards grant.b.edwardsYow! RELATIVES!! at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On 01/21/2015 04:35 PM, Chris Angelico wrote: On Thu, Jan 22, 2015 at 6:18 AM, Grant Edwards invalid@invalid.invalid wrote: On 2015-01-21, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. But does he answer the more important question and can we use it to kill PHP?. PHP won't die so long as there are people willing to apologize for its every flaw and defend it on the basis that huge sites X, Y, and Z all use it. But we don't need it to die. All we need is for Python to live, and we can ignore PHP and write Unicode-aware web sites with simple, trustworthy entry points, and not worry about the rest. To be fair, PHP has come a long way in the last few years and, I hear, there's movements within the community to make it better. Namespaces were a bit deal as were a few other things. Personally, while I am LOVING Python, I'd be sad to see PHP die. It's got a lot of potential if the community can get its crap together and take off the ruby coloured glasses. Anthony -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On 01/21/2015 10:34 AM, Steven D'Aprano wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. (No cheering, that sort of attitude is one of the things that killed Smalltalk.) Although Martin discusses Ruby, the lessons could also apply to Python. I find these kinds of discussions sort of silly. Once there is a critical mass of installed base, no language EVER dies. I suspect the real reason Smalltalk sort of got kicked to the curb is because a) It clung to a kind of OO purity that simply is at odds with the practice of programming at large scale and b) It thus never built the aforementioned critical mass. Language adoption at the scale needed to make a real dent doesn't happen because of technical superiority (witness PHP as just one example). It happens because lots of people solve real problems faster than they used to. In fact - outside the language cognoscenti and uber nerd community - I'd argue that Python adoption has little to do with functional programming, lambda, OO, generators, or whatever happens to float your boat. Python got adopted because it made code production faster, and therefore cheaper. Economics matters way more than technology here, I think. I wrote some rambling disquisition on these matters some years ago ... http://www.tundraware.com/TechnicalNotes/Python-Is-Middleware http://www.tundraware.com/TechnicalNotes/How-To-Pick-A-Programming-Language -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: The _UNPACK opcodes are new in this changelist. Yup, but they're used in the other unpacking syntax too: (*(1, 2, 3), *(4, 5, 6)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 6:18 AM, Grant Edwards invalid@invalid.invalid wrote: On 2015-01-21, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. But does he answer the more important question and can we use it to kill PHP?. PHP won't die so long as there are people willing to apologize for its every flaw and defend it on the basis that huge sites X, Y, and Z all use it. But we don't need it to die. All we need is for Python to live, and we can ignore PHP and write Unicode-aware web sites with simple, trustworthy entry points, and not worry about the rest. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
Guido van Rossum added the comment: Congrats with the fix, and thanks for your perseverance! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Check for running DHCP daemon?
So I've got this python 3 script that needs to know if there is a running DHCP daemon (ISC DHCP server) on the local system. Is there a clean way to do this that (1) doesn't require me to do syscalls to local utilities (like ps, top, etc), and (2) doesn't require any custom modules (stock only)? Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Check for running DHCP daemon?
On Thu, Jan 22, 2015 at 10:06 AM, Jason Bailey jbai...@emerytelcom.com wrote: So I've got this python 3 script that needs to know if there is a running DHCP daemon (ISC DHCP server) on the local system. Is there a clean way to do this that (1) doesn't require me to do syscalls to local utilities (like ps, top, etc), and (2) doesn't require any custom modules (stock only)? Not sure why you have these restrictions; normally I'd look at an OS-provided status function (eg /etc/init.d/isc-dhcp-server status, which on my Debian system is implemented by looking for a PID file and confirming with ps). But since DHCP uses port 67, you might be able to use that; I don't know of a way, within your restrictions, to find out if someone's bound to port 67, but you could send a DHCPDISCOVER message to 127:0.0.1:67 and see if you get back an offer. That may not be the best technique, but it could be done with just Python's standard library. (Alternatively, if you're certain the DHCP server is configured appropriately, you could send a DHCPREQUEST message with an inappropriate IP and hope for a rejection.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23295] [Windows] asyncio: add UDP support to ProactorEventLoop
New submission from STINNER Victor: ProactorEventLoop lacks UDP support: create_datagram_endpoint() is not supported. New functions should be added to the _overlapped modul. Example: add maybe WSARecvFrom()? -- components: Windows, asyncio messages: 234456 nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: [Windows] asyncio: add UDP support to ProactorEventLoop versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23295 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On 01/21/2015 04:37 PM, Tim Daneliuk wrote: On 01/21/2015 10:34 AM, Steven D'Aprano wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. (No cheering, that sort of attitude is one of the things that killed Smalltalk.) Although Martin discusses Ruby, the lessons could also apply to Python. I find these kinds of discussions sort of silly. Once there is a critical mass of installed base, no language EVER dies. I suspect the real reason Smalltalk sort of got kicked to the curb is because a) It clung to a kind of OO purity that simply is at odds with the practice of programming at large scale and b) It thus never built the aforementioned critical mass. I suspect Smalltalk lost relevance mainly because it never integrated very well into any computing system. Everything ran in a virtual machine in its own image in isolation as it were. The IDE and the runtime environment were inseparable, and as OS's developed their own environments it just never tried to fit in. It's almost as if Smalltalk was the language, runtime, your program source code, *and* operating system. That's what he meant in his talk about the problem with smalltalk being the image. The only way to distribute your smalltalk programs was to distribute the image file, which was basically a memory dump. When you wanted to list out a smalltalk program you were basically decompiling it to the editor widget. So this integrated nature of smalltalk (source code, editor, live objects, etc) was its most powerful feature, but ultimately its downfall too in my opinion. And at the same time we regularly pine for some of those features. -- https://mail.python.org/mailman/listinfo/python-list
[issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
Claudiu Popa added the comment: Thanks for the tip, Guido. The new patch uses exception chaining. If this needs backporting, most probably the first patch can be used. -- Added file: http://bugs.python.org/file37813/issue22885_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23294] A typo in the tutorial
Changes by aruseni aruseni.mag...@gmail.com: -- assignee: - docs@python components: +Documentation nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture
STINNER Victor added the comment: IocpProactor.close() must not cancel pending _WaitCancelFuture futures FYI I found this bug when running the trollius test suite. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 10:46 AM, Paul Rubin no.email@nospam.invalid wrote: Meanwhile, there's this: http://prog21.dadgum.com/203.html Retiring Python as a Teaching Language tl;dr: he's switched to recommending Javascript as a first language instead of Python, since JS makes it easier to write graphics and games, which is what lots of beginners are interested in now. Bad idea. Better to pick a language that makes it easy to get things right, and then work on the fun side with third-party libraries, than to tempt people in with hey look how easy it is to do X and then have them stuck with an inferior or flawed language. Too many people already don't know the difference between UTF-16 and Unicode. Please, educators, don't make it worse. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Very nice! So what's left besides errors? * Fixing the grammar, ast, and compilation for the list, dict, and set comprehension element unpackings Now the primary problem is giving good errors; I don't know how to make them look like they came from the function call. I'm not sure I want to, either, since these opcodes are used elsewhere. The _UNPACK opcodes are new in this changelist. You can do hg vdiff to give a side-by-side diff or just check in the patch review. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
Grant Edwards invalid@invalid.invalid: [At the time, a couple of us could stumble around with HTML enough to generate web pages that looked fresh out of 1995, but that was about it. The web pages in our older devices looked rather retro and had pretty limited functionality.] I miss that plain old look of web pages. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On Wednesday, January 21, 2015 at 4:10:08 PM UTC-8, Mario Figueiredo wrote: In article mailman.17933.1421884677.18130.python-l...@python.org, ros...@gmail.com says... Bad idea. Better to pick a language that makes it easy to get things right, and then work on the fun side with third-party libraries, than to tempt people in with hey look how easy it is to do X and then have them stuck with an inferior or flawed language. Too many people already don't know the difference between UTF-16 and Unicode. Please, educators, don't make it worse. ChrisA Indeed. If games and funnies is what drive beginners into programming, that's fine. But the educational principles of programming shouldn't be trashed in the process. We need serious developers in today's complex application systems. Not uneducated programmers with nary a knowledge of Software Engineering. Besides if games and funnies are the only thing that can drive someone into programming, I'd rather not see that person become a developer. I want to become a programmer so I can make games is, on the vast majority of cases, the quote of someone who will never become a programmer. Why should teachers reward that kind of thought? I think one of the problems is that most of the people with the I want to become a programmer so I can make games mentality really have no clue at all how much work it takes to produce a game. They just see that Minecraft was made started by just one guy and now he's a billionaire, and they think I want that to happen to me!. They think that just because the game has low-resolution graphics means they could produce something similar in just a couple days, ignoring complexities like rendering optimizations and interaction with the world. Others will pick up Python because everyone tells them its an easy language to learn and then think they're going to make the next Call of Duty or World of Warcraft with it without any knowledge of basic algorithms. They might learn a few from some tutorials, but they'll have no idea how to apply them. They won't be able to make the jump from Here's how to start a TCP server in one window while connecting to it from a client in another window and send chat messages back and forth (essentially a basic implementation of netcat) to creating a game server that sends game state updates to the players. -- https://mail.python.org/mailman/listinfo/python-list
[issue23297] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
R. David Murray added the comment: bytes does support startswith: b'abc'.startswith(b'a') True -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
I don't think that Python is doomed. I *do* think that type-hinting is useful, and Python has borrowed a syntax that is similar to that used in other languages, so that it is a familiar one to many developers. It is a stretch to call it intuitive though, either to write or to read. Personally, I would have favoured a doc string solution. The magic comments that are part of the current proposal are genuinely intuitive, I think. The function definition syntax is something to be learned and which it takes me a little time to process even though I'm getting used to it. I find that it's still a slight effort to remember which way around the name of the argument and the type go. I'm sure I've seen one language that does the oppoosite, and the fraction of a second it takes me to remember is a tiny friction. There's no doubt, too, that long function definitions (Python functions tend to have lots of arguments in the real world) are going to look cluttered, and cluttered by lots of magic punctuation. So useful, yes. Familiar already to those who use other languages, yes. Intuitive, no. And there is a linguistic reason for that: Consider this: Define function add taking price1, price2, print_error equals true. Yes, Python wouldn't understand that, but turning it in to a valid definition requires only a tiny amount of effort. Type definitions add a whole level of complexity: Define function add taking the float price1, the float price2, print_error equals the Boolean true. Make the function return a float. Converting that into python simply requires more effort: in other words the gap between what one might say in speech and what the code looks like is bigger. The reason for this is that a lot of information is being compressed in to a small space. In English writing it is usually clearer to avoid long and complicated sentences with lots of subclauses (even if they make perfect, logical sense) in favour of shorter ones, and I think there is a parallel here. I would have preferred Python to mimic: Define function add taking price1, the price2, print_error equals true. Price1 is a float. Price2 is a float. The function returns a float. But now this is sounding a little like something from Larry Wall, and so I had better stop! I wasn't trying to re-litigate the decisions that have been taken, just to understand the friction. Just my £0.2 Nicholas. -- https://mail.python.org/mailman/listinfo/python-list
[issue14910] argparse: disable abbreviation
Andy Zobro added the comment: This breaks custom actions. e.g.: class dict_action(argparse.Action): def __init__(self, *a, **k): argparse.Action.__init__(self, *a, **k) TypeError: __init__() got an unexpected keyword argument 'allow_abbrev' -- nosy: +xobes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On 01/21/2015 08:30 PM, Steven D'Aprano wrote: So what is this unspeakable, nightmarish, cryptic abomination going to look like? Here's an example from PEP 484: def greeting(name: str) - str: return 'Hello ' + name I don't know about you, but I think anyone who cannot read that and intuit that argument `name` is a string and the return result is also a string There is nothing inherently intuitive about that syntax. The : makes it look like a dictionary (but it isn't) and the - looks like a pointer to something (but it isn't). is probably going to have bigger troubles with Python than just type-hinting. Yup, true -- I do find writing meta-classes takes extra work. ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 22/01/2015 05:56, Chris Angelico wrote: On Thu, Jan 22, 2015 at 4:50 PM, Nicholas Cole nicholas.c...@gmail.com wrote: I would have preferred Python to mimic: Define function add taking price1, the price2, print_error equals true. Price1 is a float. Price2 is a float. The function returns a float. But now this is sounding a little like something from Larry Wall, and so I had better stop! Actually, it sounds like pre-ANSI C. *SCREAMS OUT LOUD* at the thought of the Whitesmith's compiler where IIRC printf was spelt format and the formatting codes weren't the same. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On 22/01/2015 02:11, Rick Johnson wrote: On Wednesday, January 21, 2015 at 10:34:40 AM UTC-6, Steven D'Aprano wrote: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby. (No cheering, that sort of attitude is one of the things that killed Smalltalk.) Although Martin discusses Ruby, the lessons could also apply to Python. Python is already headed towards obscurity. The fall began with the release of Python3000 (from which we might have recovered), but now it seems that GvR intends to drive the final nail in python's coffin with this type hinting crap that will convert Python syntax from a readable pseudo code into a cryptic nightmare. Type hinting violates the very *ESSENCE* of what Python was meant to be, that is: a clean and intuitive syntax. The cleanness of Python is what attracts people to it, and the hook is set when they discover the breadth of the stdlib. If GvR brings this gawd awful type hinting idea to reality, IT'S OVER! Python will be lost forever to history as just another interesting oddity. Time to call up the Robert Ripley estate and request some space in his museum! April 1st already? Or will Python be saved by RickedPython3? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On 01/21/2015 05:36 PM, Chris Angelico wrote: On Thu, Jan 22, 2015 at 11:09 AM, Mario Figueiredo mar...@gmail.com wrote: I want to become a programmer so I can make games is, on the vast majority of cases, the quote of someone who will never become a programmer. Why should teachers reward that kind of thought? How about I want to become a programmer so my brother, 2.5 years older than me, won't be better than me any more? Should that kind of thinking be rewarded? Because that's how I got started. My brother was being taught the basics of programming, I was jealous (being the second child will tend to produce that), and so at six years old, I started learning to code. And then a few years later, I wanted to learn C because my brother didn't know it (we'd both learned BASIC), and since I didn't have a C compiler, I learned 8086 Assembly Language instead, using DEBUG.EXE. Largely out of jealousy. There is a difference between /your/ motivation to learn something, and teachers /pandering/ to such motivations. There's nothing wrong with I want to make games as a personal driving factor, but the educational system should still teach decent programming, not whatever piece of garbage will produce quick results at the expense of long-term productivity. -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Also maybe not in this changelist, but we should consider replacing STORE_MAP and BUILD_MAP with a single opcode BUILD_MAP(n) that produces a dict out of the top n items on the stack just like BUILD_LIST(n) does. What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
Chris Angelico ros...@gmail.com writes: Either you pick up a super-restrictive hey look, you can build a game with just point and click system, which isn't teaching programming at all, or you end up getting bogged down in the massive details of what it takes to write code. Code Hero ran into various obstacles and never got finished, but it was a game whose purpose was to teach the player how to write their own games using Unity3D. I saw some early versions and it seemed pretty accessible. https://en.wikipedia.org/wiki/Code_Hero Heck, there's even a song about learning to program through wanting to write games, and ending up treating programming as a type of spirituality (there was an interview with the songwriter explaining this, but it seems to have gone offline): lyrics: http://www.sccs.swarthmore.edu/users/01/bnewman/songs/lyrics/Code-Goddess.txt mp3: http://www.sccs.swarthmore.edu/users/01/bnewman/songs/music/Code-Goddess.mp3 If someone's unfazed by the it'll take you years before you can actually write a saleable game consideration, Wanting to write games is a completely different topic than wanting to sell them. It's just like any other creative outlet. Most people who teach themselves to juggle do it because juggling is fun, not because they want to join the circus. -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 10:55:27AM +1100, Chris Angelico wrote: Where's REXX today? Still (somehow) alive in neo-Amiga platforms like AmigaOS4.x, MorphOS and AROS. I know that's as good as dead but there are still people writing AREXX glue code. -- vag·a·bond adjective \ˈva-gə-ˌbänd\ a : of, relating to, or characteristic of a wanderer b : leading an unsettled, irresponsible, or disreputable life -- https://mail.python.org/mailman/listinfo/python-list
[issue17776] IDLE Internationalization
Terry J. Reedy added the comment: I answered my Q1 in msg187219: test.test_gettest is currently passing, with no skips, on 2.7 and 3.4 on Win 7. patch.diff: I would rather add the 4 lines of the proposed idle_i18n.py to an existing module, perhaps Bindings.py itself, since that is the first place _ will be used. I think +-60 modules is already too many. The binding of '_' to gettext.gettext conflicts with the somewhat common use of '_' as a dummy identifier. I do not know of any such uses in idlelib, but there might be. There are about 4500 lines in idlelib with '_'; too many to review. Someone should do a more refined search with an re that excludes '_' preceded or followed by an identifier char, to skip '__xyz__' or '_x' or 'y_'. If '_ is used for gettest, a new rule to not otherwise bind '_' should be added the currently non-existent Idle maintainer guide. patch2.tar.gz is not readable by Rietveld, Firefox, IE, or Windows. Patches should be uploaded as plaintext.diff or .patch. Damien: Contributors must submit a signed Contributor Agreement. See https://www.python.org/psf/contrib/ and https://www.python.org/psf/contrib/contrib-form/ (the online form). Please do this even before re-uploading patch2. Receipt and acceptance of a form is acknowledged by addition of an * after Author: nick(real name). -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Trees
On Thursday, January 22, 2015 at 3:57:50 AM UTC+5:30, Paul Rubin wrote: Rustom Mody writes: Thats not bfs. That's inorder traversal Oops, you're right. How's this: bfs x = go [x] where go [] = [] go (L x:ts) = x:go ts go (B x lst rst:ts) = x : go (ts ++ [lst, rst]) *Main bfs t [6,2,8,1,4,7,9,3,5] Yeah thats right. And now you can get the duality between dfs and bfs you were earlier after by replacing the ts ++ [lst,rst] with [lst,rst] ++ ts BTW this is just converting queue to stack; And its neat; and out of reach of those who think only imperatively PS 1. Ive not tried it 2. For n-ary trees its neater 3. In my imaginary language with first-class sets, bags, lists it would be neater still -- https://mail.python.org/mailman/listinfo/python-list
Re: Trees
On Thursday, January 22, 2015 at 4:25:03 AM UTC+5:30, Ian wrote: On Tue, Jan 20, 2015 at 6:23 PM, Rustom Mody wrote: The Haskell is bullseye¹ in capturing the essense of a tree because conceptually a tree of type t is recursive in the sense that it can contain 2 subtrees -- (B x lst rst) -- or its a base case -- L x. How do you create a tree containing an even number of elements under this constraint? Not sure what you are asking... [And a text only group makes discussing pictur-esque things hard] What do you mean by 'element'? Leaf? Internal? Either? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: def median_grouped(data:Iterable[Real], interval:Real=1)-Real: ... Wow, that's really nice. I had heard something about Python type hints but hadn't seen them before. So how does Python's proposed type-hints compared to that used by other languages? The most closely comparable hinting system I can think of is the Erlang Dialyzer: -spec median_grouped(iterable(real())) - real(). median_grouped(Data, Interval) - ... Some more info at: http://learnyousomeerlang.com/types-or-lack-thereof#for-type-junkies http://learnyousomeerlang.com/dialyzer#plt -- https://mail.python.org/mailman/listinfo/python-list
[issue23298] Add ArgumentParser.add_mutually_dependence_group
New submission from dongwm:
Sometimes I need to use argparse like this:
parser = argparse.ArgumentParser(prog='PROG')
group = parser.add_mutually_dependence_group()
group.add_argument('--foo')
group.add_argument('--bar')
parser.parse_args(['--foo', 'f', '--bar', 'b'])
Namespace(bar='b', foo='f')
parser.parse_args(['--foo', 'f'])
PROG: error: --foo dependence on --bar
parser.parse_args(['--bar', 'b'])
PROG: error: --bar dependence on --foo
I have some optional argument. but if any argument in a group was present on
the command line. i need the others must also was present on. so i think
``add_mutually_dependence_group`` does make sense.
--
components: Library (Lib)
files: argparse_lib.patch
keywords: patch
messages: 234475
nosy: bethard, dongwm
priority: normal
severity: normal
status: open
title: Add ArgumentParser.add_mutually_dependence_group
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37814/argparse_lib.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23298
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On 1/21/2015 7:16 PM, Mario Figueiredo wrote: In article 873873ae91@jester.gateway.sonic.net, no.email@nospam.invalid says... Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: In 2009, Robert Martin gave a talk at RailsConf titled What Killed Smalltalk Could Kill Ruby... http://www.youtube.com/watch?v=YX3iRjKj7C0 That's an hour-long video; could someone who's watched it give a brief summary? In a nutshell, he argues, along with Ward Cunningham, that what killed Smalltalk was how easy you could create unclean code with it. Unclean in this context means Smalltalk didn't punish bad software design decisions that would eventually lead into complex code and unmanageable systems with zero options of code maintenance. He followed that by saying that fine-grained test-driven development is the way to prevent unholy messes. He noted that tdd started in smalltalk, but never really took there. Reason 2: arrogance -- the walled garden and disdain for the messy problems of real enterprises. He did not seem as sure about how to counteract this. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[issue23298] Add ArgumentParser.add_mutually_dependence_group
Changes by dongwm ciici...@gmail.com: Added file: http://bugs.python.org/file37816/argparse_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Thu, Jan 22, 2015 at 4:50 PM, Nicholas Cole nicholas.c...@gmail.com wrote:
I would have preferred Python to mimic:
Define function add taking price1, the price2, print_error equals true.
Price1 is a float. Price2 is a float. The function returns a float.
But now this is sounding a little like something from Larry Wall, and so I
had better stop!
Actually, it sounds like pre-ANSI C. Something like this:
float add(price1, price2)
float price1;
float price2;
{
... body of function ...
}
Compare the more modern C style:
float add(float price1, float price2)
{
... body of function ...
}
(I omitted print_error from both as I don't know how pre-ANSI C did
default arguments, if at all. It's possible in the modern version but
I want the comparison to be fair.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Paul Rubin no.email@nospam.invalid writes: -spec median_grouped(iterable(real())) - real(). Oops: -spec median_grouped(iterable(real()), real()) - real(). -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 22/01/2015 05:35, Paul Rubin wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: def median_grouped(data:Iterable[Real], interval:Real=1)-Real: ... Wow, that's really nice. I had heard something about Python type hints but hadn't seen them before. Currently flying here http://code.activestate.com/lists/python-ideas/30922/ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
[issue14910] argparse: disable abbreviation
Andy Zobro added the comment: Ignore previous comment, I wish I could delete it. I simply provided the allow_abbrev to the wrong function and spent zero time investigating the error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python is DOOMED! Again!
On Wednesday, January 21, 2015 at 10:31:12 PM UTC-6, Steven D'Aprano wrote: Occasionally you find people spreading Fear, Uncertainty, Doubt about Python. Python is now over 20 years old and one of the most popular languages in the world no matter how you measure popularity: What's next, are you going to drool over the TIOBE index again? I can't help but giggle when folks put faith in crap like that. You wanna know why python-list gets so much spam? Because Guido-bot is attempting to improve Python's TIOBE rating. so you don't often get FUD these days. When you do, it's usually about whitespace, or Python is too slow, or occasionally Python 3 is killing Python, but the latest FUD is about PEP 484 and type-hinting: Yeah because people *NEVER* complain when they have *REAL* problems, do they Mr DeWaldo? So what is this unspeakable, nightmarish, cryptic abomination going to look like? Here's an example from PEP 484: def greeting(name: str) - str: return 'Hello ' + name I don't know about you, but I think anyone who cannot read that and intuit that argument `name` is a string and the return result is also a string is probably going to have bigger troubles with Python than just type-hinting. Remember too that type-hinting will *absolutely* remain *completely* optional for Python. Developers can choose to use it or not, But they cannot choose whether to *READ* it or not. Once it's out there, it's out there, and everyone who has to maintain code or read tutorials will have to suffer reading noise they did not choose to write. This is not a self- inflicted wound Steven, this is assault with a noisy weapon! they can mix hinted code with regular unhinted code, they can use type declarations purely as documentation or they can run an optional type-checker, as they choose. The only thing worse than a bad idea is an inconsistent bad idea! Here's a potential real-world example, from the statistics module in Python 3.4, before and after adding annotations: def median_grouped(data, interval=1): ... def median_grouped(data:Iterable[Real], interval:Real=1)-Real: ... Nice! I like how the first toy example was less noisy, and then way down here you show us the real butt-uglyness of this feature from hell! I think it is clear that Python's annotation syntax remains quite close to executable pseudo-code. Sure, for some perverted definition of quite and close! Fears that type-hints will doom Python are not credible. Listen, there is a way that type hints can be introduced *WITHOUT* forcing folks who don't care about them to read them. If Mr Van Rossom would like my assistance, tell him to send me a private email or ask me in this thread. However, if he refuses and continues down this road to perdition, i will be unable to help him save the Python language, and all his work will have been for nothing. For the sake of this community and the many noobs who have not found programming bliss via Python, i implore you to do everything in your power to convince GvR that he is making a grave mistake, for which no recovery will be possible. -- https://mail.python.org/mailman/listinfo/python-list
[issue23296] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
Changes by Benjamin Peterson benja...@python.org: -- resolution: - duplicate status: open - closed superseder: - ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to wow someone new to Python
Alan Bawden wrote: Alan Bawden a...@scooby-doo.csail.mit.edu writes: ... Score one for untyped languages. Drat. I should have writted dynamically typed languages. The language has changed. When I was a novice Lisp hacker, we were comfortable saying that Lisp was untyped. But nowadays we always say that Lisp is dynamically typed. I could write an essay about why... I've always understood that strictly speaking, untyped refers to low-level languages like assembly or Forth, where everything is a machine word. In Forth, for example, all commands operate on single words on the stack, except for double variants which operate on two words at a time. E.g. you might have FOO to operate on the word at the top of the stack and FOOD to operate on the top two words. (Actually, given Forth's reputation for cryptic single-character line noise, it would probably be '^ and ''^ or something :-) In any case, there's a single stack, and double quantities aren't a separate data type, they're just two words. (Some versions of Forth are arguably typed, in that they have a separate stack for floating point.) I sometimes also use untyped to refer to languages like Hypertalk where everything is a string. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
[issue23298] Add ArgumentParser.add_mutually_dependence_group
Changes by dongwm ciici...@gmail.com: Added file: http://bugs.python.org/file37815/argparse_doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 11:09 AM, Mario Figueiredo mar...@gmail.com wrote: I want to become a programmer so I can make games is, on the vast majority of cases, the quote of someone who will never become a programmer. Why should teachers reward that kind of thought? How about I want to become a programmer so my brother, 2.5 years older than me, won't be better than me any more? Should that kind of thinking be rewarded? Because that's how I got started. My brother was being taught the basics of programming, I was jealous (being the second child will tend to produce that), and so at six years old, I started learning to code. And then a few years later, I wanted to learn C because my brother didn't know it (we'd both learned BASIC), and since I didn't have a C compiler, I learned 8086 Assembly Language instead, using DEBUG.EXE. Largely out of jealousy. I hope I've gained a little maturity since then... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue23294] A typo in the tutorial
Eric V. Smith added the comment: What's the typo? I'm not seeing it. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 12:38 PM, Paul Rubin no.email@nospam.invalid wrote: Mario Figueiredo mar...@gmail.com writes: I want to become a programmer so I can make games is, on the vast majority of cases, the quote of someone who will never become a programmer. Why should teachers reward that kind of thought? I don't see what the problem is. Kids are interested in games and they are into playing them, so of course they also want to program them. It's not a terrible justification for getting into programming. But writing games is (almost always) a terrible way to start programming. Either you pick up a super-restrictive hey look, you can build a game with just point and click system, which isn't teaching programming at all, or you end up getting bogged down in the massive details of what it takes to write code. If someone's unfazed by the it'll take you years before you can actually write a saleable game consideration, then getting into programming via toys (writing Fizz Buzz or a factorial calculator) will put him/her on a much better footing for actual coding work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Check for running DHCP daemon?
On Wed, Jan 21, 2015 at 3:06 PM, Jason Bailey jbai...@emerytelcom.com wrote: So I've got this python 3 script that needs to know if there is a running DHCP daemon (ISC DHCP server) on the local system. Is there a clean way to do this that (1) doesn't require me to do syscalls to local utilities (like ps, top, etc), and (2) doesn't require any custom modules (stock only)? The subprocess module is quite clean on *ix. Don't let the subprocess mess on Windows steer you away from it on *ix. And don't let the subprocesses are bad from the perl community misguide you either - shell is fast today because it's highly parallel, because it's unafraid of subprocesses. You could open the files under /proc and look around, if you're on Linux. But parsing ps -eo whatever would probably be cleaner. A syscall is an interaction with a kernel. I think you meant an os.system() call. -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Joshua Landau added the comment: According to the standard, int can be only 16 bits long so that only leaves 255/255. However, if the offset is on top of the dictionary count, this is easily enough to clear the limits for the maximum function size (worst case is a merge of 255 dicts with an offset of 1 or a merge of 2 dicts with an offset of 254). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
On Thu, Jan 22, 2015 at 1:59 PM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: To my mind, what killed REXX is that most operating systems just don't support its key feature well: ADDRESS targets! When the only target turns ADDRESS into the equivalent of os.system() (or some variant of popen() ) it just loses too much. Besides the original mainframe implementation, I have a feeling only ARexx managed to maintain the spirit of REXX -- and that may have been as it was so easy to extend the native AmigaOS message passing IPC to create ARexx ports letting processes truly communicate interactively. Very good point. I can count the instances where ADDRESS could be used for something else on the fingers of one hand... and one of them was a MUD server that I wrote myself, and which nobody else ever used. And it would have done better to use SAY rather than ADDRESS; it's kinda cute, but not very practical, to have something like this: /* code file for implementing, say, the 'search' command */ if arg(1) = haystack then do You find a needle in the haystack! It is long, sharp, and made of metal. call move_object create_object(needle), caller end else You find nothing of interest. Each quoted string got sent to the client as a line of text. Yeah, nice, but there are plenty of other ways to do it. (The main coolness of this system was that I could update the REXX code without restarting the server, which was pretty handy.) Other than that, it's really not a well-used feature. Oh, what might have been... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: You're right. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What killed Smalltalk could kill Python
Mario Figueiredo wrote: In article mailman.17933.1421884677.18130.python-l...@python.org, ros...@gmail.com says... Bad idea. Better to pick a language that makes it easy to get things right, and then work on the fun side with third-party libraries, than to tempt people in with hey look how easy it is to do X and then have them stuck with an inferior or flawed language. Too many people already don't know the difference between UTF-16 and Unicode. Please, educators, don't make it worse. ChrisA Indeed. If games and funnies is what drive beginners into programming, that's fine. But the educational principles of programming shouldn't be trashed in the process. We need serious developers in today's complex application systems. Sure, but are they the *only* kinds of programmers that we need? Isn't there room in the world for an open-source developer who creates Firefox plug-ins, sys admins who write shell-scripts, cubical workers who write Excel worksheets, etc? Why shouldn't my Aunt Tilly write a mobile phone app to manage her cheesecake recipes just the way she likes? http://livecode.com/ Programming games is hard. Arguably, it's *much* harder than most beginners can deal with, unless you start with a specialist language designed with game-related primitives: http://scratch.mit.edu/ Even text based games are hard, and arguably need their own specialist language: http://inform7.com/ Modern games *are* part of today's complex application systems, and games developers may need the same skills used by serious developers: - project management - testing - change control - release management - documentation - networking - user authentication etc. I'd further argue that many games developers have to know *more* that the typical developer. As a Python programmer, I don't have to manage memory, but many games devs are often programming down close to the metal and do need to care about the sort of low-level issues (memory, graphics, network latency) that I only have the fuzziest concept of. You don't write a high-performance 3D physics engine in Python. (At least not yet.) Not uneducated programmers with nary a knowledge of Software Engineering. Besides if games and funnies are the only thing that can drive someone into programming, I'd rather not see that person become a developer. That's a terribly judgemental and rather arrogant statement. If people have a passion for mathematics, and that leads them to take up programming and invent Mathematica, would you say the world would have been better off if they never became a programmer? What we need is more programmers with a passion for their job, and if that means learning to write games, then so be it. One of the problems with 9 to 5 code monkeys is that programming is just a job for them. They do the absolute minimum they need to keep their job. They don't program for fun, or to learn new skills, or to solve problems. They go to user groups and forums like here only when they have a question they want answered, they take and take and take and they never give back. I'd rather teach somebody passionate about writing games than somebody apathetic about programming, and I'd rather the games person became a programmer. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
Mario Figueiredo mar...@gmail.com writes: I want to become a programmer so I can make games is, on the vast majority of cases, the quote of someone who will never become a programmer. Why should teachers reward that kind of thought? I don't see what the problem is. Kids are interested in games and they are into playing them, so of course they also want to program them. -- https://mail.python.org/mailman/listinfo/python-list
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: I am a huge fan of giving good errors. Looks good to me. Will we need to make sure that the call helper function we worked on produces additional BUILD_MAP_UNPACK opcodes every 256 dictionaries just in case? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Neil Girdhar added the comment: Another option to consider is to just use a bit on the BUILD_MAP_UNPACK and then have a stack marking opcode at the function call (not sure what to call it, but say FUNCTION_CALL_MARK) The advantage would be you don't store or calculate relative stack positions. When the interpreter sees the mark, it stores the function call address for use in BUILD_MAP_UNPACK errors. Although I guess you have 24 bits to store the relative stack position? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
