Re: what does := means simply?
On 18/05/18 02:45, Steven D'Aprano wrote: To successful port anything but the most trivial code, you actually have to understand *both* languages -- including the syntax, semantics, built- in language features, AND libraries. A point that was once made to me about translating human languages is that to do it well, you need to understand both languages *and both cultures.* The same principle probably applies to computer languages as well; how often have we collectively complained about people trying to write (say) FORTRAN in Python? -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On 17/05/18 23:44, Paul wrote: I've been using email for thirty years, including thousands of group emails at many tech companies, and no one has ever suggested, let alone insisted on, bottom posting. I've been using email for thirty years, etc, etc, and I've always insisted on proper quoting, trimming and interspersed posting. Clearly you've never worked in the right companies ;-) -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 18/05/2018 02:45, Steven D'Aprano wrote: On Fri, 18 May 2018 02:17:39 +0100, bartc wrote: Normally you'd use the source code as a start point. In the case of Python, that means Python source code. But you will quickly run into problems because you will often see 'import lib' and be unable to find lib.py anywhere. Seriously? There's a finite number of file extensions to look for: .py .pyc .pyo .pyw .dll .so pretty much is the lot, except on some obscure platforms which few people use. Which one corresponds to 'import sys'? If the source to such libraries is not available then it is necessary to emulate that functionality. You are writing from scratch, not porting, according to specifications. And those specifications may be inexplicably tied to the inner workings of the language. That is a little bit harder, yes? Especially as Python is a scripting language and might rely more than most on this quite extensive built-in functionality, even on fairly short programs. (When I once thought about implementing an interpreter for Python byte-code, I found all this out very quickly. Such an interpreter could work perfectly but it would not get past 'import sys'.) To successful port anything but the most trivial code, you actually have to understand *both* languages -- including the syntax, semantics, built- in language features, AND libraries. Don't forget configuration and build systems. The code you want to port may not even exist, but is synthesised as part of the build process, and be specific to a particular build. I'm talking about the seemingly rare case these days where you DO have the source code! That's one problem. Others might involve how to deal with something like __globals__ which doesn't have an equivalent in the target language. And we haven't started on features that are specific to Python. How about features which are specific to C I'm quite familiar with C which has its own set of problems. But taking one aspect, if a C program relies on its standard library, then it is very often possible to directly call that standard library from another language, so you don't need to reimplement it, nor port it. Since every language has features that some other languages don't have, is it your position that it is impossible to port code from any language to any other? I'm saying some languages make it more difficult, and Python is one of them, especially written 'Pythonically', which seems to be code for 'this only makes sense in Python', so that you can't understand it even if you have no intention of porting it. If you want to *really* see code that is hard to port, you should try porting an Inform 7 program to another language. Any other language. You seem to be saying that because it is rarely completely impossible to port software, that we disregard any difficulties and consider all such porting as equally trivial. I'm just saying that in my experience, given the choice of porting the same program from other Python or, say, Lua, I would choose Lua. Same with choosing between 'full-on' C++ and, say, Pascal. Both C++ and Python can be used to write software in a simple style (as I would use); typically they are not used that way. Given the rich set of esoteric features of both, programmers do like to pull out all the stops. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On 17/05/2018 23:49, Chris Angelico wrote: On Fri, May 18, 2018 at 8:44 AM, Paul wrote: I've been using email for thirty years, including thousands of group emails at many tech companies, and no one has ever suggested, let alone insisted on, bottom posting. If someone's late to a thread they can read from it the bottom up. Remind me which direction text is usually written in English? Is this a trick question? It's usually written left to right. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On Fri, May 18, 2018 at 9:29 PM, bartc wrote: > On 17/05/2018 23:49, Chris Angelico wrote: >> >> On Fri, May 18, 2018 at 8:44 AM, Paul wrote: > > >>> I've been using email for thirty years, including thousands of group >>> emails >>> at many tech companies, and no one has ever suggested, let alone insisted >>> on, bottom posting. If someone's late to a thread they can read from it >>> the bottom up. >> >> >> Remind me which direction text is usually written in English? > > > Is this a trick question? It's usually written left to right. And the lines are written top to bottom. Not bottom to top. Why should people have to read sections from the bottom up, but text within the section from the top down? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 5/18/18 7:09 AM, bartc wrote: On 18/05/2018 02:45, Steven D'Aprano wrote: On Fri, 18 May 2018 02:17:39 +0100, bartc wrote: Normally you'd use the source code as a start point. In the case of Python, that means Python source code. But you will quickly run into problems because you will often see 'import lib' and be unable to find lib.py anywhere. Seriously? There's a finite number of file extensions to look for: .py .pyc .pyo .pyw .dll .so pretty much is the lot, except on some obscure platforms which few people use. Which one corresponds to 'import sys'? If the source to such libraries is not available then it is necessary to emulate that functionality. You are writing from scratch, not porting, according to specifications. And those specifications may be inexplicably tied to the inner workings of the language. That is a little bit harder, yes? Especially as Python is a scripting language and might rely more than most on this quite extensive built-in functionality, even on fairly short programs. (When I once thought about implementing an interpreter for Python byte-code, I found all this out very quickly. Such an interpreter could work perfectly but it would not get past 'import sys'.) To successful port anything but the most trivial code, you actually have to understand *both* languages -- including the syntax, semantics, built- in language features, AND libraries. Don't forget configuration and build systems. The code you want to port may not even exist, but is synthesised as part of the build process, and be specific to a particular build. I'm talking about the seemingly rare case these days where you DO have the source code! That's one problem. Others might involve how to deal with something like __globals__ which doesn't have an equivalent in the target language. And we haven't started on features that are specific to Python. How about features which are specific to C I'm quite familiar with C which has its own set of problems. But taking one aspect, if a C program relies on its standard library, then it is very often possible to directly call that standard library from another language, so you don't need to reimplement it, nor port it. Since every language has features that some other languages don't have, is it your position that it is impossible to port code from any language to any other? I'm saying some languages make it more difficult, and Python is one of them, especially written 'Pythonically', which seems to be code for 'this only makes sense in Python', so that you can't understand it even if you have no intention of porting it. If you want to *really* see code that is hard to port, you should try porting an Inform 7 program to another language. Any other language. You seem to be saying that because it is rarely completely impossible to port software, that we disregard any difficulties and consider all such porting as equally trivial. I'm just saying that in my experience, given the choice of porting the same program from other Python or, say, Lua, I would choose Lua. Same with choosing between 'full-on' C++ and, say, Pascal. Both C++ and Python can be used to write software in a simple style (as I would use); typically they are not used that way. Given the rich set of esoteric features of both, programmers do like to pull out all the stops. Your logic here seems to be to use the least-common denominator among some guessed-at set of languages, so that if you ever have to re-implement a program, you can transliterate it into another language. I would much rather choose a tool and use it well (that is, to its fullest power) than to hobble myself on the off-chance I have to switch languages in the future. I guess I don't understand the type of work you've been doing: I have only very very rarely had to reimplement the same program in another language. I can't imagine choosing tooling or style based on that concern. We have had this discussion at work: do we use Python in a "simple" way so that new developers coming from Java (or C, etc) can understand it? Or do we assume that people working in a large Python codebase understand Python? I choose the latter. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
bartc writes: > On 17/05/2018 23:49, Chris Angelico wrote: >> On Fri, May 18, 2018 at 8:44 AM, Paul wrote: > >>> I've been using email for thirty years, including thousands of group emails >>> at many tech companies, and no one has ever suggested, let alone insisted >>> on, bottom posting. If someone's late to a thread they can read from it >>> the bottom up. >> >> Remind me which direction text is usually written in English? > > Is this a trick question? It's usually written left to right. in a rather biased way "front to back" -- turning pages to the left. an English book is read left to right, top to bottom and what we call two" because in printed text, pages also ordered need to be order. Thus we read English text left to right and top to bottom. I say "at least bottom. The slightly sarcastic question was supposed remind people that lines left to right, lines are stacked, almost always from top to There are at least two directions for most text. After constructing -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On 18 May 2018 at 12:08, Rhodri James wrote: > On 17/05/18 23:44, Paul wrote: >> >> I've been using email for thirty years, including thousands of group >> emails >> at many tech companies, and no one has ever suggested, let alone insisted >> on, bottom posting. > > I've been using email for thirty years, etc, etc, and I've always insisted > on proper quoting, trimming and interspersed posting. Clearly you've never > worked in the right companies ;-) There are two completely independent cultures here. In "Corporate" cultures like where I work (where IT and business functions interact a lot, and business users typically use tools like Outlook) top-posting is common, conventional, and frankly, effective. Conversely, in purely technical communities like open source, where conventions originated in low-bandwidth channels like early networks, interspersed posting, heavy trimming and careful quoting are the norm. I've participated in both communities for 30 years or more, and you deal with people in the way that they find most comfortable. It's polite to follow the conventions of the community that you're interacting with - so on this mailing list, for example, quoting and posting inline is the norm and top-posting is considered impolite. Arguing about how the community's conventions are wrong is also impolite :-) I'm reminded of the old stereotypes of Brits speaking English NICE AND LOUDLY to foreigners to help them understand what we're saying... (Disclaimer: I'm a Brit, so I'm poking fun at myself here :-)) Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Fri, 18 May 2018 12:09:02 +0100, bartc wrote:
> On 18/05/2018 02:45, Steven D'Aprano wrote:
>> On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
>>
>>> Normally you'd use the source code as a start point. In the case of
>>> Python, that means Python source code. But you will quickly run into
>>> problems because you will often see 'import lib' and be unable to find
>>> lib.py anywhere.
>>
>> Seriously? There's a finite number of file extensions to look for:
>>
>> .py .pyc .pyo .pyw .dll .so
>>
>> pretty much is the lot, except on some obscure platforms which few
>> people use.
>
> Which one corresponds to 'import sys'?
The functions in sys are built-in to the CPython interpreter. For other
interpreters, they could correspond to some file, or not, as the
implementer desires.
So just like built-in functions, your first stop when porting is to READ
THE DOCUMENTATION and learn what the semantics of the functions you care
about, not the source code.
But you know that.
If I see:
result = math.sin(x)
and I want to port it, what should I do?
1. Dive into the source code of math.so or math.dll, and from there dig
deeper into the platform maths libraries and the intricacies of the sin
function;
2. Read the docs, discover that math.sin returns the trigonometric sine
function, and use my target languages own sine implementation? (If and
only if there is a difference in behaviour between sine implementations
should I *consider* diving into the platform sine.)
I don't believe you actually choose 1 when you are porting.
So why should sys.version be treated differently from math.sin(), for
example? What matters is the *interface*, not the implementation, and we
best get the interface from the docs, not from diving into the source.
Diving into the source is the last resort.
> If the source to such libraries is not available then it is necessary to
> emulate that functionality. You are writing from scratch, not porting,
> according to specifications.
I disagree.
Come on Bart, be serious here. You surely don't mean to say that porting
the Python script
print("Hello World!")
to Ruby:
print "Hello world!"
is "writing from scratch, not porting" unless the Ruby print uses
precisely the same implementation as the Python print. All that matters
is that for *this* specific use, the two print commands behave the same.
>> Since every language has features that some other languages don't have,
>> is it your position that it is impossible to port code from any
>> language to any other?
>
> I'm saying some languages make it more difficult, and Python is one of
> them
Only if you are trying to port *down* the Blub hierarchy, to a less
powerful language.
But that's always the case.
[...]
>> If you want to *really* see code that is hard to port, you should try
>> porting an Inform 7 program to another language. Any other language.
>
> You seem to be saying that because it is rarely completely impossible to
> port software, that we disregard any difficulties and consider all such
> porting as equally trivial.
No.
> I'm just saying that in my experience, given the choice of porting the
> same program from other Python or, say, Lua, I would choose Lua.
If they are *the same program* then surely they will be identical (modulo
syntax and naming of builtins) and there should be no difference in
difficulty in porting.
If they are *semantically the same* (they do the same thing) but have
different implementations, then you've just blown a hole in your own
argument.
If a Python program does a task T using some implementation P which Lua
cannot easily use, and a Lua program does exactly the same task T but
using a different implementation L, then the way to port the Python
program to Lua is to adapt the algorithm so that it uses L.
Any successful port is going to require changes to the implementation,
because the two languages are going to have differences in semantics. The
Ruby print is not absolutely identical to the Python print, so there may
be times you need to work around those differences. Lua's tables are not
identical to either Python lists or dicts (but a little like both).
And port is going to require you to adapt the code. Sometimes a little,
sometimes a lot.
But you know that.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On 18/05/18 13:25, Paul Moore wrote: Arguing about how the community's conventions are wrong is also impolite:-) It's not an argument, it's a contradiction :-) I'm reminded of the old stereotypes of Brits speaking English NICE AND LOUDLY to foreigners to help them understand what we're saying... (Disclaimer: I'm a Brit, so I'm poking fun at myself here :-)) It's not actually the worst thing you could do. People speaking NICE AND LOUDLY also tend to speak more slowly and with better diction, both of which make life simpler for your poor old foreigner. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Fwd: sys module does not contain ps1
-- Forwarded message -- From: Alferdize Date: Thu, May 17, 2018 at 10:13 PM Subject: sys module does not contain ps1 To: [email protected] It is giving error like I have given below >>> import sys >>> sys.ps1 Traceback (most recent call last): File "", line 1, in sys.ps1 AttributeError: module 'sys' has no attribute 'ps1' Python 3.7.0b3 (v3.7.0b3:4e7efa9c6f, Mar 29 2018, 18:42:04) [MSC v.1913 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import sys >>> sys.ps1 Traceback (most recent call last): File "", line 1, in sys.ps1 AttributeError: module 'sys' has no attribute 'ps1' >>> dir(sys) ['__breakpointhook__', '__displayhook__', '__doc__', '__excepthook__', '__interactivehook__', '__loader__', '__name__', '__package__', '__spec__', '__stderr__', '__stdin__', '__stdout__', '_clear_type_cache', '_current_frames', '_debugmallocstats', '_enablelegacywindowsfsencoding', '_framework', '_getframe', '_git', '_home', '_xoptions', 'api_version', 'argv', 'base_exec_prefix', 'base_prefix', 'breakpointhook', 'builtin_module_names', 'byteorder', 'call_tracing', 'callstats', 'copyright', 'displayhook', 'dllhandle', 'dont_write_bytecode', 'exc_info', 'excepthook', 'exec_prefix', 'executable', 'exit', 'flags', 'float_info', 'float_repr_style', 'get_asyncgen_hooks', 'get_coroutine_origin_tracking_depth', 'get_coroutine_wrapper', 'getallocatedblocks', 'getcheckinterval', 'getdefaultencoding', 'getfilesystemencodeerrors', 'getfilesystemencoding', 'getprofile', 'getrecursionlimit', 'getrefcount', 'getsizeof', 'getswitchinterval', 'gettrace', 'getwindowsversion', 'hash_info', 'hexversion', 'implementation', 'int_info', 'intern', 'is_finalizing', 'last_traceback', 'last_type', 'last_value', 'maxsize', 'maxunicode', 'meta_path', 'modules', 'path', 'path_hooks', 'path_importer_cache', 'platform', 'prefix', 'set_asyncgen_hooks', 'set_coroutine_origin_tracking_depth', 'set_coroutine_wrapper', 'setcheckinterval', 'setprofile', 'setrecursionlimit', 'setswitchinterval', 'settrace', 'stderr', 'stdin', 'stdout', 'thread_info', 'version', 'version_info', 'warnoptions', 'winver'] >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On Fri, 18 May 2018 13:25:52 +0100, Paul Moore wrote: > In "Corporate" > cultures like where I work (where IT and business functions interact a > lot, and business users typically use tools like Outlook) top-posting is > common, conventional, and frankly, effective. I don't believe that email is effective in corporate culture *at all*, regardless of posting convention. Email is for sending, not reading or responding to. When people do respond to it, they invariably send some stream of consciousness nonsense that doesn't answer the questions you asked or give you enough instructions to actually get the job done that they want you to do. Email in corporate culture is good for only one thing: after the seventeen pages of quoted text, and before the two page disclaimer telling you that legally you are in violation of a hundred and seventeen laws by merely walking past the building where the email was sent, the sender usually has their phone number so you can call them and ask them what they actually want done. *Usually*. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On 5/18/18 8:25 AM, Paul Moore wrote: > On 18 May 2018 at 12:08, Rhodri James wrote: > There are two completely independent cultures here. In "Corporate" > cultures like where I work (where IT and business functions interact a > lot, and business users typically use tools like Outlook) top-posting > is common, conventional, and frankly, effective. Conversely, in purely > technical communities like open source, where conventions originated > in low-bandwidth channels like early networks, interspersed posting, > heavy trimming and careful quoting are the norm. I've participated in > both communities for 30 years or more, and you deal with people in the > way that they find most comfortable. > > It's polite to follow the conventions of the community that you're > interacting with - so on this mailing list, for example, quoting and > posting inline is the norm and top-posting is considered impolite. > Arguing about how the community's conventions are wrong is also > impolite :-) I'm reminded of the old stereotypes of Brits speaking > English NICE AND LOUDLY to foreigners to help them understand what > we're saying... (Disclaimer: I'm a Brit, so I'm poking fun at myself > here :-)) > > Paul I would divide the two communities/cultures differently. Top Posting is reasonable, effective and common in an environment where the primary recipients of the message can be assumed to have read, and likely remembered, the previous messages, and they are included mostly as a quick memory aid to remember WHICH conversation this message pertains with, or to a lessor extent, to help bring someone new to the conversation up to speed or if the message is pulled up out of an archive. Here the real focus is on the new content and the past record is mostly a 'foot note' (which is expected to be at the end). Since people tend to ignore the quoted material, if often ends up unedited and gets long (this actual is useful when someone new gets added to the email chain) The second community has a wide audience, and it is expected that many people may come in at 'the middle' of a discussion, and thus the message with the history is likely to be read as a whole. It also can generally be assume that prior messages are available, thus less context is 'needed'. Here Interspersed/Bottom posting works better (Interspersed if responding point by point, Bottom if single point or responding to the message en-total.) Mailing list, Usenet, Forums and the like all tend to fall into the second category, but people more used to the more private type of conversations may have bad habits and not think about how it should transition to the different environment. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On Sat, May 19, 2018 at 12:30 AM, Richard Damon wrote: > I would divide the two communities/cultures differently. Top Posting is > reasonable, effective and common in an environment where the primary > recipients of the message can be assumed to have read, and likely > remembered, the previous messages, and they are included mostly as a > quick memory aid to remember WHICH conversation this message pertains > with, or to a lessor extent, to help bring someone new to the > conversation up to speed or if the message is pulled up out of an > archive. Here the real focus is on the new content and the past record > is mostly a 'foot note' (which is expected to be at the end). Since > people tend to ignore the quoted material, if often ends up unedited and > gets long (this actual is useful when someone new gets added to the > email chain) If people are generally going to ignore the quoted content, why have it at all? Why not just post context-free messages that have a reference to the rest of the conversation? The ONLY way that the unedited quoted material is useful to someone joining the email chain is if EVERY message is a response to the single most recent message, and thus carries the entire conversation. Otherwise, your email thread will branch and fork, and someone cc'd in on a message will see only part of the thread, making it worse than useless. The way you describe things, email is the wrong tool for the job, and you should be using a message board of some sort. So, no, top posting still isn't "reasonable, effective, and common" in any environment. It might be common, but that's all. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 18/05/2018 13:29, Steven D'Aprano wrote:
On Fri, 18 May 2018 12:09:02 +0100, bartc wrote:
On 18/05/2018 02:45, Steven D'Aprano wrote:
On Fri, 18 May 2018 02:17:39 +0100, bartc wrote:
Normally you'd use the source code as a start point. In the case of
Python, that means Python source code. But you will quickly run into
problems because you will often see 'import lib' and be unable to find
lib.py anywhere.
Seriously? There's a finite number of file extensions to look for:
.py .pyc .pyo .pyw .dll .so
pretty much is the lot, except on some obscure platforms which few
people use.
Which one corresponds to 'import sys'?
The functions in sys are built-in to the CPython interpreter. For other
interpreters, they could correspond to some file, or not, as the
implementer desires.
So just like built-in functions, your first stop when porting is to READ
THE DOCUMENTATION and learn what the semantics of the functions you care
about, not the source code.
But there is a huge amount of such functionality.
There are other ways of doing it which can make more use of the actual
language (ie. Python) and make use of generally available libraries (eg.
msvcrt.dll/libc.so.6), with fewer mysterious goings-on in the middle.
If I see:
result = math.sin(x)
and I want to port it, what should I do?
print("Hello World!")
is "writing from scratch, not porting" unless the Ruby print uses
precisely the same implementation as the Python print. All that matters
is that for *this* specific use, the two print commands behave the same.
And you've chosen two of the most common language features for your
examples, which would probably be available on a 1970s BASIC (I know SQR
was, can't remember about SIN).
Those are not the kinds of problem I mean.
Since every language has features that some other languages don't have,
is it your position that it is impossible to port code from any
language to any other?
I'm saying some languages make it more difficult, and Python is one of
them
Only if you are trying to port *down* the Blub hierarchy, to a less
powerful language.
You might be trying to go from one level of Blub to the same level of
Blub, but the two Blubs are completely incompatible.
I'm just saying that in my experience, given the choice of porting the
same program from other Python or, say, Lua, I would choose Lua.
If they are *the same program* then surely they will be identical (modulo
syntax and naming of builtins) and there should be no difference in
difficulty in porting.
If they are *semantically the same* (they do the same thing) but have
different implementations, then you've just blown a hole in your own
argument.
Have a look at some of the implementations here (to test some Mandelbrot
benchmark):
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
The three Python examples all use 'import sys' and 'import
multiprocessing', none of which I can find any trace of as any sort of
files let alone .py. One of them also uses 'import array', which I can't
find either.
Now look at the Lua and Lua#2 examples. They don't appear to use
anything that hairy, and could be good candidates for porting. As would
be Free Pascal #3 (the other Pascals use threads).
(Although when I tried to port the Lua just now, I ran into trouble
because I didn't know Lua well enough (it's also poorly written IMO, and
I ran out of time). That's fair enough; you need to be familiar with the
language you're porting from.
But I could be very familiar with Python and still wouldn't be able to
directly translate code which depended heavily on library functions.
Knowing the specification of those is not going to help if I don't
already have something that does exactly the same job.)
Looking also at the amount of code, the Pythons don't appear to be that
much shorter or simpler than many of the others.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Sat, May 19, 2018 at 12:37 AM, bartc wrote: > Have a look at some of the implementations here (to test some Mandelbrot > benchmark): > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html > > The three Python examples all use 'import sys' and 'import multiprocessing', > none of which I can find any trace of as any sort of files let alone .py. > One of them also uses 'import array', which I can't find either. I guess you didn't look very hard. >>> import multiprocessing >>> multiprocessing.__file__ '/usr/local/lib/python3.8/multiprocessing/__init__.py' >>> import array >>> array.__file__ '/usr/local/lib/python3.8/lib-dynload/array.cpython-38m-x86_64-linux-gnu.so' Hey look, files! But that still isn't the point. Porting does NOT mean emulating. Read the documentation, not the implementation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On 2018-05-18, Steven D'Aprano wrote: > On Fri, 18 May 2018 13:25:52 +0100, Paul Moore wrote: > >> In "Corporate" cultures like where I work (where IT and business >> functions interact a lot, and business users typically use tools >> like Outlook) top-posting is common, conventional, and frankly, >> effective. You work someplace pretty unique. Everyplace I've worked has done the whole top-posting and include the whole damn thread in reverse order thing. It just doesn't work. The attached reverse-chronological history doesn't seem to do _any_ good at all. AFAICT, nobody ever reads it. Occasionally somebody will refer opaquely to something with the phrase "see below" -- but there's never any indication to _what_ among the fifteen messages and thirty attachements they are referring. > I don't believe that email is effective in corporate culture *at all*, > regardless of posting convention. Email is for sending, not reading or > responding to. When people do respond to it, they invariably send some > stream of consciousness nonsense that doesn't answer the questions you > asked or give you enough instructions to actually get the job done that > they want you to do. And most people seem to believe that if they read more that the first two sentences of any e-mail it might trigger the apocolypse or give their cat scabies or something else dreadful. -- Grant Edwards grant.b.edwardsYow! I'm EMOTIONAL at now because I have gmail.comMERCHANDISING CLOUT!! -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On 5/18/18 10:38 AM, Chris Angelico wrote: > On Sat, May 19, 2018 at 12:30 AM, Richard Damon > wrote: >> I would divide the two communities/cultures differently. Top Posting is >> reasonable, effective and common in an environment where the primary >> recipients of the message can be assumed to have read, and likely >> remembered, the previous messages, and they are included mostly as a >> quick memory aid to remember WHICH conversation this message pertains >> with, or to a lessor extent, to help bring someone new to the >> conversation up to speed or if the message is pulled up out of an >> archive. Here the real focus is on the new content and the past record >> is mostly a 'foot note' (which is expected to be at the end). Since >> people tend to ignore the quoted material, if often ends up unedited and >> gets long (this actual is useful when someone new gets added to the >> email chain) > If people are generally going to ignore the quoted content, why have > it at all? Why not just post context-free messages that have a > reference to the rest of the conversation? Because, as I said, there are occational and lesser usages for the quoted material, it just isn't primary. It is a 'foot note' > > The ONLY way that the unedited quoted material is useful to someone > joining the email chain is if EVERY message is a response to the > single most recent message, and thus carries the entire conversation. > Otherwise, your email thread will branch and fork, and someone cc'd in > on a message will see only part of the thread, making it worse than > useless. The way you describe things, email is the wrong tool for the > job, and you should be using a message board of some sort. > > So, no, top posting still isn't "reasonable, effective, and common" in > any environment. It might be common, but that's all. > > ChrisA If the thread forks, and someone is brought into one of the forks to help with an issue brought up in THAT fork, then the context will generally be sufficient for that. Normally people WILL reply to the latest message in the chain (and in fact Outlook will warn you if you are not doing that). The main reason people don't reply to the most recent message is that several people replied nearly simultaneously, and yes the other comments not in the message people carry forward will get lost from the history. But for that to happen you need multiple active participants in the conversation which starts to strays away from the model. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On Sat, May 19, 2018 at 1:09 AM, Richard Damon wrote: > If the thread forks, and someone is brought into one of the forks to > help with an issue brought up in THAT fork, then the context will > generally be sufficient for that. That assumes that they don't need any information that was posted in reply to something else. > Normally people WILL reply to the latest message in the chain (and in > fact Outlook will warn you if you are not doing that). The main reason > people don't reply to the most recent message is that several people > replied nearly simultaneously, and yes the other comments not in the > message people carry forward will get lost from the history. But for > that to happen you need multiple active participants in the conversation > which starts to strays away from the model. Considering that I've had situations with 3-4 active participants and replies-to-non-last-emails on our family mailing list - a list whose membership is literally just my parents and siblings (including one sister-in-law) - I would be astonished if it's a rare occurrence in corporate environments. Unless, of course, the norm is to snap off an email instantly, without bothering to actually put any thought into what's being said. Oh wait, it probably is... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
Grant Edwards : > And most people seem to believe that if they read more that the first > two sentences of any e-mail it might trigger the apocolypse or give > their cat scabies or something else dreadful. I quickly glance at the hundred or so subject lines every morning and open the one or two that happen to catch my attention. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: sys module does not contain ps1
On 2018-05-18 12:40, Alferdize wrote: -- Forwarded message -- From: Alferdize Date: Thu, May 17, 2018 at 10:13 PM Subject: sys module does not contain ps1 To: [email protected] It is giving error like I have given below import sys sys.ps1 Traceback (most recent call last): File "", line 1, in sys.ps1 AttributeError: module 'sys' has no attribute 'ps1' [snip] I have the same version (Python 3.7.0b3). Here, sys has 'ps1' and 'ps2', but not 'last_traceback', 'last_type' or 'last_value'. -- https://mail.python.org/mailman/listinfo/python-list
css script project refractor code
i have a project at : README : https://github.com/Abdur-rahmaanJ/css-script/blob/master/README.md SITE : https://abdur-rahmaanj.github.io/css-script/ and i want to refractor the main file : https://github.com/Abdur-rahmaanJ/css-script/blob/master/css_script/main.py if this was an old project of yours, what advices do you give for improvements? Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: sys module does not contain ps1
On Sat, May 19, 2018 at 2:51 AM, MRAB wrote: > I have the same version (Python 3.7.0b3). Here, sys has 'ps1' and 'ps2', but > not 'last_traceback', 'last_type' or 'last_value'. They aren't there till they're needed: $ python3 Python 3.8.0a0 (heads/literal_eval-exception:ddcb2eb331, Feb 21 2018, 04:32:23) [GCC 6.3.0 20170516] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.last_type Traceback (most recent call last): File "", line 1, in AttributeError: module 'sys' has no attribute 'last_type' >>> sys.last_type ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 18/05/2018 15:47, Chris Angelico wrote:
On Sat, May 19, 2018 at 12:37 AM, bartc wrote:
Have a look at some of the implementations here (to test some Mandelbrot
benchmark):
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html
The three Python examples all use 'import sys' and 'import multiprocessing',
none of which I can find any trace of as any sort of files let alone .py.
One of them also uses 'import array', which I can't find either.
I guess you didn't look very hard.
import multiprocessing
multiprocessing.__file__
'/usr/local/lib/python3.8/multiprocessing/__init__.py'
But you have to load it first to find out. (And if you follow nested
imports, you will eventually get to those that don't have a .py file.)
import array
array.__file__
'/usr/local/lib/python3.8/lib-dynload/array.cpython-38m-x86_64-linux-gnu.so'
I get "module 'array' has no attribute '__file__'".
However, if I load sys, multiprocessing and array, then print
sys.modules, I get a very long list of modules, at which point anyone
thinking of emulating the behaviour of those modules would promptly give up.
(BTW here's a port of that benchmark based on the Lua code:
https://pastebin.com/raw/ivDaKudX
The actual language is not relevant, as this is clear enough that it
could probably be re-implemented on anything. The 'files' module is only
needed for openfile, closefile, and 'outbyte', which should be standard
in any language. ('writebytes' might not be, so that was changed to a loop.)
The point of all this: writing clean simple code has a big advantage,
and I think my version is one of the cleanest (even though it writes to
a file, not the console).
Although it should be pointed out that these programs are pulling out
all the stops in order to get the best performance; clarity wasn't a
priority. But they should all use the same algorithm (to be within the
rules), and it is that we're trying to extract.)
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Sat, May 19, 2018 at 3:27 AM, bartc wrote: > On 18/05/2018 15:47, Chris Angelico wrote: >> >> On Sat, May 19, 2018 at 12:37 AM, bartc wrote: >>> >>> Have a look at some of the implementations here (to test some Mandelbrot >>> benchmark): >>> >>> >>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html >>> >>> The three Python examples all use 'import sys' and 'import >>> multiprocessing', >>> none of which I can find any trace of as any sort of files let alone .py. >>> One of them also uses 'import array', which I can't find either. >> >> >> I guess you didn't look very hard. >> > import multiprocessing > multiprocessing.__file__ >> >> '/usr/local/lib/python3.8/multiprocessing/__init__.py' > > > But you have to load it first to find out. (And if you follow nested > imports, you will eventually get to those that don't have a .py file.) ... so? > However, if I load sys, multiprocessing and array, then print sys.modules, I > get a very long list of modules, at which point anyone thinking of emulating > the behaviour of those modules would promptly give up. Once again, you're confusing *porting* with *emulating*. If you don't understand the difference between those two concepts, I recommend spending some time with Wikipedia. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: sys module does not contain ps1
On 5/18/2018 7:40 AM, Alferdize wrote: -- Forwarded message -- From: Alferdize Date: Thu, May 17, 2018 at 10:13 PM Subject: sys module does not contain ps1 To: [email protected] It is giving error like I have given below import sys sys.ps1 Traceback (most recent call last): File "", line 1, in sys.ps1 AttributeError: module 'sys' has no attribute 'ps1' The docs say """ sys.ps1 sys.ps2 Strings specifying the primary and secondary prompt of the interpreter. These are only defined if the interpreter is in interactive mode. """ You must be running your code in a program, perhaps IDLE, that simulates the interpreter's interactive mode, but which actually runs your code in a Python interpreter running in non-interactive mode. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 18/05/2018 18:27, bartc wrote: (BTW here's a port of that benchmark based on the Lua code: https://pastebin.com/raw/ivDaKudX And here's the payoff: I was able to use this version to port it to Python. One which works better the the originals, as they wrote output to the screen (/binary/ output) which I found difficult to capture into an actual ppm file in order to test it worked. The translation was straightforward, EXCEPT that I wasted an hour trying to figure out to write /a single byte/ to a file. The following eventually worked, using a binary file as a text one had Unicode problems, but it's still hacky. Note this version doesn't use any imports at all. # For Python 3 (it'll work on Python 2 but give the wrong results) n = 200# adjust this for output size: n * n pixels outfile = "test.ppm" # adjust for output file name end = 0# lines containing 'end' can be removed def start(): m = 2/n ba = 1<<(n%8+1) bb = 1<<(8-n%8) f = open(outfile,"wb") f.write(b"P4\n") f.write((str(n)+" "+str(n)+"\n").encode()) for y in range(n): ci = y*m-1 b = 1 for x in range(n): cr = x*m-1.5 zr = cr zi = ci zrq = cr*cr ziq = ci*ci b <<= 1 for i in range(1,50): zi = zr*zi*2+ci zr = zrq-ziq+cr ziq = zi*zi zrq = zr*zr if zrq+ziq>4: b +=1 break end end if b>=256: f.write(bytes([511-b])) b = 1 end end if b != 1: f.write(bytes([(ba-b)*bb])) end end f.close() end start() -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 18/05/2018 19:36, Chris Angelico wrote: On Sat, May 19, 2018 at 3:27 AM, bartc wrote: Once again, you're confusing *porting* with *emulating*. This is the point. Those libraries are specific to Python and cannot be ported. And very often they don't just provide general support that can be found, in different forms, in any target language, but is also specific. Then if you are still porting your application, rather than rewriting or heavily adapting, you will need to emulate what they do. If you don't understand the difference between those two concepts, I recommend spending some time with Wikipedia. And I recommend you doing some actual porting from Python or any other big language. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Sat, May 19, 2018 at 4:48 AM, bartc wrote: > The translation was straightforward, EXCEPT that I wasted an hour trying to > figure out to write /a single byte/ to a file. The following eventually > worked, using a binary file as a text one had Unicode problems, but it's > still hacky. You can't write a single byte to a text file, because text files don't store bytes. I'm not sure which part of this took you an hour to figure out. > # For Python 3 (it'll work on Python 2 but give the wrong results) What does "work" mean? If it gives the wrong results, how is it working? > end = 0# lines containing 'end' can be removed You're not writing Python code here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Sat, May 19, 2018 at 4:53 AM, bartc wrote: > On 18/05/2018 19:36, Chris Angelico wrote: >> >> On Sat, May 19, 2018 at 3:27 AM, bartc wrote: > > >> Once again, you're confusing *porting* with *emulating*. > > > This is the point. Those libraries are specific to Python and cannot be > ported. > > And very often they don't just provide general support that can be found, in > different forms, in any target language, but is also specific. > > Then if you are still porting your application, rather than rewriting or > heavily adapting, you will need to emulate what they do. > >> If you don't >> understand the difference between those two concepts, I recommend >> spending some time with Wikipedia. > > > And I recommend you doing some actual porting from Python or any other big > language. > I've ported code from 8086 assembly code to C++, from C to Pike, from DeScribe Macro Language to REXX, and many other pairings, some obscure and some not. Each time, the goal has been to port the PROGRAM, not the underlying libraries. The goal is to reimplement the algorithm in a new language, not to blithely rewrite one line of code at a time using the new language's syntax. I have a quarter century of experience with a quarter million languages. (Okay, that's a bit of a Threepio exaggeration, but a lot of languages.) Porting code from one language to another is not new to me. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 2018-05-18 02:48 PM, bartc wrote: > On 18/05/2018 18:27, bartc wrote: > >> (BTW here's a port of that benchmark based on the Lua code: >> >> https://pastebin.com/raw/ivDaKudX > > And here's the payoff: I was able to use this version to port it to > Python. One which works better the the originals, as they wrote output > to the screen (/binary/ output) which I found difficult to capture > into an actual ppm file in order to test it worked. > > The translation was straightforward, EXCEPT that I wasted an hour > trying to figure out to write /a single byte/ to a file. The following > eventually worked, using a binary file as a text one had Unicode > problems, but it's still hacky. > > Note this version doesn't use any imports at all. Except your version doesn't read its parameter from the command line args and doesn't output to standard output, which all of the others do. That's why the other Python versions of that code imported sys: Because that's how you read from commandline args and write bytes to standard output in Python. You don't need to know *exactly* how sys works to have an idea of what sys.argv and sys.stdout do -- https://mail.python.org/mailman/listinfo/python-list
Re: About: from sklearn import linear_model ModuleNotFoundError: No module named sklearn
On Thursday, May 17, 2018 at 4:54:11 AM UTC-7, Jpn Jha wrote: > Dear Team > Please attached Python_PyCharm Interpreter doc and zoom it . > > The screen shots are explanatory. The Python mailing list is text-only. Your screen shots were removed. In general, please don't use screenshots when asking for programming assistance on the Internet. Aside from the extra bandwidth that screen shots consume, it is also impossible for people who are trying to help you to cut and paste code from a screen shot. Use text. -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 18/05/2018 20:15, Alexandre Brault wrote: On 2018-05-18 02:48 PM, bartc wrote: Note this version doesn't use any imports at all. Except your version doesn't read its parameter from the command line args and doesn't output to standard output, which all of the others do. That's why the other Python versions of that code imported sys: Because that's how you read from commandline args and write bytes to standard output in Python. You don't need to know *exactly* how sys works to have an idea of what sys.argv and sys.stdout do My version wasn't an entry in the Shoot-out game. The command line input was left out as, if someone wants to port the algorithm to their language, they will know how it's done. (And each one will do that messy bit of input a little differently.) Capturing the output as I said was problematic, and I needed that in order to display the .ppm output so that I could see it. Maybe in a Linux environment it can be piped into a program to do that. But that's not what I used; I needed an actual .ppm file. (Something went wrong with the header when trying to direct it to a file. But directing binary data to a text display, with arbitrary byte sequences might be some escape code that does undesirable things, is a no-no for me.) -- bart -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 18/05/2018 19:57, Chris Angelico wrote: On Sat, May 19, 2018 at 4:48 AM, bartc wrote: The translation was straightforward, EXCEPT that I wasted an hour trying to figure out to write /a single byte/ to a file. The following eventually worked, using a binary file as a text one had Unicode problems, but it's still hacky. You can't write a single byte to a text file, because text files don't store bytes. I'm not sure which part of this took you an hour to figure out. I've worked with text files for 40 years. Now Python is telling me I've been doing it wrong all that time! Look at the original code I posted from which this Python was based. That creates a file - just a file - without worrying about whether it's text or binary. Files are just collections of bytes, as far as the OS is concerned. So what could be more natural than writing a byte to the end of a file? (Note that this particular file format is a hybrid; it has a text header followed by binary data. This is not unusual; probably every binary format will contain text too. A programming language - and one that's supposed to be easy - should take that in its stride.) # For Python 3 (it'll work on Python 2 but give the wrong results) What does "work" mean? If it gives the wrong results, how is it working? It works in that Python 2 is not complaining about anything, and it finishes (very quickly too). But the output file is 3 times the size it should be, and contains the wrong data. end = 0# lines containing 'end' can be removed You're not writing Python code here. Sorry but I'm lost without the block terminators. I needed them to match the logic to the original. After I used them, I decided it looked better. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On Thu, May 17, 2018 at 07:56:41AM -0700, Rich Shepard wrote: > Allow me to add an additional reason for trimming and responding > beneath each quoted section: it puts the response in the proper > context. And another one I learned recently on a similar conversation on another mailing list (that of the e-mail client I'm using right now): it is very useful for searches. Every e-mail contains just the right amount of text necessary to be properly read, as opposed to a more or less complete copy of the current thread. Cheers, -- José María Mateos https://rinzewind.org/blog-es || https://rinzewind.org/blog-en -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax oddities
On Fri, May 18, 2018 at 02:55:52PM +, Grant Edwards wrote: > You work someplace pretty unique. Everyplace I've worked has done the > whole top-posting and include the whole damn thread in reverse order > thing. It just doesn't work. The attached reverse-chronological > history doesn't seem to do _any_ good at all. AFAICT, nobody ever > reads it. Occasionally somebody will refer opaquely to something with > the phrase "see below" -- but there's never any indication to _what_ > among the fifteen messages and thirty attachements they are referring. In my experience, this "e-mail-that-contains-the-entire-conversation" is useful if and only if you happen to receive a forwarded copy so you know something you were not previously aware of. Otherwise, replies just accumulate past conversations because people are too lazy to bother. I wouldn't dare inline-replying in my current Outlook corporate environment. I just top-post, don't trim, go with the flow. Cheers, -- José María Mateos https://rinzewind.org/blog-es || https://rinzewind.org/blog-en -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Sat, May 19, 2018 at 7:53 AM, bartc wrote: > I've worked with text files for 40 years. Now Python is telling me I've been > doing it wrong all that time! > > Look at the original code I posted from which this Python was based. That > creates a file - just a file - without worrying about whether it's text or > binary. Files are just collections of bytes, as far as the OS is concerned. > > So what could be more natural than writing a byte to the end of a file? So, you create a file without worrying about whether it's text or binary, and you add a byte to the end of the file. That means you're treating it as a binary file, not as a text file. Do you understand that? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Fri, 18 May 2018 22:53:06 +0100, bartc wrote: > I've worked with text files for 40 years. Now Python is telling me I've > been doing it wrong all that time! Welcome to the 20th Century! We interchange text and data with people from all over the world now, and one or two of them use characters that aren't ASCII! Start here: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ or https://tinyurl.com/h8yg9d7 Then follow up with: https://nedbatchelder.com/text/unipain.html -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 19/05/2018 01:00, Chris Angelico wrote: On Sat, May 19, 2018 at 7:53 AM, bartc wrote: I've worked with text files for 40 years. Now Python is telling me I've been doing it wrong all that time! Look at the original code I posted from which this Python was based. That creates a file - just a file - without worrying about whether it's text or binary. Files are just collections of bytes, as far as the OS is concerned. So what could be more natural than writing a byte to the end of a file? So, you create a file without worrying about whether it's text or binary, and you add a byte to the end of the file. That means you're treating it as a binary file, not as a text file. Do you understand that? Well I /don't/ worry about, but the reason is that long ago I switched to using binary mode for all files. (My 'createfile' function shown after my sig shows how it works. It's a thin wrapper around C's fopen, and it's C that has this thing about text and binary files.) But in Python, even as a binary file I had some trouble writing to it, as it's fussy when dealing with strings and bytearrays and bytes and array.arrays all with their own rules. -- bartc global function createfile(name, options="wb") = if not name.isstring or name="" then return nil fi return fopen(name,options) end -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote: > Unfortunately -- in the current era, "text" means "a defined encoding", Text has ALWAYS meant "a defined encoding". It is just that for a long time, people could get away with assuming that the encoding they used was the *only* possible encoding, and using it implicitly without even thinking about it. That One True Encoding is, of course, EBCDIC. No, I kid, of course it is Mac-Roman. Ha ha, no, just pulling your leg... of course it's ISO 8859-1 (not to be confused with ISO-8859-1, yes the hyphen is significant). Except for web browsers, which are required to interpret declarations of ISO 8859-1 as CP-1252 instead. Actually, I'm still kidding around. Everyone knows the One True Encoding is ISCII. (That's not a typo.) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 19/05/2018 01:42, Dennis Lee Bieber wrote: On Fri, 18 May 2018 22:53:06 +0100, bartc declaimed the following: I've worked with text files for 40 years. Now Python is telling me I've been doing it wrong all that time! Look at the original code I posted from which this Python was based. That creates a file - just a file - without worrying about whether it's text or binary. Files are just collections of bytes, as far as the OS is concerned. And on Windows, there is a difference. On Windows, sending a byte to a TEXT file will result in writing . On Windows a new-line is indicated by that combination: . Are you sure that's Windows itself, and not just the C library? (Which was presumably trying to be helpful by making programs work on Unix and Windows without changes, but is actually a nuisance.) Some Windows programs may need cr,lf, but I doubt they well convert between lf and cr,lf unless they use C file functions. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On 19/05/2018 02:00, Steven D'Aprano wrote: On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote: Unfortunately -- in the current era, "text" means "a defined encoding", Text has ALWAYS meant "a defined encoding". It is just that for a long time, people could get away with assuming that the encoding they used was the *only* possible encoding, and using it implicitly without even thinking about it. That One True Encoding is, of course, EBCDIC. No, I kid, of course it is Mac-Roman. Ha ha, no, just pulling your leg... of course it's ISO 8859-1 (not to be confused with ISO-8859-1, yes the hyphen is significant). Except for web browsers, which are required to interpret declarations of ISO 8859-1 as CP-1252 instead. Actually, I'm still kidding around. Everyone knows the One True Encoding is ISCII. (That's not a typo.) The .ppm (really .pbm) file which was the subject of this sub-thread has its header defined using ASCII. I don't think an EBCDIC 'P4' etc will work. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: what does := means simply?
On Sat, May 19, 2018 at 11:10 AM, bartc wrote: > On 19/05/2018 02:00, Steven D'Aprano wrote: >> >> On Fri, 18 May 2018 20:42:05 -0400, Dennis Lee Bieber wrote: >> >>> Unfortunately -- in the current era, "text" means "a defined >> >> encoding", >> >> Text has ALWAYS meant "a defined encoding". It is just that for a long >> time, people could get away with assuming that the encoding they used was >> the *only* possible encoding, and using it implicitly without even >> thinking about it. >> >> That One True Encoding is, of course, EBCDIC. >> >> No, I kid, of course it is Mac-Roman. >> >> Ha ha, no, just pulling your leg... of course it's ISO 8859-1 (not to be >> confused with ISO-8859-1, yes the hyphen is significant). Except for web >> browsers, which are required to interpret declarations of ISO 8859-1 as >> CP-1252 instead. >> >> Actually, I'm still kidding around. Everyone knows the One True Encoding >> is ISCII. (That's not a typo.) > > > The .ppm (really .pbm) file which was the subject of this sub-thread has its > header defined using ASCII. I don't think an EBCDIC 'P4' etc will work. > "Defined using ASCII" is a tricky concept. There are a number of file formats that have certain parts defined because of ASCII mnemonics, but are actually defined numerically. The PNG format begins with the four bytes 89 50 4E 47, chosen because three of those bytes represent the letters "PNG" in ASCII. But it's defined as those byte values. The first three represent "i&+" in EBCDIC, and that would be just as valid, because you get the correct bytes. Your file contains bytes. Not text. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
decorat{or,ion}
Let's say I want something that does most or all of foo's functionality plus a little more and maybe tweek some of foo's output, so I write a wrapper around foo and call it bar. If inside bar are the call to foo, as well as methods baz(), buz() and bug() that make their magic and bar ends up performing as I want. If I understood correctly baz(), buz() and bug() plus the glue that is bar are decorations around foo or bar is a decorator of foo. Apologies, I don't yet know how to show that foo and bar are meant to be objects. I wrote my first fortran program in the 1960's but this is my first attempt to delve into the world of OOP. At the moment this world view feels like I imagine a grasshopper sees the world through a miriad of lenses. For that matter, are baz(), buz() and bug() methods if they only help bar get the job done but don't have a place in bar's interface? Thanks again, Mike -- "Keep active but don't be afraid to occasionally indulge." - Jeralean Talley, America's oldest living woman -- https://mail.python.org/mailman/listinfo/python-list
Numpy array
This is regarding numpy array. I am a bit confused how parts of the array are
being accessed in the example below.
1 import scipy as sp
2 data = sp.genfromtxt("web_traffic.tsv", delimiter="\t")
3 print(data[:10])
4 x = data[:,0]
5 y = data[:,1]
Apparently, line 3 prints the first 10 entries in the array
line 4 & 5 is to extract all rows but only 1st and second columns alone for x
and y respectively.
I am confused as to how data[:10] gives the first 10 rows while data[:,0] gives
all rows
--
https://mail.python.org/mailman/listinfo/python-list
Re: decorat{or,ion}
Mike McClain writes:
> Let's say I want something that does most or all of foo's
> functionality plus a little more and maybe tweek some of foo's
> output, so I write a wrapper around foo and call it bar.
> If inside bar are the call to foo, as well as methods baz(),
> buz() and bug() that make their magic and bar ends up performing
> as I want.
>
> If I understood correctly baz(), buz() and bug() plus the glue
> that is bar are decorations around foo or bar is a decorator of foo.
Maybe. I have never had need to speak of a "decoration".
My feeling tends more to use this term for the syntactic
construct ("@[(args)]") then the implementation
details of the decorator ("bar" in your example).
> Apologies, I don't yet know how to show that foo and bar are
> meant to be objects.
No need to force yourself to view them as "object"s.
An "object", in general, is something that can have attributes
(holding the object state) and methods (defining often operations on
the object state but in some cases also general operations (not
related to the object state).
In this sense, almost everything you handle in a Python script
can be view as an object (an exception are the variables;
they, themselves, are not objects but their values are objects).
In your example, "foo" and "bar" are functions.
As such, they are also objects - but the feature (attributes,
methods) is rarely used explicitely (you can use
"dir()" to learn what attributes and methods
your function has). You use functions in Python typically as
you are used to use them in another programming language.
> ...
> For that matter, are baz(), buz() and bug() methods if they only
> help bar get the job done but don't have a place in bar's interface?
Your functions are methods, if they are defined inside a class.
Typically (there are exceptions), this means that their definition
occurs at the top level of a "class" statement:
class CLS...:
...
def method(self, ...):
...
In this case, "method" is a method of class "CLS"
and its instances (called "CLS" objects).
When you access a method of an object, then
the function representing the method is wrapped;
the wrapper remembers the object and the function and
ensures that the object is automatically passed as
the first parameter of the function ("self" in the example above)
in method calls.
Thus, the distinction between a method and a "normal" function
is that for a method, the first parameter is passed automatically
while in a "normal" function, the call must pass all arguments explicitly.
--
https://mail.python.org/mailman/listinfo/python-list
