tkMessageBox dialog help
Hi,
I've been testing the standard dialog boxes in tkMessageBox under IDLE.
If I type for example, tkMessageBox.askyesno('test', 'test'), the dialog box
comes up fine but another window also appears. I'm guessing this is the
parent window of the message box. If I click on either of the yes/no
buttons, i get a True/False on the std out and the dialog box closes but the
parent window remains and seems to hang. This is on WinXP by the way. Is
this normal behaviour? How do I get the dialog box appearing without the
parent window or is this not possible?
Thanks,
Nathan.
--
http://mail.python.org/mailman/listinfo/python-list
FPE: Add bindings to exception tracebacks.
Hi folks! Throughout my python development career, I've occasionally made various developer tools to show more information about assertions or exceptions with less hassle to the programmer. Until now, these tools didn't pass a utility vs pain-to-use threshold. Now I've created a tool I believe to have passed that threshold, which I call "binding annotated exception tracebacks". In short, this tool adds text showing relevant local bindings to each level in a stack trace print out. I consider it to be so useful that it should be part of the standard library. I'm not sure the best process to propose this (shall I make a PEP? -is this already an FPE?), so I thought I'd start with a published early/often patch, then point people to it. I've submitted a patch against the 2.6 head on the sf tracker as ticket 1654974, or try this url: http://sourceforge.net/tracker/index.php?func=detail&aid=1654974&group_id=5470&atid=305470 The patch modifies the traceback module. It's also entirely reasonable to have this functionality in a new, separate module (and also it may be implemented in earlier python versions), but for my personal build I wanted all programs to use this new feature. Here's an example to clarify. Consider the following script: #! /usr/bin/env python2.6 import sys import traceback # Install annotated exception printing: sys.excepthook = lambda t, v, b: traceback.print_exception(t, v, b, annotate=True) def f(c): d = 2*c return g(c) def g(x): return (lambda z: z+'foo')(x) f(42) -The output (with the patch of course) is: Traceback (most recent call last): File "/home/n/tmp/demo-bindann.py", line 16, in # With bindings: # f = # Source: f(42) File "/home/n/tmp/demo-bindann.py", line 11, in f # With bindings: c = 42 # g = # Source: return g(c) File "/home/n/tmp/demo-bindann.py", line 14, in g # With bindings: x = 42 # Source: return (lambda z: z+'foo')(x) File "/home/n/tmp/demo-bindann.py", line 14, in # With bindings: z = 42 # Source: return (lambda z: z+'foo')(x) TypeError: unsupported operand type(s) for +: 'int' and 'str' -- http://mail.python.org/mailman/listinfo/python-list
Re: Checking for EOF in stream
On 2/20/07, Nathan <[EMAIL PROTECTED]> wrote: > On 2/19/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > > En Mon, 19 Feb 2007 21:50:11 -0300, GiBo <[EMAIL PROTECTED]> escribió: > > > > > Grant Edwards wrote: > > >> On 2007-02-19, GiBo <[EMAIL PROTECTED]> wrote: > > >>> > > >>> Classic situation - I have to process an input stream of unknown length > > >>> until a I reach its end (EOF, End Of File). How do I check for EOF? The > > >>> input stream can be anything from opened file through sys.stdin to a > > >>> network socket. And it's binary and potentially huge (gigabytes), thus > > >>> "for line in stream.readlines()" isn't really a way to go. > > >>> > > >>> For now I have roughly: > > >>> > > >>> stream = sys.stdin > > >>> while True: > > >>> data = stream.read(1024) > > >> if len(data) == 0: > > >> break #EOF > > >>> process_data(data) > > > > > > Right, not a big difference though. Isn't there a cleaner / more > > > intuitive way? Like using some wrapper objects around the streams or > > > something? > > > > Read the documentation... For a true file object: > > read([size]) ... An empty string is returned when EOF is encountered > > immediately. > > All the other "file-like" objects (like StringIO, socket.makefile, etc) > > maintain this behavior. > > So this is the way to check for EOF. If you don't like how it was spelled, > > try this: > > > >if data=="": break > > > > If your data is made of lines of text, you can use the file as its own > > iterator, yielding lines: > > > > for line in stream: > > process_line(line) > > > > -- > > Gabriel Genellina > > > > -- > > http://mail.python.org/mailman/listinfo/python-list > > > > Not to beat a dead horse, but I often do this: > > data = f.read(bufsize): > while data: > # ... process data. > data = f.read(bufsize) > > > -The only annoying bit it the duplicated line. I find I often follow > this pattern, and I realize python doesn't plan to have any sort of > do-while construct, but even still I prefer this idiom. What's the > concensus here? > > What about creating a standard binary-file iterator: > > def blocks_of(infile, bufsize = 1024): > data = infile.read(bufsize) > if data: > yield data > > > -the use would look like this: > > for block in blocks_of(myfile, bufsize = 2**16): > process_data(block) # len(block) <= bufsize... > (ahem), make that iterator something that works, like: def blocks_of(infile, bufsize = 1024): data = infile.read(bufsize) while data: yield data data = infile.read(bufsize) -- http://mail.python.org/mailman/listinfo/python-list
Re: Checking for EOF in stream
On 2/19/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Mon, 19 Feb 2007 21:50:11 -0300, GiBo <[EMAIL PROTECTED]> escribió: > > > Grant Edwards wrote: > >> On 2007-02-19, GiBo <[EMAIL PROTECTED]> wrote: > >>> > >>> Classic situation - I have to process an input stream of unknown length > >>> until a I reach its end (EOF, End Of File). How do I check for EOF? The > >>> input stream can be anything from opened file through sys.stdin to a > >>> network socket. And it's binary and potentially huge (gigabytes), thus > >>> "for line in stream.readlines()" isn't really a way to go. > >>> > >>> For now I have roughly: > >>> > >>> stream = sys.stdin > >>> while True: > >>> data = stream.read(1024) > >> if len(data) == 0: > >> break #EOF > >>> process_data(data) > > > > Right, not a big difference though. Isn't there a cleaner / more > > intuitive way? Like using some wrapper objects around the streams or > > something? > > Read the documentation... For a true file object: > read([size]) ... An empty string is returned when EOF is encountered > immediately. > All the other "file-like" objects (like StringIO, socket.makefile, etc) > maintain this behavior. > So this is the way to check for EOF. If you don't like how it was spelled, > try this: > >if data=="": break > > If your data is made of lines of text, you can use the file as its own > iterator, yielding lines: > > for line in stream: > process_line(line) > > -- > Gabriel Genellina > > -- > http://mail.python.org/mailman/listinfo/python-list > Not to beat a dead horse, but I often do this: data = f.read(bufsize): while data: # ... process data. data = f.read(bufsize) -The only annoying bit it the duplicated line. I find I often follow this pattern, and I realize python doesn't plan to have any sort of do-while construct, but even still I prefer this idiom. What's the concensus here? What about creating a standard binary-file iterator: def blocks_of(infile, bufsize = 1024): data = infile.read(bufsize) if data: yield data -the use would look like this: for block in blocks_of(myfile, bufsize = 2**16): process_data(block) # len(block) <= bufsize... -- http://mail.python.org/mailman/listinfo/python-list
netCDF4 usage issues
I am having issues correctly implementing the multi-file read
functionality in the Python module netCDF4 (whitaker -
http://code.google.com/p/netcdf4-python/). I am a relative beginner
to Python, so I may be missing something simple. I've done my best to
follow the example in the documentation at the website referenced
above (reprinted):
>>> from netCDF4 import MFDataset
>>> f = MFDataset('mftest*nc')
>>> print f.variables['x'][:]
[ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
23 24
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
48 49
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
73 74
75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
98 99]
>>>
Where I attempt to follow the same flow, I don't get the full data set
returned. I only get a data set for the first file in my list (see
notes in the code below).
>from netCDF4 import MFDataset
>f = MFDataset('E*nc') # All files I want to read are .nc files in a single
>directory, each file starting with E
>temp = f.variables['TEMP'][:]
>temp.shape
Out[17]: (8940, 150) #This is the exact shape of the TEMP variables
array in the first file I need to read verified by an external netCDF
reader application
>f.file_format #There are two files I am trying to read in this example
Out[33]: ['NETCDF3_CLASSIC', 'NETCDF3_CLASSIC']
Does the module only support netcdf4 files? If so, why is it getting
data out of one of the files? I'm unsure how to trouble shoot this.
Any suggestions would be appreciated. If this should be posted
elsewhere, please direct me to another list/forum as I didn't find any
directly related to netCDF or this specific netCDF module. Thank you!
--
http://mail.python.org/mailman/listinfo/python-list
numpy array merge
Is there an easy way to merge two numpy arrays with different rank sizes (terminology?). I want to make a single array by concatenating two arrays along a given direction and filling the excess cells with a dummy variable. numpy concatenate works well as long as the two arrays have the same dimension, but I want to do this on two array with a matching dimension size. An example: import numpy as np a = np.array([[1,2,3],[4,5,6]]) b = np.array([[1,2],[3,4],[5,6]]) np.concatenate((a,a),axis=1) #This works fine, but isn't what I need. Out: array([[1, 2, 3, 1, 2, 3], [4, 5, 6, 4, 5, 6]]) np.concatenate((a,b),axis=1) #This doesn't work, but this is what I need. I want to fill the third row of array "a" with a dummy variable (9 or NaN) and concatenate with "b" to make: [1,2,3,1,2] [4,5,6,4,5] [9,9,9,5,6] This just seems like it would be relatively common. So I thought I'd check if I'm missing something before I go write the logic. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Fwd: Programming Issues
-- Forwarded message -- From: Nathan Spicer Date: Tue, Sep 18, 2012 at 8:32 PM Subject: Programming Issues To: [email protected] Hello, My name is Nathan Spicer. I'm taking a computer programming class using python. I have a project that's due in a week and I'm not certain how to d this. I'm totally new to this form of programming. I've stated the scope of the project below. Any form of help would be great. Ask the user for the amount of change expressed in cents. Your program must compute and display the number of half-dollars, quarters, dimes, nickels, and pennies to be returned. Return as many half-dollars as possible, then quarters, dimes, nickels, and pennies, in that order. Your program must allow the user to continue entering different amounts of change until they enter 0 to indicate they are finished. If the user enters a negative number, inform them of their mistake and ask them to enter a correct value. -Code that is formatted to be easy to read Thank you for your time, Nathan Spicer -- http://mail.python.org/mailman/listinfo/python-list
Constraints -//- first release -//- Flexible abstract class based validation for attributes, functions and code blocks
PyPi name: constraintslib (you'll be dissapointed if you get
constraints by accident)
Docs: http://packages.python.org/constraintslib/
Github: https://github.com/nathan-rice/Constraints
>From the docs:
Constraints - Sleek contract-style validation tools
===
Constraints provides flexible validation tools for a variety of circumstances.
All validation in constraints is done by type checking. Constraints provides
a special abstract base class (Constraints) which facilitates on the fly
construction of validation types. Constraints also provides a special class
(Symbol) which can be used to generate natural, easy to read
constraint expressions.
for example::
>>> from constraints.proxy import Symbol
>>> from constraints.constraints import Constraints
>>> X = Symbol()
>>> SizeConstraint = Constraints(X * 2 + 1 >= 5)
>>> ModuloConstraint = Constraints(X % 2 != 0, X != 3)
>>> CharacterConstraint = Constraints(X[-1] == "h")
# My apologies for the lambda spam. I provide some functions in
# constraints.util for this purpose...
>>> callable_expr = lambda x: all(lambda x: isinstance(x, SizeConstraint), x)
>>> CollectionConstraint = Constraint(callable_expr)
>>> isinstance(1, SizeConstraint)
False
>>> isinstance(2, SizeConstraint)
True
>>> isinstance(1, ModuloConstraint)
True
>>> isinstance("blah", CharacterConstraint)
True
>>> isinstance([2, 3, 4, 5], CollectionConstraint)
True
Constraint instances also provide descriptors which will verify values at set
time. For example::
>>> class Foo(object):
...x = Constraints(X > 2)
...
>>> bar = Foo()
>>> bar.x = 1
Traceback (most recent call last):
...
AssertionError: Specified value (1) does not satisfy this constraint
Design by contract style preconditions, postconditions and invariants are also
supported, and can be used either as context managers or function decorators::
>>> x_pre = SizeConstraint.precondition("x")
>>> x_post = SizeConstraint.postcondition("x")
>>> x = 1
>>> with x_pre:
... do_stuff()
...
Traceback (most recent call last):
...
AssertionError: The value (1) did not meet the specified pre-condition
>>> x = 5
>>> with x_post:
... x -= 4
...
Traceback (most recent call last):
...
AssertionError: The value (1) did not meet the specified post-condition
>>> @x_pre
... def foo(x):
...return x
...
>>> foo(1)
Traceback (most recent call last):
...
AssertionError: The value (1) did not meet the specified pre-condition
>>> @x_post
... def foo(x):
...return x - 5
...
>>> foo(6)
Traceback (most recent call last):
...
AssertionError: The value (1) did not meet the specified post-condition
Symbol objects are very flexible, and provide a nice
way to specify your constraints without resorting to a domain specific language.
Symbol objects are fairly simple; whenever an operation is performed on them,
they capture it and return a new Symbol object wrapping the operation so that
it can be performed with concrete input at a later time. There are exceptions
to this, for example isinstance, which uses the metaclass method, and the type
constructors (str, int, bool, etc) which throw an error if the correct type is
not returned.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Constraints -//- first release -//- Flexible abstract class based validation for attributes, functions and code blocks
On Thu, Jan 26, 2012 at 2:51 PM, Devin Jeanpierre wrote: > Ooh, runtime turing-complete dependent-types. :) > > I'm not sure if you're aware of the literature on this sort of thing. > It's nice reading. A library such as this that's designed for it could > be used for static checks as well. Actually, that is kind of the direction I was going :) One of the nice things about Haskell is that the language is designed in a way that is conducive to proving things about your code. A side benefit of being able to prove things about your code is that in some cases you will be able to derive code just from well crafted specifications (like higher order Prolog). This isn't a game changer yet, but with advances in theorem proving software and a thoughtful language ontology, I could see it taking off very soon. Dijkstra was focused primarily on this area for the last 25 years of his life. > Probably deserves a better name than "constraintslib", that makes one > think of constraint satisfaction. As you can probably tell from my other projects, I'm bad at coming up with snappy names. > Any way to get them to raise a different error, such as ValueError (in > particular for preconditions)? Currently, no. I would like to add an event mechanism, or some kind of function hooks (ala Enthought Traits but much lighter). I'm sure I'll come up with something soon :) Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Constraints -//- first release -//- Flexible abstract class based validation for attributes, functions and code blocks
> May I suggest a look at languages such as ATS and Epigram? They use > types that constrain values specifically to prove things about your > program. Haskell is a step, but as far as proving goes, it's less > powerful than it could be. ATS allows you to, at compile-time, declare > that isinstance(x, 0 <= Symbol() < len(L)) for some list L. So it > might align well with your ideas. Thanks for the tip. >>> Probably deserves a better name than "constraintslib", that makes one >>> think of constraint satisfaction. >> >> As you can probably tell from my other projects, I'm bad at coming up >> with snappy names. > > I'm bad at doing research on previous projects ;) I guess I'm not plugging my other projects enough... You should check out elementwise. Thanks, Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: SnakeScript? (CoffeeScript for Python)
>> Mm I don't think it's what the OP is asking (unless I misunderstood...).
>> I think he wants to compile some syntax TO Python.
>> But I don't really see why you would something like this (if not for fun).
>
> Maybe because you think that Python syntax could be improved upon --
> for instance, Python with pattern-matching would be freaking awesome
> -- but at the same time you want to leverage Python's extensive
> ecosystem of libraries. So instead of creating your own brand-new
> language with no third party libraries whatsoever, you create one that
> just compiles down to regular Python.
You can generalize the dictionary based dispatch used for "case"
statements to do this. The main downsides are:
1.) You have to define your functions ahead of time or use lambdas
2.) The syntax is not quite as nice as it could be (e.g.)
foo = DispatchDict({
Pattern1: f1,
Pattern2: f2,
etc...
})
Reminds me more of javascript than I would like.
>> Then how are you going to maintain the code? Maintain the compiled
>> code or the source?
>
> As with all compiled software, you maintain the input, not the output.
I think maintaining the output can be valuable. There are going to be
things that can be expressed in the more verbose expanded form that
will not be easily expressible in the terse pre-translated macro.
Unfortunately, most macro writers don't put much time into making sure
their macro produces concise code.
>> And proving that your translator is always correct
>
> That's what unit tests are for.
I have a love hate affair with unit tests. You need them, but I'd
really rather analytically prove that my software is correct under
some set of assumptions.
Cheers,
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
Looking for PyPi 2.0...
As a user: * Finding the right module in PyPi is a pain because there is limited, low quality semantic information, and there is no code indexing. * I have to install the module to examine it; I don't need to look at docs all the time, sometimes I just want a package/class/function/method breakdown. * Given the previous point, having in-line documentation would be nice (for instance, just the output of .. automodule::) * Package usage/modification stats are not well exposed * No code metrics are available * I would like some kind of social service integration, for tagging and +1/likes. I know ratings were scrapped (and they weren't that useful anyhow), but for example, if Armin Ronacher or Robert Kern thumbs up a module there is a pretty good chance I will be interested in it. As a developer: * I don't want to have to maintain my code repository and my package releases separately. I want to let module repository know that my code repository exists, and that branches tagged as "release" should be made available. * I want to maintain one README. I don't like "someone needs to do this now" type posts but every time I use PyPi it infuratiates me. I usually end up finding modules via Stack Overflow, which seems silly to me. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict
> Turn the question around: why should there be? > Python is intentionally parsimonious in adding builtins. For the same reason there are frozensets? I put dicts in sets all the time. I just tuple the items, but that means you have to re-dict it on the way out to do anything useful with it. I am too lazy to write a frozendict or import one, but I would use it if it was a builtin. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict
On Thu, Feb 9, 2012 at 5:33 AM, Duncan Booth wrote: > Nathan Rice wrote: > >> I put dicts in sets all the time. I just tuple the items, but that >> means you have to re-dict it on the way out to do anything useful with >> it. I am too lazy to write a frozendict or import one, but I would >> use it if it was a builtin. >> > I hope you sort the items before putting them in a tuple, otherwise how do > you handle two identical dicts that return their items in a different > order? Two dicts created from the same inputs will return items in the same arbitrary order. As long as you don't insert or delete a key you're fine. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict
>> Two dicts created from the same inputs will return items in the same
>> arbitrary order. As long as you don't insert or delete a key you're
>> fine.
>>
> Two dicts that contain the same keys and values may or may not return them
> in the same order:
>
>>>> dict.fromkeys('ia')
> {'i': None, 'a': None}
>>>> dict.fromkeys('ai')
> {'a': None, 'i': None}
>
> Would your system count those two dicts as the same?
>
> If the sequence in which the keys were added to the dict (and deleted if
> appropriate) is exactly the same then it is likely but still not guaranteed
> that they will have the same order. The only ordering guarantee is that
> within a single dict keys and values will appear in a consistent order so
> long as you don't add/delete keys between calls.
As I said, two dictionaries created from the same input will be the
same... 'ai' != 'ia'. If I need to hash a dict that I don't know was
created in a deterministic order, I'd frozenset(thedict.items()).
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
Re: frozendict
On Thu, Feb 9, 2012 at 11:35 AM, Ian Kelly wrote: > On Thu, Feb 9, 2012 at 8:19 AM, Nathan Rice > wrote: >> As I said, two dictionaries created from the same input will be the >> same... > > That's an implementation detail, not a guarantee. It will hold for > current versions of CPython but not necessarily for other Python > implementations. That is true. The implications of the function that creates dictionaries being non-deterministic are a little scary though, so I suspect that it will hold :) Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict
On Thu, Feb 9, 2012 at 8:24 PM, Steven D'Aprano wrote: > On Thu, 09 Feb 2012 09:35:52 -0700, Ian Kelly wrote: > >> On Thu, Feb 9, 2012 at 8:19 AM, Nathan Rice >> wrote: >>> As I said, two dictionaries created from the same input will be the >>> same... >> >> That's an implementation detail, not a guarantee. It will hold for >> current versions of CPython but not necessarily for other Python >> implementations. > > That day may be sooner than you think. It is very likely that in Python > 3.3, dict order will be randomized on creation as a side-effect of adding > a random salt to hashes to prevent a serious vulnerability in dicts. > > http://securitytracker.com/id/1026478 > > http://bugs.python.org/issue13703 > > > If there is anyone still assuming that dicts have a predictable order, > they're going to be in for a nasty surprise one of these days. The only thing needed to avoid the hash collision is that your hash function is not not 100% predictable just by looking at the python source code. I don't see why every dict would have to be created differently. I would think having the most ubiquitous data structure in your language be more predictable would be a priority. Oh well Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict
On Fri, Feb 10, 2012 at 5:08 AM, Chris Angelico wrote: > On Fri, Feb 10, 2012 at 1:30 PM, Nathan Rice > wrote: >> The only thing needed to avoid the hash collision is that your hash >> function is not not 100% predictable just by looking at the python >> source code. I don't see why every dict would have to be created >> differently. I would think having the most ubiquitous data structure >> in your language be more predictable would be a priority. Oh well > > It's perfectly predictable. If you put a series of keys into it, you > get those same keys back. Nobody ever promised anything about order. > > If your hash function is not 100% predictable, that means it varies on > the basis of something that isn't part of either the Python > interpreter or the script being run. That means that, from one > execution to another of the exact same code, the results could be > different. The keys will come out in different orders. I think having a hash function that is not referentially transparent is a bad thing. Basing your language on a non-deterministic function? Yeah... A type factory that produces the dict type on interpreter initialization (or, replaces the hash function, rather), and uses time/system information/etc would solve the problem, while limiting the introduced non-determinism. I don't care if the order of iteration for keys is different from interpreter run to run. I have used frozenset(mydict.items()) when my requirements dictated. It is a minor performance hit. Lets also not forget that knowing an object is immutable lets you do a lot of optimizations; it can be inlined, it is safe to convert to a contiguous block of memory and stuff in cache, etc. If you know the input to a function is guaranteed to be frozen you can just go crazy. Being able to freeze(anyobject) seems like a pretty clear win. Whether or not it is pythonic is debatable. I'd argue if the meaning of pythonic in some context is limiting, we should consider updating the term rather than being dogmatic. Just my 2 cents... Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: frozendict
>> Lets also not forget that knowing an object is immutable lets you do a >> lot of optimizations; it can be inlined, it is safe to convert to a >> contiguous block of memory and stuff in cache, etc. If you know the >> input to a function is guaranteed to be frozen you can just go crazy. >> Being able to freeze(anyobject) seems like a pretty clear win. >> Whether or not it is pythonic is debatable. I'd argue if the meaning >> of pythonic in some context is limiting, we should consider updating >> the term rather than being dogmatic. Sweet, looking at the reason for rejection: 1. How dicts (and multiply nested objects) should be frozen was not completely obvious 2. "frozen()" implies in place, thus confusing users 3. freezing something like a list is confusing because some list methods would disappear or cause errors 4. Because automatic conversion in the proposal was seen as too involved to be so magical 5. Because frozendicts are the main end user benefit, and using dicts as keys was seen as "suspect" Honestly, as far as #1, we already have copy and deepcopy, the can of worms is already opened (and necessarily so). For 2, choose a better name? For 3, we have abstract base classes now, which make a nice distinction between mutable and immutable sequences; nominal types are a crutch, thinking in terms of structure is much more powerful. I agree with point 4, if magic does anything besides make the code conform to what an informed user would expect, it should be considered heretical. As for #5, I feel using a collection of key value relations as a key in another collection is not inherently bad, it just depends on the context... The mutability is the rub. Also, immutability provides scaffolding to improve performance and concurrency (both of which are top tier language features). I understand that this is one of those cases where Guido has a strong "bad feeling" about something, and I think a consequence of that is people tread lightly. Perhaps I'm a bit of a language communist in that regard (historically a dangerous philosophy :) As an aside, I find it kind of schizophrenic how on one hand Python is billed as a language for consenting adults (see duck typing, no data hiding, etc) and on the other hand users need to be protected from themselves. Better to serve just one flavor of kool-aid imo. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: how to tell a method is classmethod or static method or instance method
> And I'll take this opportunity to plug my dualmethod descriptor: > > http://code.activestate.com/recipes/577030-dualmethod-descriptor/ I use an analogous pattern in SQL Alchemy all the time (it's called hybridmethod/hybridproperty there). +1 to dualmethod, that pattern is great when you want a method or property that does something concrete when passed an instance, or something abstract relating to all instances when passed a class. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for PyPi 2.0...
> Hopefully soon crate.io will be useful for finding modules ;) I have plans > for it to try and, encourage people to host their code and encourage > following packaging standards. I'm currently focused mostly on the backend > stability (e.g. getting it stable) but emphasizing things that are generally > good for the packaging ecosystem is something I hope to do. I think providing commit hooks for version control ala read the docs is the #1 thing you could do in the short term to add a lot of value. That would be enough for me to adopt the service :) Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
Just to troll the discussion a little bit more... On Sun, Mar 18, 2012 at 6:02 PM, Chris Angelico wrote: > On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky wrote: >> What I would say is that, when PROGRAMMERS look at Python code for the >> first time, they will understand what it does more readily than they >> would understand other unfamiliar programming languages. That has >> value. > > This is something that's never truly defined. Everyone talks of how > this language or that language is readable, but if you mean that you > can look at a line of code and know what *that line* does, then Python > suffers badly and assembly language wins out; but if you mean that you > should be able to glance over an entire function and comprehend its > algorithm, then I have yet to see any language in which it's not > plainly easy to write bad code. Even with good code, anything more > than trivial can't be eyeballed in that way - if you could, what would > docstrings be for? I agree, docstrings/code comments are a pretty obvious indication that code (as it exists currently) fails as a human communication medium. I suppose that I could make an exception for elaboration on statement with subtle implications. This seems like something people should think more about fixing. > Really, the metric MUST be Python programmers. Intuitiveness is of > value, but readability among experienced programmers is far more > useful. If I write a whole lot of code today, and next year I'm dead > and someone else has replaced me, I frankly don't mind if he has to > learn the language before he can grok my code. I _do_ mind if, even > after he's learned the language, he can't figure out what my code's > doing; and that's where Python's placed itself at about the right > level - not so high that it's all in airy-fairy conceptual work, but > not so low that it gets bogged down. There's a handful of other > languages that are similarly placed, and they're the languages that I > would call "readable". In mathematics, when you perform global optimization you must be willing to make moves in the solution space that may result in a temporary reduction of your optimality condition. If you just perform naive gradient decent, only looking to the change that will induce the greatest immediate improvement in optimality, you will usually end up orbiting around a solution which is not globally optimal. I mention this because any readability or usability information gained using trained programmers is simultaneously measuring the readability or usability and its conformance to the programmer's cognitive model of programming. The result is local optimization around the current-paradigm minimum. This is why we have so many nearly identical curly brace C-like languages. In my opinion, language readability and usability should be determined based on the following tests: - Given users with no programming experience: -- What is the probability that they can correctly guess the result of a program, and how long does it take? -- What is the probability that they can take a program and correctly modify it to change its output to another specified output, or modify it to support another input representation, and how long does it take? - Given users with no programming experience who are provided with a controlled training period: -- What is the probability that they can produce a program that correctly implements a simple, completely described algorithm for solving a puzzle or winning a game, and how long does it take? - Given users with previous (but not extensive) programming experience who are provided with a controlled training period: -- What is the probability that they can produce a program that correctly implements a simple, partially described algorithm for solving a puzzle or winning a game, and how long does it take? -- What is the probability that they can produce a program that correctly implements a complex, completely described algorithm for solving a puzzle or winning a game, and how long does it take? It would probably also be worth examining user behavior relating to code organization and composition under a variety of circumstances. It seems likely that if proper organization and composition are intuitive, productivity would scale well with program size. > Here's an analogy: One statement (aka line of code, etc) corresponds > to one sentence in English. Massive one-liners are like some of the > sentences in Paul's epistles; assembly language is like "The cat sat > on the mat". Both are valid; both are hard to read. This is one of my gripes with the dogmatic application of the "break it into multiple statements" mantra of Python. Not only are you forced to use generators to maintain semantic equivalence in many cases, in some cases a partial statement fragment doesn't have any intuitive meaning. The result is that readers are forced to hold the value of intermediate_variable in their head while reading another statement, then tran
Re: Python is readable
>> This is one of my gripes with the dogmatic application of the "break it >> into multiple statements" mantra of Python. > > I must admit I don't recognise that one, unless you're talking about "not > everything needs to be a one liner". > ... > Perhaps you could give some examples (actual or contrived) of stuff where > "breaking it into multiple statements" is a bad thing? One example is performing a series of transformations on a collection of data, with the intent of finding an element of that collection that satisfies a particular criterion. If you separate out the individual transformations, you need to understand generators or you will waste space and perform many unnecessary calculations. If you only ever do a single transformation with a clear conceptual meaning, you could create a "master transformation function," but what if you have a large number of potential permutations of that function? What if you are composing three or four functions, each of which is conditional on the data? If you extract things from a statement and assign them somewhat arbitrary names, you've just traded horizontal bloat for vertical bloat (with a net increase in volume), while forcing a reader to scan back and forth to different statements to understand what is happening. To steal a line from Einstein, "Make things as simple as possible, but not simpler" >> I agree, docstrings/code comments are a pretty obvious indication that >> code (as it exists currently) fails as a human communication medium. > > > The fact that scientific journal articles start with a documentation string > called an abstract does not indicate that scientific English fails as a > human communication medium. Function docstrings say what the function does > and how to use it without reading the code. They can be pulled out and > displayed elsewhere. They also guide the reading of the code. Abstracts > serve the same functions. A paper, with topic introduction, methods exposition, data/results description and discussion is a poor analog to a function. I would compare the abstract of a scientific paper to the overview section of a program's documentation. The great majority of the docstrings I see are basically signature rehashes with added type information and assertions, followed by a single sentence English gloss-over. If the code were sufficiently intuitive and expressive, that would be redundant. Of course, there will always be morbidly obese functions and coders that like to wax philosophical or give history lessons in comments. Also, because of Sphinx, it is very common in the Python community weave documents and code together in a way that is convenient for authors but irritating for readers. I personally would prefer not to have to scroll past 100 lines of a tutorial with examples, tests and what not in order to go from one function to another. It would be really awesome if everyone used links to that material in docstrings, and the default sphinx theme created an inline collapsible iframe that included that material for the HTML version. Don't get me wrong, I adore Sphinx, the problem here is people who are lazy or don't know the right way to structure docs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
>>> The fact that scientific journal articles start with a documentation >>> string >>> called an abstract does not indicate that scientific English fails as a >>> human communication medium. Function docstrings say what the function >>> does >>> and how to use it without reading the code. They can be pulled out and >>> displayed elsewhere. They also guide the reading of the code. Abstracts >>> serve the same functions. >> >> >> A paper, with topic introduction, methods exposition, data/results >> description and discussion is a poor analog to a function. I would >> compare the abstract of a scientific paper to the overview section of >> a program's documentation. The great majority of the docstrings I see >> are basically signature rehashes with added type information and >> assertions, followed by a single sentence English gloss-over. If the >> code were sufficiently intuitive and expressive, that would be >> redundant. Of course, there will always be morbidly obese functions >> and coders that like to wax philosophical or give history lessons in >> comments. > > > Both abstracts and doc strings are designed to be and are read independently > of the stuff they summarize. Perhaps you do not use help(obj) as often as > some other people do. I find help() to be mostly useless because of the clutter induced by double under methods. I use IPython, and I typically will either use tab name completion with the "?" feature or %edit if I really need to dig around. I teach Python to groups from time to time as part of my job, and I usually only mention help() as something of an afterthought, since typically people react to the output like a deer in headlights. Some sort of semantic function and class search from the interpreter would probably win a lot of fans, but I don't know that it is possible without a standard annotation format and the addition of a namespace cache to pyc files. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
>> One example is performing a series of transformations on a collection of >> data, with the intent of finding an element of that collection that >> satisfies a particular criterion. If you separate out the individual >> transformations, you need to understand generators or you will waste >> space and perform many unnecessary calculations. If you only ever do a >> single transformation with a clear conceptual meaning, you could create >> a "master transformation function," but what if you have a large number >> of potential permutations of that function? > > I'm sorry, that is far too abstract for me. Do you have a *concrete* > example, even an trivial one? How about a hypothetical log analyzer that parses a log file that is aggregated from multiple event sources with disparate record structures. You will need to perform a series of transformations on the data to convert record elements from text to specific formats, and your function for identifying "alarm" records is also dependent on record structure (and possibly system state, imagining an intrusion detection system). Of course you could go through a lot of trouble to dispatch and detect alarms over 6-7 statements, however given the description "for each log record you receive, convert text elements to native data types based on the value of the first three fields of the record, then trigger an alert if that record meets defined requirements" and assuming you have maps from record values to conversion functions for record elements, and a map from record types to alert criteria functions for record types already constructed, it seems like a one liner to me. >> What if you are composing >> three or four functions, each of which is conditional on the data? If >> you extract things from a statement and assign them somewhat arbitrary >> names, you've just traded horizontal bloat for vertical bloat (with a >> net increase in volume), while forcing a reader to scan back and forth >> to different statements to understand what is happening. > > First off, vertical bloat is easier to cope with than horizontal bloat, > at least for people used to reading left-to-right rather than vertically. > There are few anti-patterns worse that horizontal scrolling, especially > for text. I agree that if a line goes into horizontal scroll buffer, you have a problem. Of course, I often rail on parenthesized function-taking-arguments expression structure for the fact that it forces you to read inside out and right to left, and I'd prefer not to conflate the two issues here. My assertion is that given an expression structure that reads naturally regardless, horizontal bloat is better than larger vertical bloat, in particular when the vertical bloat does not fall along clean semantic boundaries. > Secondly, the human brain can only deal with a limited number of tokens > at any one time. It's easier to remember large numbers when they are > broken up into chunks: > > 824-791-259-401 versus 824791259401 > > (three tokens, versus twelve) > > Likewise for reading code. Chunking code into multiple lines instead of > one long expression, and temporary variables, make things easier to > understand, not harder. This is true, when the tokens are an abstraction. I read some of the research on chunking, basically it came down to people being able to remember multiple numbers efficiently in an auditory fashion using phonemes. Words versus random letter combinations have the same effect, only with visual images (which is why I think Paul Graham is full of shit with regards to his "shorter is better than descriptive" mantra in old essays). This doesn't really apply if storing the elements in batches doesn't provide a more efficient representation. Of course, if you can get your statements to read like sensible English sentences, there is definitely a reduction in cognitive load. > And thirdly, you're not "forcing" the reader to scan back and forth -- or > at least if you are, then you've chosen your functions badly. Functions > should have descriptive names and should perform a meaningful task, not > just an arbitrary collection of code. This is why I quoted Einstein. I support breaking compound logical statements down to simple statements, then combining those simple statements. The problem arises when your compound statement still looks like "A B C D E F G H I J K L M N", and portions of that compound statement don't have a lot of meaning outside the larger statement. You could say X = A B C D E, Y = F G H I J, Z = K L M N, then say X Y Z, but now you've created bloat and forced the reader to backtrack. > > When you read: > > x = range(3, len(sequence), 5) > > you're not forced to scan back and forth between that line and the code > for range and len to understand it, because range and len are good > abstractions that make sensible functions. > > There is a lot of badly written code in existence. Don't blame poor > execution of design principles on the design princip
Re: Python is readable
MOAR TROLLING... >> In my opinion, people who make statements such as "#1/2 are imperative, >> #3 is OO" are missing pretty much the entire point of what OO is. >> >> OO is much more about semantics and the way code is structured. The >> difference between #1/2 (especially #1, of course) and #3 is >> surface-level syntax only. The idea of actions as concrete attributes of entities is probably the worst bit of object oriented programming, except perhaps inheritance. Events occur in the context of multiple entities, but they are conceptually distinct and should not be subordinated. Furthermore, if you have an explicit self or this context, your ability to override elements of an event is limited to things which are directly encapsulated in that context. Additionally, dynamic dispatch induces overhead and the possibility of action at a distance. Reflective template meta-programming and explicit attribute delegation are VASTLY superior. To rant about inheritance, outside of mathematics platonic ideals are bullshit. Natural kinds are the closest we might actually be able to come to ideals, and philosophers still debate whether atomic elements and subatomic particles should have this designation. On the macro scale, classes or types are dynamic, fuzzy unions of structure, context and intent. Making any sort of invariant categorical statement about real things is just begging to be proven wrong. Programmers would be much better off if we made assertions about relationships and structure with an explicit, contextual reference. I think this would simplify code reuse, since you would be able to compare contexts to know if program elements were compatible and programs could be assembled by the union or intersection of sets of assertions. >> About the strongest statement you can make along those lines is that #3 >> will allow you to do dynamic dispatch on the type of 'stack' while #1/2 >> won't, but even that isn't true of course. For instance, CLOS will let >> you write '(push stack item)' (which is the direct analogy in that >> language to #1) and do even more powerful dynamic dispatch than what a >> language like C++, Java, or Python will let you do. >> > > In the grand scheme of things, of course code structure and semantics > are more important the surface-level syntax. > > If you take it as a given that structure/semantics are sound (big > assumption, I know), then the next issue with regards to "readability" > is the syntax itself. Sadly, defining sound (i.e. valid) language semantics is not terribly difficult; Turing complete systems occur spontaneously with surprising frequency in nature. The problem is that fundamentally, languages model the conceptual space at large, but language designers choose a semantic vocabulary that models their minuscule subset of that space. This semantic vocabulary is by its nature static, while the conceptual space is dynamic. We aren't going to get semantics really right until we model the dynamical meta structure of the concept space, and put abstract structure, context and intent at the fore. As for syntax, we have a lot of "real" domain specific languages, such as English, math and logic. They are vetted, understood and useful outside the context of programming. We should approach the discussion of language syntax from the perspective of trying to define a unified syntactical structure for real these DSLs.Ideally it would allow representation of things in a familiar way where possible, while providing an elegant mechanism for descriptions that cut across domains and eliminating redundancy/ambiguity. This is clearly possible, though a truly successful attempt would probably be a work of art for the ages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
>> If I'm reading you correctly, you're expressing frustration with the >> state of language syntax unification in 2012. You mention language in a >> broad sense (not just programming languages, but also English, math, >> logic, etc.), but even in the narrow context of programming languages, >> the current state of the world is pretty chaotic. > > And this is a good thing. Programming languages are chaotic because the > universe of programming problems is chaotic, and the strategies available > to solve those problems are many and varied. > > Different programming languages are good for different things because > they have been designed to work in different problem/solution spaces. > Although I dislike C with a passion, I do recognise that it is good for > when the programmer needs fine control over the smallest details. It is, > after all, a high-level assembler. Likewise for Forth, which lets you > modify the compiler and language as you go. There is a concept in statistical/mathematical modeling called minimum message length (a close analog is minimum description length), which asserts that the optimum model for some set of information is the one that minimizes the sum of the length of the model and the length of the set described by that model. Clearly no model is going to be optimal for every set of information. What I was alluding to in the post that Steve Howell replied to was that we need to have a programming language that is a model of models, then include a second order model as part of the program. Having one core language with many DSLs that can interoperate is infinitely better than having many languages that cannot. A language designed in such a way would also prevent issues like the Python 2 -> 3 fiasco, because two versions of a DSL can be separate, and code can reference them independently while being able to interoperate. > Some languages are optimized for the compiler, some for the writer, and > some for the reader. So are optimized for numeric work, others for > database access. Some are Jack-Of-All-Trades. Each language encourages > its own idioms and ways of thinking about programming. The difference between compiler optimized and writer optimized languages is how many assertions they require about the thing being modeled to be a "valid" program, given its deductive rules. Ideally, the number of assertions should be flexible, and the interpreter/compiler should try and figure out the best way to implement it given the information it has. > When it comes to programming, I say, let a thousand voices shout out. > Instead of imagining a single language so wonderful that every other > language is overshadowed and forgotten, imagine that the single language > is the next Java, or C, or even for that matter Python, but whatever it > is, it's not ideal for the problems you care about, or the way you think > about them. Not so attractive now, is it? I agree about letting a thousand voices shout out, in the context of an embedding language that guarantees code interoperability. Additionally, the size of optimal DSLs for different areas is actually quite small, yet having separate languages for each DSL requires the user to re-learn common patterns such as collection manipulation, IO, etc. Pretty horrible all around. >> The optimistic view is that there will be some kind of inflection point >> around 2020 or so. I could imagine a perfect storm of good things >> happening, like convergence on a single browser platform, > > You call that a perfect storm of good things. I call that sort of > intellectual and software monoculture a nightmare. The cores of English and math are pretty much singularly represented. At more nuanced or abstract levels, there is divergence in order to simplify the process of describing complicated things. How would you like it if linear algebra or algebraic geometry re-invented addition, multiplication, etc with completely different syntax and semantics (I'm ignoring non-commutativity of vector space multiplication) > I want a dozen browsers, not one of which is so common that web designers > can design for it and ignore the rest, not one browser so common that > nobody dares try anything new. How about one browser that is infinitely configurable? That way if someone tries something new, you can try it as well without precluding anything else you already do. The CLI/JVM provide some flexibility, but they are not the correct path. They model the executable machine representations of language, rather than modeling the meta structure of language. This means that you still lack flexibility and dynamism. At least things are moving in the right direction. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico wrote: > On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice > wrote: >> Having one core language with >> many DSLs that can interoperate is infinitely better than having many >> languages that cannot. A language designed in such a way would also >> prevent issues like the Python 2 -> 3 fiasco, because two versions of >> a DSL can be separate, and code can reference them independently while >> being able to interoperate. > > This is either utterly impossible, or already available, depending on > your point of view. Of course it is already available. It is called the laws of physics. Everything we know of inter-operates in the context of physical reality perfectly. > To have an infinitely-configurable program, you must make its > configuration equivalent to writing code. There is already an > infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes > a simple-format text file called "config.c" and processes it. It is true that infinite configuration requires that the configuration be specified in the language of the program. What's the problem? > You want infinite DSLs? Behold! > > $ ./module1 | ./module2 | ./module3 | ./module4 > > Each one has a shebang that tells you what they are (Python 2, Python > 3, something else entirely). There's a very strict interoperability > protocol between the modules - they pass information around through > stdout and stdin. You can write any module in any language, and you > can rewrite module1 for Python 3 without affecting any other or the > invocation sequence. It has always been possible to get from one point in space to another point in space in finite time. Was the invention of the automobile was redundant and unimportant? Obviously not, the characteristics of the process matter. For example, your ability to reason about the behavior of the system you posited as a whole is limited. Are there parts of the different modules that can execute concurrently? Is the output of module1 guaranteed to be acceptable as the input for module2? Is part of module3 redundant (and thus avoidable) given some conditions in module1? If you make a change in module2 what effect does that have on module3 and module4? What if you need to go back and forth between module2 and module3 until some criterion is met before you transition to module4? What if you sometimes want to run module2b instead of module2? > Problems always come when you want to share data between dissimilar > modules. There's no single perfect data-transfer protocol that works > across all languages. What does it mean to "call a function"? If you > truly want this level of flexibility, the best thing to do is to > separate sections cleanly. In fact, the pipe system I show above could > be used that way, although it's stupidly ugly. Everything going on > stdout/stdin has a two-word dispatch envelope with a from and a to, > and each module reads a line, and if it's not addressed to it, passes > it on to stdout. Responses get sent out with their from and to > reversed. All you need is for the last module's stdout to be linked > back into the first module's stdin (not sure if you can do that or not > - it has the feeling of plugging a power strip into itself), and it'll > work perfectly. Add a bit of boilerplate so that the application > developers don't see what's happening underneath, and you could > pretend that dissimilar languages are able to call into each other. > Doesn't mean it's efficient though! What is a function? You could say that it is a sequence of logical statements that relates some assertion with another. You can make a big deal about call by name versus call by value, but it only really matters on a conceptual level when dealing with infinite objects that do not have an analytic closure. You can make a big deal about data format, but scientists have been communicating using different unit systems for hundreds of years, I don't see assertions of relationship between structures as different from unit conversions from imperial to metric; it's all data. There are of course a few snags such as cardinality of the set represented by the integer data type in one case versus another, but that is a low level detail that would be a problem if DSLs were embedded in an expressive modelling language. Data structures ultimately boil down to assertions, assertions about those assertions and relations between assertions. > TLDR version: Infinite flexibility means you're doing nothing. I could address that from a number of ways. First off, anything that is Turing complete is basically "infinitely flexible" but the difference in expressiveness (as measured by the combined length of the
Re: Python is readable
>> There is a concept in statistical/mathematical modeling called minimum >> message length (a close analog is minimum description length), which >> asserts that the optimum model for some set of information is the one >> that minimizes the sum of the length of the model and the length of the >> set described by that model. > > (1) Optimum in what sense? Oh, I don't know, the information theoretic one? Of course, if you're part of the department of redundancy department, that might seem to appear to look like a poor, weak, sub-optimal criterion for the purposes of evaluation of optimality, goodness and positive quality. If you're getting hung up on the fact that there are deep ties to data compression in this language, let me help you out. Imagine that instead of having a simple Boolean algebra of two values, the possible values ranged over a set of elementary concepts. You are then trying to come up with a set of compound concepts and a permutation of those concepts that can describe > (2) What does this have to do with designing programming languages? A program is a representation of knowledge (i.e. a model) which a machine has the ability to interpret. Let me know if you can't understand this, I'll break it down further for you. > This discussion sounds to me like the apocryphal story about the > spherical cow. > > http://en.wikipedia.org/wiki/Spherical_cow When you take the baton, you're supposed to keep running along the path in the same direction as the person who handed it to you. >> Clearly no model is going to be optimal >> for every set of information. What I was alluding to in the post that >> Steve Howell replied to was that we need to have a programming language >> that is a model of models, then include a second order model as part of >> the program. Having one core language with many DSLs that can >> interoperate is infinitely better than having many languages that >> cannot. > > Some people, when confronted with a problem, think "I know, I'll use a > DSL." Now they have two problems. Sure. When confronted with the problem of finding the area under a curve, using integral calculus is going to make things worse... I should just manually sum the infantesimals, from now until the end of time. > And some people think "I know, I'll use a meta-language with an infinite > number of infinitely variable DSLs." Now they have an infinite number of > problems. I'll agree with you, if we change that statement to say "an infinite number of possible problems, all isomorphic to each other." >> A language designed in such a way would also prevent issues >> like the Python 2 -> 3 fiasco, > > What fiasco? The extremely slow uptake? I don't really care one way or another but a lot of the devs have lamented the issue. > You've just lost an awful lot of credibility with me. I didn't lose anything, technically you lost some of your belief in my credibility. So, tautologically, you are the one that lost in this situation. > I'm just surprised you didn't manage to fit quantum mechanics and "the > interconnectedness of all things" into it :) Math/Logic are encompassing. I could draw analogies to quantum theory if you really wanted (category theory is great for this sort of thing). As for the interconnectedness of all things, that is quack language, I do science. >> TL;DR there are a huge number of incompatible programming languages >> because people are modeling a permutation rather than the input to a >> permutation generating function. > > No offence Nathan, but I think you need to come back down to earth for > air before you black out: > > http://www.joelonsoftware.com/articles/fog18.html I read that article a long time ago, it was bullshit then, it is bullshit now. The only thing he gets right is that the Shannon information of a uniquely specified program is proportional to the code that would be required to generate it. Never mind that if a program meets a specification, you shouldn't care about any of the values used for unspecified parts of the program. If you care about the values, they should be specified. So, if Joel had said that the program was uniquely specified, or that none of the things that weren't specified require values in the programming language, he might have been kinda, sorta right. Of course, nobody cares enough to specify every last bit of minutiae in a program, and specifications change, so it is pretty much impossible to imagine either case ever actually occurring. > Or at least before *I* black out. Even if somebody manages to write your > meta-language, you're going to run into the problem of who is going to be > able to use it. The t
Re: Python is readable
>> For example, your ability to reason about the behavior of the system >> you posited as a whole is limited. Are there parts of the different >> modules that can execute concurrently? Is the output of module1 >> guaranteed to be acceptable as the input for module2? Is part of >> module3 redundant (and thus avoidable) given some conditions in >> module1? If you make a change in module2 what effect does that have >> on module3 and module4? What if you need to go back and forth between >> module2 and module3 until some criterion is met before you transition >> to module4? What if you sometimes want to run module2b instead of >> module2? > > Pipes allow different modules to execute concurrently (except on DOS > and maybe Windows, haven't checked). Nothing in ANY language > "guarantees" acceptable input, but protocolling would do that for you. > If part of module3 is redundant, you don't call it. If you make a > change to one that affects others, then you fix the others, same as in > any other coding system (or non-coding system - if you upgrade your > hardware from an 8086 with 1MB of memory to a modern box with >4GB, > you'll have to rewrite your code to take advantage of it). The > (somewhat stupid) protocol I suggested allows you to go between 2 and > 3 before going to 4. If you want module2b, you add it to the chain and > call on it. > > Yep, Unix solved all your problems back in the 1970s. Pipes do not provide any fine grained control over the concurrent behavior. If you want to change the order of calls, suddenly you have to write a bash script (with its own set of issues), etc. Unix solved these problems in much the same way that the evolution of appendages solved the problem of changing location from one point to another before the automobile. The process matters. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
>> Do you think we'll always have a huge number of incompatible >> programming languages? I agree with you that it's a fact of life in >> 2012, but will it be a fact of life in 2062? > > It will be a fact of life wherever Godels theorem is; which put > simplistically is: consistency and completeness cannot coexist. This > is the 'logic-generator' for the mess in programming languages. > Put in more general terms: > Completeness is an 'adding' process > Consistency is a 'subtracting' process > Running the two together, convergence is hopeless. This isn't exactly correct. The incompleteness theorem basically shows that in a sufficiently expressive system, there are statements in the system that cannot be proven given the language of that system. We live with this already given the fact that the incompleteness theorem is closely related to Turing's halting problem. That doesn't indicate anything about the convergence of programming languages. It does say that we will need some form of unit testing or restricted subset simulation system as an adjunct to formal verification in most cases, until the end of time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
Logo. It's turtles all the way down. -- http://mail.python.org/mailman/listinfo/python-list
Re: Stream programming
> I will use "<=>" to mean "is equivalent to". That's not part of the DSL.
> A flow has one or more streams:
> 1 stream:
> [1,2,3]
> 2 streams:
> [1,3,5] | [2,4,6]
> Two flows can be concatenated:
> [1,2,3] + [4,5,6] <=> [1,2,3,4,5,6]
> [0] + ([1,2] | [3,4]) + [10] <=> [0,1,2,10] | [0,3,4,10]
> ([1,2] | [10,20]) + ([3,4] | [30,40]) <=> [1,2,3,4] | [10,20,30,40]
Algebraically, your concatenation rules don't really make sense - your
flows are both distributive and non distributive. You also make the
implicit assumption of an order over streams in a flow, but disregard
the implications of that assumption in some cases. I understand what
you're trying to communicate, so I think you need to be a little more
strict and explicit in your definitions.
> A flow can be transformed:
> [1,2] - f <=> [f(1),f(2)]
> ([1,2] | [3,4]) - f <=> [f(1,3),f(2,4)]
> ([1,2] | [3,4]) - [f] <=> [f(1),f(2)] | [f(3),f(4)]
> ([1,2] | [3,4]) - [f,g] <=> [f(1),f(2)] | [g(3),g(4)]
> [1,2] - [f,g] <=> [f(1),f(2)] | [g(1),g(2)]
Given the examples you pose here, it is clear that you are assuming
that the streams are synchronized in discrete time. Since you do not
provide any mechanism for temporal alignment of streams you are also
assuming every stream will have an element at every time point, the
streams start at the same time and are of the same length. Is this
what you want? These seem like pretty rough simplifying assumptions.
> Some functions are special and almost any function can be made special:
> [1,2,3,4,5] - filter(isprime) <=> [2,3,5]
> [[],(1,2),[3,4,5]] - flatten <=> [1,2,3,4,5]
> Note that 'filter' is not really necessary, thanks to 'flatten'.
This implies that your transformations again produce flows. You
should explicitly state this.
> Flows can be named, remembered and used
> as a value:
> [1,2,3,4,5] - 'flow' + val('flow') <=> [1,2,3,4,5]*2
Is this a flow with two identical streams, or a flow with one long
stream formed by concatenation?
> as a transformation chain:
> [1,2,3] - skipfirst - 'again' | [4,5,6] - func('again')
> <=> [2,3] | [5,6]
> Recursion is also possible and stops when a function is applied to an empty
> sequence.
> Flows can be saved (push) and restored (pop) :
> [1,2,3,4] - push - by(2) - 'double' - pop | val('double')
> <=> [1,2,3,4] | [2,4,6,8]
> There are easier ways to achieve the same result, of course:
> [1,2,3,4] - [id, by(2)]
You are grasping at an algebra here, a sort of calculus of temporal
observations. You need to step back and make it rigorous before you
worry about issues such as a readable syntax.
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Stream programming
>>> I will use "<=>" to mean "is equivalent to". That's not part of the DSL. >>> A flow has one or more streams: >>> 1 stream: >>> [1,2,3] >>> 2 streams: >>> [1,3,5] | [2,4,6] >>> Two flows can be concatenated: >>> [1,2,3] + [4,5,6]<=> [1,2,3,4,5,6] >>> [0] + ([1,2] | [3,4]) + [10]<=> [0,1,2,10] | [0,3,4,10] >>> ([1,2] | [10,20]) + ([3,4] | [30,40])<=> [1,2,3,4] | [10,20,30,40] >> >> >> Algebraically, your concatenation rules don't really make sense - your >> flows are both distributive and non distributive. You also make the >> implicit assumption of an order over streams in a flow, but disregard >> the implications of that assumption in some cases. I understand what >> you're trying to communicate, so I think you need to be a little more >> strict and explicit in your definitions. >> > When concatenating, either there are the same number of streams, or one > of them is a single stream which is duplicated. > > Therefore, in this example: > > [0] + ([1, 2] | [3, 4]) > > you're concatenating a single stream with a pair, so the single stream > is duplicated: > > ([0] | [0]) + ([1, 2] | [3, 4]) > > and then they can be concatenated: > > ([0, 1, 2] | [0, 3, 4]) > > However, this: > > ([0, 1] | [2, 3]) + ([4, 5] | [6, 7] | [8, 9]) > > won't work. I understand how he wants the system to work in this case; my point was that it isn't consistent. He stated flows can be concatenated, so [0] is just a flow of a single stream. Because he clearly intends that streams in a flow are ordered, that indicates that he wants some sort of algebraic module. He could get close if he can extend a stream to meet the requirements of a ring, then a flow would be a module over the ring of streams. The problem he is going to run into is that operations on streams as he defines them are not commutative. Identity elements for the two binary operations are also not immediately obvious to me. He could just be smart and use the pi calculus, it is rigorously developed and can model his desired behavior, if he reformulates it slightly. Another option is just to give up on being rigorous. Given the abstract treatment he attempted I would be disappointed, but if his only goal is to get practice writing code and he isn't interested in exploring the conceptual space of the problem domain it would be the right decision. -- http://mail.python.org/mailman/listinfo/python-list
Re: Stream programming
>> I understand what >> you're trying to communicate, so I think you need to be a little more >> strict and explicit in your definitions. > > > No, I don't think you understand what I meant. I don't agree. Sorry. > Yes. I thought that streams as an alternative to functional programming were > widely known. Streams aren't really a paradigm of computation. They're a semantic element of a computational system which cuts across paradigms. If you want to retract that and say you were talking about dataflow programming (which is much larger than streams, and actually has a cohesive definition), I won't hold it against you. Ultimately though, functional programming and dataflow programming are closely linked, the main difference being the use of queues based rather than stacks. > Isn't that obvious? BTW, those are not rigorous definitions. I thought I was > talking to people who regularly works with streams. That is the GPU mailing list, down the hall on the left. > Instead of talking of what I wasn't trying to do and, indeed, I didn't do, > you should try to understand what I wanted to do and, in fact, I did. > I'm afraid your cup is too full to understand simple things as the one I > wrote in my OP. Clearly, because I didn't explicitly include the possibility that you are just writing throwaway code with no attempt at development of ideas for the purpose of practicing writing code in the paragraph after the one you quoted. If your goal is to learn to code, instead of posting a message stating that you have a superior way to compose code, you might want to try to solve a problem and ask others their opinion of the structure and techniques in your code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Wed, Mar 28, 2012 at 9:33 PM, Chris Angelico wrote: > On Thu, Mar 29, 2012 at 11:59 AM, Rodrick Brown > wrote: >> The best skill any developer can have is the ability to pickup languages >> very quickly and know what tools work well for which task. > > Definitely. Not just languages but all tools. The larger your toolkit > and the better you know it, the more easily you'll be able to grasp > the tool you need. The thing that bothers me is that people spend time and mental energy on a wide variety of syntax when the semantics are ~90% identical in most cases (up to organization). We would be better off if all the time that was spent on learning syntax, memorizing library organization and becoming proficient with new tools was spent learning the mathematics, logic and engineering sciences. Those solve problems, languages are just representations. Unfortunately, programming languages seem to have become a way to differentiate yourself and establish sub-cultural membership. All the cool kids are using XYZ, people who use LMN are dorks! Who cares about sharing or compatibility! Human nature is depressingly self-defeating. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Thu, Mar 29, 2012 at 10:03 AM, Chris Angelico wrote: > On Fri, Mar 30, 2012 at 12:44 AM, Nathan Rice > wrote: >> We would be better off if all the time that was spent on learning >> syntax, memorizing library organization and becoming proficient with >> new tools was spent learning the mathematics, logic and engineering >> sciences. Those solve problems, languages are just representations. > > Different languages are good at different things. REXX is an efficient > text parser and command executor. Pike allows live updates of running > code. Python promotes rapid development and simplicity. PHP makes it > easy to add small amounts of scripting to otherwise-static HTML pages. > C gives you all the power of assembly language with all the > readability of... assembly language. SQL describes a database request. Here's a thought experiment. Imagine that you have a project tree on your file system which includes files written in many different programming languages. Imagine that the files can be assumed to be contiguous for our purposes, so you could view all the files in the project as one long chunk of data. The directory and file names could be interpreted as statements in this data, analogous to "in the context of somedirectory" or "in the context of somefile with sometype". Any project configuration files could be viewed as declarative statements about contexts, such as "in xyz context, ignore those" or "in abc context, any that is actually a this". Imagine the compiler or interpreter is actually part of your program (which is reasonable since it doesn't do anything by itself). Imagine the build management tool is also part of your program in pretty much the same manner. Imagine that your program actually generates another program that will generate the program the machine runs. I hope you can follow me here, and further I hope you can see that this is a completely valid description of what is actually going on (from a different perspective). In the context of the above thought experiment, it should be clear that we currently have something that is a structural analog of a single programming metalanguage (or rather, one per computer architecture), with many domain specific languages constructed above that to simplify tasks in various contexts. The model I previously proposed is not fantasy, it exists, just not in a form usable by human beings. Are machine instructions the richest possible metalanguage? I really doubt it. Lets try another thought experiment... Imagine that instead of having machine instructions as the common metalanguage, we pushed the point of abstraction closer to something programmers can reasonably work with: abstract syntax trees. Imagine all programming languages share a common abstract syntax tree format, with nodes generated using a small set of human intelligible semantic primes. Then, a domain specific language is basically a context with a set of logical implications. By associating a branch of the tree to one (or the union of several) context, you provide a transformation path to machine instructions via logical implication. If implications of a union context for the nodes in the branch are not compatible, this manifests elegantly in the form of a logical contradiction. What does pushing the abstraction point that far up provide? For one, you can now reason across language boundaries. A compiler can tell me if my prolog code and my python code will behave properly together. Another benefit is that you make explicit the fact that your parser, interpreter, build tools, etc are actually part of your program, from the perspective that your program is actually another program that generates programs in machine instructions. By unifying your build chain, it makes deductive inference spanning steps and tools possible, and eliminates some needless repetition. This also greatly simplifies code reuse, since you only need to generate a syntax tree of the proper format and associate the correct context to it. It also simplifies learning languages, since people only need to understand the semantic primes in order to read anything. Of course, this describes Lisp to some degree, so I still need to provide some answers. What is wrong with Lisp? I would say that the base syntax being horrible is probably the biggest issue. Beyond that, transformations on lists of data are natural in Lisp, but graph transformations are not, making some things awkward. Additionally, because Lisp tries to nudge you towards programming in a functional style, it can be un-intuitive to learn. Programming is knowledge representation, and state is a natural concept that many people desire to model, so making it a second class citizen is a mistake. If I were to re-imagine Lisp for this purpose, I would embrace state and an explicit notion of temporal order. Rather than pretending it di
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Thu, Mar 29, 2012 at 2:53 PM, Devin Jeanpierre wrote: > Agreed with your entire first chunk 100%. Woohoo! High five. :) Damn, then I'm not trolling hard enough ಠ_ಠ > On Thu, Mar 29, 2012 at 1:48 PM, Nathan Rice > wrote: >> transformations on lists of data are natural in Lisp, but graph >> transformations are not, making some things awkward. > > Eh, earlier you make some argument towards lisp being a universal > metalanguage. If it can simulate prolog, it can certainly grow a graph > manipulation form. You'd just need to code it up as a macro or > function :p Well, a lisp-like language. I would also argue that if you are using macros to do anything, the thing you are trying to do should classify as "not natural in lisp" :) I'm really thinking here more in terms of a general graph reactive system here, matching patterns in an input graph and modifying the graph in response. There are a lot of systems that can be modeled as a graph that don't admit a nested list (tree) description. By having references to outside the nesting structure you've just admitted that you need a graph rather than a list, so why not be honest about it and work in that context from the get-go. >> Additionally, >> because Lisp tries to nudge you towards programming in a functional >> style, it can be un-intuitive to learn. > > I think you're thinking of Scheme here. Common Lisp isn't any more > functional than Python, AFAIK (other than having syntactic heritage > from the lambda calculus?) > > Common-Lisp does very much embrace state as you later describe, Scheme > much less so (in that it makes mutating operations more obvious and > more ugly. Many schemes even outlaw some entirely. And quoted lists > default to immutable (rgh)). I find it interesting that John McCarthy invented both Lisp and the situation calculus. As for set/setq, sure, you can play with state, but it is verbose, and there is no inherent notion of temporal locality. Your program's execution order forms a nice lattice when run on hardware, that should be explicit in software. If I were to do something crazy like take the union of two processes that can potentially interact, with an equivalence relation between some time t1 in the first process and a time t2 in the second (so that you can derive a single partial order), the computer should be able to tell if I am going to shoot myself in the foot, and ideally suggest the correct course of action. > Well, what sort of language differences make for English vs Mandarin? > Relational algebraic-style programming is useful, but definitely a > large language barrier to people that don't know any SQL. I think this > is reasonable. (It would not matter even if you gave SQL python-like > syntax, the mode of thinking is different, and for a good reason.) I don't think they have to be. You can view functions as names for temporally ordered sequence of declarative implication statements. Databases just leave out the logic (this is hyperbole, I know), so you have to do it in client code. I don't feel that a database necessarily has to be a separate entity, that is just an artifact of the localized, specialized view of computation. As stronger abstractions are developed and concurrent, distributed computation is rigorously systematized, I think we'll go full circle. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Thu, Mar 29, 2012 at 9:44 AM, Albert van der Horst wrote: > In article , > Nathan Rice wrote: >>> >>> http://www.joelonsoftware.com/articles/fog18.html >> >>I read that article a long time ago, it was bullshit then, it is >>bullshit now. The only thing he gets right is that the Shannon >>information of a uniquely specified program is proportional to the >>code that would be required to generate it. Never mind that if a > > Thank you for drawing my attention to that article. > It attacks the humbug software architects. > Are you one of them? > I really liked that article. I read the first paragraph, remembered that I had read it previously and stopped. I accidentally remembered something from another Joel article as being part of that article (read it at http://www.joelonsoftware.com/items/2007/12/03.html). I don't really have anything to say on Joel's opinions about why people can or should code, their his and he is entitled to them. I feel they are overly reductionist (this isn't a black/white thing) and have a bit of luddite character to them. I will bet you everything I own the only reason Joel is alive today because of some mathematical abstraction he would be all too happy to discount as meaningless (because, to him, it is). Of course, I will give Joel one point: too many things related to programming are 100% hype, without any real substance; if his article had been about bullshit software hype and he hadn't fired the broadsides at the very notion of abstraction, I wouldn't have anything to say. Anyhow, if you "ugh rock good caveman smash gazelle put in mouth make stomach pain go away" meaning, here it is: Programs are knowledge. The reverse is not true, because programming is an infantile area of human creation, mere feet from the primordial tide pool from whence it spawned. We have a very good example of what a close to optimal outcome is: human beings - programs that write themselves, all knowledge forming programs, strong general artificial intelligence. When all knowledge is also programs, we will have successfully freed ourselves from necessary intellectual drudgery (the unnecessary kind will still exist). We will be able to tell computers what we want on our terms, and they will go and do it, checking in with us from time to time if they aren't sure what we really meant in the given context. If we have developed advanced robotics, we will simultaneously be freed from most manual labor. The only thing left for Joel to do will be to lounge about, being "creative" while eating mangos that were picked, packed, shipped and unloaded by robots, ordered by his computer assistant because it knows that he likes them, then delivered, prepared and served by more robots. The roadblocks in the path include the ability to deal with uncertainty, understand natural languages and the higher order characteristics of information. Baby steps to deal with these roadblocks are to explicitly forbid uncertainty, simplify the language used, and explicitly state higher order properties of information. The natural evolution of the process is to find ways to deal with ambiguity, correctly parse more complex language and automatically deduce higher order characteristics of information. Clearly, human intelligence demonstrates that this is not an impossible pipe dream. You may not be interested in working towards making this a reality, but I can pretty much guarantee on the scale of human achievement, it is near the top. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Thu, Mar 29, 2012 at 7:37 PM, Devin Jeanpierre wrote: > On Thu, Mar 29, 2012 at 3:50 PM, Nathan Rice > wrote: >> Well, a lisp-like language. I would also argue that if you are using >> macros to do anything, the thing you are trying to do should classify >> as "not natural in lisp" :) > > You would run into disagreement. Some people feel that the lisp > philosophy is precisely that of extending the language to do anything > you want, in the most natural way. That is some people's lisp philosophy, though I wouldn't say that is a universal. Just like I might say my take on python's philosophy is "keep it simple, stupid" but others could disagree. > At least, I disagree, but my lisp thoughts are the result of > indoctrination of the Racket crowd. I don't know how well they > represent the larger lisp community. But you should definitely take > what I say from the viewpoint of the sort of person that believes that > the whole purpose of lisps is to embed new syntax and new DSLs via > macros. Without macros, there's no point of having this despicable > syntax (barring maybe pedagogy and other minor issues). Heh, I think you can have a homoiconic language without nasty syntax, but I won't get into that right now. >> I'm really thinking here more in terms of a general graph reactive >> system here, matching patterns in an input graph and modifying the >> graph in response. There are a lot of systems that can be modeled as >> a graph that don't admit a nested list (tree) description. By having >> references to outside the nesting structure you've just admitted that >> you need a graph rather than a list, so why not be honest about it and >> work in that context from the get-go. > > I don't see any issue in defining a library for working with graphs. > If it's useful enough, it could be added to the standard library. > There's nothing all that weird about it. Graphs are the more general and expressive data structure, I think if anything you should special case the less general form. > Also, most representations of graphs are precisely via a tree-like > non-recursive structure. For example, as a matrix, or adjacency list, > etc. We think of them as deep structures, but implement them as flat, > shallow structures. Specialized syntax (e.g. from macros) can > definitely bridge the gap and let you manipulate them in the obvious > way, while admitting the usual implementation. We do a lot of things because they are efficient. That is why gaussian distributions are everywhere in statistics, people approximate nonlinear functions with sums of kernels, etc. It shouldn't be the end goal though, unless it really is the most expressive way of dealing with things. My personal opinion is that graphs are more expressive, and I think it would be a good idea to move towards modeling knowledge and systems with graphical structures. >> I don't think they have to be. You can view functions as names for >> temporally ordered sequence of declarative implication statements. >> Databases just leave out the logic (this is hyperbole, I know), so you >> have to do it in client code. I don't feel that a database >> necessarily has to be a separate entity, that is just an artifact of >> the localized, specialized view of computation. As stronger >> abstractions are developed and concurrent, distributed computation is >> rigorously systematized, I think we'll go full circle. > > Maybe I'm too tired, but this went straight over my head, sorry. > Perhaps you could be a bit more explicit about what you mean by the > implications/logic? Well, the curry howard correspondance says that every function can be seen as a named implication of outputs given inputs, with the code for that function being a representation of its proof. Since pretty much every function is a composition of many smaller functions, this holds down to the lowest level. Even imperative statements can be viewed as functions in this light, if you assume discrete time, and view every function or statement as taking the state of the world at T as an implicit input and returning as an implicit output the state of the world at T+1. Thus, every function (and indeed pretty much all code) can be viewed as a named collection of implication statements in a particular context :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
> He did no such thing. I challenge you to find me one place where Joel has > *ever* claimed that "the very notion of abstraction" is meaningless or > without use. "When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there's a general pattern: sending files. That's one level of abstraction already. Then they go up one more level: people send files, but web browsers also "send" requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It's the same thing again! Those are all sending operations, so our clever thinker invents a new, higher, broader abstraction called messaging, but now it's getting really vague and nobody really knows what they're talking about any more. Blah. When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all." To me, this directly indicates he views higher order abstractions skeptically, and assumes because he does not see meaning in them, they don't hold any meaning. Despite Joel's beliefs, new advances in science are in many ways the result of advances in mathematics brought on by very deep abstraction. Just as an example, Von Neumann's treatment of quantum mechanics with linear operators in Hilbert spaces utilizes very abstract mathematics, and without it we wouldn't have modern electronics. I'm 100% behind ranting on software hype. Myopically bashing the type of thinking that resulted in the computer the basher is writing on, not so much. If he had said "if you're getting very high up, find very smart people and talk to them to make sure you're not in wing nut territory" I could have given him a pass. I really wish people wouldn't try to put Joel up on a pedestal. The majority of his writings either seem like sensationalist spins on tautological statements, self aggrandizement or luddite trolling. At least Stephen Wolfram has cool shit to back up his ego, Fog Creek makes decent but overpriced debuggers/version control/issue trackers... From my perspective, Stack Overflow is the first really interesting thing Joel had his hand in, and I suspect Jeff Atwood was probably the reason for it, since SO doesn't look like anything Fog Creek ever produced prior to that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
>>> He did no such thing. I challenge you to find me one place where Joel >>> has *ever* claimed that "the very notion of abstraction" is meaningless >>> or without use. > [snip quote] >> To me, this directly indicates he views higher order abstractions >> skeptically, > > Yes he does, and so we all should, but that's not the claim you made. You > stated that he "fired the broadsides at the very notion of abstraction". > He did no such thing. He fired a broadside at (1) software hype based on > (2) hyper-abstractions which either don't solve any problems that people > care about, or don't solve them any better than more concrete solutions. Mathematics is all about abstraction. There are theories and structures in mathematics that have probably gone over a hundred years before being applied. As an analogy, just because a spear isn't useful while farming doesn't mean it won't save your life when you venture into the woods and come upon a bear. >> and assumes because he does not see meaning in them, they >> don't hold any meaning. > > You are making assumptions about his mindset that not only aren't > justified by his comments, but are *contradicted* by his comments. He > repeatedly describes the people coming up with these hyper-abstractions > as "great thinkers", "clever thinkers", etc. who are seeing patterns in > what people do. He's not saying that they're dummies. He's saying that > they're seeing patterns that don't mean anything, not that the patterns > aren't there. He is basically saying they are too clever for their own good, as a result of being fixated upon purely intellectual constructs. If math was a failed discipline I might be willing to entertain that notion, but quite the opposite, it is certainly the most successful area of study. > >> Despite Joel's beliefs, new advances in science >> are in many ways the result of advances in mathematics brought on by >> very deep abstraction. Just as an example, Von Neumann's treatment of >> quantum mechanics with linear operators in Hilbert spaces utilizes very >> abstract mathematics, and without it we wouldn't have modern >> electronics. > > I doubt that very much. The first patent for the transistor was made in > 1925, a year before von Neumann even *started* working on quantum > mechanics. The electronic properties of silicon (among other compounds) is an obvious example of where quantum theory provides for us. We might have basic circuits, but we wouldn't have semiconductors. > In general, theory *follows* practice, not the other way around: parts of > quantum mechanics theory followed discoveries made using the transistor: You do need data points to identify an explanatory mathematical structure. > The Romans had perfectly functioning concrete without any abstract > understanding of chemistry. If we didn't have QM, we'd still have > advanced electronics. Perhaps not *exactly* the electronics we have now, > but we'd have something. We just wouldn't understand *why* it works, and > so be less capable of *predicting* useful approaches and more dependent > on trial-and-error. Medicine and pharmaceuticals continue to be > discovered even when we can't predict the properties of molecules. The stochastic method, while useful, is many orders of magnitude less efficient than analytically closed solutions. Not having access to closed form solutions would have put us back hundreds of years at least. > My aunt makes the best damn lasagna you've ever tasted without any > overarching abstract theory of human taste. And if you think that quantum > mechanics is more difficult than understanding human perceptions of > taste, you are badly mistaken. Taste is subjective, and your aunt probably started from a good recipe and tweaked it for local palates. That recipe could easily be over a hundred years old. An overarching mathematical theory of human taste/mouth perception, if such a silly thing were to exist, would be able to generate new recipes that were perfect for a given person's tastes very quickly. Additionally, just to troll this point some more (fun times!), I would argue that there is an implicit theory of human taste (chefs refer to it indirectly as gastronomy) that is very poorly organized and lacks any sort of scientific rigor. Nonetheless, enough empirical observations about pairings of flavors, aromas and textures have been made to guide the creation of new recipes. Gastronomy doesn't need to be organized or rigorous because fundamentally it isn't very important. > In any case, Spolsky is not making a general attack on abstract science. > Your hyperbole is completely unjustified. The mathematics of the 20th century, (from the early 30s onward) tend to get VERY abstract, in just the way Joel decries. Category theory, model theory, modern algebraic geometry, topos theory, algebraic graph theory, abstract algebras and topological complexes are all very difficult to understand because they seem so incredibly abstract, yet most of
Re: Number of languages known [was Re: Python is readable] - somewhat OT
>> Here's a thought experiment. Imagine that you have a project tree on >> your file system which includes files written in many different >> programming languages. Imagine that the files can be assumed to be >> contiguous for our purposes, so you could view all the files in the >> project as one long chunk of data. The directory and file names could >> be interpreted as statements in this data, analogous to "in the context >> of somedirectory" or "in the context of somefile with sometype". Any >> project configuration files could be viewed as declarative statements >> about contexts, such as "in xyz context, ignore those" or "in abc >> context, any that is actually a this". Imagine the compiler or >> interpreter is actually part of your program (which is reasonable since >> it doesn't do anything by itself). Imagine the build management tool is >> also part of your program in pretty much the same manner. Imagine that >> your program actually generates another program that will generate the >> program the machine runs. I hope you can follow me here, and further I >> hope you can see that this is a completely valid description of what is >> actually going on (from a different perspective). > [...] >> What does pushing the abstraction point that far up provide? > > I see why you are so hostile towards Joel Spolsky's criticism of > Architecture Astronauts: you are one of them. Sorry Nathan, I don't know > how you breathe that high up. > > For what it's worth, your image of "everything from the compiler on up is > part of your program" describes both Forth and Hypercard to some degree, > both of which I have used and like very much. I still think you're > sucking vacuum :( We live in a world where the tools that are used are based on tradition (read that as backwards compatibility if it makes you feel better) and as a mechanism for deriving personal identity. The world is backwards and retarded in many, many ways, this problem is interesting to me because it actually cuts across a much larger tract than is immediately obvious. People throughout history have had the mistaken impression that the world as it existed for them was the pinnacle of human development. Clearly all of those people were tragically deluded, and I suspect that is the case here as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
>> Mathematics is all about abstraction. There are theories and structures >> in mathematics that have probably gone over a hundred years before being >> applied. As an analogy, just because a spear isn't useful while farming >> doesn't mean it won't save your life when you venture into the woods and >> come upon a bear. > > A spear is a concrete application of the principle of leverage, not an > abstraction. I also point out leverage was discovered experimentally long > before anyone had an abstraction for it. And an analogy is a device to demonstrate the fundamental character of an argument in a different context. > In any case, so what? Who is saying that mathematics is useless? Not me, > and not Joel Spolksy. You are hunting strawmen with your non-abstract > spear. I don't think it is a strawman. He decries things that aren't immediately useful. That describes almost all pure math. If he had excluded things that have some characteristic of truth, and just talked about overly general systems, I might agree with him. > Spolsky has written at least three times about Architecture Astronauts, > and made it abundantly clear that the problem with them is that they > don't solve problems, they invent overarching abstractions that don't do > anything useful or important, and hype them everywhere. I believe in the idea of "things should be as simple as possible, but not simpler". Programming as it currently exists is absolutely convoluted. I am called on to help people learn to program from time to time, and I can tell you that we still have a LONG way to go before programming approaches a global optimum in either the semantic or syntactic space. Never mind configuring a build or anything else related to projects. The whole setup really is horrible, and I'm convinced that most of the people who are capable of changing this are more concerned about their personal investment in the way things are than helping others. There are a few exceptions like Alan Kay, but mostly people want to graft shortcuts on to what already exists. > You keep reading this as an assault on abstract mathematics, science and > knowledge for its on sake. It isn't any of these things. I never said it was an attack on science. Scientists don't really do abstraction, they explain observations. Mathematicians are the ones who discover truth that may be completely disconnected from reality. > If I'm paid to solve a problem, and instead I build an abstraction that > doesn't help solve the problem, then I'm guilty of doing architecture > astronauting. If I ignore everything Joel wrote and just use that definition, I agree with you. >> He is basically saying they are too clever for their own good, as a >> result of being fixated upon purely intellectual constructs. > > Yes, and he is right to do so, because that is the characteristic of the > Architecture Astronaut: being so fixated on over-arching abstract > concepts that, far from those abstractions making it easier to solve the > problems they are being paid to solve, they actually make them harder. > > Good abstractions enable problems to be solved. Bad abstractions don't. > > If I ask you to build me a website, I probably don't want a website- > builder, I certainly don't want a website-builder-generator, and I > absolutely do not want you to generalise the concept of a compiler and > create a whole new abstract language for describing meta-compilers so > that I can create a brand new programming language for generating meta- > compilers that build compilers that will build factories for building > website generators so I can make my own website in just three easy steps > (the simplest one of which is about twice as difficult as just building > the website would have been). Again, I follow the principle of "everything should be as simple as possible, but no simpler". I have in the past built website builders rather than build websites (and done a similar thing in other cases), but not because I am trying to discover some fundamental truth of website building, because that would be bullshit. I did it because building websites (or whatever else it was) is a boring, tedious problem, and a website builder, while being more work, is an engaging problem that requires thought. I enjoy challenging myself. > If you are being paid to build abstractions in the ivory tower, on the > chance that one in a thousand abstractions turns out to be a game > changer, or just because of a love of pure knowledge, that's great. I > love abstract mathematics too. I read maths in my free time, you won't > find me saying that it is bad or useless or harmful. But does it solve > real problems? You forget that even abstractions that never directly get turned into something real are almost invariably part of the intellectual discourse that leads to real things. > Well, of course it does, and often in a most surprising places. But > that's because out of the hundred thousand abstractions, we see
Re: Python is readable
On Fri, Mar 30, 2012 at 12:20 PM, Chris Angelico wrote: > On Sat, Mar 31, 2012 at 12:46 AM, Nathan Rice > wrote: >> I believe in the idea of "things should be as simple as possible, but >> not simpler". Programming as it currently exists is absolutely >> convoluted. I am called on to help people learn to program from time >> to time, and I can tell you that we still have a LONG way to go before >> programming approaches a global optimum in either the semantic or >> syntactic space. > > Aside from messes of installing and setting up language > interpreters/compilers, which are averted by simply having several > pre-installed (I think my Linux boxes come with some Python 2 version, > Perl, bash, and a few others), that isn't really the case. Starting a > Python script is easy. Programming gets convoluted only when, and to > the extent that, the task does. It is true that program complexity is correlated with problem complexity, language and environment complexity is undeniable. If you want to prove this to yourself, find someone who is intelligent and has some basic level of computer literacy, sit them down at a computer and ask them to solve simple problems using programs. You could even be nice by opening the editor first. Don't help them, just watch them crash and burn. Then sit them in front of code that already works, and ask them to modify it to do something slightly different, and again just watch them crash and burn in all but the simplest of cases. It is painful - most of the time they just give up. These same people almost universally can describe the exact process of steps verbally or in writing to do what is required without any trouble; there might be some neglected edge cases, but if you describe the failed result, often times they will realize their mistake and be able to fix it quickly. Jeff Atwood had an article about programming sheep and non programming goats, and while he views it as a statement about people's failings, I view it as a statement about the failings of programming. Human computer interaction is really important, and the whole prefab GUI concept doesn't scale along any axis; people need to be able to interact with their computers in a flexible manner. In the beginning, we had no choice but to bend our communication to the the machine, but we're moving past that now. The machine should respect the communication of humans. We shouldn't decry natural language because of ambiguity; If we're ambiguous, the machine should let us know and ask for clarification. If we phrase things in a really awkward way, the machine should tell us so, and suggest a more understandable rendition (just like word processors do now). If the machine does something we didn't want based on our instructions, we should be able to state additional requirements in a declarative manner. Restricted natural languages are an active area of current research, and they clearly demonstrate that you can have an expressive formal language that is also valid English. Make no mistake about it, programming is a form of computer human interaction (I figured that would be an accepted mantra here). Think of it as modeling knowledge and systems instead of pushing bits around. You are describing things to the computer. To move from the syntactic domain to my point about programming languages, imagine if one person describes physics to a computer in French, and another person describes chemistry to a computer in English. The creators of the computer made different languages act as disjoint knowledge domains. The computer is incapable of making any inferences in physics which are informed by chemistry, and vice versa, unless someone comes along and re-describes one of the disciplines in the other language. Worse still, if someone that only speaks Mandarin comes along, the computer won't be able to tell him anything about either domain. Now imagine the creators of the computer decided that an acceptable solution was to have people print out statements from one domain in a given language, take it to another computer that scans the printout, translates it to a different language, and prints out the translated copy, then have that person take the translated copy back to the original computer, and scan it again in order to ask a cross cutting question. I hope from that perspective the paucity of our current methods will be more apparent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
> This is more a matter of being unable to express themselves > appropriately. If I allowed them to write an exact process of steps to > do what's required, those steps would either be grossly insufficient > for the task, or would BE pseudo-code. There are plenty of people who > cannot write those sorts of instructions at all. They're called > non-programmers. Anyone who doesn't code but can express a task in > such clear steps as you describe is what I would call a non-coding > programmer - and such people are VERY easily elevated to full > programmer status. I've worked with several like that, and the border > between that kind of clear, concise, simple instruction list and > actual Python or REXX code is so small as to be almost nonexistent. > It's not the programming languages' fault. It's a particular jump in > thinking that must be overcome before a person can use them. Your statement that the difference between Python or REXX and pseudo-code is almost non existent is completely false. While people reading Python might be able to guess with higher accuracy what a program does than some other programming languages, there is still a set of VERY specific set of glyphs, words and phrase structures it requires. Pretty much anyone can follow a recipe to make a meal (and there are a lot other examples of this), and conversely given the knowledge of how to make some dish, pretty much everyone could describe the process as a recipe. The same person will fail miserably when trying to create working code that is MUCH simpler from a conceptual standpoint. "Non coders" are not stupid, they just don't appreciate the multitude of random distinctions and computer specific abstractions programming foists on them for the purpose of writing EFFICIENT code. I'm talking about like multiple int/number types, umpteen different kinds of sequences, tons of different data structures that are used for basically the same things under different circumstances, indices starting at 0 (which makes amazing sense if you think like a machine, and very little if you think like a human), the difference between logical and bitwise operators (union and intersection would be better names for the latter), string encoding, etc. When you combine these with having to communicate in a new (very arbitrary, sometimes nonsensical) vocabulary that doesn't recognize synonyms, using an extremely restricted phrase structure and an environment with very limited interactivity, it should become clear that the people who learn to program are invariably fascinated by computers and very motivated to do so. I'm going to assume that you didn't mean that "non coders" are incapable of instructing others (even though your statement implies it directly). I think the ability of "non coders" to describe procedures would surprise you. Things I hear over and over from "non coders" all tie into people being frustrated that computers don't grasp similarity, and don't try to figure out what they want at all; most people provide instructions in an interactive manner. The computer is too stupid to interact with humans, so you have to tell it what to do, then try to run it, watch it fail, then go back and modify your program, which is highly unnatural. I think you'd find that these "non coders" would do very well if given the ability to provide instructions in a natural, interactive way. They are not failing us, we are failing them. > Etcetera, etcetera. Everyone who's made the jump will see the benefit > of the side they're on; most who haven't won't. Same with > non-programmers to programmers. Why should I write like that when I > could just write English? Simple: Because dedicated programming > languages are far more expressive for the job. Really? Or could it be that algorithms for natural language processing that don't fail miserably is a very recent development, restricted natural languages more recent still, and pretty much all commonly used programming languages are all ~20+ years old? Could it also be that most programmers don't see a lot of incentives to make things accessible, since they're already invested in the status quo, and they might lose some personal value if programming stopped being an arcane practice? Creating a programming language is a time consuming and laborious process, the fact that people are doing it constantly is a clear indication that what we have is insufficient. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Fri, Mar 30, 2012 at 4:20 PM, Chris Angelico wrote: > On Sat, Mar 31, 2012 at 6:55 AM, Nathan Rice > wrote: >> I think you'd find that these "non coders" would do very well if given >> the ability to provide instructions in a natural, interactive way. >> They are not failing us, we are failing them. > > The nearest thing to natural-language command of a computer is voice > navigation, which is another science that's plenty old and yet still > current (I first met it back in 1996 and it wasn't new then). You tell > the computer what you want it to do, and it does it. Theoretically. > The vocabulary's a lot smaller than all of English, of course, but > that's not a problem. The problem is that it's really REALLY slow to > try to get anything done in English, compared to a dedicated > domain-specific language (in the case of typical OS voice navigation, > the nearest equivalent would probably be a shell script). I'm sure a ford truck would smoke a twin engine cessna if you compare their speed on the ground. Let the cessna fly and the ford doesn't have a snowball's chance. If you're navigating by going "cee dee space slash somefolder slash some other folder slash some third folder slash semicolon emacs somename dash some other name dash something dot something else dot one" the analogy would be a boss telling his secretary to reserve him a flight by saying "visit site xyz, click on this heading, scroll halfway down, open this menu, select this destination, ..." instead of "book me a flight to San Jose on the afternoon of the 23rd, and don't spend more than $500". > Totally. That's why we're all still programming in assembly language > and doing our own memory management, because we would lose a lot of > personal value if programming stopped being so difficult. If it > weren't for all these silly new-fangled languages with their automatic > garbage collection and higher order function handling, we would all be > commanding much higher salaries. Did you miss the fact that a 50 year old programming language (which still closely resembles its original form) is basically tied for the title of currently most popular, and the 3 languages following it are both nominal and spiritual successors, with incremental improvements in features but sharing a large portion of the design. Programming language designers purposefully try to make their language C-like, because not being C-like disqualifies a language from consideration for a HUGE portion of programmers, who cower at the naked feeling they get imagining a world without curly braces. Fear of change and the unknown are brutal, and humans are cowardly creatures that will grasp at whatever excuses they can find not to acknowledge their weaknesses. I also mentioned previously, most developers are just trying to graft shortcut after shortcut on to what is comfortable and familiar because we're inherently lazy. Additionally, I'm quite certain that when we finally do have a method for programming/interacting with computers in a natural way, many people invested in previous methods will make snarky comments about how lame and stupid people using the new methods are, just like we saw with command line/keyboard elitists who make fun of people who prefer a mouse/gui, even though in most cases research showed that the people using the mouse/gui actually got work done faster. You can even look at some comments on this thread for evidence of this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Fri, Mar 30, 2012 at 5:45 PM, Chris Angelico wrote: > On Sat, Mar 31, 2012 at 7:58 AM, Nathan Rice > wrote: >> Programming >> language designers purposefully try to make their language C-like, >> because not being C-like disqualifies a language from consideration >> for a HUGE portion of programmers, who cower at the naked feeling they >> get imagining a world without curly braces. Fear of change and the >> unknown are brutal, and humans are cowardly creatures that will grasp >> at whatever excuses they can find not to acknowledge their weaknesses. > > Braces are clear delimiters. English doesn't have them, and suffers > for it. (Python's indentation is, too, but English doesn't have that > either.) It's a lot harder to mark the end of an "if" block in English > than in pretty much any programming language. It seems to me that Indented blocks of text are used pretty frequently to denote definition bodies, section subordinate paragraphs and asides. The use of the colon seems pretty natural too. Parentheses are fairly natural for small asides. The notion of character delimiters for large sections of text is actually pretty unnatural with the exception of quotes. > And be careful of what has to be given up to gain your conveniences. > I've used languages that demand variable declarations and ones that > don't, and I'm very much a fan of the former. There are many benefits > to being explicit about that. I don't like declarations, my personal preference is to have typed signatures, and implicit declaration with type inference elsewhere. I view it as a matter of personal preference though, the result should be the same, and it should be possible to view the code either way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is readable
On Sat, Mar 31, 2012 at 2:15 AM, Lie Ryan wrote: > On 03/21/2012 03:55 AM, Nathan Rice wrote: >> >> > > I think you've just described that greedy algorithm can't always find the > globally optimal solution. Right. Using gradient descent on an algebraic surface is probably the most natural example of why this is the case, since balls rolling down a surface from a starting point to the bottom of a bowl is an exact analogy. On Sat, Mar 31, 2012 at 4:05 AM, Chris Angelico wrote: > On Sat, Mar 31, 2012 at 10:01 AM, Nathan Rice > wrote: >> It seems to me that Indented blocks of text are used pretty frequently >> to denote definition bodies, section subordinate paragraphs and >> asides. The use of the colon seems pretty natural too. Parentheses >> are fairly natural for small asides. The notion of character >> delimiters for large sections of text is actually pretty unnatural >> with the exception of quotes. > > Perhaps in formal written English, but not in spoken, and often not in > casual writing either. Play around with my actual example, an "if" > clause, and see where the punctuation goes in English - and how easily > you can construct ambiguous sentences. Sure an event has occurred recently if it occurred in the last time step. if xyz has occurred recently, that implies abc will occur in the next time step. when event abc occurs, all unbound floops become bound, and at most three newly bound floops are eaten by blargs. blargs that have not eaten in the last 3 time steps eat before blargs that have eaten in those time steps. Notice I don't talk about HOW anything is done, just the logic of what is happening. The computer should be capable of making an inventory of exactly what it will need to do given the statements I have made, and choose the best data structures and algorithms for the job. If we are in undecidable/halting problem territory (indefinite recursion) then the computer should at least be nice enough to tell you it is confused and would like some help. >> I don't like declarations, my personal preference is to have typed >> signatures, and implicit declaration with type inference elsewhere. I >> view it as a matter of personal preference though, the result should >> be the same, and it should be possible to view the code either way. > > I'm not sure what you mean by "typed signatures", can you elaborate please? Just like the standard way in the Haskell community. To demonstrate using Python annotations... def myfunc(Sequence : a, Integral : b, Map : c) -> Sequence: ... Given starting types and ending types, you can correctly infer some VERY complex internal types. Haskell will let you omit signature types as well, but that is really a bad idea because they add readability and you will have to add them often anyhow if you are dealing with complex types. Better to be consistent... As a funny aside, people usually provide input type and return type annotations to python functions, as part of the docstring (for sphinx). To be honest, I like having types baked into my code, though not nominal types (the sort that is an A because it was declared as an A or a subclass of A), but rather structural types (i.e. Abstract base classes, or Java interfaces, if you didn't have to add the implements ...). I don't like having to verbosely tell the computer about the types of everything I'm going to use, I only care that it gives me the output I want if I give it some agreed upon input. It should be smart enough to check the little things. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Sun, Apr 1, 2012 at 11:18 PM, alex23 wrote: > On Mar 30, 3:37 pm, Nathan Rice > wrote: >> We live in a world where the tools that are used are based on >> tradition (read that as backwards compatibility if it makes you feel >> better) and as a mechanism for deriving personal identity. The world >> is backwards and retarded in many, many ways, this problem is >> interesting to me because it actually cuts across a much larger tract >> than is immediately obvious. > > Do you produce commercial code in a team? Because going by your > absolutist bullshit here, it certainly doesn't sound like it. Think of me like the Wolf, the cleaner in pulp fiction that Marcellis Wallis calls in to take care of the mess when Jules accidentally blows a kid's brains out in the back of a car. I get called in when my skills are needed, and when the mess has been handled and things are back to normal I take my leave. > When I join an organisation that requires language A as all of its > systems are written in it, is that 'tradition' or 'personal identity'? > How is 'compatibility' - either with existing systems or existing > *developers* - a "backwards and retarded" approach to complex > problems? I don't care what people do related to legacy systems. There will always be a COBOL. I do care about programmers that are too lazy to learn, and would be happy to ignore the fact that programming is hard for most people to learn, so they can continue not learning. Those programmers are scumbags. Just don't let me hear you complaining because some syntax is not "C like" enough for you. Whenever I hear that I want to strangle the self-serving 'tard that wrote it. When I see people defending "C like" syntax as optimal or somehow much more expressive, that makes me doubly irritated. These are the people who are selfishly defending the status quo because they're invested. If you're going to be selfish and inconsiderate at least be honest about it, rather than pretending that one of the earliest languages somehow got almost everything right and should be the basis for new languages till the end of time. This goes for most of the ALGOL derived languages. I don't have a problem if you know your language well and are happy using it, that's great. Don't try to delude people that our modern ALGOL derivatives are the best possible way to model knowledge (including process knowledge) to a computer, because that is a lie. > If I've chosen language A because some aspect of its syntax maps > better onto my mind (or for _whatever_ reason that makes individuals > prefer one language to another), and you've chosen language B: who > gets to decide which is the 'superior' language, which is the 'better' > mapping etc? You should be able to live in your reality if you want, as long that doesn't impinge on others. Of course, if you disagree on basic grammar, then I would have to ask you, do you disagree about English grammar, or have you accepted it so that you can communicate with people? This is why I advocate following English grammar closely for syntax - people have accepted it and don't make a big deal, and it is the way we represent information already. > You're arguing for a top-down centralised approach to language > development that just will _never_ exist, simply because it cannot. If > you don't accept that, I believe there's a fascinating fork called > "Python 4000" where your ideas would be readily adopted. You completely missed my point. In fact, my argument is for a bottom up approach, with a meeting point which is much closer than the machine code which is currently used. However you want to represent it, the knowledge is the same, and that is what matters. We need to get past the idea of different, incompatible languages, and settle on a common knowledge representation format that underlies all languages, and is compatible. If you want to make an alex23 DSL where up is down and inside is upside down, go for it, just as long as it is represented in a sensible set of semantic primes that I can transform to whatever reality I want. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Tue, Apr 3, 2012 at 1:40 AM, alex23 wrote: > On Apr 3, 2:55 pm, Nathan Rice > wrote: >> I don't care what people do related to legacy systems. > > And that's what earns you the label 'architecture astronaut'. Legacy > systems are _part_ of the problem; it's very easy to hold to a purist > approach when you ignore the bulk of the domain that causes the > issues. There's _never_ going to be an InfoTech3k where we just stop > supporting older code. There are people who are paid pretty well to support crappy old COBOL apps, but I am not among them (nor are you, with very high likelihood), so your "we" is misplaced. For all intents and purposes that software exists in an alternate reality. Remember the tutorial on global vs local optimization I made previously? Let me distill it... If you are unwilling to endure pain to move towards a better world you will always be trapped in a sub-optimal situation. >> I do care about programmers that are too lazy to >> learn, and would be happy to ignore the fact that programming is hard >> for most people to learn, so they can continue not learning. Those >> programmers are scumbags. > > Wait, what? > > Programmers are both "too lazy to learn" and yet somehow happy that > the skills they've acquired are "too hard for most people to learn"? > So how did they learn them? > > And they're also somehow "lazy" because they have to learn multiple > languages to be effective, rather than one mythical ur-language? > > In my 20 years as a software developer, I have _never_ encountered > anyone trying to deliberately expand the knowledge gap. This isn't a > priesthood. Did you miss the part where I said that most people who learn to program are fascinated by computers and highly motivated to do so? I've never met a BROgrammer, those people go into sales. It isn't because there aren't smart BROmosapiens (sadly, there are), they just couldn't give two shits about computers so programming seems like a colossal waste of time to them. It isn't about people scheming to "dis-empower then plebs" rather it is about people who don't want to move outside their comfort zone. You can talk about people learning multiple languages all you want, but for the most part they will be 10 descendants of ALGOL, with minor variations. Very few people are willing to tackle something like Haskell or ML if they weren't taught functional programming in university, though there are a few that view it as an endurance trial or mountain to climb. Those people get a pass on most of what I've said thus far. >> Just don't let me hear you complaining because some syntax is not "C >> like" enough for you. Whenever I hear that I want to strangle the >> self-serving 'tard that wrote it. When I see people defending "C >> like" syntax as optimal or somehow much more expressive, that makes me >> doubly irritated. These are the people who are selfishly defending >> the status quo because they're invested. > > Syntax is never the issue, it's the deeper semantics. Is the scoping > of one C-like language the same as C? How does it differ? Why does it > differ? Is the difference a fundamental implementation issue that you > really need to know before you actually grok the language? Are > functions first-class objects? Are they actual objects or some kind of > magical stub? Can you extend those objects with properties? etc etc Syntax and semantics are both a big mess right now. That is why I always address them both. > Every language tackles _so many_ things differently. It's not lazy to > say that you prefer something to resemble/be based on a language you > have experience with, that's human nature. If you're insistent that > your non-typical syntax is so much better, the onus is on you to prove > it, not to insist that the lack of uptake is 'laziness'. The winds of change generally blow for programming when generations of older programmers leave the workforce. Alan Kay was a smart man, viewing programming as an educational tool and designing for youth is absolutely the right way to do things. If you try to retrain older programmers, you are basically telling them they have to change decades of learning for a moderate (but not huge) productivity increase, so that programming is accessible to a much wider group of people. Much like with the terminal to GUI transition, you will have people attacking declarative natural language programming as a stupid practice for noobs, and the end of computing (even though it will allow people with much less experience to be more productive than them). > And one again: code is _communication_. Not having
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Tue, Apr 3, 2012 at 9:51 AM, rusi wrote: > On Apr 3, 5:39 pm, Nathan Rice > wrote: >> >> Don't think "underlying", instead think "canonical". >> >> Ultimately, the answers to your questions exist in the world for you >> to see. How does a surgeon describe a surgical procedure? How does a >> chef describe a recipe? How does a carpenter describe the process of >> building cabinets? Aside from specific words, they all use natural >> language, and it works just fine. > > A carpenter describes his carpentry-process in English > A CSist describes his programming-process in English (at least all my > CS books are in English) > > A carpenter uses his tools -- screwdriver, saw, planer --to do > carpentry > A programmer uses his tools to to programming -- one of which is > called 'programming language' > > Doing programming without programming languages is like using toenails > to tighten screws I would argue that the computer is the tool, not the language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Tue, Apr 3, 2012 at 11:01 AM, Ian Kelly wrote: > On Tue, Apr 3, 2012 at 6:39 AM, Nathan Rice > wrote: >> Did you miss the part where I said that most people who learn to >> program are fascinated by computers and highly motivated to do so? >> I've never met a BROgrammer, those people go into sales. It isn't >> because there aren't smart BROmosapiens (sadly, there are), they just >> couldn't give two shits about computers so programming seems like a >> colossal waste of time to them. > > I have never met the brogrammer stereotype. I have also never met the > non-brogrammer stereotype of nerdy solitude (well, maybe once). > That's all these things are -- stereotypes. Real programmers are much > more complex. I have never met a programmer that was not completely into computers. That leaves a lot unspecified though. >> Computers require you to state the exact words you're searching for as >> well. Try looking again, and this time allow for sub-categories and >> synonyms, along with some variation in word order. > > Lazy troll. You made the claim. The onus is on you to provide the evidence. I reserve the right to be lazy :) As part of my troll-outreach effort, I will indulge here. I was specifically thinking about some earlier claims that programming languages as they currently exist are somehow inherently superior to a formalized natural language in expressive power. I think part of this comes from the misconception that terse is better (e.g. Paul Graham's thoughts on car/cdr), which doesn't take into account that your brain compresses frequently occurring English words VERY efficiently, so they actually take up less cognitive bandwidth than a much shorter non-word. This behavior extends to the phrase level as well; longer phrases that are meaningful in their own right take up less bandwidth than short nonsensical word combinations. On the semantic side, most people already understand branched processes and procedures with conditional actions pretty well. People "program" other people to perform tasks constantly, and have been doing so for the entirety of our existence. The problem occurs when programming language specific semantic artifacts must be considered. These artifacts are for the most part somewhat arbitrary, or you would see them frequently in other areas, and they wouldn't confuse people so much. I think the majority of these relate to how the computer operates internally - this is the stuff that really turns most people off to programming. The crux of my view is that programming languages exist in part because computers in general are not smart enough to converse with humans on their own level, so we have to talk to them like autistic 5 year-olds. That was fine when we didn't have any other options, but all the pieces exist now to let computers talk to us very close to our own level, and represent information at the same way we do. Projects like IBM's Watson, Siri, Wolfram Alpha and Cyc demonstrate pretty clearly to me that we are capable of taking the next step, and the resurgence of the technology sector along with the shortage of qualified developers indicates to me that we need to move now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
>> > A carpenter uses his tools -- screwdriver, saw, planer --to do >> > carpentry >> > A programmer uses his tools to to programming -- one of which is >> > called 'programming language' >> >> > Doing programming without programming languages is like using toenails >> > to tighten screws >> >> I would argue that the computer is the tool, not the language. > > "Computer science is as much about computers as astronomy is about > telescopes" -- E W Dijkstra > > Here are some other attempted corrections of the misnomer "computer > science": > http://en.wikipedia.org/wiki/Computer_science#Name_of_the_field I view "computer science" as applied mathematics, when it deserves that moniker. When it doesn't, it is merely engineering. Ironically, telescopes are a tool that astronomers use to view the stars. On Tue, Apr 3, 2012 at 1:25 PM, rusi wrote: > All this futuristic grandiloquence: > > On Apr 3, 10:17 pm, Nathan Rice > wrote: >> The crux of my view is that programming languages exist in part >> because computers in general are not smart enough to converse with >> humans on their own level, so we have to talk to them like autistic 5 >> year-olds. That was fine when we didn't have any other options, but >> all the pieces exist now to let computers talk to us very close to our >> own level, and represent information at the same way we do. Projects >> like IBM's Watson, Siri, Wolfram Alpha and Cyc demonstrate pretty >> clearly to me that we are capable of taking the next step, and the >> resurgence of the technology sector along with the shortage of >> qualified developers indicates to me that we need to move now. > > needs to be juxtaposed with this antiquated view > >> I would argue that the computer is the tool, not the language. > > > ... a view that could not be held by an educated person after the > 1960s -- ie when it became amply clear to all that the essential and > hard issues in CS are about software and not hardware I'll go ahead and forgive the club handed fallacies, so we can have a nice discussion of your primary point. What a civil troll I am :) Lets start with some analogies. In cooking, chefs use recipes to produce a meal; the recipe is not a tool. In architecture, a builder uses a blueprint to produce a building; the blueprint is not a tool. In manufacturing, expensive machines use plans to produce physical goods; the plans are not the tool. You could say the compiler is a tool, or a development environment is a tool. The programming language is a mechanism for communication. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Tue, Apr 3, 2012 at 4:20 PM, Terry Reedy wrote: > On 4/3/2012 8:39 AM, Nathan Rice wrote: > >> Ultimately, the answers to your questions exist in the world for you >> to see. How does a surgeon describe a surgical procedure? How does a >> chef describe a recipe? How does a carpenter describe the process of >> building cabinets? Aside from specific words, they all use natural >> language, and it works just fine. > > > Not really. Surgeon's learn by *watching* a surgeon who knows the operation > and next (hopefully) doing a particular surgery under supervision of such a > surgeon, who watches and talks, and may even grab the instruments and > re-show. They then really learn by doing the procedure on multiple people. > They often kill a few on the way to mastery. Well, there is declarative knowledge and procedural knowledge. In all these cases, only the procedural knowledge is absolutely necessary, but the declarative knowledge is usually a prerequisite to learning the procedure in any sort of reasonable manner. > I first learned basic carpentry and other skills by watching my father. I > don't remember that he ever said anything about how to hold the tools. > > I similarly learned basic cooking by watching my mom. My knowledge of how to > crack open an egg properly and separate the yolk from the rest is a wordless > memory movie. A picture is worth a thousand words :) If you would like, I don't have any problem incorporating visual programming and programming by demonstration. I didn't go in that direction because I have enough to defend as it is. I like to look at it from the perspective of teaching/communicating, rather than operating a simple machine. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
On Wed, Apr 4, 2012 at 1:49 AM, Steven D'Aprano wrote: > On Tue, 03 Apr 2012 13:17:18 -0400, Nathan Rice wrote: > >> I have never met a programmer that was not completely into computers. >> That leaves a lot unspecified though. > > You haven't looked hard enough. There are *thousands* of VB, Java, etc. > code monkeys who got into programming for the money only and who have > zero inclination to expand their skills or knowledge beyond that > necessary to keep their job. Every programmer that I've ever met who got into it for the money has washed out within about five years. Sometimes they make a lateral move to project management, other times they end up as requirements analysts, and occasionally they become technical sales staff. The story is always the same - they do technical mediocre work, but get along well with their peers, so they are transitioned to a role that requires more people skills. I've never met someone who had both poor people skills and mediocre technical skills who actually kept their job. > Go to programming blogs, and you will find many examples of some > allegedly professional programmer selecting an arbitrary blog post to ask > "Pls sombody write me this code", where "this code" is either an utterly > trivial question or a six month project. Honestly, I have seen that, but usually when I inspect closer it is an Indian ODesk or Rent-a-coder worker who oversold himself and is trying to cover his ass. >> As part of my troll-outreach effort, I will indulge here. I was >> specifically thinking about some earlier claims that programming >> languages as they currently exist are somehow inherently superior to a >> formalized natural language in expressive power. > > I would argue that they are, but only for the very limited purpose for > which they are written. With the possible exception of Inform 7, most > programming languages are useless at describing (say) human interactions. > > Human languages are optimised for many things, but careful, step-by-step > algorithms are not one of them. This is why mathematicians use a > specialist language for their problem domain, as do programmers. Human > language is awfully imprecise and often ambiguous, it encourages implicit > reasoning, and requires a lot of domain knowledge: You have to be careful when you bring mathematical notation into the picture. Remember that mathematics has developed over thousands of years, with developments shared in many languages. Greek letters serve the same purpose in math that latin and greek names serve in biology - they are neutral and avoid confusion with common names in "living" languages. Not everything about mathematical notation is good, and in some cases it suffers the same issues that programming does. Mathematicians have a tendency to be very terse, and although some greek letters and symbols have standard meaning, many authors run roughshod over them. Logic is somewhat better than math in this regard, logicians respect their notation and rarely deviate from the standard meaning of symbols. Things ARE getting better, but for the most part it is still kind of a mess. Also, I should clarify that I consider part of mathematical notation to be "natural language", namely +/-/*, and rational numbers. People "discover" these things on their own, mathematics just provides rigor. It is considered bad form to use them in prose, but that is just an arbitrary "style" restriction; children intermix mathematical symbols and language all the time, as to older students taking notes in a variety of subjects. > Joe snatched the hammer from Fred. "Hey," he said, "what are > you doing? Don't you know that he'll hit the roof if he catches > you with that?" Are you trying to get me to write obfuscated code? You can write ambiguous garbage in any language. >> The crux of my view is that programming languages exist in part because >> computers in general are not smart enough to converse with humans on >> their own level, so we have to talk to them like autistic 5 year-olds. >> That was fine when we didn't have any other options, but all the pieces >> exist now to let computers talk to us very close to our own level, and >> represent information at the same way we do. > > I think you're dreaming. We (that is to say, human beings in general, not > you and I specifically) cannot even talk to each other accurately, > precisely and unambiguously all the time. Natural language simply isn't > designed for that -- hence we have specialist languages like legal > jargon, mathematics, and programming languages, for specialist purposes. Legalese is English with a ton of new words. Mathematics is older than most language
Re: Number of languages known [was Re: Python is readable] - somewhat OT
> Long personal note ahead. > tl;dr version: Computers are such a large shift for human civilization > that generally we dont get what that shift is about or towards. Another option: since *computers* are such a general device, there isn't just one notion. > In the long run I expect computing science to transcend its parent > disciplines, mathematics and logic, by effectively realizing a > significant part of Leibniz's Dream of providing symbolic calculation > as an alternative to human reasoning. (Please note the difference > between "mimicking" and "providing an alternative to": alternatives > are allowed to be better.) A thinking machine. +1. > Needless to say, this vision of what computing science is about is not > universally applauded. On the contrary, it has met widespread --and > sometimes even violent-- opposition from all sorts of directions. I > mention as examples > > (0) the mathematical guild, which would rather continue to believe > that the Dream of Leibniz is an unrealistic illusion Mathematics is not a closet guild, it is large and contentious. Ideas live and die in mathematics based on their fundamental truth. If there is some bold, sweeping statement it *MIGHT* be possible to prove or disprove, mathematicians will be all over it. just look at Fermat's last theorem and the Poincare conjecture if you want proof of this. > (1) the business community, which, having been sold to the idea that > computers would make life easier, is mentally unprepared to accept > that they only solve the easier problems at the price of creating much > harder one Most business people I know secretly love when they can sell a solution to one problem that creates new problems (and thus opportunities for new products!). The business term for this is an "Upsell" or "Value-add". > (2) the subculture of the compulsive programmer, whose ethics > prescribe that one silly idea and a month of frantic coding should > suffice to make him a life-long millionaire I love hacker culture, but it has been infected by the idea of entrepreneurship as a good in and of itself. Being a creator is a beautiful thing, go forth and make *art*. Improve the human condition. Make the world a better place. STFU about venture capital and stage 2 funding and minimum viable products; that sort of talk is a sure sign that you haven't created anything of actual value. > (3) computer engineering, which would rather continue to act as if it > is all only a matter of higher bit rates and more flops per second These guys are doing something that I find very uninteresting, but is absolutely necessary. Bravo I say. > (4) the military, who are now totally absorbed in the business of > using computers to mutate billion-dollar budgets into the illusion of > automatic safety Nations will always try and be imperialist. At least drones and robot soldiers mean less human suffering. > (5) all soft sciences for which computing now acts as some sort of > interdisciplinary haven Digital humanities (outside of a VERY small set of projects) is a joke. Multimedia history presentations (and what not) are the domain of edutainment companies, not academia. > (6) the educational business that feels that, if it has to teach > formal mathematics to CS students, it may as well close its schools. I feel quite the opposite actually. At the really top notch computer science schools, there is a clear mathematical bent (though it is interdisciplinary). Places like MIT, Stanford, Berkeley, CMU, Cambridge, etc make a STRONG effort to separate the mathematical/theory of computation side and engineering side. At your average state college, the computer science department is just a hodgepodge, and you tend to see more graphics, "applied computation" and embedded/DSP type people. -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
> The "building cabinets" problem is interesting: > > 1. To actually build a cabinet, there's a lot of domain knowledge > that's probably implicit in most circumstances. A carpenter might > tell another carpenter which hinge to use, but they won't have to talk > about why doors need hinges or how to do the assembly. > 2. It's quite common for humans to use computer programs as part of > the design process. > 3. Often, the output of a CAD program (at the file level) is some > sort of vector representation that only describes the end product > (basic dimensions, etc.). > > I wonder if there are mini-languages out there that allow you to > describe cabinets in a very descriptive way, where the description > easily translates to the actual steps of building the cabinet, not > just the final dimensions. I think if you were to describe the parts of the cabinet that needed to be assembled separately (and thus could be viewed as separate entities in some sense) and showed the cabinet as the composition of those parts, you would be on the right track. Being a mediocre carpenter, I can't really say anything conclusively here though :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Number of languages known [was Re: Python is readable] - somewhat OT
Re-trolling.
On Wed, Apr 4, 2012 at 1:49 AM, Steven D'Aprano
wrote:
>> As part of my troll-outreach effort, I will indulge here. I was
>> specifically thinking about some earlier claims that programming
>> languages as they currently exist are somehow inherently superior to a
>> formalized natural language in expressive power.
>
> I would argue that they are, but only for the very limited purpose for
> which they are written. With the possible exception of Inform 7, most
> programming languages are useless at describing (say) human interactions.
I was thinking about this statement this morning. Compression is just
the process of finding a more efficient encoding for information. I
suppose you could say then that language developers could
theoretically be trying to compress natural language representations
of information. The problem then is that everyone is doing a horrible
job, because they are approaching the subject in an ad hoc manner.
There are multiple branches of mathematics and computer science that
deal with this exact subject in a rigorous way. The trick is to find
an encoding that has low space complexity, and for which the
transformation to knowledge is efficient, for human beings.
Lets assume that the input to be encoded are logical
(proposition/predicate) statements. The first thing that came to mind
when thinking this way is radix trees and directed acyclic word graphs
(a form of DFA). These structures are fairly easy to work out on
paper given a set of inputs, and it is fairly easy to reconstruct a
set of inputs from the structure. Perhaps, we could use natural
language statements, and some very minimal extended syntax to indicate
a data structure (which fans out to a set of statements). As a quick
example to see what I mean (mimicking some python syntax for
similarity):
in the context of chess:
a color is either white or black
the board:
is a cartesian grid having dimension (8, 8)
has squares, representing points on the grid
a square:
has a color
contains a piece or is empty
a piece:
has a color
is located in a square or has been captured
a { king, queen, rook, bishop, knight, pawn } is a type of piece
It should be clear that this is a directed acyclic phrase graph, and
if you select a phrase fragment, then one phrase fragment from each
child level until reaching a leaf, the concatenation of the phrase
fragments forms a logical phrase. Note that the set braces are
shorthand for multiple statements. This was really easy to write, and
I bet even non programmers would have little or no trouble
understanding what was going on. Additionally, I could make a full
statement elsewhere, and if we have an algorithm to transform to a
canonical phrase structure and merge synonyms, it could be inserted in
the phrase graph, just as neatly as if I had written it there in the
first place. The sexy thing about that, is that lets you take two
sets of propositional statements, and perform set theoretic operations
on them (union, complement, etc), and get a phrase graph structure out
at the end which looks just like a nice neat little "program". You
could even get really crazy, if you could define equivalence relations
(other than the natural relation) for the union (Set1.A ~ Set2.B) as
that would let you compose the graphs in arbitrarily many ways. If
you're dealing processes, you would also want to be able to specify
temporal equivalence (Process1.T1 ~ Process2.T6).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Java is killing me! (AKA: Java for Pythonheads?)
public FooClass(String requiredArgument1, Long requiredArgument2, map
yourOptionalArgumentMap) {
...
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: there is a problem, holp someone could help me,thanks
hi John it's simple, let's make a little modification for the scipt: def fib(x): if x==0 or x==1: return 1 else: return fib(x-1) + fib(x-2) for i in range(10): print 'fib(%s): ' % i, fib(i) result: fib(0): 1 fib(1): 1 fib(2): 2 fib(3): 3 fib(4): 5 fib(5): 8 fib(6): 13 fib(7): 21 fib(8): 34 fib(9): 55 you see, when we put 0 or 1 into fib, we definitely get 1 individually, if we put 2 into fib(), inside script we get two fib() result plus 1 + 1. If we put 9 into fib(), we get plus of two results of fib(7) and fib(8), that is 21 + 34, so we get 55. hope it can give you a little help. On Thu, Aug 25, 2011 at 12:46 AM, John Gordon wrote: > In > [email protected] writes: > > > Hi everyone > > > I just study python for a few time. > > Now I have a problem and I holp someone can help me. > > There is a piece of code: > > > def fib(x): > > if x==0 or x==1: return 1 > > else: return fib(x-1) + fib(x-2) > > > Could you explain how it works? > > Thanks for you help. > > > Vince > > When a function calls itself, as fib() does, it's called recursion. > > http://en.wikipedia.org/wiki/Recursion_(computer_science) > > Basically the fib() method keeps calling itself with smaller and smaller > arguments until it gets 1 or 0. > > -- > John Gordon A is for Amy, who fell down the stairs > [email protected] B is for Basil, assaulted by bears >-- Edward Gorey, "The Gashlycrumb Tinies" > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Py_Initialize() fails on windows when SDL.h is included.
I began porting one of my projects from linux (no problems under
linux) to windows, but I am getting the following problem when
attempting to run it (This was within gdb)
warning: Fatal Python error:
warning: Py_Initialize: can't initialize sys standard streams
warning:
I narrowed it down the following testcase,
#include
#include
int main(int argc, char*argv[])
{
Py_Initialize();
}
commenting out the first include (SDL/SDL.h) allows it to run w/o any problems.
SDL-1.2.13, Python 3.1.3 (Also tested w/ 3.2.), GCC 4.5.1,
w32api-3.17.1, mingw-rt-3.18 (Toolchain is a linux to windows cross
compiler, designed from
http://nathancoulson.com/proj_cross_mingw.shtml)
I noticed when I mess with the include order (Python.h before SDL.h), it gives
3rdparty/i686-pc-mingw32/include/SDL/SDL_config.h:131:0: warning:
"HAVE_SNPRINTF" redefined
3rdparty/i686-pc-mingw32/include/python3.2/pyerrors.h:361:0: note:
this is the location of the previous definition
it is defined in SDL_config.h as
#define HAVE_SNPRINTF 1
although no clue if it's related... probably a red herring
--
Nathan Coulson (conathan)
--
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Py_Initialize() fails on windows when SDL.h is included.
Recompiling SDL, using --disable-stdio-redirect fixed this problem.
On Tue, Mar 15, 2011 at 1:48 AM, Nathan Coulson wrote:
> I began porting one of my projects from linux (no problems under
> linux) to windows, but I am getting the following problem when
> attempting to run it (This was within gdb)
>
> warning: Fatal Python error:
> warning: Py_Initialize: can't initialize sys standard streams
> warning:
>
>
> I narrowed it down the following testcase,
>
> #include
> #include
>
> int main(int argc, char*argv[])
> {
> Py_Initialize();
> }
>
> commenting out the first include (SDL/SDL.h) allows it to run w/o any
> problems.
>
> SDL-1.2.13, Python 3.1.3 (Also tested w/ 3.2.), GCC 4.5.1,
> w32api-3.17.1, mingw-rt-3.18 (Toolchain is a linux to windows cross
> compiler, designed from
> http://nathancoulson.com/proj_cross_mingw.shtml)
>
> I noticed when I mess with the include order (Python.h before SDL.h), it gives
>
> 3rdparty/i686-pc-mingw32/include/SDL/SDL_config.h:131:0: warning:
> "HAVE_SNPRINTF" redefined
> 3rdparty/i686-pc-mingw32/include/python3.2/pyerrors.h:361:0: note:
> this is the location of the previous definition
>
> it is defined in SDL_config.h as
> #define HAVE_SNPRINTF 1
>
> although no clue if it's related... probably a red herring
>
> --
> Nathan Coulson (conathan)
> --
> Location: British Columbia, Canada
> Timezone: PST (-8)
> Webpage: http://www.nathancoulson.com
>
--
Nathan Coulson (conathan)
--
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
--
http://mail.python.org/mailman/listinfo/python-list
Looking for ideas on controlling python module loading
Hello, I am working on a client/server program (game) that uses C w/ an embedded python interpreter, that uses python to script what objects do in the game. (primarily a C environment) I was wondering if it is possible to control what modules get loaded (or not). perhaps by determining if the hash of the local file matches a hash provided by the server. I was also wondering, if you could construct a module, without a .py file, and define functions and variables. -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
looking for libpython31.a 64bit (missing from python-3.1.3.amd64.msi)
Well, as the subject says, I am looking to find libpython31.a [win64bit version] for use in a linux to windows 64bit cross compiler [x86_64-w64-mingw32-gcc], but seems to be missing. so far, tried installing it on a real 64bit windows system, cabextract, as well as msiexec /a python-3.1.3.amd64.msi /qb TARGETDIR=out. Either case, libs/libpython31.a is not there. as a last resort, tried cross compiling it with my tools, but a few google searches tell me that way will lead to headaches, and currently not supported out of the box. -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for libpython31.a 64bit (missing from python-3.1.3.amd64.msi)
On Wed, Apr 13, 2011 at 7:03 PM, David Cournapeau wrote: > On Wed, Apr 13, 2011 at 5:17 PM, Nathan Coulson wrote: >> Well, as the subject says, I am looking to find libpython31.a >> [win64bit version] for use in a linux to windows 64bit cross compiler >> [x86_64-w64-mingw32-gcc], but seems to be missing. >> >> so far, tried installing it on a real 64bit windows system, >> cabextract, as well as msiexec /a python-3.1.3.amd64.msi /qb >> TARGETDIR=out. Either case, libs/libpython31.a is not there. >> >> as a last resort, tried cross compiling it with my tools, but a few >> google searches tell me that way will lead to headaches, and currently >> not supported out of the box. > > If you are willing to jump through a few oops. I have documented what > I needed last time I tried mingw-w64 for numpy: > > http://projects.scipy.org/numpy/wiki/MicrosoftToolchainSupport > > If anything, it should be easier now because mingw-w64 is much more > stable can can be installed without being compiled first (I wrote > those notes almost 2 years ago IIRC), > > cheers, > > David actually figured out a neat trick, mingw-w64 can link directly to the .dll. gcc file.c python31.dll -o file.exe no .a needed. http://www.mingw.org/wiki/sampleDLL (have yet to find out if it actually works yet, but so far looks promising) -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
Re: looking for libpython31.a 64bit (missing from python-3.1.3.amd64.msi)
On Wed, Apr 13, 2011 at 7:53 PM, David Cournapeau wrote: > On Thu, Apr 14, 2011 at 11:28 AM, Nathan Coulson wrote: > >> actually figured out a neat trick, mingw-w64 can link directly to the .dll. >> gcc file.c python31.dll -o file.exe >> >> no .a needed. >> >> http://www.mingw.org/wiki/sampleDLL >> >> (have yet to find out if it actually works yet, but so far looks promising) > > Note the "If this method works for your application then there is > usually no need for an import library.". Whether it works or not is > often found the hard way (i.e. you won't have a linking error, but > subtle bugs). Building a .a library is more stable in my experience > (even in 32 bits). > > In any case, note the -DMS_WIN64 which is mandatory if you want to > make it work (without this define, mingw will use the python headers > for 32 bits, with pointers typedef defined for 32 bits pointers > instead of 64 bits, which will not work very well :) ). > > cheers, > > David very good note, had no clue. -- Nathan Coulson (conathan) -- Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://mail.python.org/mailman/listinfo/python-list
Re: "comprehend" into a single value
dict= {10: ['a',1,'c'], 20: ['d',2,'f']}
p = sum([dict[i][1] for i in dict])
Something like that?
On Sat, Oct 7, 2017 at 11:07 PM, Andrew Z wrote:
> Hello,
> i wonder how can i accomplish the following as a one liner:
>
> dict= {10: ['a',1,'c'], 20: ['d',2,'f']}
> p = 0
> for i in dict:
> p += dict[i][1]
>
>
> Thank you
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Fwd: Is there a function of ipaddress to get the subnet only from input like 192.168.1.129/25
Hit wrong button before.
-- Forwarded message --
From: Nathan Hilterbrand
Date: Tue, Oct 17, 2017 at 2:22 PM
Subject: Re: Is there a function of ipaddress to get the subnet only from
input like 192.168.1.129/25
To: Rob Gaddi
I may have misunderstood what you were looking for, but went ahead and
cobbled this ugly function together. Takes a string like "192.168.1.128/25"
as input, and returns the subnet address. Just slapped together, so not
the most robust thing in the world
def subnet(inp):
addr, bits = inp.split('/')
mask = 2 ** (32 - int(bits)) - 1
allones = (2 ** 32) - 1
mask = allones ^ mask
addroctets = [int(o) for o in addr.split('.')]
addrval = 0
for o in addroctets:
addrval = addrval * 256 + o
snval = addrval & mask
snoctets = []
q = snval
for i in range(4):
q,r = divmod(q, 256)
snoctets.insert(0,str(r))
sn = ".".join(snoctets)
return sn
On Tue, Oct 17, 2017 at 1:36 PM, Rob Gaddi wrote:
> On 10/17/2017 09:59 AM, Daniel Flick wrote:
>
>> I am very new to Python and have been struggling to find some info on
>> processing IP addresses.
>>
>> get_network returns 192.168.1.128/25 but I need 192.168.1.128 only. I
>> can do this with netaddr but I am working with Mako templates and ipaddress
>> is a built in module so there are less dependencies.
>>
>> Any ideas?
>>
>>
> You mean, other than .split('/')?
>
> --
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order. See above to fix.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Is there a function of ipaddress to get the subnet only from input like 192.168.1.129/25
Absolutely, Stefan! I like yours a lot better. I am an old perl hack that
is still learning the ins and outs of Python, and this is just the sort of
thing that I like to see.
Thanks!
On Tue, Oct 17, 2017 at 4:19 PM, Stefan Ram wrote:
> Nathan Hilterbrand writes:
> >I may have misunderstood what you were looking for, but went ahead and
> >cobbled this ugly function together. Takes a string like "
> 192.168.1.128/25"
> >as input, and returns the subnet address. Just slapped together, so not
> >the most robust thing in the world
>
> The IP address of the OP has some so-called "host bits" set.
> Therefore, it might not be considered to be a valid subnet
> specification by some parties.
>
> Your code seems to have the intention to remove those
> disturbing host bits. You did this using a bit mask.
> It might also be possible to accomplish the same by
> a right shift plus a left shift, e.g.,
>
> |>>> IPv4Address( int( IPv4Address( '192.168.1.129' ))>> 25 << 25 )
> |IPv4Address('192.0.0.0')
>
> .
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Stackoverflow question: Is there a built-in identity function in Python?
There is a built-in identity function in Python. The function is called
'id'. See https://docs.python.org/3/library/functions.html#id Note that
this will not behave the same across different Python runtimes. e.g.
CPython, IronPython or Jython all implement this differently.
An example:
Python 3.5.2 (default, Sep 14 2017, 22:51:06)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 1
>>> b = 2
>>> id(a)
10911168
>>> id(b)
10911200
>>> c = 1
>>> id (c)
10911168
Regards,
Nathan
On Thu, Dec 7, 2017 at 1:46 PM, Paul Moore wrote:
> On 7 December 2017 at 18:28, Ethan Furman wrote:
> > The simple answer is No, and all the answers agree on that point.
> >
> > It does beg the question of what an identity function is, though.
> >
> > My contention is that an identity function is a do-nothing function that
> > simply returns what it was given:
> >
> > --> identity(1)
> > 1
> >
> > --> identity('spam')
> > 'spam'
> >
> > --> identity('spam', 'eggs', 7)
> > ('spam', 'eggs', 7)
> >
> > Of the five answers to that SO question, mine is the only one that will
> > correctly handle those three examples. If you agree with my contention
> feel
> > free to up-vote my answer. :)
>
> IMO (as a mathematician ;-)) the identity function is a
> *single-argument* function that returns the value passed to it. So:
>
> def identity(x):
> return x
>
> See https://en.wikipedia.org/wiki/Identity_function
>
> identity(1,2) is an error.
>
> Extending the definition to multiple arguments causes all sorts of
> confusion, as you've seen.
>
> Paul
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: mssql date format
Note that this issue is mentioned in the pymssql FAQ:
http://pymssql.org/en/stable/faq.html#pymssql-does-not-unserialize-date-and-time-columns-to-datetime-date-and-datetime-time-instances
Regards,
Nathan
On Mon, Sep 12, 2016 at 8:29 PM, Dennis Lee Bieber
wrote:
> On Tue, 13 Sep 2016 00:52:59 +0100, MRAB
> declaimed the following:
>
> >On 2016-09-13 00:06, sum abiut wrote:
> >> Thanks for the response,
> >> i pulling data from an mssql database and i need to convert the date
> >> column. how to i covert and pass it to my template. i am using Django
> >>
> >> this is what i did
> >>
> >> conn=pymssql.connect(server,username,password,database)
> >> #cus=conn.cursor()
> >> cus=conn.cursor(as_dict=True)
> >> cus.execute("SELECT
> >> account_code,currency_code,balance_date,debit,credit,net_
> change,home_net_change
> >> FROM glbal where account_code= '50101001CORP'")
> >>
> >> return render_to_response('revenue_budget.html',locals())
> >>
> >>
> >> how to i convert the balance_date with the code below:
> >>
> >>
> >>
> >> import datetime
> >> datetime.datetime.fromordinal(733010)
> >>
> >> datetime.datetime(2007, 11, 30, 0, 0)
> >>
> >>
> >The documentation for pymssql should tell you how to get the values of
> >the fields.
> >
> >In the case of the 'balance_date' field, just pass its value into
> >datetime.datetime.fromordinal like the code I gave.
>
> I have a suspicion the OP needs more basic help than that -- like
> how
> to take data from the database, modify it, and pass it on to Django for
> rendering. Note that the sample code never references records from the
> cursor, and seems to just dump [locals()] everthing into the response
> template.
> --
> Wulfraed Dennis Lee Bieber AF6VN
> [email protected]://wlfraed.home.netcom.com/
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Where is the documentation for ','?
The grammar and what it represents is defined at https://docs.python.org/3/reference/expressions.html#expression-lists Regards On Sep 16, 2016 9:59 PM, "Peng Yu" wrote: > OK. But it is documented somewhere in python doc? > > On Fri, Sep 16, 2016 at 9:48 PM, Lawrence D’Oliveiro > wrote: > > On Saturday, September 17, 2016 at 2:05:49 PM UTC+12, Peng Yu wrote: > >> x, y = y, x > > > > It’s just syntactic sugar for > > > > (x, y) = (y, x) > > -- > > https://mail.python.org/mailman/listinfo/python-list > > > > -- > Regards, > Peng > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: xlsxwriter considering worksheet.write as tuple ???
On Mon, Sep 26, 2016 at 6:00 PM, MRAB wrote:
> On 2016-09-26 23:03, M2 wrote:
>
>> Hello
>> The program is designed to collect different statistics from servers
>> across the network and populate in excel sheet.
>> Library : xlsxwriter.0.9.3
>>
>> Below is the Snip of code being used
>> #! /usr/bin/python
>>
>> import xlsxwriter
>> import os;
>> import subprocess;
>> import sys;
>> import os.path;
>>
>>
>> workbook=xlsxwriter.Workbook('Turnover_sheet.xlsx');
>>
>> tools_sheet=workbook.add_worksheet('Citi Tools Verification');
>>
>> hw_sheet=workbook.add_worksheet('Hardware Verification');
>>
>> os_sheet=workbook.add_worksheet('OS Verification');
>>
>> build_spec_sheet=workbook.add_worksheet('Build Specs Verification');
>>
>> info_sheet=workbook.add_worksheet('Server Handover Info');
>>
>> stan_sheet=workbook.add_worksheet('Standards');
>>
>> sup_sheet=workbook.add_worksheet('Support Information');
>>
>> tools_sheet.write('A3', 'Device Name', table_head);
>>
>> tools_sheet.write('B3', 'Machine Category', table_head);
>>
>> tools_sheet.write('C3', 'OS Platform', table_head);
>>
>>
>> hw_sheet.merge_range('A1:N1', 'Hardware Information', head);
>>
>> hw_sheet.merge_range('A2:A3', 'Device Name', table_head);
>>
>> hw_sheet.merge_range('B2:B3', 'CPU / vCPU Count', table_head);
>>
>>
>> os_sheet.merge_range('A2:A3', 'Server Name', table_head);
>>
>> os_sheet.merge_range('B2:B3', 'Kdump Config', table_head);
>> os_sheet.merge_range('C2:C3', 'Grub Config', table_head);
>>
>>
>> info_sheet.write('A1', 'Server Name', table_head);
>>
>> info_sheet.write('B1', 'Serial Number', table_head);
>>
>> info_sheet.write('C1', 'Backup Type', table_head);
>>
>>
>> stan_sheet.write('A1', 'Item', table_head);
>>
>> stan_sheet.write('B1', 'Standard', table_head);
>>
>> stan_sheet.write('C1', 'Comments', table_head);
>>
>>
>> def data_collection(fqdn,counter):
>> counter=int(counter);
>> red_counter=(int(counter))-2;
>> s_count='A'+str(counter);
>> s_r_count='A'+str(red_counter);
>> tools_sheet.write(s_count,fqdn,cell_format);
>> hw_sheet.write(s_count,fqdn,cell_format);
>> os_sheet.write(s_count,fqdn,cell_format);
>> info_sheet.write(s_r_count,fqdn,cell_format);
>> s_count='D'+str(red_counter);
>> sup_sheet.write(s_count,fqdn,cell_format);
>>
>> I get the following error
>> sup_sheet.write(s_count,fqdn,cell_format);
>> TypeError: 'tuple' object is not callable
>>
>> What I do not understand is why is python thinking sup_sheet.write as
>> tuple.
>> I tired to debug the program and added the following line
>> print "\ts_count is ", type(s_count)," and value",s_count,"\n\tfqdn is ",
>> type(fqdn), " and value is ",fqdn,"\n\tcell_format is ", type(cell_format),
>> " and value is ",cell_format,"\n\t sup_sheet is ",type(sup_sheet)," and
>> value is ",sup_sheet,"\n\n\n";
>>
>> just before
>> sup_sheet.write(s_count,fqdn,cell_format);
>>
>> And I got the following output:
>> s_count isand value D2
>> fqdn isand value is Sample1.xyz.com
>> cell_format isand value is
>>
>> sup_sheet isand
>> value is
>>
>>
>>
>> s_count isand value D3
>> fqdn isand value is sample2.xyz.com
>> cell_format isand value is
>>
>> sup_sheet isand
>> value is
>>
>>
>>
>> Traceback (most recent call last):
>> File "./turnover_sheet.py", line 398, in
>> data_population(str(sys.argv[1]));
>> File "./turnover_sheet.py", line 380, in data_population
>> data_collection(fqdn,count);
>> File "./turnover_sheet.py", line 219, in data_collection
>> sup_sheet.write(s_count,fqdn,cell_format);
>> TypeError: 'tuple' object is not callable
>>
>> I also saw the sheet populated with the first server and when it went to
>> the second server and while populating it considered
>> sup_sheet.write as a tuple which makes no sense because the rest of the
>> writes are working fine.
>>
>> I have no clue why is it doing it ?
>> Thoughts ?
>>
>> I can't see a problem in the part of the code that you've posted.
>
> Are there any other lines that use 'sup_sheet'?
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
There's nothing wrong with the snippet as shown - the problem must be
elsewhere. I took the snippet as in the original email and made some
slight changes to define cell_format, head and table_head & close the
workbook:
#!/usr/bin/env python
import xlsxwriter
import os;
import subprocess;
import sys;
import os.path;
workbook = xlsxwriter.Workbook('Turnover_sheet.xlsx');
cell_format = workbook.add_format({})
head = table_head = workbook.add_format({'bold': True})
# snipped the rest
data_collection("sample1.xyz.com", 2)
data_collection("sample2.xyz.com", 3)
workbook.close()
This runs cleanly for me with xlsxwriter 0.9.3 on Python 2.7.6.
I understand this is a snippet, but it feels like you may be reassigning
sup_sheet. Or, possibly assigning to "sup_sheet.w
Re: xlsxwriter considering worksheet.write as tuple ???
There's a bug at line 362: sup_sheet.write=(s_count,"VM", cell_format); ---^ Like I suggested, you've an errant assignment to sup_sheet.write. Also, a couple of notes on style: the terminating semicolons in your code is unnecessary. It's only needed for multiple statements on a single line. Please use a single space on each side of a binary operator or assignment - it improves readability. Regards, On Mon, Sep 26, 2016 at 8:18 PM, Mohan Mohta wrote: > On Monday, September 26, 2016 at 8:08:13 PM UTC-5, MRAB wrote: > > On 2016-09-27 01:34, Mohan Mohta wrote: > > > On Monday, September 26, 2016 at 6:56:20 PM UTC-5, Nathan Ernst wrote: > > >> On Mon, Sep 26, 2016 at 6:00 PM, MRAB > wrote: > > >> > > >> > On 2016-09-26 23:03, M2 wrote: > > >> > > > >> >> Hello > > >> >> The program is designed to collect different statistics from > servers > > >> >> across the network and populate in excel sheet. > > >> >> Library : xlsxwriter.0.9.3 > > >> >> > > >> >> Below is the Snip of code being used > > [snip] > > >> >> > > >> >> Traceback (most recent call last): > > >> >> File "./turnover_sheet.py", line 398, in > > >> >> data_population(str(sys.argv[1])); > > >> >> File "./turnover_sheet.py", line 380, in data_population > > >> >> data_collection(fqdn,count); > > >> >> File "./turnover_sheet.py", line 219, in data_collection > > >> >> sup_sheet.write(s_count,fqdn,cell_format); > > >> >> TypeError: 'tuple' object is not callable > > >> >> > > >> >> I also saw the sheet populated with the first server and when it > went to > > >> >> the second server and while populating it considered > > >> >> sup_sheet.write as a tuple which makes no sense because the rest > of the > > >> >> writes are working fine. > > >> >> > > >> >> I have no clue why is it doing it ? > > >> >> Thoughts ? > > >> >> > > >> >> I can't see a problem in the part of the code that you've posted. > > >> > > > >> > Are there any other lines that use 'sup_sheet'? > > >> > > > >> There's nothing wrong with the snippet as shown - the problem must be > > >> elsewhere. I took the snippet as in the original email and made some > > >> slight changes to define cell_format, head and table_head & close the > > >> workbook: > > >> > > >> #!/usr/bin/env python > > [snip] > > > > > > But when it picks the second server from the list and starts doing > what it needs to do then for whatever reason it thinks that this is a tuple > > > sup_sheet.write(s_count,fqdn,cell_format); > > > > > > > > > Let me know if you need I can load the entire program ( if it helps ) > > > It is just that it is a still in progress and is a 400+ lines of code. > > > > > You could post the code at Pastebin.com to avoid filling people's > inboxes. > > Here you go > http://pastebin.com/YsbV79XM > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: cx_freeze_zipimporter_instance
No, because you've not provided anything resembling a question or a problem. Please provide a minimal example set of code that exposes the problem you are encountering, and describe the problem you are having. And note that we will not write code for you if it ends up looking like a homework problem. Regards On Tue, Nov 1, 2016 at 10:55 PM, wrote: > can anybody help me in this problem... > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Best way to go about embedding python
In regards to performance of Lua vs Python, I don't have enough (near zero experience) with Lua to comment there. But in regards to embedding in a game, the only experience I have w/ Python being embedded is while working on modding Civilization IV. What I saw there just made me nauseous. The reasoning for moving to Lua in Civilization V was performance & memory usage - but they completely screwed up exposing the C++ internals to Python in Civ IV. They copied object instances & containers to the Python embedded, then marshalled them back to the C++ code when the Python code was finished. It was horribly inefficient. I don't have much experience hosting Python inside of a C/C++ app, but I've 10 years of experience consuming C++ APIs from Python, mostly wrapped using Boost Python. I always did my best to minimize data marshalling. The Python objects exposed the C++ objects' interface, directly while holding a pointer (usually shared) to underlying C++ objects and only marshalling on method/property calls where needed (i.e. w/ strings, dates, datetimes). Containers were wrapped to expose a Python interface to an underlying C++ container w/ no copying. TLDR; Civilization IV shows an antipattern about how to embed Python in a native app and expecting anything resembling good performance. Civ IV used Boost Python, but they did it in an extremely poor, suboptimal fashion. Boost Python itself can be very performant, and I love the library. Boost Python, however does suffer from a learning curve that is akin to attempting to scale a 1000ft cliff with no rope or tools or even shoes. Due to the heavy use of template metaprogramming in C++, compiler errors if you're even just slightly off can be extremely hard to decipher. I've not used it lately or on modern compilers, so I don't know if it's gotten better, but tools like pretty_make.py (can find on github) can help filter out the compiler spewage from the real compiler error. PS. I don't think that Python couldn't/shouldn't be used for scripting a game, I'm just offering up Civ IV as an example of how it can be done horribly wrong. Regards, Nate On Sun, Nov 13, 2016 at 7:03 PM, Chris Angelico wrote: > On Mon, Nov 14, 2016 at 11:40 AM, Steve D'Aprano > wrote: > > On Mon, 14 Nov 2016 12:23 am, Chris Angelico wrote: > > > >> Python without its stdlib is a disappointingly featureless > >> language :) > > > > > > I don't think that's true. You can do a lot in Python without any > imports in > > your code: > > > > - basic string processing > > - BigNum (int) and float arithmetic > > - lists and tuples > > - dicts > > - lazy processing of iterators > > - custom functions and classes > > - functional style zip, map and filter > > > > and more. > > > > Some parts of the standard library are required for built-in functions, > e.g. > > the io module is needed to open files. But I think you could probably > > reduce the standard library by, oh, 90% and still have a decent language > > for game scripting. > > Perhaps what would be more accurate is that Python without its stdlib > is as featureless as (say) Lua, but still without being safe to embed. > Yes, it's technically usable, but you really don't have a lot. And > remember, some of the stdlib is what we call builtins; if you embed > Python and engage "restricted mode", it's by emptying out the > builtins. You're pretty much down to three things: > > 1) Stuff that you could pass to ast.literal_eval > 2) Control flow statements > 3) Hacks that get you around the limitations, thus proving that > Python-without-stdlib is really really hard to actually test anything > with. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: help on "from deen import *" vs. "import deen"
I would also toss in there: never name a script test.py. Causes nothing but trouble, at least in python2. On Nov 17, 2016 8:01 PM, wrote: > Steven D'Aprano at 2016/11/17 4:04:04PM wrote: > > The most important thing you should learn from this thread is: > > > > - avoid using "from module import *" as it is usually more trouble > > than it is worth. > > > > > > It is confusing and leads to more problems than it solves. If Python was > being > > invented now, rather than 20 years ago, I would expect that there would > be no > > "import *" in the language. > > It's the greatest advice I ever had in Python:-) > > --Jach > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Unexpected PendingDeprecationWarning
I'm using Python 3.5.2, and the following code (when invoked) causes a PendingDeprecationWarning when used in a unit test: def identity(x): return x def adjacent_difference(seq, selector=identity): i = iter(seq) l = selector(next(i)) while True: r = selector(next(i)) yield r - l l = r I wrote this to mimic the C++ std algorithm (defined here: http://en.cppreference.com/w/cpp/algorithm/adjacent_difference). What I don't understand is why I get this warning. The exact error message I get from unittest is: PendingDeprecationWarning: generator 'adjacent_difference' raised StopIteration I'd appreciate any insight into what is causing this deprecation warning, as I am stumped. Regards, Nate -- https://mail.python.org/mailman/listinfo/python-list
Re: Unexpected PendingDeprecationWarning
Thanks, I was not aware of that PEP. The logic in my function is exactly as desired, so to squelch the warning, I merely wrapped the iteration in a try/except: def adjacent_difference(seq, selector=identity): i = iter(seq) l = selector(next(i)) try: while True: r = selector(next(i)) yield r - l l = r except StopIteration: return On Tue, Nov 22, 2016 at 9:02 PM, MRAB wrote: > On 2016-11-23 02:50, Nathan Ernst wrote: > >> I'm using Python 3.5.2, and the following code (when invoked) causes a >> PendingDeprecationWarning when used in a unit test: >> >> def identity(x): >> return x >> >> def adjacent_difference(seq, selector=identity): >> i = iter(seq) >> l = selector(next(i)) >> while True: >> r = selector(next(i)) >> yield r - l >> l = r >> >> I wrote this to mimic the C++ std algorithm (defined here: >> http://en.cppreference.com/w/cpp/algorithm/adjacent_difference). >> >> What I don't understand is why I get this warning. >> >> The exact error message I get from unittest is: >> PendingDeprecationWarning: generator 'adjacent_difference' raised >> StopIteration >> >> I'd appreciate any insight into what is causing this deprecation warning, >> as I am stumped. >> >> The 'while' loop keeps calling next(i) until it raises StopIteration, and > that kind of behaviour can hide obscure bugs. > > If you want to know the details, you can read the rationale behind the > change in the relevant PEP: > > PEP 479 -- Change StopIteration handling inside generators > https://www.python.org/dev/peps/pep-0479/ > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Unexpected PendingDeprecationWarning
Thanks, ChrisA On Tue, Nov 22, 2016 at 9:24 PM, Chris Angelico wrote: > On Wed, Nov 23, 2016 at 2:14 PM, Nathan Ernst > wrote: > > I was not aware of that PEP. > > > > The logic in my function is exactly as desired, so to squelch the > warning, > > I merely wrapped the iteration in a try/except: > > > > def adjacent_difference(seq, selector=identity): > > i = iter(seq) > > l = selector(next(i)) > > try: > > while True: > > r = selector(next(i)) > > yield r - l > > l = r > > except StopIteration: > > return > > You'll probably want to move the 'try' up one line - unless you want > an exception if the sequence is empty. And it's exactly this kind of > ambiguity that this change helps to catch. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: NameError
I don't see anything in that output resembling an error, just a few warnings that some features may no be available. Have you tried importing pygame after you did that? That's what'll prove one way or another that it worked. Regards, Nate On Wed, Nov 23, 2016 at 10:48 PM, Cai Gengyang wrote: > Yea, using Mac > > Following the instructions here for Mac ---https://bitbucket.org/ > pygame/pygame/issues/82/homebrew-on-leopard-fails-to- > install#comment-627494 > > GengYang Cai CaiGengYangs-MacBook-Pro:~ CaiGengYang$ brew install python > ==> Installing dependencies for python: xz, pkg-config, readline, sqlite, > ==> Installing python dependency: xz > ==> Downloading https://homebrew.bintray.com/. > ../xz-5.2.2.yosemite.bottle.ta > > 100.0% > ==> Pouring xz-5.2.2.yosemite.bottle.tar.gz > 🍺 /usr/local/Cellar/xz/5.2.2: 91 files, 1.4M > ==> Installing python dependency: pkg-config > ==> Downloading https://homebrew.bintray.com/. > ../pkg-config-0.29.1_1.yosemit > > 100.0% > ==> Pouring pkg-config-0.29.1_1.yosemite.bottle.tar.gz > 🍺 /usr/local/Cellar/pkg-config/0.29.1_1: 10 files, 627.3K > ==> Installing python dependency: readline > ==> Downloading https://homebrew.bintray.com/. > ../readline-6.3.8.yosemite.bot > > 100.0% > ==> Pouring readline-6.3.8.yosemite.bottle.tar.gz > ==> Caveats > This formula is keg-only, which means it was not symlinked into /usr/local. > > OS X provides the BSD libedit library, which shadows libreadline. > In order to prevent conflicts when programs look for libreadline we are > defaulting this GNU Readline installation to keg-only. > > Generally there are no consequences of this for you. If you build your > own software and it requires this formula, you'll need to add to your > build variables: > > LDFLAGS: -L/usr/local/opt/readline/lib > CPPFLAGS: -I/usr/local/opt/readline/include > > ==> Summary > 🍺 /usr/local/Cellar/readline/6.3.8: 46 files, 2M > ==> Installing python dependency: sqlite > ==> Downloading https://homebrew.bintray.com/. > ../sqlite-3.13.0.yosemite.bott > > 100.0% > ==> Pouring sqlite-3.13.0.yosemite.bottle.tar.gz > ==> Caveats > This formula is keg-only, which means it was not symlinked into /usr/local. > > OS X provides an older sqlite3. > > Generally there are no consequences of this for you. If you build your > own software and it requires this formula, you'll need to add to your > build variables: > > LDFLAGS: -L/usr/local/opt/sqlite/lib > CPPFLAGS: -I/usr/local/opt/sqlite/include > > ==> Summary > 🍺 /usr/local/Cellar/sqlite/3.13.0: 10 files, 2.9M > ==> Installing python dependency: gdbm > ==> Downloading https://homebrew.bintray.com/. > ../gdbm-1.12.yosemite.bottle.t > > 100.0% > ==> Pouring gdbm-1.12.yosemite.bottle.tar.gz > 🍺 /usr/local/Cellar/gdbm/1.12: 18 files, 490.8K > ==> Installing python dependency: openssl > ==> Downloading https://homebrew.bintray.com/. > ../openssl-1.0.2h_1.yosemite.b > > 100.0% > ==> Pouring openssl-1.0.2h_1.yosemite.bottle.tar.gz > ==> Caveats > A CA file has been bootstrapped using certificates from the system > keychain. To add additional certificates, place .pem files in > /usr/local/etc/openssl/certs > > and run > /usr/local/opt/openssl/bin/c_rehash > > This formula is keg-only, which means it was not symlinked into /usr/local. > > Apple has deprecated use of OpenSSL in favor of its own TLS and crypto > libraries > > Generally there are no consequences of this for you. If you build your > own software and it requires this formula, you'll need to add to your > build variables: > > LDFLAGS: -L/usr/local/opt/openssl/lib > CPPFLAGS: -I/usr/local/opt/openssl/include > > ==> Summary > 🍺 /usr/local/Cellar/openssl/1.0.2h_1: 1,691 files, 12.0M > ==> Installing python > Warning: Building python from source: > The bottle needs the Apple Command Line Tools to be installed. > You can install them, if desired, with: > xcode-select --install > > ==> Downloading https://www.python.org/.../2.7.12/Python-2.7.12.tar.xz > > 100.0% > ==> Downloading https://bugs.python.org/file30805/issue10910- > workaround.txt > > 100.0% > ==> Patching > ==> Applying issue10910-workaround.txt > patching file Include/pyport.h > Hunk #1 succeeded at 713 (offset 14 lines). > Hunk #2 succeeded at 736 (offset 14 lines). > ==> ./configure --prefix=/usr/local/Cellar/python/2.7.12 --enable-ipv6 > --dataroo > ==> make > /usr/local/share/python/easy_install mecurial > > brew install sdl > brew ins
Re: printing funny symbols within spyder ide
You're attempting to print out control characters most of which have no
visible representation. For "\7", at least if you're running from bash, and
not in an IDE, you should get an audible bell. All decimal ordinals below
32 are control
You can find a list of the symbols here:
http://en.cppreference.com/w/c/language/ascii
Even though this is an ASCII table, the ordinals for characters are the
same as in UTF-8 encoding.
Regards.
On Thu, Nov 24, 2016 at 1:46 PM, andy wrote:
> when printing these 'escaped-number-texts' within Linux/Spyder3 ide
> console, i get funny symbols like a "phone-symbol", triangles or symbols
> for male or female.
>
> >>> print("\7") # gives a phone
> >>> print("\5")
> >>> print("\1")
> >>> print("\21")
> >>> print("\30")
> >>> print("\31")
> >>> print("\32")
>
> def phonesymbol():
> print("\7")
>
> phonesymbol() # prints a phone symbol
>
> my question is, is this a bug or a feature of Spyder3?
> if it is a feature, where can I find the complete table of symbols?
>
> within bash - starting python3 - i get some ugly "unicode?" symbols,
> which look like a square containig tiny alphanumeric numbers.
>
> best regards
> andy
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
Sure, what if the input used a double quote instead of single, cursory
glance looks like it might vulnerable.
(Not trying to be argumentative here)
On Nov 26, 2016 7:21 PM, "Steve D'Aprano"
wrote:
> On Sun, 27 Nov 2016 11:25 am, Chris Angelico wrote:
>
> > On Sun, Nov 27, 2016 at 11:13 AM, Steve D'Aprano
> > wrote:
> >> So-called f-strings haven't even hit the already been implicated in a
> >> code-injection vulnerability:
> >>
> >> http://bugs.python.org/issue28563
> >>
> >> I feel kind of vindicated here, because when so-called f-strings were
> >> first proposed I asked about the security implication of another way of
> >> evaluating arbitrary expressions, and I was told that there were no
> >> security implications. Technically that might be true in the sense that
> >> f-strings don't do anything that wasn't already possible, but as the
> >> above bug shows, they can make exploiting code injection trivially easy
> >> in cases where they were previously diabolically hard.
> >
> > Given that the exploit exists in 2.7, I would say f-strings didn't
> > create this, eval did.
>
> I never said that f-strings caused the vulnerability. I choose my words
> carefully. As I said when I mentioned this issue three weeks ago, the
> underlying cause of the vulnerability is the use of eval on an untrusted
> string. But the existence of a theoretical vulnerability is not the same as
> an exploit, let alone an easy exploit.
>
>
> > The problem is that you absolutely CANNOT
> > "sanitize" something before giving it to eval.
>
> Be careful about making absolute claims. I challenge you to break this use
> of eval:
>
> def calculate(phrase):
> try:
> phrase = sanitize(phrase)
> except ValueError:
> return
> return eval(phrase, {'x': 20})
>
>
> def sanitize(phrase):
> phrase = phrase.replace(' ', '')
> if phrase in ('x+1', '2*x'):
> return phrase
> raise ValueError('unsafe phrase')
>
>
> For a more practical example, namedtuple uses exec to dynamically build the
> class. Can you find a code injection attack in namedtuple? I doubt it. Not
> all uses of exec or eval lead to a code injection vulnerability.
>
>
> > An f-string slips past the sanitizer, but so do other things.
>
> I daresay you are right that a sufficiently clever adversary may have found
> an exploit. But there's no sign that anyone actually did find an exploit,
> until f-strings made exploiting this trivial.
>
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: The Case Against Python 3
You're right. Didn't look closely enough at it in my phone. Still don't think i'd recommend this in a general solution, though. You effectively have to white-list code snippets. Not very useful. On Nov 26, 2016 7:51 PM, "Michael Torrie" wrote: > On 11/26/2016 06:26 PM, Nathan Ernst wrote: > > Sure, what if the input used a double quote instead of single, cursory > > glance looks like it might vulnerable. > > Either a single quote or a double quote would not pass the sanitizer. Or > am I misunderstanding you? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Asyncio -- delayed calculation
To be fair, in other languages, such as C# or C++ with similar mechanisms, if you don't ask for the result from an async or future task, there's no guarantee the async task will be executed at all unless (or until) you ask for the result. C++'s futures even give an explicit flag indicating you want the task to be executed on the current thread, but deferred until the result is asked for. I'm sure the people on the standards committee had a rationale for this, but I see only marginal utility for that use case (maybe such as a cancellable expensive calc?). Seems like "I might need the result of this calc down the road, but I don't need it currently, so I'll just kick the can down the road.". I'm not aware of a mechanism to make C# behave that way, but I know it's possible that tasks will not execute until they're asked for their result, but I don't know that it is 100% deterministic. To be honest, I think async/await stile programming is so new that there's not a lot of good material about how to properly use it (as far as both when and how). The limit of my experience has been in C# dealing with web requests, where the usage is basically, I'm going to need this data, so I'll fire off the async request for it, and I've got a lot of work I can do before I need the result, so lets do that, until I need to wait (await) for the result of that request before I can proceed any further. It can be useful, but it is a new, completely different paradigm and methodology to wrap ones head around. I've used it for about 2 years in C# land, and I still don't know that I'm doing it right. I've not done any async/await in Python space, but I'm eager to learn and try, when it may be appropriate, But, most of my current use cases don't require it. On Mon, Nov 28, 2016 at 10:37 PM, Chris Angelico wrote: > On Tue, Nov 29, 2016 at 3:16 PM, Gregory Ewing > wrote: > > Chris Angelico wrote: > >> > >> "await" means "don't continue this function until that's done". It > >> blocks the function until a non-blocking operation is done. > > > > > > However, *not* using 'await' doesn't mean the operation > > will be done without blocking. Rather, it won't be done > > at all (and is usually an error, but there's no way for > > the implementation to detect it at the time). > > > > I don't blame Steve for being confused. All the > > terminology around async/await is inherently confusing > > and counterintuitive, IMO. I'm disappointed that we've > > ended up here. > > Asynchronous I/O is something to get your head around. As someone who > teaches both JavaScript and Python, I've run into this quite a bit, > and frankly, callbacks may be easy to explain at a concrete level, but > I'd much rather work with generator-based async functions (which JS is > getting soon too). The best way to think about it IMO is a "process" > that does blocking calls, and which the "system" can multitask away > from any time it's blocked. Your function awaits something, but Python > doesn't. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Rather than argue about what is/should be allowed by a filesystem, this defines what is allowed on NTFS (default for modern Windows systems): https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx One can complain about whether or not something should be allowed, but, you'd have to take that up with Microsoft (and I'll doubt you'll make a convincing enough argument for them to change it). What is allowed on linux may be defined by linux itself, and it may be restricted by the filesystem type itself (I don't know). Regards, Nathan On Mon, Dec 5, 2016 at 8:25 PM, Dennis Lee Bieber wrote: > On Mon, 5 Dec 2016 20:55:41 +, BartC declaimed the > following: > > >This was a response to someone saying the wildcard param needs to be at > >the end. There need be no such restriction if handled properly (ie. no > >auto-expansion). > > > That only applies if there is no prefix indicating a command option > from a file name. > > >but one of the files in the list is called "-lm", or some other option > > -lm is not a valid file name on the OS's that use - as an option > prefix. > > >Without expansion, input is easy to parse: filespec, followed by > >optional options. But with expansion, now you have to decide if a > >particular argument is an option, or a filename. > > > And you do that using a delimiter character that is not valid in > filenames. On Windows, file names can not have a /, and that is the > character used by the command line interpreter to indicate an option > follows. On UNIX, - is used as the delimiter of an option. > > -- > Wulfraed Dennis Lee Bieber AF6VN > [email protected]://wlfraed.home.netcom.com/ > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
Ifyou're running on Windows 10, at least, you can soon purge that memory. command.com doesn't exist (may never have existed on Win2k, XP, Vista, 7, 8, 8.1 or 10). If I try and run either "command" or "command.com" from Win10, both say command cannot be found. IIRC, command.com was a relic of Win9x running on top of DOS and was a 16-bit executable, so inherently crippled (and probably never support by the NT kernel). Whereby cmd.exe coexisted but ran in a 32-bit context. On Mon, Dec 5, 2016 at 8:44 PM, Steve D'Aprano wrote: > On Tue, 6 Dec 2016 10:09 am, eryk sun wrote: > > > On Mon, Dec 5, 2016 at 4:49 PM, Steve D'Aprano > > wrote: > >> > >> You've never used cmd.com or command.exe? "The DOS prompt"? > > > > The default Windows shell is "cmd.exe", and it's informally called the > > "Command Prompt", > > Thanks for the correction, I always mix up cmd/command . exe/com. I fear > this won't be the last time either -- I wish there was a good mnemonic for > which is which. > > > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
OT, but I'm curious, do they explain *why* it's wrong and give an alternative, or just outright deride it as "the wrong way". I ask because I've read similar complaints about the community around systemd, but as it rarely affects me personally, I've never bothered to care. On Mon, Dec 5, 2016 at 8:48 PM, Steve D'Aprano wrote: > On Tue, 6 Dec 2016 11:08 am, Michael Torrie wrote about systemd: > > > I have yet to see any evidence of this Pyonguang situation. > > Let me guess... you're running a single-user Linux box? > > Fortunately, I've managed to avoid needing to personally interact with > systemd at all. But over the last year or so, I've had to listen to a > continual chorus of complaints from the sys admins I work with as they > struggle to adapt our code to the Brave New World of systemd. > > Let me put it this way: one of our techs took it upon himself to migrate > our > Python code base from Python 2.6 to 3.4, some tens of thousands of lines. > It took him half of one afternoon. > > In comparison, migrating to systemd has given us nothing but headaches, and > invariably when we try asking for help on the main systemd IRC channel > we're told that we're wrong for wanting to do what we want to do. > > Not just "systemd can't do that", but "you shouldn't do that". > > Why not? We used to do it, and it is necessary for our application. > > "Because its wrong." > > > > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
One other consideration in regards to globbing in the argument list: there's a static limit to the byte length of argv. On windows, it's 8191 bytes (I'm assuming a null-terminator brings that to 8192, which is a weird 2**13). For Linux, as of kernal 2.6.25, apparently, the limit is 131072 bytes, an equally odd choice of 2**17 bytes. I'm not sure if globs directly to commands bypass these restrictions, but I've seen real world issues with build systems with thousands of files that attempted to pass all dependencies to a target that blew up spectacularly (one of the reasons cl & link on windows accept argument files as input instead of just command line arguments). Regards, Nate On Tue, Dec 6, 2016 at 4:24 PM, Chris Angelico wrote: > On Wed, Dec 7, 2016 at 8:46 AM, Cameron Simpson wrote: > > Nothing prevents you writing an extremely simple shell yourself you > know. It > > needn't expand anything. _Or_ you could have it adopt the inverse > > convention: expand nothing unless asked. Eg: > > > > cp G:*.c > > > > to cause "*.c" to get expanded. Of course, because the various > executables > > don't feel any burden to implement globbing you may run into some > impedence > > mismatch. > > I actually have something like this in one application's inbuilt > command executor - it does globbing ONLY if the parameter starts with > a question mark (eg "?*.c" will glob "*.c" in that directory). It's > deliberate, but frankly, it ends up annoying more often than not. I'm > considering switching to a more normal way of doing it. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
With a case-sensitive file system, how do you search only for 'harry', not knowing what combinations of upper and lower case have been used? (It's a good thing Google search isn't case sensitive!) On Linux, I'd do "find . -iname harry". A lot, but not all, of the tools usually have options to ignore case. I don't know how this works with unicode, as I don't normally have to deal with non-ASCII, either. Probably the only time I see unicode is when I see files with symbols for currencies instead of the ISO-3 currency code (I work in finance) and occasionally in company names. Regards, Nate On Thu, Dec 8, 2016 at 7:34 PM, BartC wrote: > On 09/12/2016 00:55, Chris Angelico wrote: > >> On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote: >> > > So it it perfectly possible to have case conversion defined for English, >>> while other alphabets can do what they like. >>> >> >> And there we have it. Not only do you assume that English is the >> only thing that matters, you're happy to give the finger to everyone >> else on the planet. >> > > I haven't given the finger to anybody. I'm not an expert on all these > other languages, but I don't want to tell them what to do either. /They/ > decide what meaning upper/lower has, if any. > > Or maybe we can just do away with it altogether. (What are Python's > .lower/.upper used for, after all? With any such functions, you are > guaranteed to find a Unicode sequence which is going to give trouble. So > take them out so as not to offend anyone!) > > It does seem however as though users of other languages are telling /me/ > how I should deal with English, which is what I spend nearly 100% of my > life dealing with (those language lessons not having worked out...). > > >> It is a little ridiculous however to have over two thousand distinct files >>> all with the lower-case normalised name of "harry_potter". >>> >> >> It's also ridiculous to have hundreds of files with unique two-letter >> names, but I'm sure someone has done it. The file system shouldn't >> stop you >> > > With a case-sensitive file system, how do you search only for 'harry', not > knowing what combinations of upper and lower case have been used? (It's a > good thing Google search isn't case sensitive!) > > What were we talking about again? Oh yes, belittling me because I work with >> >>> Windows! >>> >> >> Or because you don't understand anything outside of what you have >> worked with, and assume that anything you don't understand must be >> inferior. It's not a problem to not know everything, but you >> repeatedly assert that other ways of doing things are "wrong", without >> acknowledging that these ways have worked for forty years and are >> strongly *preferred* by myriad people around the world. I grew up on >> OS/2, using codepage 437 and case insensitive file systems, and there >> was no way for me to adequately work with other Latin-script >> languages, >> > > I developed applications that needed to work in French, German and Dutch, > apart from English. That might have been long enough ago that I may have > had to provide some of the fonts (both bitmap and vector), as well as > implement suitable keyboard layouts used with digitising tablets. /And/ > provide support in the scripting languages that went with them. > > Not particularly demanding in terms of special or quirky characters (or > word-order issues when constructing messages for translation) but it's not > quite the same as my assuming everything was 7-bit ASCII and in English. > > much less other European languages (Russian, Greek), and > >> certainly I had no way of working with non-alphabetic languages >> (Chinese, Japanese). Nor right-to-left languages (Hebrew, Arabic). >> > > Did you really need to work with all those languages, or is this a generic > 'I'. > > > -- > Bartc > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Choosing a Python IDE. what is your Pythonish recommendation? I do not know what to choose.
Have you looked into Visual Studio Code (https://code.visualstudio.com/)? I've not used it extensively, and only on Windows, but it's an open source IDE originated by MS that purportedly works on Windows, Linux & OS X. It does have pretty decent Python support (haven't tried debugging, but syntax highlighting works well). There's also a really good vim extension available. I tend to prefer vim (or vim extensions) when I can because even though I probably know less than 10% of vim's capabilities, I'm more productive using it. I also use the VsVim extension in full proper Visual Studio. Regards, Nate On Thu, Jan 5, 2017 at 12:12 PM, Chris Clark wrote: > I want an IDE that I can use at work and home, linux and dare I say > windows. > > Sublime, had to remove it from my work PC as it is not licensed. > > Atom, loved it until it slowed down. > > VIM, ok the best if you know vi inside out. > > Any JAVA based IDE, just slows up on work PC's due to all the background > stuff that corporates insist they run. > > Why can not someone more clever than I fork DrPython and bring it up to > date. > > Its is fast, looks great and just does the job ? > > Its wx, no idea if that is good or bad but it just works. > > > > From: Python-list > on behalf of ArnoB > Sent: 05 January 2017 17:32:33 > To: [email protected] > Subject: Re: Choosing a Python IDE. what is your Pythonish recommendation? > I do not know what to choose. > > > > On 02-01-17 12:38, Antonio Caminero Garcia wrote: > > Hello, I am having a hard time deciding what IDE or IDE-like code editor > should I use. This can be overwhelming. > > > > So far, I have used Vim, Sublime, Atom, Eclipse with PyDev, Pycharm, > IntelliJ with Python plugin. > > > > The thing with the from-the-scratch full featured IDEs (Eclipse, > IntelliJ, Pycharm) is that they look like a space craft dashboard and that > unwarranted resources consumption and the unnecessary icons. I want my IDE > to be minimalistic but powerful. My screen should be mostly “made of code” > as usually happens in Vim, Sublime or Atom. However, Pycharm is really cool > and python oriented. > > > > The problem with Vim is the learning curve, so I know the very basic > stuff, but obviously not enough for coding and I do not have time to learn > it, it is a pity because there are awesome plugins that turns Vim into a > lightweight powerful IDE-like. So now it is not an option but I will > reconsider it in the future, learning little by little. Also, I am not very > fan GUI guy if the task can be accomplished through the terminal. However, > I don’t understand why people underrate GUIs, that said I normally use > shortcuts for the most frequent tasks and when I have to do something that > is not that frequent then I do it with the mouse, for the latter case in > vim you would need to look for that specific command every time. > > > > Sublime is my current and preferred code editor. I installed Anaconda, > Git integration and a couple of additional plugins that make sublime very > powerful. Also, what I like about sublime compared to the full featured > IDEs, besides the minimalism, is how you can perform code navigation back > and forth so fast, I mean this is something that you can also do with the > others but for some subjective reason I specifically love how sublime does > it. The code completion in sublime I do not find it very intelligence, the > SublimeCodeIntel is better than the one that Anaconda uses but the > completions are not as verbose as in the IDEs. > > > > Now, I am thinking about giving a try to Visual Studio Code Edition > (take a look, it sounds good https://marketplace.visualstudio.com/items? > itemName=donjayamanne.python). I need an editor for professional software > development. What would you recommend to me? > > Hi Antonio, > > Just an extra one in case you'll ever want to create > a nice GUI, then there's also QT Creator: > https://wiki.qt.io/QtCreator_and_PySide > > A very simple but powerful interface a la XCode... > > It integrates nicely with PySide: > https://wiki.qt.io/QtCreator_and_PySide > > gr > Arno > > -- > https://mail.python.org/mailman/listinfo/python-list > This message is private and confidential and may also be legally > privileged. If you have received this message in error, please email it > back to the sender and immediately permanently delete it from your computer > system. Please do not read, print, re-transmit, store or act in reliance on > it or any attachments. British Airways may monitor email traffic data and > also the content of emails, where permitted by law, for the purposes of > security and staff training and in order to prevent or detect unauthorised > use of the British Airways email system. Virus checking of emails > (including attachments) is the responsibility of the recipient. British > Airways Plc is a public limited company registered in England and Wales. > Registered number: 177. Registered office: W
Re: How coding in Python is bad for you
I used to manually reformat unfamiliar C++ by hand, if for no other reason in that it forced me to read the code and somewhat comprehend what was going on. Now, I've lost my patience and use clang-format, a great & highly configurable tool. I also use vim for Python & C++ coding, so I also rely upon the command "gg=G" to reformat the current file (this doesn't do much in Python, however). One of the things I like about python is the indentation. It almost forces (or rather strongly encourages you) to keep functions short & sweet, to do a single thing in a function, and avoid too deeply nested structures. I've seen horrible abominations in C++ over the years. In separate projects, I've seen functions that were, in one case, over 45 printed pages, another over 65 pages. The nesting level was way too deep. I think in the worst case there were 8 levels of nested loops. This was problematic for many reasons. Multiple developers working on this function at the same time and attempting to merge was a big problem - the diff tool used by Clearcase (I know, a WTF, in of itself) would get confused and occassionally omit closing braces. Good luck resolving a compilation error by a missing brace in a 5000 line function. As a result of the pain I've experienced, I try and keep functions small enough to fit on a half-vertical, half-horizontal screen, with no line-wraps on a 1080p monitor. (I'm usually working in a terminal half-screen wide and use vertical splits in vim to see different parts of a file, or different files). On Fri, Jan 27, 2017 at 4:54 AM, Cecil Westerhof wrote: > On Friday 27 Jan 2017 05:07 CET, Brandon McCaig wrote: > > > Hell, considering the code that I have seen in the wild it might > > even catch some extra errors that become syntax errors! It's not > > at all rare for indentation to not match in languages that don't > > require it to at least fit a pattern. > > I remember that when I had to amend the code of a certain programmer I > always needed half a day to reformat his code. Because he was very > good in copy/paste, but I could not made head or tail of his code > because of the zig-zag of his code. > > That is why I immediately like the indent rule of Python very much. > > My only ‘problem’ was that I used to put debug statement at the > beginning of a line to see immediately what the debug statements > where. But that was a small price to pay. ;-) > > -- > Cecil Westerhof > Senior Software Engineer > LinkedIn: http://www.linkedin.com/in/cecilwesterhof > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: What are your opinions on .NET Core vs Python?
I mostly agree with this On Mon, Jan 30, 2017 at 7:18 PM, Joseph L. Casale wrote: > > C# hardly seems any better than Java to me as far as a language goes. > > Which sounds pretty good to me, they are both high performance, mature > and rich languages. > > > Being forced into working with classes even when they are not > > appropriate is jarring. > > And 100% irrelevant, it doesn't prevent you from doing anything you > otherwise could without. > > > Because everything is forced into a class, one > > often ends up with very long classes in C#, spanning more than one file! > > Sorry, sounds like you need to learn SOLID, none of my classes > have ever taken this form. > There is no reason you cannot introduce a static class with pure static members (i.e. the Math class in System). A static class effectively becomes another namespace in C++ parlance. I'll admit the syntax is a bit odd, and enforces you, at a minimum to use the outer name a as a qualifier, but it's effectively the same effect. > > > Makes the code much harder to follow from a human point of view. After > > working in C# I very much appreciate Python's explicit self requirement > > for accessing local instance variables. > > So, prefix them with "this." and they will look the same? > -- > https://mail.python.org/mailman/listinfo/python-list > self vs this, and you might start a language holy war. Of course "self" is the preferred to refer to an instance, just by python convention. Whether I agree with or not, I've seen "this" used to refer to instances where it is ambiguous in Python parlance between a "self" instance or a class instance - those instances are a bit weird, but there are rare occasions you do want to override class variables where this makes sense (they should be rare - because it's generally very hard to follow). -- https://mail.python.org/mailman/listinfo/python-list
how to obtain the text for BeautifulSoup object
Hi Team,
could anyone help me?
for webpage having source code like this:
...
number
name
I only can use below sentence, since there are a lot of tag em and tag a in
other area.
output = bs4.BeautifulSoup(res.content,'lxml').findAll("span",{"class":"xst
thread-name"})
how can I get the text in tag em and tag a under tag span?
thank you for your support!
Nathan
--
https://mail.python.org/mailman/listinfo/python-list
Re: Regex to extract multiple fields in the same line
On Wed, Jun 13, 2018 at 4:08 AM, Ganesh Pal wrote:
> Hi Team,
>
> I wanted to parse a file and extract few feilds that are present after "="
> in a text file .
>
>
> Example , form the below line I need to extract the values present after
> --struct =, --loc=, --size= and --log_file=
>
> Sample input
>
> line = '06/12/2018 11:13:23 AM python toolname.py --struct=data_block
> --log_file=/var/1000111/test18.log --addr=None --loc=0 --mirror=10
> --path=/tmp/data_block.txt size=8'
>
>
> Expected output
>
> data_block
> /var/1000111/test18.log
> 0
> 8
>
>
> Here is my sample code , its still not complete , I wanted to use regex
> and find and extract all the fields after " =", any suggestion or
> alternative way to optimize this further
>
>
> import re
> line = '06/12/2018 11:13:23 AM python toolname.py --struct=data_block
> --log_file=/var/1000111/test18.log --addr=None --loc=0 --mirror=10
> --path=/tmp/data_block.txt size=8'
>
> r_loc = r"--loc=(\d+)"
> r_struct = r'--struct=(\w+)'
>
> if re.findall(r_loc, line):
>print re.findall(r_loc, line)
>
> if re.findall(r_struct, line):
>print re.findall(r_struct, line)
>
>
> root@X1:/# python regex_02.py
> ['0']
> ['data_block']
>
>
> I am a Linux user with python 2.7
>
>
> Regards,
> Ganesh
>
---
Ooops... I didn't notice the 'python 2.7' part until after I had coded up
something. This solution could probably be squeezed to work with Python 2
somehow, though
I am actually a perl guy, and I love regex... in perl. I do tend to avoid
it if all possible in Python, though. I pieced together an ugly function
to do what you want. It avoids naming the arguments, so if a new argument
is added to your records, it should handle it with no changes. In python,
I love comprehensions almost as much as I love regex in perl.
Anyway, here is my n00bish stab at it:
#!/usr/bin/python3
line = '06/12/2018 11:13:23 AM python toolname.py --struct=data_block
--log_file=/var/1000111/test18.log --addr=None --loc=0 --mirror=10
--path=/tmp/data_block.txt size=8'
def get_args(lne):
first_hyphens = lne.find('--')# find where the args start
if first_hyphens == -1:# Blow up if ill-formed arg
raise ValueError("Invalid input line")
prelude = lne[0:first_hyphens] # Get the stuff before the args
prelude = prelude.strip()
args = lne[first_hyphens:] # Get the arguments
# The following line uses comprehensions to build a dictionary of
# argument/value pairs. The arguments portion is split on whitespace,
# then each --XX=YY pair is split by '=' into a two element list, Each
# two element list then provides the key and value for each argument.
# Note the 'd[0][2:]' strips the '--' from the front of the argument
# name
argdict = {d[0][2:]:d[1] for d in [e.split('=')[0:2] for e in
args.split()]}
return (prelude, argdict)
if __name__ == "__main__":
pre, argdict = get_args(line)
print('Prelude is "{}"'.format(pre))
for arg in argdict:
print(' Argument {} = {}'.format(arg, argdict[arg]))
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pylint prefers list comprehension over filter...
On 05/07/2016 05:22 PM, Chris Angelico wrote: On Sun, May 8, 2016 at 5:17 AM, Christopher Reimer wrote: pylint. Never know when an asshat hiring manager would reject my resume out of hand because my code fell short with pylint. I see that as a good motivation to make sure your code was good, clean, and definitely did fall a bit short with pylint. I have worked for asshat managers before. It is something to be avoided. Nathan -- https://mail.python.org/mailman/listinfo/python-list
Can anyone tell me if pygame and Tkinter can work together?
Hi, Can anyone tell me if pygame and Tkinter can work together in the same application? I thought I'd better ask before trying it, since both use widgets. Thanks, Nathan Pinno -- For great sites go to: http://www.the-web-surfers-store.com MSN Messenger: [EMAIL PROTECTED],com Yahoo! Messenger: spam_swatter31 ICQ: 199020705 AIM: f3mighty -- . > Posted thru AtlantisNews - Explore EVERY Newsgroup < > http://www.AtlantisNews.com -- Lightning Fast!!! < > Access the Most Content * No Limits * Best Service < -- http://mail.python.org/mailman/listinfo/python-list
RE: Can anyone tell me if pygame and Tkinter can work together?
Thanks. I was going to use TKInter to pop up a message box, then use pygame to run the game and display the score on the playing surface. Is this still possible (I'm using Python 2.4.1 and Pygame 1.7.0 on WinXP with Service Pack 2)? Nathan Pinno Nathan Pinno, Owner/operator of The Web Surfer's Store. http://www.the-web-surfers-store.com/ MSN Messenger: [EMAIL PROTECTED] Yahoo! Messenger: spam_swatter31 AIM: f3mighty ICQ: 199020705 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: November 15, 2005 6:28 PM To: Nathan Pinno Cc: [email protected] Subject: Re: Can anyone tell me if pygame and Tkinter can work together? It's likely to be a challenge; each one has its own "event loop", and the exact pitfalls of trying to use both at the same time probably depend on the operating system too. For instance, on X, Tk and SDL probably both expect full control of the handlers registered with XSetErrorHandler and XSetIOErrorHandler, but Xlib only permits a single handler. Jeff -- http://mail.python.org/mailman/listinfo/python-list
RE: Can anyone tell me if pygame and Tkinter can work together?
Sounds good, I'll give it a try and see what happens, and report back about my results. Nathan Pinno, Owner/operator of The Web Surfer's Store. http://www.the-web-surfers-store.com/ MSN Messenger: [EMAIL PROTECTED] Yahoo! Messenger: spam_swatter31 AIM: f3mighty ICQ: 199020705 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: November 15, 2005 8:47 PM To: Nathan Pinno Cc: [email protected] Subject: Re: Can anyone tell me if pygame and Tkinter can work together? On Tue, Nov 15, 2005 at 06:33:40PM -0700, Nathan Pinno wrote: > Thanks. I was going to use TKInter to pop up a message box, then use > pygame to run the game and display the score on the playing surface. > Is this still possible (I'm using Python 2.4.1 and Pygame 1.7.0 on > WinXP with Service Pack 2)? This is more likely to work than the scenario I first considered, where both GUI libraries would be in use at the same time. With my understanding of how X works, and my knowledge of Tk, you'd probably be successful if what you want to do is first use GUI Library A, and then GUI Library B. This resolves the issue with XSetErrorHandler, for instance, because you'll be completely done with Library A at the time you call the initialization routines of Library B. It also resolves the event loop problem, because you never need to allow Libraries A and B to receive events during the same phase of the program. I don't know anything about Windows, and I haven't actually given this scenario a try on Linux either, so it's still all idle speculation on my part. Actual experimentation on your part wouldn't be that hard, though. Just write the simplest possible Tk program as a callable function 't()' and the simplest possible pygame program as a callable function 'p()', and then see what happens when you run them back to back: def t(): import Tkinter t = Tkinter.Tk() Tkinter.Button(t, command = t.destroy).pack() t.mainloop() def p(): likewise t() p() Jeff -- http://mail.python.org/mailman/listinfo/python-list
