Re: [OT] fortran lib which provide python like data type
Rustom Mody : > There is a real conflict between the logician's goal and the > educator's. The logician wants to minimize the variety of ideas, > and doesn't mind a long, thin path. The educator (rightly) wants > to make the paths short and doesn't mind–in fact, > prefers–connections to many other ideas. And he cares almost not > at all about the directions of the links. The natural language has a rigorous grammar plus a lexicon that includes a number of idioms. Nobody has so far been able to codify a natural language completely because the rigorous grammar consists of maybe 10,000 rules. Perl came out of the needs of natural language translation. Perl's novel idea was to make a programming language like a natural language (yes, there had been Cobol). So Perl's language description evades a complete, rigorous description, but it has numerous handy idioms for many common situations. Python showed that while interesting and amusing, Perl's way leads to unnecessary clutter. Why make things complicated when simple will serve everybody's needs best. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: CSV and number formats
On 01/02/2015 06:45, Frank Millman wrote: Hi all I downloaded some bank statements in CSV format with a view to providing an automated bank reconciliation feature for my accounting software. One of them shows the opening balance in an unusual format. Most transaction amounts are in the format '-0031.23' or '+0024.58' This can easily be parsed using decimal.Decimal(). If the opening balance is positive, it appears as '+0021.45' If it is negative, it appears as '+0-21.45' Predictably, decimal.Decimal does not like this. Is this a recognised format, and is there a standard way of parsing it? If not, I will have to special-case it, but I would prefer to avoid that if possible. Thanks Frank Millman I've never seen anything like it and have to believe that this is a bug, although I'd guess that the bank in question will claim it's a feature. You'll surely have to work around it whilst waiting for a reply to the "WTF do you think you're playing at?" question. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Sorry, sort of responding to both of you. On Sat, Jan 31, 2015 at 10:12 PM, Paul Rubin wrote: > Steven D'Aprano writes: >> Some degree of weakness in a type system is not necessarily bad. Even the >> strongest of languages usually allow a few exceptions, such as numeric >> coercions. > > Haskell doesn't have automatic coercions of any sort. You have to call > a conversion function if you want to turn an Int into an Integer. Yeah. In fact, it isn't very compatible with the ML/Haskell type system to automatically convert, because it does weird things to type inference and type unification. So this is common in that language family. That said, Haskell (and the rest) do have a sort of type coercion, of literals at compile time (e.g. 3 can be an Integer or a Double depending on how you use it.) BTW it's weird that in this thread, and in the programmer community at large, int->string is considered worse than int->float, when the former is predictable and reversible, while the latter is lossy and can cause subtle bugs. Although at least we don't have ten+ types with sixty different spellings which change from platform to platform, and all of which automatically coerce despite massive and outrageous differences in representable values. (Hello, C.) >> I've never come across a language that has pointers which insists on >> having a separate Nil pointer for ever pointer type > > Haskell's idiomatic substitute for a null pointer is a Nothing value > (like Python's None) and there's a separate one for every type. The FFI > offers actual pointers (Foreign.Ptr) and there is a separate nullPtr > for every type. For that matter, how is this (first part) different from, say, Java? It's really only dynamically typed languages that have a single null value of a single type. Maybe I misunderstand the original statement. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
CSV and number formats
Hi all I downloaded some bank statements in CSV format with a view to providing an automated bank reconciliation feature for my accounting software. One of them shows the opening balance in an unusual format. Most transaction amounts are in the format '-0031.23' or '+0024.58' This can easily be parsed using decimal.Decimal(). If the opening balance is positive, it appears as '+0021.45' If it is negative, it appears as '+0-21.45' Predictably, decimal.Decimal does not like this. Is this a recognised format, and is there a standard way of parsing it? If not, I will have to special-case it, but I would prefer to avoid that if possible. Thanks Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Marko Rauhamaa writes: > The guiding principle in C++ language development is to take static > type safety to the extreme. Heh, try Ada. > Stroustrup apparently has never had to deal with callbacks; his thick > books never made a mention of them last time I checked. C++ has function pointers just like C, but more idiomatically you'd pass a class instance and the library would invoke some method on it. There is also Boost::Coroutine which can get rid of the need for callbacks in some situations. > Esthetically, I'm most impressed with Scheme. One day it might give > Python a run for its money. It's in a small and shrinking niche, unfortunately. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Steven D'Aprano writes:
> Some degree of weakness in a type system is not necessarily bad. Even the
> strongest of languages usually allow a few exceptions, such as numeric
> coercions.
Haskell doesn't have automatic coercions of any sort. You have to call
a conversion function if you want to turn an Int into an Integer.
> I've never come across a language that has pointers which insists on
> having a separate Nil pointer for ever pointer type
Haskell's idiomatic substitute for a null pointer is a Nothing value
(like Python's None) and there's a separate one for every type. The FFI
offers actual pointers (Foreign.Ptr) and there is a separate nullPtr
for every type.
> the compiler will allow Nil to be used for any pointer type. Anything
> else would be impractical.
It's completely practical: polymorphism and type inference get you the
value you want with usually no effort on your part.
> What if you add two empty objects?
> js> {} + {}
OMG, javascript is worse than I thought
> https://www.destroyallsoftware.com/talks/wat
Can't view, needs flash. :(
Try this instead (NFSW): https://www.youtube.com/watch?v=FJ7QsEytQq4
--
https://mail.python.org/mailman/listinfo/python-list
dunder-docs (was Python is DOOMED! Again!)
On Sunday, February 1, 2015 at 10:15:13 AM UTC+5:30, Ethan Furman wrote: > On 01/31/2015 07:16 PM, Steven D'Aprano wrote: > > > > But by default, Python will fallback on __repr__ if __str__ doesn't exist, > > or __str__ if __repr__ doesn't exist, or both. Or something. (I always > > forget what the rules are exactly.) > > If __str__ is missing, __repr__ is called. > > If __repr__ is missing, object.__repr__ (or some intermediate base class' > __repr__) is called. > > -- > ~Ethan~ The other day I was taking a class in which I was showing - introspection for discovering -- help, type, dir etc at the repl - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b) And a student asked me the diff between dir([]) and [].__dir__() I didnt know what to say... Now surely the amount of python I dont know is significantly larger than what I know Still it would be nice to have surface-syntax ←→ dunder-magic more systematically documented -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 01/31/2015 07:16 PM, Steven D'Aprano wrote: > > But by default, Python will fallback on __repr__ if __str__ doesn't exist, > or __str__ if __repr__ doesn't exist, or both. Or something. (I always > forget what the rules are exactly.) If __str__ is missing, __repr__ is called. If __repr__ is missing, object.__repr__ (or some intermediate base class' __repr__) is called. -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Sun, Feb 1, 2015 at 2:16 PM, Steven D'Aprano wrote: > Chris Angelico wrote: > >> On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano >> wrote: >>> Both ints and floats are models of the same abstract thing, namely >>> "number". Ideally, from a mathematically standpoint, there should be no >>> difference between 23 and 23.0. Automatic coercions allow us to get a >>> little closer to that ideal. >> >> So far, I'm mostly with you. (Though if your float type is not a >> perfect superset of your integer type - as in Python - then the >> default "up-cast" from int to float, while disallowing a corresponding >> implicit "down-cast", seems flawed. But in concept, yes, automatic >> coercion allows us to treat 23 and 23.0 as the same.) > > In principle, we might have a real-number type that is a perfect superset of > ints, and we might even have int versions of NAN and INF. But down-casting > real-to-integer is ambiguous, due to the need to handle any fractional > parts: > > - raise an exception if the fractional part is non-zero > - truncate (round towards zero) > - round down towards -infinity > - round up toward +infinity > - round to nearest, ties to odd numbers > - round to nearest, ties to even numbers > - round to nearest, ties split randomly > - something else > > One might semi-arbitrarily pick one (say, truncation) as the default when > you cast using int(x) but you need to support at least the most common > rounding modes, perhaps as separate functions. Agreed; but the trap here is that there are equivalent problems when converting integers to floating point - just more subtle, because they don't happen in the low ranges of values. In the same way that a UTF-16 string representation has more subtle problems than an ASCII string representation (because it's easy to test your code on "foreign text" and still not realize that it has issues with astral characters), casting int to float is subtle because you'll probably do all your testing on numbers less than 2**53. It might take a lot of tracking-down work before you finally discover that there's one place in your code where you do division with / instead of //, and you get back a float, and then only when your integers are really huge (maybe you encode an eight-digit date, four-digit time, then a three-digit country code, and finally a two-digit incrementing number) do you actually start losing precision. The bulk of Python programs will never run into this; yet we do have an arbitrary-precision integer type, we're not like ECMAScript with a single "Number" type. >>> Arbitrary objects, on the other hand, are rarely related to strings. >>> Given that we need to be able to display arbitrary objects to the human >>> programmer, if only for debugging, we need to be able to *explicitly* >>> convert into a string: >>> >>> >>> py> import nntplib >>> py> SERVER = "news.gmane.org" >>> py> server = nntplib.NNTP(SERVER) >>> py> str(server) >>> '' >> >> Here, though, I'm not so sure. Why should you be able to *type-cast* >> anything to string? Python has another, and perfectly serviceable, >> function for converting arbitrary objects into strings, and that's >> repr(). > > Which *also* converts to a string. (Note I didn't say *cast* to a string. I > cannot imagine any meaningful definition of what casting a NNTP server > object to a str might be.) Sure, but Python doesn't really have a way to spell "convert this to a string if it's already basically stringy, otherwise raise TypeError". You can do that for other types like int, but not for string, because you can always call str() on something. > I agree with all of that. And for what it is worth, a class can refuse to > convert to str while still supporting repr: > > py> class K(object): > ... def __str__(self): raise TypeError > ... def __repr__(self): return "Stuff and things. Mostly stuff." > ... > py> k = K() > py> str(k) > Traceback (most recent call last): > File "", line 1, in > File "", line 2, in __str__ > TypeError > py> repr(k) > 'Stuff and things. Mostly stuff.' Hmm. Sure you can do that, but is that just part of the freedom you have to shoot yourself in the foot? Would that be considered an ill-behaved class? >> Complete and automatic casting to string, I would agree. However, I >> would suggest that there are a few *binary operations* which could be >> more convenient if they allowed some non-strings. For instance, Pike >> allows addition of strings and integers: "1" + 2 == "12", where Python >> requires "1" + str(2) for the same operation. (But Pike does *not* >> allow just any object there. Only a few, like numbers, can be quietly >> cast on being added to strings.) > > I'm surprised you're not into Perl, with an attitude like that. A sick, > disgusting, despicably perverted attitude. *wink* > > But seriously, I can see some uses there, but frankly why bother to make an > exception for ints when you require all other types to have an explicit > coercion? Ints, floats, and any user
Re: RAII vs gc (was fortran lib which provide python like data type)
On Fri, Jan 30, 2015 at 1:28 PM, Sturla Molden wrote:
> in Python. It actually corresponds to
>
> with Foo() as bar:
>
The problem with with statements is that they only handle the case of
RAII with stack allocated variables, and can't handle transfer of
ownership cleanly.
Consider the case of a function that opens a file and returns it:
def myfunction(name, stuff):
f = open(name)
f.seek(stuff) # or whatever
return f
def blahblah():
with myfunction('hello', 12) as f:
This code is wrong, because if an error occurs during seek in
myfunction, the file is leaked.
The correct myfunction is as follows:
def myfunction(name, stuff)
f = open(name)
try:
f.seek(stuff)
except:
f.close()
raise
Or whatever. (I would love a close_on_error context manager, BTW.)
With RAII, the equivalent C++ looks nearly exactly like the original
(bad) Python approach, except it uses unique_ptr to store the file,
and isn't broken. ("Modern") C++ makes this easy to get right. But
then, this isn't the common case.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On Sun, Feb 1, 2015 at 2:06 PM, Mark Lawrence wrote: > The one-liner might not be better code, but it must be better speed wise > precisely because it's on one line, right? :) Well of course it is. Python code speed is always measured in lines per minute. That's why you should eliminate blank lines from your code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: RAII vs gc (was fortran lib which provide python like data type)
On Sun, Feb 1, 2015 at 2:00 PM, Steven D'Aprano
wrote:
>> A C++ statement with RAII like
>>
>> {
>>Foo bar();
>>// suite
>> }
>>
>> is not equivalent to
>>
>> bar = Foo()
>>
>> in Python. It actually corresponds to
>>
>> with Foo() as bar:
>>
>
>
> Nice answer! I'm not qualified to tell whether you are right or not, but
> what you say has the ring of truth about it.
I would say that this is indeed correct, with the caveat that RAII is
most often used for memory allocation, in which case the correct
transformation into Python _would_ be a constructor call. But when you
use this kind of thing to set up state and clean up afterwards, then
yes, Python's equivalent would be a context manager.
So a C++ way to release and reacquire the GIL might look like this
(borrowing from https://docs.python.org/3.5/c-api/init.html):
class ReleaseGIL
{
//Internal state
PyThreadState *_save;
public:
//Constructor
ReleaseGIL() {_save = PyEval_SaveThread();}
//Destructor
~ReleaseGIL() {PyEval_RestoreThread(_save);}
};
//Usage example:
int do_work()
{
while (1)
{
//use the Python C API to figure out what we need to do
ReleaseGIL heavy_processing_coming;
//do the heavy computational work
} //GIL is reacquired here
}
The Python equivalent would be something like:
@contextlib.contextmanager
def release_gil():
"""Why the are we manipulating the
GIL from Python code anyway???"""
_save = PyEval_SaveThread()
yield
PyEval_RestoreThread(_save)
def do_work()
while True:
# get some work
with release_gil() as heavy_processing_coming:
# do the heavy computational work
# GIL is reacquired here
In each case, you have a guarantee that code following the suite will
not be executed without first performing the appropriate cleanup.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Chris Angelico wrote: > On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano > wrote: >> Both ints and floats are models of the same abstract thing, namely >> "number". Ideally, from a mathematically standpoint, there should be no >> difference between 23 and 23.0. Automatic coercions allow us to get a >> little closer to that ideal. > > So far, I'm mostly with you. (Though if your float type is not a > perfect superset of your integer type - as in Python - then the > default "up-cast" from int to float, while disallowing a corresponding > implicit "down-cast", seems flawed. But in concept, yes, automatic > coercion allows us to treat 23 and 23.0 as the same.) In principle, we might have a real-number type that is a perfect superset of ints, and we might even have int versions of NAN and INF. But down-casting real-to-integer is ambiguous, due to the need to handle any fractional parts: - raise an exception if the fractional part is non-zero - truncate (round towards zero) - round down towards -infinity - round up toward +infinity - round to nearest, ties to odd numbers - round to nearest, ties to even numbers - round to nearest, ties split randomly - something else One might semi-arbitrarily pick one (say, truncation) as the default when you cast using int(x) but you need to support at least the most common rounding modes, perhaps as separate functions. >> Arbitrary objects, on the other hand, are rarely related to strings. >> Given that we need to be able to display arbitrary objects to the human >> programmer, if only for debugging, we need to be able to *explicitly* >> convert into a string: >> >> >> py> import nntplib >> py> SERVER = "news.gmane.org" >> py> server = nntplib.NNTP(SERVER) >> py> str(server) >> '' > > Here, though, I'm not so sure. Why should you be able to *type-cast* > anything to string? Python has another, and perfectly serviceable, > function for converting arbitrary objects into strings, and that's > repr(). Which *also* converts to a string. (Note I didn't say *cast* to a string. I cannot imagine any meaningful definition of what casting a NNTP server object to a str might be.) > It would make perfect sense for a language to make this > distinction much more stark: > > 1) str() attempts to convert something into a string. It can do this > automatically in the case of "string-like" objects (eg buffers, maybe > some magical things that come from databases), and can convert others > with help (eg bytes->string using an encoding parameter), but anything > else will raise an error. > > 2) repr() guarantees to convert anything into a string. It does this > in a relatively arbitrary fashion; you can write a helper method for > your class to make this more useful to the human. > > #2 is how Python's repr already functions, so explicitly converting > arbitrary objects into strings is covered. The idea that we can str() > them as well isn't necessarily part of a sane typing system. > > (Note that I'm not saying that Python got it wrong, here; just that > taking the alternate choice would also be not-wrong.) I agree with all of that. And for what it is worth, a class can refuse to convert to str while still supporting repr: py> class K(object): ... def __str__(self): raise TypeError ... def __repr__(self): return "Stuff and things. Mostly stuff." ... py> k = K() py> str(k) Traceback (most recent call last): File "", line 1, in File "", line 2, in __str__ TypeError py> repr(k) 'Stuff and things. Mostly stuff.' But by default, Python will fallback on __repr__ if __str__ doesn't exist, or __str__ if __repr__ doesn't exist, or both. Or something. (I always forget what the rules are exactly.) >> but doing so *implicitly* gains us nothing except the saving of a few >> keystrokes, while risking serious bugs. > > Complete and automatic casting to string, I would agree. However, I > would suggest that there are a few *binary operations* which could be > more convenient if they allowed some non-strings. For instance, Pike > allows addition of strings and integers: "1" + 2 == "12", where Python > requires "1" + str(2) for the same operation. (But Pike does *not* > allow just any object there. Only a few, like numbers, can be quietly > cast on being added to strings.) I'm surprised you're not into Perl, with an attitude like that. A sick, disgusting, despicably perverted attitude. *wink* But seriously, I can see some uses there, but frankly why bother to make an exception for ints when you require all other types to have an explicit coercion? The problem with string/int automatic coercions is that there are lots of answers but none of them are obviously the right answer: "1" + 1 --> "11" or 2? "1a" + 1 --> 2 like Perl does, or "1a1" like Javascript does? Do you strip out all non-numeric characters, or truncate at the first non-numeric character? Should you perhaps be a little more flexible and allow common mistypings like O for 0 and l for 1? How about whitespace?
Re: Python is DOOMED! Again!
Mario Figueiredo wrote: > In article <54ca5bbf$0$12992$c3e8da3$54964...@news.astraweb.com>, > steve+comp.lang.pyt...@pearwood.info says... >> >> Why should I feel guilty? You wrote: >> >> >> "Static analysis cannot and should not clutter executable code." >> >> >> But what are type declarations in statically typed languages like C, >> Pascal, Haskell, etc.? They are used by the compiler for static analysis. >> The same applies to type declarations in dynamically typed languages like >> Cobra and Julia. And yet, there they are, in the executable code. >> >> So there are a whole lot of languages, going all the way back to 1950s >> languages like Fortran, to some of the newest languages which are only a >> few years old like Go, both dynamically typed and statically typed, which >> do exactly what you say languages "cannot and should not" do: they put >> type information used for static analysis there in the code. > > You are confusing static analysis with compile time checking which > produces side-effects like implicit conversion for instance and that > affects the resulting binary code. Something that Python won't do with > type annotations. And something that Julia, Scala or C does. I'm not confusing anything. I'm fully aware of the differences between what C or Pascal does and what Python does. But I'm also aware of the similarities. > This is also the first time I hear compilation time mentioned as static > analysis. Compilation consists of many different tasks. They may be explicitly handled by different tools, or implicitly handled by a single tool. That tool may combine them into a single phase, or keep them separate. These are all implementation details: different compilers for the same language could do this differently. Typical tasks for a compiler, in no particular order: - lexing and parsing of source code - type analysis and checking - code generation - linking to external libraries - optimisation For languages like C and Pascal, the type checking is typically done statically at compile-time. So of course they include static analysis. The compiler hasn't compiled the code yet, so it only has the source code to work with! A type error will halt the compiler and stop the program from compiling. > To be clear, type declarations in Julia, Scala, C have the potential to > produce side-effects, can result in optimized code and can result in > compile time errors or warnings. Type annotations in Python are instead > completely ignored by the interpreter. They do nothing of the above. > They do not participate in code execution. As as been pointed out repeatedly, Python annotations DO participate in the code execution: the annotations are created and stored in the function object at runtime, and one could easily create a library to use those annotations at runtime for runtime type-checks. >> As I said, these languages disagree with you. You are not just arguing >> against Guido, but against the majority of programming language designers >> for 60+ years. > > You are right. I'm not arguing against Guido. I have yet to hear his > opinion on your or mine arguments. I'm not arguing against the majority > of programming languages either, because they agree with me. Do you really expect us to believe that the majority of programming languages put type declarations in docstrings, or a second file separate from the source of the function? Okay, let's see some examples. Here is a list of languages still well-known enough that people use them: http://rosettacode.org/wiki/Category:Programming_Languages How many of them use docstrings as the only way to declare the type of a variable? How many use header files as the sole way to declare the type of variables? I'm feeling generous. You don't even need to show a *majority* (50%). I'd be amazed if you can find *ten percent* of those languages that agree with you. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
On 31/01/2015 02:38, Chris Angelico wrote:
On Sat, Jan 31, 2015 at 1:27 PM, wrote:
l1 = ["a","b","c","d","e","f","g","h","i","j"]
l2 = ["aR","bR","cR"]
l2 will always be smaller or equal to l1
numL1PerL2 = len(l1)/len(l2)
I want to create a dictionary that has key from l1 and value from l2 based on
numL1PerL2
So
{
a:aR,
b:aR,
c:aR,
d:bR,
e:bR,
f:bR,
g:cR,
h:cR,
i:cR,
j:cR
}
So last item from l2 is key for remaining items from l1
So the Nth element of l1 will always be paired with the
(N/numL1PerL2)th element of l2 (with the check at the end)? Seems easy
enough.
dups = len(l1)/len(l2)
l2.append(l2[-1])
result = {x:l2[i/dups] for i,x in enumerate(l1)}
This mutates l2 for convenience, but you could also adjust the index
to take care of the excess. As a one-liner:
result = {x:l2[min(i/(len(l1)/len(l2)),len(l2)-1)] for i,x in enumerate(l1)}
But the one-liner is not better code :)
ChrisA
The one-liner might not be better code, but it must be better speed wise
precisely because it's on one line, right? :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: RAII vs gc (was fortran lib which provide python like data type)
Sturla Molden wrote:
> Rustom Mody wrote:
>
>> The case of RAII vs gc is hardly conclusive:
>>
>> http://stackoverflow.com/questions/228620/garbage-collection-in-c-why
>
> The purpose of RAII is not to be an alternative to garbage collection
> (which the those answers imply), but to ensure deterministc execution of
> setup and tear-down code. The Python equivalent of RAII is not garbage
> collection but context managers.
>
> Those answers is a testimony to how little the majority of C++ users
> actually understand about the language.
>
>
>
> A C++ statement with RAII like
>
> {
>Foo bar();
>// suite
> }
>
> is not equivalent to
>
> bar = Foo()
>
> in Python. It actually corresponds to
>
> with Foo() as bar:
>
Nice answer! I'm not qualified to tell whether you are right or not, but
what you say has the ring of truth about it.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Create dictionary based of x items per key from two lists
> I have two lists
>
> l1 = ["a","b","c","d","e","f","g","h","i","j"]
> l2 = ["aR","bR","cR"]
>
> l2 will always be smaller or equal to l1
>
> numL1PerL2 = len(l1)/len(l2)
>
> I want to create a dictionary that has key from l1 and value from l2 based on
> numL1PerL2
>
> So
>
> {
> a:aR,
> b:aR,
> c:aR,
> d:bR,
> e:bR,
> f:bR,
> g:cR,
> h:cR,
> i:cR,
> j:cR
> }
Another possibility is:
import itertools
my_dict = {x:y for x,y in zip(list1, itertools.cycle(list2))}
--
https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On Saturday, January 31, 2015 at 11:13:29 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody: > > > On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote: > >> Esthetically, I'm most impressed with Scheme. One day it might give > >> Python a run for its money. > > > > Aren't you getting this backwards? > > Deep down I'm a minimalist romantic. > > > Its just that its 2015 now not 1985... > > "Python was conceived in the late 1980s" ["Python", Wikipedia] > Scheme was conceived in the 1920s. ["Combinatory Logic", Wikipedia] > > > People did not 'settle' the question: "How many angels can dance on > > the head of a pin". It just stopped being relevant. > > Speak for yourself. It's just that the answer was found: > > ι = λf.((fS)K) ["Iota and Jot", Wikipedia] > > Donc Dieu existe, répondez! My répondez: Marvin Minsky's Turing award lecture http://web.media.mit.edu/~minsky/papers/TuringLecture/TuringLecture.html There is a real conflict between the logician's goal and the educator's. The logician wants to minimize the variety of ideas, and doesn't mind a long, thin path. The educator (rightly) wants to make the paths short and doesn't mind–in fact, prefers–connections to many other ideas. And he cares almost not at all about the directions of the links. Anyway… Thanks for those links or rather the pointer to http://en.wikipedia.org/wiki/Iota_and_Jot -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Marko Rauhamaa wrote: > I'm most impressed with Scheme. One day it might give > Python a run for its money. Scheme is forty years old, having come out in 1975. Python is 24 years old, having come out in 1991. If Scheme hasn't caught up with Python by now, it never will. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT]very high tech humour
LOL! -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
[OT]very high tech humour
https://www.youtube.com/watch?v=kAG39jKi0lI -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: parsing tree from excel sheet
Hi Peter,
Peter Otten <__pete...@web.de> wrote:
[]
> Let's start with the simplest:
>
>> Peter Otten <__pete...@web.de> wrote:
>
>>>def show2(self):
>>>yield str(self)
>>>for child in self.children:
>>>yield from child.show2()
[]
>
> Given a tree
>
> A --> A1
> A2 --> A21
> A22
> A3
>
> assume a slightly modified show2():
>
> def append_nodes(node, nodes):
>nodes.append(node)
>for child in node.children:
>append_nodes(child, nodes)
I'm assuming you are referring to the method in the Node class.
>
> When you invoke this with the root node in the above sample tree and
> an empty list
>
> nodes = [] append_nodes(A, nodes)
>
> the first thing it will do is append the root node to the nodes list
>
> [A]
>
> Then it iterates over A's children:
>
> append_nodes(A1, nodes) will append A1 and return immediately because
> A1 itself has not children.
>
> [A, A1]
>
> append_nodes(A2, nodes) will append A2 and then iterate over A2's
> children. As A21 and A22 don't have any children append_nodes(A21,
> nodes) and append_nodes(A22, nodes) will just append the respective
> node with no further nested ("recursive") invocation, and thus the
> list is now
>
> [A, A1, A21, A22]
>
> Finally the append_nodes(A3, nodes) will append A3 and then return
> because it has no children, and we end up with
>
> nodes = [A, A1, A21, A22, A3]
So the recursive function will append children as long as there are any,
traversing the whole tree structure (yep, I saw the missing A2 in the
list as you mentioned already).
> Now why the generator? For such a small problem it doesn't matter, for
> large datasets it is convenient that you can process the first item
> immmediately, when the following ones may not yet be available.
I've read something about generators and they are a strong concept
(especially for a C-minded guy like me!).
[]
> Ok, how to get from the recursive list building to yielding nodes as
> they are encountered? The basic process is always the same:
>
> def f(items)
> items.append(3)
> items.append(6)
> for i in range(10):
> items.append(i)
>
> items = []
> f(items)
> for item in items:
> print(item)
>
> becomes
>
> def g():
>yield 3
>yield 6
>for i in range(10):
>yield i
>
> for item in g():
>print(items)
---^ should be item and not items.
>
> In Python 3.3 there was added some syntactic sugar so that you can
> write
>
> def g():
>yield 3
>yield 6
>yield from range(10)
>
>
> Thus
>
> def append_nodes(node, nodes):
>nodes.append(node)
>for child in node.children:
>append_nodes(child, nodes)
>
>
> becomes
>
> def generate_nodes(node):
>yield node
>for child in node.children:
>yield from generate_nodes(child)
I'm with you now! I guess it would have been nearly impossible to see
the real picture behind.
> This looks a lot like show2() except that it's not a method and thus
> the node not called self and that the node itself is yielded rather
> than str(node). The latter makes the function a bit more flexible and
> is what I should have done in the first place.
Indeed returning the node might be more useful than just yielding its
string.
>
> The show() method is basically the the same, but there are varying
> prefixes before the node name. Here's a simpler variant that just adds
> some indentation. We start with generate_nodes() without the syntactic
> sugar. This is because we need a name for the nodes yielded from the
> nested generator call so that we can modify them:
>
> def indented_nodes(node):
>yield node
>for child in node.children:
>for desc in from indented_nodes(child):
>yield desc
>
> Now let's modify the yielded nodes:
>
> def indented_nodes(node):
>yield [node]
why this line has changed from 'yield node'?
>for child in node.children:
>for desc in indented_nodes(child):
>yield ["***"] + desc
Ok, the need for manipulation does not allow to use the syntax sugar of
above.
>
> How does it fare on the example tree?
>
> A --> A1
> A2 --> A21
> A22
> A3
>
> The lists will have an "***" entry for every nesting level, so we get
>
> [A]
> ["***", A1]
> ["***", A2]
> ["***", "***", A21]
> ["***", "***", A22]
> ["***", A3]
>
> With "".join() we can print it nicely:
>
> for item in indented_nodes(tree):
>print("".join(item))
>
> But wait, "".join() only accepts strings so let's change
>
>yield [node]
>
> to
>yield [node.name] # str(node) would also work
Again my question, why not simply yield node.name?
> A
> ***A1
> ***A2
> **A21
> **A22
> ***A3
>
>>> def show2(root):
>>>for line in root.show2():
>>>print(line)
>
>> Here we implement the functions to print a node, but I'm not sure I
>> understand why do I have to iterate if the main() iterates again over the
>> nodes.
>
Re: [OT] fortran lib which provide python like data type
On 31/01/2015 15:50, Rustom Mody wrote: On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote: Esthetically, I'm most impressed with Scheme. One day it might give Python a run for its money. Marko Aren't you getting this backwards? http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python Dont get me wrong: Ive had more fun with scheme than any other language. [And APL for very different reasons] Its just that its 2015 now not 1985... People did not 'settle' the question: "How many angels can dance on the head of a pin". It just stopped being relevant. Likewise, which is the 'best' programming language is a question without the edge it had when I was a student The answer is beautifully put here https://mail.python.org/pipermail/python-list/2002-November/154258.html so I have no hesitation in reposting for the umpteenth time. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Rustom Mody : > On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote: >> Esthetically, I'm most impressed with Scheme. One day it might give >> Python a run for its money. > > Aren't you getting this backwards? Deep down I'm a minimalist romantic. > Its just that its 2015 now not 1985... "Python was conceived in the late 1980s" ["Python", Wikipedia] Scheme was conceived in the 1920s. ["Combinatory Logic", Wikipedia] > People did not 'settle' the question: "How many angels can dance on > the head of a pin". It just stopped being relevant. Speak for yourself. It's just that the answer was found: ι = λf.((fS)K) ["Iota and Jot", Wikipedia] Donc Dieu existe, répondez! Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On Saturday, January 31, 2015 at 4:34:14 PM UTC+5:30, Steven D'Aprano wrote: > > Yesterday, as I wrote that message, my web browser crashed *eight times* in > a matter of half an hour. There are thousands of serious security > vulnerabilities due to mishandled pointers. Anyone who thinks that Linux > is "secure" is deluding themselves. It's only secure in comparison to > nightmares like Windows. The fact is, the security of computer systems is > best described as "with care and attention to detail, we can make it merely > awful". Beware that may be closer to ghost than you may think http://blog.trendmicro.com/trendlabs-security-intelligence/analyzing-cve-2015-0311-flash-zero-day-vulnerability/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote: > Esthetically, I'm most impressed with Scheme. One day it might give > Python a run for its money. > > > Marko Aren't you getting this backwards? http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python Dont get me wrong: Ive had more fun with scheme than any other language. [And APL for very different reasons] Its just that its 2015 now not 1985... People did not 'settle' the question: "How many angels can dance on the head of a pin". It just stopped being relevant. Likewise, which is the 'best' programming language is a question without the edge it had when I was a student -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano
wrote:
> Both ints and floats are models of the same abstract thing, namely "number".
> Ideally, from a mathematically standpoint, there should be no difference
> between 23 and 23.0. Automatic coercions allow us to get a little closer to
> that ideal.
So far, I'm mostly with you. (Though if your float type is not a
perfect superset of your integer type - as in Python - then the
default "up-cast" from int to float, while disallowing a corresponding
implicit "down-cast", seems flawed. But in concept, yes, automatic
coercion allows us to treat 23 and 23.0 as the same.)
> Arbitrary objects, on the other hand, are rarely related to strings. Given
> that we need to be able to display arbitrary objects to the human
> programmer, if only for debugging, we need to be able to *explicitly*
> convert into a string:
>
>
> py> import nntplib
> py> SERVER = "news.gmane.org"
> py> server = nntplib.NNTP(SERVER)
> py> str(server)
> ''
Here, though, I'm not so sure. Why should you be able to *type-cast*
anything to string? Python has another, and perfectly serviceable,
function for converting arbitrary objects into strings, and that's
repr(). It would make perfect sense for a language to make this
distinction much more stark:
1) str() attempts to convert something into a string. It can do this
automatically in the case of "string-like" objects (eg buffers, maybe
some magical things that come from databases), and can convert others
with help (eg bytes->string using an encoding parameter), but anything
else will raise an error.
2) repr() guarantees to convert anything into a string. It does this
in a relatively arbitrary fashion; you can write a helper method for
your class to make this more useful to the human.
#2 is how Python's repr already functions, so explicitly converting
arbitrary objects into strings is covered. The idea that we can str()
them as well isn't necessarily part of a sane typing system.
(Note that I'm not saying that Python got it wrong, here; just that
taking the alternate choice would also be not-wrong.)
> but doing so *implicitly* gains us nothing except the saving of a few
> keystrokes, while risking serious bugs.
Complete and automatic casting to string, I would agree. However, I
would suggest that there are a few *binary operations* which could be
more convenient if they allowed some non-strings. For instance, Pike
allows addition of strings and integers: "1" + 2 == "12", where Python
requires "1" + str(2) for the same operation. (But Pike does *not*
allow just any object there. Only a few, like numbers, can be quietly
cast on being added to strings.)
> Forcing all arbitrary objects to
> support string operations would be pointless and confusing. What could this
> possibly mean?
>
> server.replace('7', 'FOO')
Well duh, you would go to the server and replace the 7th stored post
with the new body 'FOO' :)
Strings have *tons* of methods. There's no way you'd want them all on
every object, and it wouldn't make sense. You definitely don't up-cast
everything to string just to use methods on them... I can't imagine
any (sane) language ever doing that.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: AssertionError (3.X only) when calling Py_Finalize with threads
Hi Tom, Tom Kent gmail.com> writes: > > I'm getting an error output when I call the C-API's Py_Finalize() from a different C-thread than I made a > python call on. Can you please post a bug on https://bugs.python.org ? Be sure to upload your example there. Thank you Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python tracker manual password reset
Terry Reedy : > On 1/30/2015 10:46 AM, Ian Kelly wrote: >> Is there someone I can contact to have my password manually reset? > > Answered offline. Spoilsport. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Gregory Ewing : > I'm completely convinced nowadays that there is *no* use case for C++. While I wouldn't go quite that far (my most recent creation was written in C++; why? because the legacy support libraries were written in C++). However, C++ is like putting lipstick on a pig. In fact, C++ has so much makeup on you wouldn't even no there's a pig underneath it. The guiding principle in C++ language development is to take static type safety to the extreme. That overriding principle has sacrificed other objectives and made working with the language painful. And despite all that machinery, C++ omitted the simplest of things that Delphi/C# got right: delegates. Stroustrup apparently has never had to deal with callbacks; his thick books never made a mention of them last time I checked. Java was a masterful simplification of C++ although it, too, has taken on unnecessary weight in the form of annotations, generics and closures. I was exposed to Java very late in the game and was very positively impressed by the programming model. Too bad Java's ecosystem and stringent portability requirements make it difficult to integrate Java with other software. At any rate, Java makes for a great production server backend language with its high-level programming features coupled with great performance. Currently, my main programming languages are bash, Python and C. They work beautifully together and cover the whole gamut of programming needs from interrupt routines all the way to test automation. Over time, I've shifted more and more weight from bash to Python because Python's predictable, flexible semantics has turned out to be worth its clunky multiprocessing facilities. Python exposes the OS facilities so doing the "right thing" in the linux ecosystem is very possible (unlike in Java). Python, too, is fast picking up Stroustrup-esque features so I'm a bit concerned for losing Python as the no-nonsense swiss-army knife. Esthetically, I'm most impressed with Scheme. One day it might give Python a run for its money. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
random...@fastmail.us wrote:
> On Thu, Jan 29, 2015, at 10:56, Steven D'Aprano wrote:
>> Bar language, on the other hand, tries extremely hard to ensure that
>> every
>> type is automatically able to be coerced into every other type. The
>> coercion might not do what you expect, but it will do *something*:
>
> See, this is where the concept falls apart. Many people will define a
> dynamically-typed language as weakly-typed *only if* the result of the
> automatic type coercion is unexpected/distasteful/fattening,
Oh, the curse of the discontinuous mind! :-)
https://richarddawkins.net/2013/01/the-tyranny-of-the-discontinuous-mind-christmas-2011/
A concept doesn't fall apart just because a few people are unable to use it
correctly. We may not be able to distinguish the exact moment when a child
becomes an adult (except, of course, by picking some arbitrary culturally
sanctioned age) but the concepts of child and adult are meaningful. And so
it is with strong and weak typing: people of good faith may nevertheless
disagree where the dividing line should be draw, or even whether a dividing
line is meaningful, but the concept of typing strength remains meaningful.
> even if it
> is well-defined and predictable according to the rules of the language.
> Which makes it a matter of personal taste.
Some degree of weakness in a type system is not necessarily bad. Even the
strongest of languages usually allow a few exceptions, such as numeric
coercions. I've never come across a language that has pointers which
insists on having a separate Nil pointer for ever pointer type: the
compiler will allow Nil to be used for any pointer type. Anything else
would be impractical.
Unfortunately, weakly typed languages get a bad reputation because so few of
them have well-defined rules that can be derived without having to learn a
bunch of arbitrary rules. Consider Javascript. What happens when you add
two arrays?
js> [1, 2, 3] + [4]
1,2,34
If it makes no sense to you, consider this:
js> typeof([1, 2, 3] + [4])
string
If it still makes no sense to you, you're not alone.
How about an array and an object?
js> [] + {} //empty array plus empty object
[object Object]
js> {} + [] //empty object plus empty array
0
What if you add two empty objects?
js> {} + {}
NaN
More here:
https://www.destroyallsoftware.com/talks/wat
>> Bar will never give you a TypeError. I think we can agree that Bar is a
>> *very weakly typed* language.
>
> Statically typed lanugages by definition can never give you a TypeError
They can't give you a *runtime* TypeError, but the compiler can give you a
compile-time type error. (Sorry for the misleading use of "TypeError" as in
the Python exception, I was thinking more broadly than just runtime
exceptions.)
> - there are no runtime conversions that can succeed or fail based on the
> type of the arguments. What makes a statically typed language strong or
> weak? Are statically typed languages always weak?
Statically typed languages tend to be strong. The point of doing static type
analysis is to prohibit ill-defined operations at compile-time, rather than
have the compiler mindlessly (say) write a 16-byte struct where a 2-byte
int is expected. But I don't think that it is necessarily the case that
statically-typed languages *must* be strongly typed, or dynamically-typed
languages weak.
>> There are degrees of strength, and I think that Python comes closer to
>> the
>> Foo end than the Bar end. There are few automatic coercions, and most of
>> those are in the numeric tower according to the usual mathematical rules.
>
> Why is converting an int to a float when passed to a math function
> better than converting any object to a string when passed to a string
> function?
Both ints and floats are models of the same abstract thing, namely "number".
Ideally, from a mathematically standpoint, there should be no difference
between 23 and 23.0. Automatic coercions allow us to get a little closer to
that ideal.
Arbitrary objects, on the other hand, are rarely related to strings. Given
that we need to be able to display arbitrary objects to the human
programmer, if only for debugging, we need to be able to *explicitly*
convert into a string:
py> import nntplib
py> SERVER = "news.gmane.org"
py> server = nntplib.NNTP(SERVER)
py> str(server)
''
but doing so *implicitly* gains us nothing except the saving of a few
keystrokes, while risking serious bugs. Forcing all arbitrary objects to
support string operations would be pointless and confusing. What could this
possibly mean?
server.replace('7', 'FOO')
We shouldn't insist that server objects support string methods, since that
would preempt them using methods of the same name for their own purposes,
and would needlessly clutter their API. We shouldn't want server objects to
automatically coerce into a string (why a string? why not a list or a dict
or a float?) because there is no real benefit to doing so. It can only
cause confusion.
--
Steven
-
Re: [OT] fortran lib which provide python like data type
Michael Torrie wrote: > On 01/30/2015 04:50 PM, Steven D'Aprano wrote: >> Oh great. So if the average application creates a hundred thousand >> pointers of the course of a session, you'll only have a thousand or so >> seg faults and leaks. >> >> Well, that certainly explains this: >> >> https://access.redhat.com/articles/1332213 > > I fail to see the connection. The connection is that you made a comment about eliminating "99%" of segfaults, as if that was something to be proud of. It's not. Like 99% uptime (which means you are down for over three and a half days per year), it's not very impressive. All it takes is *one* mishandled pointer, and you can have a seg fault, leak, buffer overflow, security exploit, or other serious bug. Which leads to vulnerabilities like Ghost. Yesterday, as I wrote that message, my web browser crashed *eight times* in a matter of half an hour. There are thousands of serious security vulnerabilities due to mishandled pointers. Anyone who thinks that Linux is "secure" is deluding themselves. It's only secure in comparison to nightmares like Windows. The fact is, the security of computer systems is best described as "with care and attention to detail, we can make it merely awful". And the manual use of pointers in low-level languages like C is a huge factor in that. > GLibc is a low-level library written in C, > not C++. By its nature requires a lot of pointer use, and is prone to > having errors. But not that many, seeing as *all* Linux software > depends on it and uses at least part of it *all* the time. Pretty > remarkable if you ask me. Wonder how they do it. Perhaps they try to > follow "basic rules." Exactly. And as Ghost demonstrates, that is *not good enough*. >> Manual low-level pointer manipulation is an anti-pattern. What you glibly >> describe as programmers following "basic rules" has proven to be beyond >> the ability of the programming community as a whole. > > I don't see how you would write system code without this "anti-pattern" > as you describe. Python is a great language for everything else, but I > certainly wouldn't call it a system language. I didn't actually mention Python. > Couldn't write a kernel > in it without providing it with some sort of unsafe memory access > (pointers!). Or even write a Python interpreter (Yes there's PyPy, but > with a jit it's still working with pointers). Systems languages now are, in a sense, in the same position that programming was back in the days before the invention of Fortran. The programmer, writing in a low-level assembly, was responsible for pushing items onto the stack, jumping to a sub-routine, popping the arguments off, then jumping back to the return address. Before Fortran, there were a number of proto-languages that aimed to make that safer, but Fortran was the first language where the compiler itself could completely handle all the book-keeping needed to use functions easily and safely. The problem is not *pointers*, but "manual low-level pointer manipulation", as I said. We programmers are expected to work out how much memory we need before allocating a pointer, remember to check whether it is nil or not before dereferencing it, don't forget to release the memory when you're done, oh you just wrote past the end of the buffer and now the Russian mob owns your computer... Where are the systems languages that will do to pointer access what Fortran did to the stack? They do exist: Rust claims to be a blazing fast systems language that is memory-safe and eliminates dangling pointers and buffer overflows at compile time. Assuming this is true, that means that the Rust compiler could generate code that is just as fast and efficient as C but without all the unsafe memory accesses of C. http://doc.rust-lang.org/nightly/intro.html#ownership I've never used Rust. I don't know whether it is ready for kernel development, or whether it lives up to its claims. Rust itself is not the point: there are other approaches to memory-safety, some of them are suitable for application development and some are suitable for systems languages. C is now four decades old. It took a single decade to go from hand-writing machine code in binary to Fortran, and here we are sixty years later still having buffer overflows. The fact that C is still one of the top three *application development languages* is a shameful indictment on the conservatism, resistance to change, intellectual laziness and hubris of the programming community as a whole. I won't go so far as to say that C must die. But it must become a niche language, used for the tiny (and growing ever more tiny as time goes on) segment of code that modern, memory-safe languages *provably* cannot handle. > What I call glibly "basic rules" are in fact shown to more or less work > out, as Glibc proves. Pointer use does lead to potential > vulnerabilities. And they must be corrected as they are found. Still > not sure what your point is. No. They mus
Re: help() function screen output
On 1/31/2015 4:13 AM, Steven D'Aprano wrote: Jacob Kruger wrote: Using python 3.4 32 bit on windows 7 64 bit machine, and when, for example, type in something like the following in interpreter window: help(str) It will populate the screen with one full screen of information, with a prompt of --more-- to hit enter, or something to continue displaying information, but, when, for example, hit enter key, it merely populates one more line of info, each time - under pythn 2.7, it seemed to render one full screen of info each time. I don't have Windows to try, but in Linux using both Python 2.7 and 3.3, pressing Enter advances by a single line. Same on Windows, 2.7 and 3.4. Is there rather a different keystroke should use to invoke that, or is this a python 3.4 feature/issue? Try using the Space key to advance an entire page. This works on Windows. You can also try Page Up and Page Down keys. Nada In Idle Shell, help displays entire text and one can scroll up and down as desired with scrollbar or PageUp/Down or arrows. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: help() function screen output
- Original Message - > Specifically, the last two lines show: Display next page Display next line which is, I suspect, what you're after here. (If you're interested, the code for all this is in the pydoc module (Lib\pydoc.py) in the getpager() function. TJG -- https://mail.python.org/mailman/listinfo/python-list Yes, that makes sense/works - wonder what changed recently in my overall configuration/setup - suppose might have something to do with screen reader's system wide interference - maybe it was passing a different effective keystroke through to command line prompt before, or something, since am 99.9% sure always just used key to advance one screen at a time before - who knows, but, main thing is, yes, space bar does what I want it to. Thanks Jacob Kruger Blind Biker Skype: BlindZA "Roger Wilco wants to welcome you...to the space janitor's closet..." -- https://mail.python.org/mailman/listinfo/python-list
Re: help() function screen output
- Original Message - From: "Steven D'Aprano" Newsgroups: comp.lang.python To: Sent: Saturday, January 31, 2015 11:13 AM Subject: Re: help() function screen output Jacob Kruger wrote: Using python 3.4 32 bit on windows 7 64 bit machine, and when, for example, type in something like the following in interpreter window: help(str) It will populate the screen with one full screen of information, with a prompt of --more-- to hit enter, or something to continue displaying information, but, when, for example, hit enter key, it merely populates one more line of info, each time - under pythn 2.7, it seemed to render one full screen of info each time. Are you sure? I don't have Windows to try, but in Linux using both Python 2.7 and 3.3, pressing Enter advances by a single line. Is there rather a different keystroke should use to invoke that, or is this a python 3.4 feature/issue? Try using the Space key to advance an entire page. You can also try Page Up and Page Down keys. Ok, strangely, while am relatively sure 2.7 rendered a screen at a time before when hitting enter key, it now also seems to advance one line at a time, but, yes, seems like space bar does advance a whole screen in both versions, and page up/down doesn't react, but, space bar will do for now... And, I generally let it render a screen full, and then review the screen contents using screen-reader screen review functionality, but, in this case it pretty much matches what people see. Thanks Jacob Kruger Blind Biker Skype: BlindZA "Roger Wilco wants to welcome you...to the space janitor's closet..." -- https://mail.python.org/mailman/listinfo/python-list
Re: help() function screen output
On 31/01/2015 08:17, Jacob Kruger wrote: Using python 3.4 32 bit on windows 7 64 bit machine, and when, for example, type in something like the following in interpreter window: help(str) It will populate the screen with one full screen of information, with a prompt of --more-- to hit enter, or something to continue displaying information, but, when, for example, hit enter key, it merely populates one more line of info, each time - under pythn 2.7, it seemed to render one full screen of info each time. Is there rather a different keystroke should use to invoke that, or is this a python 3.4 feature/issue? The help() function uses (by default, on Windows) the built-in "more.com" command. There's some hand-waving going on there because it can/will be overridden if you have a different "more" executable available before the system-provided more.com or if you have a PAGER env var set. If you, at the Windows command prompt (ie *not* in Python), type: more /? You can see the various keystrokes which the program responds to. Specifically, the last two lines show: Display next page Display next line which is, I suspect, what you're after here. (If you're interested, the code for all this is in the pydoc module (Lib\pydoc.py) in the getpager() function. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: A python coder needed
On Saturday, January 31, 2015 at 11:11:02 AM UTC+2, Chris Angelico wrote: > On Sat, Jan 31, 2015 at 7:51 PM, wrote: > > Hello. I am looking for a python coder. Please find the details which are > > in the below: > > > > A bittorrent client will be coded in order to share files in a private > > group. The private tracker server was coded by me (PHP & MySQL) and > > bittorrent client will be communicated with this tracker server via REST > > API. File meta data and peer information will be stored on this private > > tracker server. Files will be stored on peers computers and shared in each > > others by peers. > > > > For this project, Python coder will use libtorrent library and produce a > > software with a simple and user friendly UI. During the file sharing, all > > bittorent features will be used (for example segmented file transfer, > > cryptographic hash etc.). > > > > There are various job posting sites; I believe the Stack Overflow > family of sites has one, for instance. The Python Job Board is > currently down, or I'd point you there. > > However, this sounds like something that must surely exist. Can't you > just take one of the existing torrent clients and maybe have a tiny > script to signal it to start using a particular torrent file? > > ChrisA Thank you for your response ChrisA. I have checked deluge-torrent. But it is very complicated. However, I need a simple client for just one purpose but I dont have enough experience for Pyhton. In my project, REST API, GUI and torrent classes shall be used. Therefore, I am looking for a coder. Fatih. -- https://mail.python.org/mailman/listinfo/python-list
Re: help() function screen output
Jacob Kruger wrote: > Using python 3.4 32 bit on windows 7 64 bit machine, and when, for > example, type in something like the following in interpreter window: > help(str) > > It will populate the screen with one full screen of information, with a > prompt of --more-- to hit enter, or something to continue displaying > information, but, when, for example, hit enter key, it merely populates > one more line of info, each time - under pythn 2.7, it seemed to render > one full screen of info each time. Are you sure? I don't have Windows to try, but in Linux using both Python 2.7 and 3.3, pressing Enter advances by a single line. > Is there rather a different keystroke should use to invoke that, or is > this a python 3.4 feature/issue? Try using the Space key to advance an entire page. You can also try Page Up and Page Down keys. The exact keys will depend on the pager program used by help. The help function depends on the pydoc module, which tries to use your operating system's "pager" program for displaying pages of text. On Linux, that may be the external programs "more" or "less". I don't know what Windows uses. If there is no external pager program available, pydoc may end up using its own internal pager. So the exact keys used will differ. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: parsing tree from excel sheet
alb wrote:
> >
> > def read_tree(rows, levelnames):
> >root = Node("#ROOT", "#ROOT")
> >old_level = 0
> >stack = [root]
> >for i, row in enumerate(rows, 1):
>
> I'm not quite sure I understand what is the stack for. As of now is a
> list whose only element is root.
The stack is used to emulate the function call stack in a recursive
solution. Every nested call produces a new set of local variables and the
innermost call corresponds to the top of the stack or the end of the `stack`
list in my code.
Given a tree
A
A1
A11
A12
A2
or in another notation
0 A
1 A1
2 A11
2 A12
1 A2
we start with a stack (with the node's children in parens)
[A()]
then look at A1 and see that the level is one deeper than that of A and
append it to A, the current TOS (top of stack)
[A(A1)]
Next is A11 which is two levels deeper than A, so we take the last child of
A and put it on the stack,
[A(A1), A1()]
then add A11 as a child to the new TOS
[A(A1), A1(A11)]
Next is A12 which is one level deeper than A1, so we add it to the current
TOS
[A(A1), A1(A11, A12)]
Next is A2 which is one level higher than A1, so we keep removing nodes from
the stack until the current TOS is one level higher than A2. Here we only
have to remove A1 from the stack to get
[A(A1)]
and after adding A2 to the TOS
[A(A1, A2)]
I have ommitted the children of the children so far, but the actual
structure is now
[A(A1(A11(), A12()), A2())]
Therefore I just need to return A which contains the complete layout of the
tree.
> >new_level = column_index(row)
> >node = Node(row[new_level], levelnames[new_level])
>
> here you are getting the node based on the current row, with its level.
>
> >if new_level == old_level:
> >stack[-1].append(node)
>
> I'm not sure I understand here. Why the end of the list and not the
> beginning?
>
> >elif new_level > old_level:
> >if new_level - old_level != 1:
> >raise ValueError
>
> here you avoid having a node which is distant more than one level from
> its parent.
>
> >stack.append(stack[-1].children[-1])
>
> here I get a crash: IndexError: list index out of range!
>
> >stack[-1].append(node)
> >old_level = new_level
> >else:
> >while new_level < old_level:
> >stack.pop(-1)
> >old_level -= 1
> >stack[-1].append(node)
>
> Why do I need to pop something from the stack??? Here you are saying
> that if current row has a depth (new_level) that is smaller than the
> previous one (old_level) I decrement by one the old_level (even if I may
> have a bigger jump) and pop something from the stack...???
>
> >return root
>
> once filled, the tree is returned. I thought the tree would have been
> the stack, but instead is root...nice surprise.
> Why do I need to pop something from the stack???
That got me thinking, and I found that my code is indeed much more complex
than necessary. Sorry for that ;)
As a compensation here is the simplified non-popping version of read_tree():
def read_tree(rows, levelnames):
root = Node("#ROOT", "#ROOT")
parents = [root] + [None] * len(levelnames)
for row in rows:
level = column_index(row)
node = Node(row[level], levelnames[level])
parents[level].append(node)
parents[level+1] = node
return root
--
https://mail.python.org/mailman/listinfo/python-list
Re: A python coder needed
On Sat, Jan 31, 2015 at 7:51 PM, wrote: > Hello. I am looking for a python coder. Please find the details which are in > the below: > > A bittorrent client will be coded in order to share files in a private group. > The private tracker server was coded by me (PHP & MySQL) and bittorrent > client will be communicated with this tracker server via REST API. File meta > data and peer information will be stored on this private tracker server. > Files will be stored on peers computers and shared in each others by peers. > > For this project, Python coder will use libtorrent library and produce a > software with a simple and user friendly UI. During the file sharing, all > bittorent features will be used (for example segmented file transfer, > cryptographic hash etc.). > There are various job posting sites; I believe the Stack Overflow family of sites has one, for instance. The Python Job Board is currently down, or I'd point you there. However, this sounds like something that must surely exist. Can't you just take one of the existing torrent clients and maybe have a tiny script to signal it to start using a particular torrent file? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: parsing tree from excel sheet
alb wrote:
> >
> > def read_tree(rows, levelnames):
> >root = Node("#ROOT", "#ROOT")
> >old_level = 0
> >stack = [root]
> >for i, row in enumerate(rows, 1):
>
> I'm not quite sure I understand what is the stack for. As of now is a
> list whose only element is root.
The stack is used to emulate the function call stack in a recursive
solution. Every nested call produces a new set of local variables and the
innermost call corresponds to the top of the stack or the end of the `stack`
list in my code.
Given a tree
A
A1
A11
A12
A2
or in another notation
0 A
1 A1
2 A11
2 A12
1 A2
we start with a stack (with the node's children in parens)
[A()]
then look at A1 and see that the level is one deeper than that of A and
append it to A, the current TOS (top of stack)
[A(A1)]
Next is A11 which is two levels deeper than A, so we take the last child of
A and put it on the stack,
[A(A1), A1()]
then add A11 as a child to the new TOS
[A(A1), A1(A11)]
Next is A12 which is one level deeper than A1, so we add it to the current
TOS
[A(A1), A1(A11, A12)]
Next is A2 which is one level higher than A1, so we keep removing nodes from
the stack until the current TOS is one level higher than A2. Here we only
have to remove A1 from the stack to get
[A(A1)]
and after adding A2 to the TOS
[A(A1, A2)]
I have ommitted the children of the children so far, but the actual
structure is now
[A(A1(A11(), A12()), A2())]
Therefore I just need to return A which contains the complete layout of the
tree.
> >new_level = column_index(row)
> >node = Node(row[new_level], levelnames[new_level])
>
> here you are getting the node based on the current row, with its level.
>
> >if new_level == old_level:
> >stack[-1].append(node)
>
> I'm not sure I understand here. Why the end of the list and not the
> beginning?
>
> >elif new_level > old_level:
> >if new_level - old_level != 1:
> >raise ValueError
>
> here you avoid having a node which is distant more than one level from
> its parent.
>
> >stack.append(stack[-1].children[-1])
>
> here I get a crash: IndexError: list index out of range!
>
> >stack[-1].append(node)
> >old_level = new_level
> >else:
> >while new_level < old_level:
> >stack.pop(-1)
> >old_level -= 1
> >stack[-1].append(node)
>
> Why do I need to pop something from the stack??? Here you are saying
> that if current row has a depth (new_level) that is smaller than the
> previous one (old_level) I decrement by one the old_level (even if I may
> have a bigger jump) and pop something from the stack...???
>
> >return root
>
> once filled, the tree is returned. I thought the tree would have been
> the stack, but instead is root...nice surprise.
> Why do I need to pop something from the stack???
That got me thinking, and I found that my code is indeed much more complex
than necessary. Sorry for that ;)
As a compensation here is the simplified non-popping version of read_tree():
def read_tree(rows, levelnames):
root = Node("#ROOT", "#ROOT")
parents = [root] + [None] * len(levelnames)
for row in rows:
level = column_index(row)
node = Node(row[level], levelnames[level])
parents[level].append(node)
parents[level+1] = node
return root
--
https://mail.python.org/mailman/listinfo/python-list
A python coder needed
Hello. I am looking for a python coder. Please find the details which are in the below: A bittorrent client will be coded in order to share files in a private group. The private tracker server was coded by me (PHP & MySQL) and bittorrent client will be communicated with this tracker server via REST API. File meta data and peer information will be stored on this private tracker server. Files will be stored on peers computers and shared in each others by peers. For this project, Python coder will use libtorrent library and produce a software with a simple and user friendly UI. During the file sharing, all bittorent features will be used (for example segmented file transfer, cryptographic hash etc.). At the end of project, all source will be furnished as open and will be complied for WINDOWS and Linux as well. If you want more details for my project, please send an email to me: faithbazman at gmail. Regards, Fatih. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] fortran lib which provide python like data type
Am 30.01.15 um 19:23 schrieb Paul Rubin:
> Michael Torrie writes:
>> Follow basic [C++] rules and 99% of segfaults will never happen and
>> the majority of leaks will not happen either.
>
> That is a safe and simple approach, but it works by copying data all
> over the place instead of passing pointers, resulting in performance
> loss.
This "performance loss" is partly a myth. Consider the following code,
assuming it is compiled using a recent (C++11) compiler
#include
std::vector compute() {
const size_t N=10;
std::vector result(N);
for (size_t i=0; ihttps://mail.python.org/mailman/listinfo/python-list
help() function screen output
Using python 3.4 32 bit on windows 7 64 bit machine, and when, for example, type in something like the following in interpreter window: help(str) It will populate the screen with one full screen of information, with a prompt of --more-- to hit enter, or something to continue displaying information, but, when, for example, hit enter key, it merely populates one more line of info, each time - under pythn 2.7, it seemed to render one full screen of info each time. Is there rather a different keystroke should use to invoke that, or is this a python 3.4 feature/issue? TIA Jacob Kruger Blind Biker Skype: BlindZA "Roger Wilco wants to welcome you...to the space janitor's closet..." -- https://mail.python.org/mailman/listinfo/python-list
Re: Python tracker manual password reset
On 1/30/2015 10:46 AM, Ian Kelly wrote: I just tried to use the password recovery tool for the Python tracker. I entered my personal email. It sent me the confirmation email with the password reset link, which I followed. It then reset my password and sent an email to a different address, an old work address that I no longer have, so I have no idea what the new password is. Is there someone I can contact to have my password manually reset? Answered offline. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
