Re: What's the best way to minimize the need of run time checks?

[Steven D'Aprano]

On Fri, 12 Aug 2016 09:55 pm, BartC wrote:

> On 12/08/2016 12:07, Steven D'Aprano wrote:
>> On Fri, 12 Aug 2016 07:38 pm, BartC wrote:
>>
>>> 'year' has been spelled wrongly
>>
>> How do you know?
> 
> I know because my intention was to create a RECORD, with a specific set
> of members or fields. With records, you usually don't just create
> arbitrary named members as you go along.

Unfortunately your intention counts for nothing. You know what they say
about computers: the damned things don't do what you want, only what you
tell them to do.

The equivalent of a record in Python is not an arbitrary object, but a
tuple, or perhaps a namedtuple if you want to access fields by name.



>> There are broadly two tactics that a language can take when it comes to
>> attribute (or more widely, variable) names:
>>
>>
>> (1) Editing is cheap, but compiling and testing code is expensive
> 
> No, compiling is cheap too.

Perhaps now, but not always. And not even always now.


>> The first time I ever compiled a full-sized application (not a particular
>> large one either, it was a text editor a little more featureful than
>> Notepad) it took something like nine hours to compile on a Mac SE (this
>> was circa 1990).
> 
> That is completely crazy even for 1990. I was using my own tools then
> and the time to re-compile a 50,000-line application would have been
> measured in seconds. Certainly not minutes anyway (I wouldn't have had
> the patience!).

Long compile times were certainly not unusual in the 1980s and even into the
1990s. Using the most powerful machines available, people would regularly
set up compile jobs to run overnight.

The Macintosh SE was built on a Motorola 68000 CPU with a clock speed of 7.8
MHz. (That was a little slower than equivalent Intel processors at the
time, but the Motorola CPUs had bigger pipelines or more registers or
something, I forget exactly what, that meant that they were actually a tad
faster than Intel despite the lower clock speed.)

Let's compare with something more recent:

http://www.openoffice.org/FAQs/build_faq.html#howlong

Building Open Office on a 1.8GHz Pentium takes about 4 hours, or 1.44e+13
nanoseconds (the reciprocal unit of GHz). Now, I know, and you know, that
you can't just compare clock speeds across entirely different CPUs, but I'm
going to do it anyway. The Pentium was something like 230 times faster than
the Motorola 68000 in my Mac SE, which would suggest that Open Office would
have taken over 900 hours (five weeks plus change) to build on my Mac SE,
if it had existed (it didn't) and if it could have fit on the 20MB hard
drive I had at the time (just the Open Office source code is 400MB, so it
wouldn't have).

Of course Open Office is a little bigger and more complex than that old text
editor: 30K files versus a dozen or so, nine million LOC versus, oh I don't
know, let's say 50 KLOC. That gives a back-of-the-envelope figure of about
180 times "bigger", based on LOC. 900 hours divide by 180 gives five hours,
within the ballpark of my memory.

By memory, my Mac SE had all of 1MB of RAM, although unlike earlier Macs at
least it had dedicated VRAM for the display. You know how software can
trade off space for time? Yeah, well when you've got less than 1MB
available, you're often trading off time for space.

So I completely reject your assertion that compilation is and always has
been cheap. Overnight builds were common, and I'm not being unreasonable to
talk about a nine-hour compilation on an underpowered entry-level machine
back in 1990 or thereabouts.


[...]
> My example was specifically about attribute names where pre-declaring
> the set of allowed attributes would not be onerous, 

Others disagree: millions of people use languages which eschew mandatory
variable declarations (Ruby, Lua, Python, Javascript, Perl, PHP, etc).


> would be usefully 
> self-documenting, and would allow more errors to be picked up.

Not really - declarations simply switch *when* the error is noticed, not
whether or not it is.


> (Of course the design of Python makes that impractical because it would
> require the byte-code compiler to see inside imported modules before
> execution is commenced.)

That's not the fundamental problem. Most of the time, modules are available
compiled to byte-code (.pyc files), so Python could compile a list of
variable names used. CPython does something similar for functions: each
function has a table of variables, taken from a quick two-pass compilation
process.

But the fundamental problem is that Python has an exec command. Ultimately,
the only way to tell what variables actually exist is to execute the code.
In Python 2, CPython worked around exec inside functions with difficulty.
In Python 3, exec inside a function is simply prohibited unless you supply
a separate local namespace.

Now, a linter, editor or other external tool is perfectly capable of using
heuristics to recognise what is *likely* to be a variable. It doesn't
matter if your IDE

Re: What's the best way to minimize the need of run time checks?

[Steven D'Aprano]

On Fri, 12 Aug 2016 11:30 pm, Michael Torrie wrote:

> On 08/12/2016 05:07 AM, Steven D'Aprano wrote:
>> The first time I ever compiled a full-sized application (not a particular
>> large one either, it was a text editor a little more featureful than
>> Notepad) it took something like nine hours to compile on a Mac SE (this
>> was circa 1990). How mad would I have been if, eight hours and thirty
>> minutes into the compilation, the compiler suddenly stopped with an error
>> caused by a mistyped variable name?
> 
> Surely this application was built using a build system, even back then,
> that would allow compilation to resume and not rebuild object files that
> were already built.

To be honest, I don't remember. It was so-called "Lightspeed Pascal", later
renamed "Think Pascal", and especially after that experience I mostly used
it for experimenting with Hypertalk XCMDs and XFNCs, which were much
simpler as they weren't stand-alone GUI applications.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Asynchronous programming

[Marko Rauhamaa]

Paul Rubin :

> Keep in mind that the above basically takes the task off the list of
> runnables for 0.2 seconds, so it sits doing nothing and doesn't
> interfere with other tasks running. In the case where you're doing
> actual computation, you want to yield (await) much more often than 0.2
> sec, so other tasks can stay responsive. This is cooperative
> multitasking, where each task has to be nice to the others, in
> contrast with preemptive multitasking where the task switches happen
> behind the scenes.

I don't suppose the Python database API has yet been ported to asyncio,
has it? That means database access is not yet quite usable with asyncio
(or any other form of asynchronous programming).

Also, one must be careful with file access, which is necessarily
blocking on linux (unless Python takes Linux's AIO API into use, which
would be groundbreaking).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

How to add data in xlm file ?

[Asad ur Rehman]

def Test(request):

save_path = '/usr/share/newfies/'

name_of_file = ("Avatar")

completeName = os.path.join(save_path, name_of_file+".xlm") 

file1 = open(completeName, "w")

toFile = raw_input("Write what you want into the field")

file1.write(toFile)

file1.close()

This is code for save file in specific directory.Output of this file is empty i 
want to get data from database i write database query in it but it did't 
work.Example\

def Test(request):

save_path = '/usr/share/newfies/'

name_of_file = ("Avatar")

completeName = os.path.join(save_path, name_of_file+".xlm") 

file1 = open(completeName, "w")

toFile = Subscriber.objects.all().count()

file1.write(toFile)

file1.close()


Subscriber is table name in my database.

How can i get data ?
Thanks in advance !
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[BartC]

On 13/08/2016 08:37, Steven D'Aprano wrote:

On Fri, 12 Aug 2016 09:55 pm, BartC wrote:



I know because my intention was to create a RECORD, with a specific set
of members or fields. With records, you usually don't just create
arbitrary named members as you go along.


Unfortunately your intention counts for nothing. You know what they say
about computers: the damned things don't do what you want, only what you
tell them to do.

The equivalent of a record in Python is not an arbitrary object, but a
tuple, or perhaps a namedtuple if you want to access fields by name.


OK, yet another thing I wasn't aware of (Python seems to be bristling 
with these things!). But when I tried it, it seems even namedtuples are 
immutable, so in most instances they can't do the same job.


The __slots__ thing, while crude, seems to be a better bet.

(The way I deal with records elsewhere is so ridiculously simple that it 
almost makes me want to cry when I see what most dynamic languages have 
to do. Example:


record date=# define the record
   var day, month, year
end

d := date(25,12,2015)   # create an instance

d.year := 1999  # change a field

println d   # show "(25,12,1999)"

Typing .yaer by mistake is usually picked up at compile-time - unless 
there is an actual field 'yaer' define elsewhere and it's in scope. Then 
it's detected at runtime like using __slots__.)



(1) Editing is cheap, but compiling and testing code is expensive


No, compiling is cheap too.


Perhaps now, but not always. And not even always now.



The Macintosh SE was built on a Motorola 68000 CPU with a clock speed of 7.8
MHz.



Of course Open Office is a little bigger and more complex than that old text
editor: 30K files versus a dozen or so, nine million LOC versus,


Ridiculously bloated project. And an average of 300 lines per file? Why 
not just one function per file then.


But even given that, I can't see that a 9Mloc project, as a monolithic 
file, would take (today) more than a minute or so with a snappy 
compiler. What kills it is probably two things: being fragmented among 
30,000 files; and, assuming this is C code, those things called 
'headers' where you have to repeatedly compile the same junk over and 
over again (perhaps 30,000 times in this case).


A static size of 9Mloc could mean a /considerably/ higher line-count 
needing to be compiled when headers are taken into account.


So a poor language, poor project structure, and probably slow compilers 
all contributing.



By memory, my Mac SE had all of 1MB of RAM, although unlike earlier Macs at
least it had dedicated VRAM for the display. You know how software can
trade off space for time? Yeah, well when you've got less than 1MB
available, you're often trading off time for space.


The first working compiler I did was for an 8-bit 4-MHz Z80 with 64KB 
memory. It was designed to give instant results (commercial compilers 
such as for C I understood spent most of their time grinding floppy disks).


The programs were small, but there was anyway an upper limit as to how 
big they could be as they had to fit into a small memory. I don't 
remember /ever/ having to wait unduly for any re-compile even as 
machines and projects got bigger.


I saw it as part of my job to continually ensure my tools were fit for 
purpose. Eventually I introduced dynamic, scripting languages into my 
apps to keep the edit-compile-run cycle close minimal most of the time.



So I completely reject your assertion that compilation is and always has
been cheap.


You're right in that using conventional tools it probably wasn't. It was 
for me however.



(Of course the design of Python makes that impractical because it would
require the byte-code compiler to see inside imported modules before
execution is commenced.)



But the fundamental problem is that Python has an exec command.


Also that 'import' statements can be conditional. And could have 
intervening code between them that redefines names from an earlier import.



Now, a linter, editor or other external tool is perfectly capable of using
heuristics to recognise what is *likely* to be a variable. It doesn't
matter if your IDE's code completion fails to work here:

exec("value = 1")
x = val[press tab for code completion]

but it would be completely unacceptable for the compiler to flag this as an
error:

exec("value = 1")
x = value + 1
^
SyntaxError: no variable called 'value'


I don't know how exec works. Is the 'value' name a local if this is in a 
function, or a global if outside a function?


If your example was in a function, wouldn't 'value' be assumed to be a 
global anyway, if it wasn't assigned to anywhere else in the function?


I can't see an issue with names inside exec() that are designed to be 
used outside, required to be 'declared' outside the exec. That is, 
created as they normally are in Python, by assignment. But then I expect 
that any Python code, inside exec or not, 

Re: Win32 API in pywin32

[eryk sun]

On Sat, Aug 13, 2016 at 4:22 AM, Lawrence D’Oliveiro
 wrote:
> On Friday, August 5, 2016 at 11:58:05 AM UTC+12, I wrote:
>>
>> Are people still using Win32? I thought Windows went 64-bit years ago.
>
> Here  
> is a little titbit I was looking for:
>
> Win32 has a function for getting the size of a file. File sizes on
> Windows are limited to 2^64 bytes, and so they need a 64-bit integer to
> be expressed easily. But the API call to get the size of a file doesn't
> give you a 64-bit value. Instead, it gives you a pair of 32-bit values
> that have to be combined in a particular way. For 32-bit Windows, that's
> sort of understandable; 32-bit Windows is, well, 32-bit, so you might not
> expect to be able to use 64-bit integers. But if you use the same API in
> 64-bit Windows, it still gives you the pair of numbers, rather than just
> a nice simple 64-bit number. While this made some kind of sense on 32-bit
> Windows, it makes no sense at all on 64-bit Windows, since 64-bit Windows
> can, by definition, use 64-bit numbers.
>
> This is why it’s still called “Win32” and not “Win64”...

You can call GetFileSizeEx [1]. Or call GetFileInformationByHandleEx
[2] to get the FileStandardInfo. These APIs use the LARGE_INTEGER
union type, which has a long long "QuadPart" member. Pointer casting
between LARGE_INTEGER and long long (or int64_t from stdint.h) poses
no alignment problem. That's why ctypes can define LARGE_INTEGER
simply as a c_longlong:

>>> wintypes.LARGE_INTEGER


In contrast, FILETIME isn't a union, so ctypes has to define the low
and high parts separately to get the correct 4-byte alignment:

>>> wintypes.FILETIME._fields_
[('dwLowDateTime', ),
 ('dwHighDateTime', )]
>>> ctypes.alignment(wintypes.FILETIME)
4

FILETIME is a legacy of the Windows API. The kernel and user-mode
runtime library (i.e. Rtl* in ntdll) use LARGE_INTEGER. Note that all
of the info classes for GetFileInformationByHandleEx also use
LARGE_INTEGER because they're basically a thin layer over the NT API.
For example, compare WinAPI FileFullDirectoryInfo [3] with NT API
FileFullDirectoryInformation [4]. They're identical. Using the WinAPI
wrapper is just missing some features of the native
NtQueryDirectoryFile system call, such as the ability to use an event
or APC routine to operate asynchronously and also the FileName
parameter that supports wildcards (NT style [5], not DOS).

[1]: https://msdn.microsoft.com/en-us/library/aa364957
[2]: https://msdn.microsoft.com/en-us/library/aa364953
[3]: https://msdn.microsoft.com/en-us/library/hh447298
[4]: https://msdn.microsoft.com/en-us/library/ff540289
[5]: https://msdn.microsoft.com/en-us/library/ff546850
-- 
https://mail.python.org/mailman/listinfo/python-list

Python Indentation

[Cai Gengyang]

Indentation matters. Each line under the if statement that is indented will 
only be executed if the statement is true:

if a == 1:
print("If a is one, this will print.")
print("So will this.")
print("And this.")
 
print("This will always print because it is not indented.")

Indentation must be the same. This code doesn't work.

if a == 1:
  print("Indented two spaces.")
 print("Indented four. This will generate an error.")
print("The computer will want you to make up your mind.")

Why does the first example work and the 2nd example doesn't work ? Can someone 
explain in layman's terms what indentation is and why the first one works and 
the 2nd one doesn't ? Thanks alot

Gengyang
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Chris Angelico]

On Sat, Aug 13, 2016 at 8:09 PM, BartC  wrote:
> The language doesn't make it easy for itself!

No, it doesn't. But it does make things easy for *me*, the programmer.
And yaknow what? If I want a language that makes things easy on
*itself*, I can always go write assembly language code. That's not
what I want, usually. It's definitely not what I want for efficient,
productive code on a project with more than one programmer.

At the very highest level of abstraction are human thoughts. At the
lowest, we have actual CPU-level opcodes and whatnot. In between, we
have layer upon layer of execution systems, designed to spare us
humans the hassle of translating our thoughts all the way down. When
you write code, you're reducing your thoughts to a more concrete
level; and you can pick any of quite a number of actual abstraction
levels. Programmers are generally more productive when they get to
write more abstract code, rather than mess around with the lower, more
concrete, levels - maybe it doesn't seem like much difference on
initial coding, but it's HUGELY beneficial when you edit afterwards.
In fact, the correct way to edit code is to go right back to the
highest level of abstraction - the human thought - and either correct
an error in translation (ie "this is what was intended, so make the
code do that" - debugging, at its most fundamental) or change the
thought and retranslate. Keeping the code closer to that thought is
critical to that.

Python is already at a fairly high level of abstraction. That's part
of what makes it so good. Another important part, though, is its
incredible dynamism, which allows you to *create new levels* above
what the language itself offers. Consider this code, for instance:

class Invoice(Base):
__tablename__ = "invoices"
id = Column(Integer, primary_key=True)
customer_id = Column(Integer)
date = Column(Date, nullable=False)
updated = Column(Boolean, nullable=False, default=False)

It's a declarative way to create a database table. It's pretty
readable. It's fully executable, thanks to some magic in the "Base"
class (itself made by SQLAlchemy's declarative_base() factory, if you
want to look up the docs and find something that I got wrong here).
But in concrete terms, all it's doing is subclassing a class and
creating some class-level attributes. If Python's class system were a
simple and rigid thing like you have in C++, sure, maybe some simple
jobs would be a bit easier - but this kind of thimg would be
*impossible*. You can't use a C++ class to represent something like
this, simply by subclassing the right thing.

And if subclassing isn't enough, there's no end of stuff you can do
with decorators. Try this:

class Foo:
@prop
class demo:
"""Declarative property"""
def get(self):
print("Getting %s.demo" % self)
return 42
def set(self, val):
print("Setting %s.demo" % self)
def delete(self):
print("Deleting %s.demo" % self)

Yaknow, because @property is just waaay too clunky, right? :) But
I needed a simple demo. The decorator isn't even all that complicated.

def prop(cls):
return property(cls.get, getattr(cls, "set"), getattr(cls,
"delete"), cls.__doc__)

Now, try to do this kind of thing in a strict language. Use a class to
create something that isn't a class. Slap metaprogramming into
anything you want. Make executable DSLs that seamlessly integrate with
the rest of the code. It might be possible, but it sure won't be this
easy!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Indentation

[Marko Rauhamaa]

Cai Gengyang :

> Can someone explain in layman's terms what indentation is

Indentation means the number space (" ") characters in the beginning of a
line.

A sequence of lines that have the same indentation belong to the same
block of statements.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Indentation

[Chris Angelico]

On Sat, Aug 13, 2016 at 8:52 PM, Cai Gengyang  wrote:
> Indentation must be the same. This code doesn't work.
>
> if a == 1:
>   print("Indented two spaces.")
>  print("Indented four. This will generate an error.")
> print("The computer will want you to make up your mind.")
>
> Why does the first example work and the 2nd example doesn't work ? Can 
> someone explain in layman's terms what indentation is and why the first one 
> works and the 2nd one doesn't ? Thanks alot

Indentation is whitespace at the beginning of the line. And the reason
this code doesn't work is that more indentation means more levels in,
like this:

# Top level
def frobnicate(stuff):
# Inside the function
for thing in stuff:
# Inside the loop
if thing.frobbable:
# Inside the conditional
thing.frob()
# Where is this?
return "All frobbed"

A casual eye will tell you that the return statement is outside the
loop, outside the condition, but inside the function. And that's
exactly how Python interprets it, too - but to do that, it absolutely
depends on the indentation levels being consistent. Normally you'll be
extremely consistent (eg four spaces for the first level, eight for
the second, then twelve, sixteen, etc); all Python actually demands is
that you use the same number of spaces and/or tabs (and they're not
equivalent - one tab matches one tab, one space matches one space) for
the same level of nesting.

My recommendation to you is that you pick some way of indenting and
use it everywhere. The most common would be either one tab per level,
or four spaces per level. (Also, do not get into arguments about which
one is better. They're not productive.)

Python makes things fairly easy on you. If you end a line with a
colon, you indent the next line. If you don't, you don't. Good rule of
thumb :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Gregory Ewing]

Steven D'Aprano wrote:

To be honest, I don't remember. It was so-called "Lightspeed Pascal", later
renamed "Think Pascal", and especially after that experience I mostly used
it for experimenting with Hypertalk XCMDs and XFNCs, which were much
simpler as they weren't stand-alone GUI applications.


I did some pretty extensive work with Think Pascal on a
1MB Mac Plus with two floppy drives (no HD) and I always
found it to be very efficient and a pleasure to work with.

Nine hours to compile a simple text editor sounds completely
ridiculous to me, even for the times. Something must have
been very, very badly wrong.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[BartC]

On 13/08/2016 12:10, Chris Angelico wrote:

On Sat, Aug 13, 2016 at 8:09 PM, BartC  wrote:



And if subclassing isn't enough, there's no end of stuff you can do
with decorators. Try this:

class Foo:
@prop
class demo:
"""Declarative property"""
def get(self):
print("Getting %s.demo" % self)
return 42
def set(self, val):
print("Setting %s.demo" % self)
def delete(self):
print("Deleting %s.demo" % self)

Yaknow, because @property is just waaay too clunky, right? :) But
I needed a simple demo. The decorator isn't even all that complicated.

def prop(cls):
return property(cls.get, getattr(cls, "set"), getattr(cls,
"delete"), cls.__doc__)


Which level is this nearer to, human thoughts or cpu codes?

My knowledge of Python isn't advanced enough to understand what this 
does. But if you would be good enough to explain or to show the end 
results (what it makes possible) then I could get an opinion as to how 
hard it might be with less dynamic features.


(But don't try and explain decorators. I've tried several times to get 
my head around them.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Marko Rauhamaa]

Gregory Ewing :
> Nine hours to compile a simple text editor sounds completely
> ridiculous to me, even for the times. Something must have been very,
> very badly wrong.

Some ten years back full compilations of our product could take 23
hours. The bulk of the time was spent thrashing, as SCons produced a
dependency graph so large (~ 90,000 nodes) the Python process couldn't
fit in the RAM of the build machine. When we split the build by the
target architecture, build times came down to three hours.

Still, the main problem was that the whole code base was in a single
repository. By the time I left, work was under way to divide the code
into independent components.

A similar componentization strategy in my current job has made it so
that a full build takes less than a minute, and an incremental build a
few seconds.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[BartC]

On 13/08/2016 13:08, BartC wrote:

On 13/08/2016 12:10, Chris Angelico wrote:

On Sat, Aug 13, 2016 at 8:09 PM, BartC  wrote:



And if subclassing isn't enough, there's no end of stuff you can do
with decorators. Try this:

class Foo:
@prop
class demo:
"""Declarative property"""
def get(self):
print("Getting %s.demo" % self)
return 42
def set(self, val):
print("Setting %s.demo" % self)
def delete(self):
print("Deleting %s.demo" % self)

Yaknow, because @property is just waaay too clunky, right? :) But
I needed a simple demo. The decorator isn't even all that complicated.

def prop(cls):
return property(cls.get, getattr(cls, "set"), getattr(cls,
"delete"), cls.__doc__)



(But don't try and explain decorators. I've tried several times to get
my head around them.)


This is a clearer than usual explanation:

 http://thecodeship.com/patterns/guide-to-python-function-decorators/

Not quite simple enough however to figure out how decorators benefit 
your example! (Maybe an example with and without decorators?)


So if the aim is to keep code readable and understandable to as wide an 
audience as possible, 'decorators' don't really work. (Perhaps if they 
are buried somewhere else and only an interface is visible, but then it 
doesn't matter so much how hairy that buried code is.)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Asynchronous programming

[Paul Rubin]

Marko Rauhamaa  writes:
> Also, one must be careful with file access, which is necessarily
> blocking on linux (unless Python takes Linux's AIO API into use, which
> would be groundbreaking).

AIO is a possibility for i/o on an already-open file and I think there
may be other ways to do it too.  But there appears to be no way to open
a file without potentially blocking, potentially for a long time on a
busy hard disk or a remote file system.  GHC and Erlang both use a
thread pool to deal with opening disk files.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Steven D'Aprano]

On Sat, 13 Aug 2016 08:09 pm, BartC wrote:

> (The way I deal with records elsewhere is so ridiculously simple that it
> almost makes me want to cry when I see what most dynamic languages have
> to do. Example:
> 
> record date=# define the record
> var day, month, year
> end
> 
> d := date(25,12,2015)   # create an instance
> d.year := 1999  # change a field
> println d   # show "(25,12,1999)"

Sure. But you've put most of the work into the compiler. Since you wrote the
compiler, you still had to do the work.

Python has gone over 20 years with no syntax or built-in function for
creating "records", because they're not really needed. We have tuples,
namedtuples and objects, which are much more powerful. But out of
curiosity, I thought I'd write something to define a record as you would
have it.

A couple of tricky bits:

- Since I'm not writing a compiler, I'm limited to syntax as 
  allowed by Python. That means I have to give the record name
  twice: once as the binding target, and once as an argument
  to the "record" function.

- The trickiest bit is defining the record class' __init__ 
  method, since I don't know how many arguments it will need.

Nevertheless, here you go. This was about 5 minutes work. Not too bad for a
first draft.

def record(name, fieldnames, verbose=False):
if isinstance(fieldnames, str):
fieldnames = fieldnames.split()
class Inner(object):
__slots__ = fieldnames
def __str__(self):
fields = ', '.join([repr(obj) for obj in self._fields])
return "record %s(%s)" % (type(self).__name__, fields)
__repr__ = __str__
@property
def _fields(self):
return [getattr(self, name) for name in fieldnames]
Inner.__name__ = name
ns = {}
template = "def __init__(self, %s):\n" % ', '.join(fieldnames)
for name in fieldnames:
template += 'self.%s = %s\n' % (name, name)
if verbose:
print("Using __init__ template:")
print(template)
exec(template, ns, ns)
Inner.__init__ = ns['__init__']
return Inner


py> date = record('date', 'year month day')
py> x = date(2016, 8, 14)
py> x
record date(2016, 8, 14)
py> x.year = 1999
py> x
record date(1999, 8, 14)


> I don't know how exec works. Is the 'value' name a local if this is in a
> function, or a global if outside a function?

exec takes a string, and executes it as Python code. You can specify the
name spaces to use for globals and locals; by default they use globals()
and locals().

Exec of a string on its own is like executing code at the top level of the
module:

exec("spam = 1")

is like:

spam = 1 

in the module scope. You can specify another namespace:

import math
exec("spam = 1", vars(math))

is like executing "spam = 1" in the top level of the math module.

ns = {}
exec("spam = cos(pi)", vars(math), ns)
print(ns['spam'])


will print -1.0. It is equivalent to executing the line "spam = cos(pi)"
inside an imaginary function running inside the math module. That imaginary
function's local variables (in this case, there's only one, "spam") is
recorded in the dictionary "ns" for later retrieval.

> If your example was in a function, wouldn't 'value' be assumed to be a
> global anyway, if it wasn't assigned to anywhere else in the function?

Maybe.

The rules for running exec inside a function in Python 2 are awfully
complex, as it interact with the CPython optimization of using a table for
locals instead of a dict. In Python 3, you cannot call exec() inside a
function unless you explicitly specify a namespace to use.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Creating dictionary of items from Excel with mutliple keys

[Atri Mahapatra]

I am trying to create a following dictionary. I am reading data from excel 
which has data in the following format:

Sl no:  Name Thickness Length Material Width Quantity Side 

It has 20 rows of data.


The dictionary for the 20 rows, I would like to make is 

Data_Dict = [ 
{ 'Name': 'X', 'Length': '10' , 'Width': '5', 'Quantity': 2 'Area': 50};
{ 'Name': 'Y', 'Length': '20' , 'Width': 10', 'Quantity': 1 'Area': 200};
.
.
.
.
till 20 rows
];

I would like to add another key 'Area' as shown above. I used the following 
code(s):

using openpyxl:
d={}
for i  in range(3,sheet.max_row+1):
#for j in range(3,9):
#for k in range(0,5):
  Name = sheet.cell(row= i,column=3).value
  Length =sheet.cell(row =i,column=6).value
  Breadth= sheet.cell(row=i,column=7).value
  Quantity = sheet.cell (row=i,column=8).value
  Area = sheet.cell(row 
=i,column=6).value*sheet.cell(row=i,column=7).value
  d[Name]= Length,Breadth,Quantity,Area

which gave an output like: 
['X': (10, 5, 2, 50), 'Y': (20, 10, 1, 2232600), 'Z': (5, 2, 1, 10), 
.]

Another code using xlrd:

keys = [sheet.cell(2, col_index).value for col_index in range(0,8)]
print (keys)
dict_list = []
d = {}
for row_index in range(1, xl_sheet.nrows):
   for col_index in range(0,8):
   d = {keys[col_index]: xl_sheet.cell(row_index, col_index).value 
   for col_index in range(0,8)}
   dict_list.append(d)

print (dict_list)
which did not have the area and neither the output was little messy.



The main purpose is to sort the dictionary based on different criteria like 
Length or Area. I think the first one may be easier to sort. However if there 
are any better way to represent  the dictionary  and the code so that it can be 
sorted later based on different attributes please feel free to suggest. 


Thanks,
Atri 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Indentation

[Cai Gengyang]

Oh ok, so for the first block , it works because the indentation is the same 
for all 3 "print" statements , i.e. the indentation is 4 spaces for each of the 
3 print statements.

if a == 1: 
print("If a is one, this will print.") 
print("So will this.") 
print("And this.") 
  
print("This will always print because it is not indented.") 

For the 2nd block of code, it doesn't work because the indentation is 
different, 2 spaces for the first statement, 5 for the 2nd statement and 4 for 
the 3rd statement.

if a == 1: 
  print("Indented two spaces.") 
 print("Indented four. This will generate an error.") 
print("The computer will want you to make up your mind.") 

Am i correct ?







On Saturday, August 13, 2016 at 7:12:19 PM UTC+8, Marko Rauhamaa wrote:
> Cai Gengyang :
> 
> > Can someone explain in layman's terms what indentation is
> 
> Indentation means the number space (" ") characters in the beginning of a
> line.
> 
> A sequence of lines that have the same indentation belong to the same
> block of statements.
> 
> 
> Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Indentation

[Chris Angelico]

On Sun, Aug 14, 2016 at 3:06 AM, Cai Gengyang  wrote:
> Oh ok, so for the first block , it works because the indentation is the same 
> for all 3 "print" statements , i.e. the indentation is 4 spaces for each of 
> the 3 print statements.
>
> if a == 1:
> print("If a is one, this will print.")
> print("So will this.")
> print("And this.")
>
> print("This will always print because it is not indented.")
>
> For the 2nd block of code, it doesn't work because the indentation is 
> different, 2 spaces for the first statement, 5 for the 2nd statement and 4 
> for the 3rd statement.
>
> if a == 1:
>   print("Indented two spaces.")
>  print("Indented four. This will generate an error.")
> print("The computer will want you to make up your mind.")
>
> Am i correct ?

Yep! That's correct.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Indentation

[Cai Gengyang]

Yay !

On Sunday, August 14, 2016 at 1:40:09 AM UTC+8, Chris Angelico wrote:
> On Sun, Aug 14, 2016 at 3:06 AM, Cai Gengyang  wrote:
> > Oh ok, so for the first block , it works because the indentation is the 
> > same for all 3 "print" statements , i.e. the indentation is 4 spaces for 
> > each of the 3 print statements.
> >
> > if a == 1:
> > print("If a is one, this will print.")
> > print("So will this.")
> > print("And this.")
> >
> > print("This will always print because it is not indented.")
> >
> > For the 2nd block of code, it doesn't work because the indentation is 
> > different, 2 spaces for the first statement, 5 for the 2nd statement and 4 
> > for the 3rd statement.
> >
> > if a == 1:
> >   print("Indented two spaces.")
> >  print("Indented four. This will generate an error.")
> > print("The computer will want you to make up your mind.")
> >
> > Am i correct ?
> 
> Yep! That's correct.
> 
> ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Christian Gollwitzer]

Am 12.08.16 um 11:58 schrieb BartC:

On 12/08/2016 10:45, Chris Angelico wrote:

On Fri, Aug 12, 2016 at 7:38 PM, BartC  wrote:

You can be too dynamic. Take an example like this:



 d.yaer=1999

 print (d.day,d.month,d.year)



This would never get past a static language nor some that also have
dynamic
types.


Nor will it get past a lot of linters. Or unit tests. There are other
solutions.


How would a linter know that you didn't /want/ to create a new attribute
called 'yaer'?


It is possible to create an attribute outside of the class, but it is 
unusual. I tried your example using pylint. It gives me:


W:  9, 0: Attribute 'yaer' defined outside __init__ 
(attribute-defined-outside-init)


Granted, pylint also spits an enormous amount of other stylistic 
warnings about spaces and "wrong" indents which, strangely, have the 
same weight "warning" as this bug, so it's a bit hard to find.


A linter from another language I use also spell-checks variable names, 
i.e. if it finds two variables with suspiciously similar names, it 
reports it. Of course the linter never knows for sure, it can only give 
warnings.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Creating dictionary of items from Excel with mutliple keys

[Michael Selik]

On Sat, Aug 13, 2016 at 12:46 PM Atri Mahapatra 
wrote:

> I am trying to create a following dictionary. I am reading data from excel
>

Rather than using xlrd or other tools to read from excel, can you save the
file as CSV (comma-separated values)? I think you'll find Python's csv
module is very pleasant to use.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to add data in xlm file ?

[Karim]

On 13/08/2016 11:05, Asad ur Rehman wrote:

def Test(request):

 save_path = '/usr/share/newfies/'

 name_of_file = ("Avatar")

 completeName = os.path.join(save_path, name_of_file+".xlm")

 file1 = open(completeName, "w")

 toFile = raw_input("Write what you want into the field")

 file1.write(toFile)

 file1.close()

This is code for save file in specific directory.Output of this file is empty i 
want to get data from database i write database query in it but it did't 
work.Example\

def Test(request):

 save_path = '/usr/share/newfies/'

 name_of_file = ("Avatar")

 completeName = os.path.join(save_path, name_of_file+".xlm")

 file1 = open(completeName, "w")

 toFile = Subscriber.objects.all().count()

 file1.write(toFile)

 file1.close()


Subscriber is table name in my database.

How can i get data ?
Thanks in advance !


Hello,

Use the standard module (I use python2.7), code not tested If my memory 
is good this is the general way to do it:


from xml.dom   import minidom
from xml.etree import ElementTree as et

from xml.etree.ElementTree import ElementTree, Element


fname = "my_input_file"

xml_data = et.parse(fname)

root_element = xml_data.getroot()

new_element = et.Element("new_tag")

root_element.append(new_element)

new_element.set('new_attribute', 'attribute value')

fout = "my_ouput_file"

fout.write(prettify(root_element))


Where prettify() is defined by:

def prettify(element):
"""
Pretty print to an indented XML output.

@param element   a Element object.

@return a pretty-printed XML string for the element.
"""
# The idea is to print your Element in a string, parse it using
# minidom and convert it again in XML using toprettyxml function.
raw_string = et.tostring(element, encoding='UTF-8', method='xml')
reparsed   = minidom.parseString(raw_string)

return reparsed.toprettyxml(indent='\t', encoding='UTF-8')

Cheers
Karim





--
https://mail.python.org/mailman/listinfo/python-list

Looking for info on how Python developers negotiate breaking changes in PyPI packages

[Chris Bogart]

Hi, I'm looking for some help from Python developers who write PyPI
packages (or open source software that depends on PyPI packages). My
research group is interested in the impacts of different choices
package managers make when designing their ecosystems -- e.g.
Python/PyPi, Hackage and R/CRAN. We'd like to know what the
implications of PyPI's design choices are on Python programmers'
collaboration when making breaking changes among packages, and what
you think PyPI's design is trying to accomplish.

Could I ask people to take ~20 minutes of your time and fill out our
survey at http://breakingapis.org/survey ? I'll report back here when
we've analyzed the results (or there's a sign up link to be notified
when results are out at http://breakingapis.org ).

(If you don't use PyPI, but do use some other software ecosystem, like
Node.js/NPM, CPAN, Erlang/Hex, or something else, we're still
interested -- just make a different "software ecosystem" choice on the
first page. The study is a comparison among ecosystems; PyPI is one
point of comparison).

Thanks,
Chris Bogart
Institute for Software Research
Carnegie Mellon University
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Asynchronous programming

[Ethan Furman]

On 08/11/2016 07:14 AM, Steven D'Aprano wrote:

On Thu, 11 Aug 2016 03:06 pm, Paul Rubin wrote:


The basic characteristic of asynchronous programming is that it involves
changing all your usual blocking i/o calls to non-blocking ones, so your
program can keep running as soon as your request is started.


That's the bit that confuses me. I understand about parallel processing, but
that's not what this is about.

Say I want to download data from a network, and it will take a long time. If
I can do the read in parallel to something else, that makes sense:

   begin downloading in another thread/process
   make a coffee
   process download


But what's the point in doing it asynchronously if I have to just wait for
it to complete?

   begin downloading in an async thread
   twiddle thumbs, doing nothing
   process download


async, threads, multiprocessing, etc., all only make sense if you have more 
than one thing to do.  The advantage of the new async stuff is it allows us to 
write in a synchronous manner (making async calls instead of blocking calls) 
and the underlying framework takes care of the hassle of using threads or 
multiprocessing or whatever.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[BartC]

On 13/08/2016 17:06, Steven D'Aprano wrote:

On Sat, 13 Aug 2016 08:09 pm, BartC wrote:



record date=# define the record
var day, month, year
end

d := date(25,12,2015)   # create an instance



Sure. But you've put most of the work into the compiler.


Into the language so that it's always available and consistent rather 
than leaving it to individuals to somehow build something on top of 
existing language features.



But out of
curiosity, I thought I'd write something to define a record as you would
have it.

A couple of tricky bits:

- Since I'm not writing a compiler, I'm limited to syntax as
  allowed by Python. That means I have to give the record name
  twice: once as the binding target, and once as an argument
  to the "record" function.

- The trickiest bit is defining the record class' __init__
  method, since I don't know how many arguments it will need.

Nevertheless, here you go. This was about 5 minutes work. Not too bad for a
first draft.

def record(name, fieldnames, verbose=False):
if isinstance(fieldnames, str):
fieldnames = fieldnames.split()
class Inner(object):
__slots__ = fieldnames
def __str__(self):
fields = ', '.join([repr(obj) for obj in self._fields])
return "record %s(%s)" % (type(self).__name__, fields)
__repr__ = __str__
@property
def _fields(self):
return [getattr(self, name) for name in fieldnames]
Inner.__name__ = name
ns = {}
template = "def __init__(self, %s):\n" % ', '.join(fieldnames)
for name in fieldnames:
template += 'self.%s = %s\n' % (name, name)
if verbose:
print("Using __init__ template:")
print(template)
exec(template, ns, ns)
Inner.__init__ = ns['__init__']
return Inner


py> date = record('date', 'year month day')
py> x = date(2016, 8, 14)
py> x
record date(2016, 8, 14)
py> x.year = 1999
py> x
record date(1999, 8, 14)


That's pretty good actually. Although I noticed you used the __slots__ 
feature that you were scathing about earlier on! (Also that you've 
thrown in examples of using decorators, and using exec(), free of charge..)


There are a number of ways this approach differs from the native record 
example (but I acknowledge your example was put together as a quick demo):


* The fields in my record are known at compile time; using the wrong 
name will usually be picked immediately. As will using the wrong number 
of initialisers.


* (My record fields have other features: aliases for any field; the 
ability to access by index, doing len() etc; fast conversions to and 
from a list; also the ability to create packed records that exactly 
match C structs, and so on.)


* Each defined record in my scheme ('date' and so on) is a distinct 
type. If I use the Python record() to create two records R and S, then 
type(R) and type(S) seem to give the same result (both 'type').


* Record names and fields are case insensitive in my implementation.

* The Python version can't take advantage of a simple and fast native 
implementation of records. (A simple loop creating a list of a few 
million date records, excluding overheads, took 12 times as long Python 
3, as my language. PyPy only took twice as long, but it's likely just 
taking advantage of the big loop.


* But the biggest problem I think, as I hinted above, is that this is 
not a standard part of the language. It's same thing with trying to fix 
C issues by writing macros; everyone will roll their own versions. Or 
not bother at all.


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: A strange list concatenation result

[Mok-Kong Shen]

Am 13.08.2016 um 03:08 schrieb Steven D'Aprano:

On Sat, 13 Aug 2016 06:44 am, Mok-Kong Shen wrote:


list2 = [1,2,3]
list1 += [4,5,6]
print(list1, list2)

[1, 2, 3, 4, 5, 6] [1, 2, 3]


Does that help?


I don't yet understand why in my 2nd example list2 came out as
[1, 2, 3] outside.


Because you assign list2 = [1, 2, 3]. What did you expect it to be?


But in my function test() there is a code line "list2=list2+[4,5,6]".
Could you kindly explain why this didn't work?

M. K. Shen

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why my image cannot be displayed?

[huey . y . jiang]

On Friday, August 12, 2016 at 9:40:15 PM UTC-4, huey.y...@gmail.com wrote:
> Hi All,
> 
> Image display drives me crazy. After I get it displayed, and want to do the 
> job with a class, display failed again. Please take a look at my trial code:
> 
> from Tkinter import *
> 
> class imageDisplay:
>   def __init__(self, parent=None):
>   canvas = Canvas(width=400, height=300, bg='beige')
>   canvas.pack()
>   self.canvas = canvas
>   img = PhotoImage(file="xxx.gif")
>   self.canvas.create_image(150, 0, image=img, anchor=NW)
> 
> if __name__ == '__main__':
>   imageDisplay()
>   mainloop()
> 
> Result:  A blank canvas was displayed. No error message. 
> 
> Can somebody help? Thanks so much!

Thanks! it's working. Particularly thanks for your explanation! 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Win32 API in pywin32

[Lawrence D’Oliveiro]

On Saturday, August 13, 2016 at 10:49:11 PM UTC+12, eryk sun wrote:
> You can call GetFileSizeEx [1]. Or call GetFileInformationByHandleEx
> [2] to get the FileStandardInfo. These APIs use the LARGE_INTEGER
> union type, which has a long long "QuadPart" member.
> ...
> FILETIME is a legacy of the Windows API. The kernel and user-mode
> runtime library (i.e. Rtl* in ntdll) use LARGE_INTEGER. Note that all
> of the info classes for GetFileInformationByHandleEx also use
> LARGE_INTEGER because they're basically a thin layer over the NT API.
> ...
> [etc etc]

What an absolute mess, compared to the simplicity of POSIX/Linux 
.

Is it any wonder that Microsoft is now adding a Linux API layer to Windows?
-- 
https://mail.python.org/mailman/listinfo/python-list

Multi-Line Strings: A Modest Proposal

[Lawrence D’Oliveiro]

Python allows a single string literal to cross multiple lines, provided it 
begins and ends with three quote characters, e.g.

s = """this string continues
on the next line."""

There is a drawback with this: any whitespace at the start of the continuation 
line is included as part of the string:

>>> print(s)
this string continues
on the next line.

So really, you should write it more like

s = """this string continues
on the next line."""

which gets a bit ugly.

Python has quite a different convention for its compound statements, which can 
(and usually do) continue across multiple lines: and that is the use of 
indentation to denote nesting.

So I propose adapting this convention to triply-quoted strings, as follows: 
lines where the string literal continues must begin with the *same* initial 
whitespace as the line where the string started. This initial whitespace is 
stripped off before including the rest as part of the string. Any additional 
whitespace after that at the start of the line becomes part of the string. So 
the first example would now print as

>>> print(s)
this string continues
on the next line.

which looks more like what was intended.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating dictionary of items from Excel with mutliple keys

[Lawrence D’Oliveiro]

On Sunday, August 14, 2016 at 6:43:54 AM UTC+12, Michael Selik wrote:
> Rather than using xlrd or other tools to read from excel, can you save the
> file as CSV (comma-separated values)? I think you'll find Python's csv
> module is very pleasant to use.

Trying to use Python as a substitute for VBA is not a recipe for happiness.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Asynchronous programming

[Lawrence D’Oliveiro]

On Saturday, August 13, 2016 at 8:26:05 PM UTC+12, Marko Rauhamaa wrote:

> ... (unless Python takes Linux's AIO API into use, which
> would be groundbreaking).

Last I looked, asynchronous I/O on Linux was still a work in progress. The 
whole POSIX API has been grounded in the assumption that all I/O is 
blocking--in other words, I/O requests and process scheduling have been 
inextricably linked. And that has been incorporated into the design of Linux, 
which they now have to disentangle.

Before I was introduced to Unix/Linux, I was using VMS, where all I/O was 
inherently asynchronous and decoupled from process scheduling: all the 
synchronous I/O calls were just userland wrappers that did “queue I/O request” 
followed by “wait for completion”.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multi-Line Strings: A Modest Proposal

[Ben Finney]

Lawrence D’Oliveiro  writes:

> So really, you should write it more like
>
> s = """this string continues
> on the next line."""
>
> which gets a bit ugly.

For this I have the following treatment
http://stackoverflow.com/a/2504454/70157>:

import textwrap

s = textwrap.dedent("""\
this string continues
on the next line.
""")

> So I propose adapting this convention to triply-quoted strings, as
> follows: lines where the string literal continues must begin with the
> *same* initial whitespace as the line where the string started. This
> initial whitespace is stripped off before including the rest as part
> of the string.

Fortunately, the time machine has provided that in the standard library
so you can choose to use it, even without waiting for a convention :-)

-- 
 \   “Prediction is very difficult, especially of the future.” |
  `\   —Niels Bohr |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Asynchronous programming

[Ethan Furman]

On 08/11/2016 10:47 PM, Paul Rudin wrote:

Steven D'Aprano writes:


[...]


In this case, all the work is pure computation, so I don't expect to save
any time by doing this, because the work is still all being done in the
same process/thread, not in parallel. It may even take a little bit longer,
due to the overhead of switching from one to another.


Yeah - you're not gaining anything here. All (?) the interesting use
cases involve waiting for something (e.g. disk access, network
communication, separate process) before you can proceed with your
computation.


The obvious exception being a UI remaining responsive to the user while the 
calculation is processing.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Win32 API in pywin32

[Michael Torrie]

On 08/13/2016 06:22 PM, Lawrence D’Oliveiro wrote:
> On Saturday, August 13, 2016 at 10:49:11 PM UTC+12, eryk sun wrote:
>> You can call GetFileSizeEx [1]. Or call GetFileInformationByHandleEx
>> [2] to get the FileStandardInfo. These APIs use the LARGE_INTEGER
>> union type, which has a long long "QuadPart" member.
>> ...
>> FILETIME is a legacy of the Windows API. The kernel and user-mode
>> runtime library (i.e. Rtl* in ntdll) use LARGE_INTEGER. Note that all
>> of the info classes for GetFileInformationByHandleEx also use
>> LARGE_INTEGER because they're basically a thin layer over the NT API.
>> ...
>> [etc etc]
> 
> What an absolute mess, compared to the simplicity of POSIX/Linux 
> .

POSIX has its share of cruft and redundant interfaces too, I'm sure.
While some parts of the Linux API are simple, others definitely are not,
and Linux has its share of legacy stuff (can you say X11?). And for
user-space things like sound and graphics, APIs are a real hodge-podge
and jumble on Linux and modern Unix operating systems.

> Is it any wonder that Microsoft is now adding a Linux API layer to Windows?

It's certainly not to someday completely replace the native windows
APIs, I can assure you.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Win32 API in pywin32

[Michael Torrie]

On 08/13/2016 06:22 PM, Lawrence D’Oliveiro wrote:
> On Saturday, August 13, 2016 at 10:49:11 PM UTC+12, eryk sun wrote:
>> You can call GetFileSizeEx [1]. Or call GetFileInformationByHandleEx
>> [2] to get the FileStandardInfo. These APIs use the LARGE_INTEGER
>> union type, which has a long long "QuadPart" member.
>> ...
>> FILETIME is a legacy of the Windows API. The kernel and user-mode
>> runtime library (i.e. Rtl* in ntdll) use LARGE_INTEGER. Note that all
>> of the info classes for GetFileInformationByHandleEx also use
>> LARGE_INTEGER because they're basically a thin layer over the NT API.
>> ...
>> [etc etc]
> 
> What an absolute mess, compared to the simplicity of POSIX/Linux 
> .
> 
> Is it any wonder that Microsoft is now adding a Linux API layer to Windows?

Oops had to read the link first.  I get it now!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multi-Line Strings: A Modest Proposal

[John Wong]

On Sat, Aug 13, 2016 at 8:38 PM, Lawrence D’Oliveiro  wrote:

> Python allows a single string literal to cross multiple lines, provided it
> begins and ends with three quote characters, e.g.
>
> s = """this string continues
> on the next line."""
>
> There is a drawback with this: any whitespace at the start of the
> continuation line is included as part of the string:
>
> >>> print(s)
> this string continues
> on the next line.
>
>
I think you meant both trailing characters and starting characters.

The way I solve it, and I still find that extremely ugly, is

s = ("this string continues " +
   "substring continues")

The blackslash is a method I used to do but I start regretting. I have ran
into issue with blackslash before, can't remember but, but most likely with
escaping.

It's ugly when I am in the middle of a deep indented function call. Imagine
I am writing an exception

def foo(...)
  

  raise SomeErrorKindofLong("This is an exception and I need to
write something long {v1} so I need to wrap around it {v2}".format(v1=v1,
v2=v2))

You get the point... by wrapping, I ended up breaking this into multiple
lines. In some cases I would build the string before calling the exception.

That seems a little tangent, but relevant.

The problem with this proposal is that could break existing application.
It's impossible to switch to this convention.

John
-- 
https://mail.python.org/mailman/listinfo/python-list

Anyone here running Python on a PowerPC?

[Steven D'Aprano]

Is there anyone here running Python on a PowerPC willing to help me diagnose
and fix this issue?

http://bugs.python.org/issue27761




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here running Python on a PowerPC?

[Paul Rubin]

Steven D'Aprano  writes:
> Is there anyone here running Python on a PowerPC willing to help me
> diagnose and fix this issue? http://bugs.python.org/issue27761

https://duckduckgo.com/?q=powerpc+emulator

gets a few hits, one on sourceforge and one in QEMU.  I don't know if
those would exhibit the same bug.

I expect there's still old PowerMacs kicking around.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here running Python on a PowerPC?

[Michael Torrie]

On 08/13/2016 08:35 PM, Paul Rubin wrote:
> Steven D'Aprano  writes:
>> Is there anyone here running Python on a PowerPC willing to help me
>> diagnose and fix this issue? http://bugs.python.org/issue27761
> 
> https://duckduckgo.com/?q=powerpc+emulator
> 
> gets a few hits, one on sourceforge and one in QEMU.  I don't know if
> those would exhibit the same bug.
> 
> I expect there's still old PowerMacs kicking around.

It's possible QEMU's PPC emulation is faithful enough to replicate this
issue.

http://wiki.qemu.org/download/qemu-doc.html#PowerPC-System-emulator

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here running Python on a PowerPC?

[Michael Torrie]

On 08/13/2016 08:35 PM, Paul Rubin wrote:
> Steven D'Aprano  writes:
>> Is there anyone here running Python on a PowerPC willing to help me
>> diagnose and fix this issue? http://bugs.python.org/issue27761
> 
> https://duckduckgo.com/?q=powerpc+emulator
> 
> gets a few hits, one on sourceforge and one in QEMU.  I don't know if
> those would exhibit the same bug.
> 
> I expect there's still old PowerMacs kicking around.

I also suggested QEMU, but I'm not sure it's 64-bit PPC, and I'm pretty
sure PowerMacs wouldn't be 64-bit either.  Though I see some references
to PPC64 and QEMU in google searches.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multi-Line Strings: A Modest Proposal

[Steven D'Aprano]

On Sun, 14 Aug 2016 11:53 am, John Wong wrote:

> The way I solve it, and I still find that extremely ugly, is
> 
> s = ("this string continues " +
>"substring continues")

You don't need the plus sign, as Python will concatenate string literals
(not variables) at compile time:

"foo" 'bar' # compiles as 'foobar'

Note that you can mix any of the string delimiters, including raw strings.
And they don't have to be on the same line:

raise ValueError(
"This is a long 'error message' using"
' mixed "quotes" specifically so I can'
" show off Python's string literal concatenation."
)

That's equivalent to the one-line:

raise ValueError("This is a long 'error message' using mixed \"quotes\" 
specifically so I can show off Python's string literal concatenation.")




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure 
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Multi-Line Strings: A Modest Proposal

[Lawrence D’Oliveiro]

On Sunday, August 14, 2016 at 1:53:42 PM UTC+12, John Wong wrote:
> s = ("this string continues " +
>"substring continues")

Now there’s a Java way of doing it. :)

I prefer implicit string concatenation myself.

Isn’t it peculiar that, while this feature was introduced in C and faithfully 
propagated to C++ (and Python), it was inexplicably omitted from Java?

And seemingly, from Perl as well...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here running Python on a PowerPC?

[Lawrence D’Oliveiro]

On Sunday, August 14, 2016 at 3:11:56 PM UTC+12, Michael Torrie wrote:
> I also suggested QEMU, but I'm not sure it's 64-bit PPC, and I'm pretty
> sure PowerMacs wouldn't be 64-bit either.  Though I see some references
> to PPC64 and QEMU in google searches.

A little table here  has a “yes” in the 
“ppc64” column and “GNU/Linux” row. The referenced note 12 says to use qemu 
2.0.0 and the “qemu-system-ppc64” command, plus some other details. (That 
command does exist on my system, though I’ve not tried it.)

While Apple never used 64-bit PowerPC processors, it was clear that the 
architecture was designed with 64-bit in mind from the beginning. Just like the 
Motorola 68000 and immediate successors in the early 1980s were cut-down 32-bit 
processors, so the 601 etc through the 1990s were cut-down 64-bit processors.

(There was a full 64-bit PowerPC processor, the 620, released as part of the 
first generation in 1994 or so. Did anybody ever make use of it?)
-- 
https://mail.python.org/mailman/listinfo/python-list

How do I tell if I'm running on a PowerPC?

[Steven D'Aprano]

I need to be able to programmatically test whether I'm running on a PowerPC.
How can I do that?

import platform
if platform.machine() in ('ppc', 'ppc64'):
print('running PowerPC')


Is that right?


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Steven D'Aprano]

On Sun, 14 Aug 2016 06:59 am, BartC wrote:

> On 13/08/2016 17:06, Steven D'Aprano wrote:
>> On Sat, 13 Aug 2016 08:09 pm, BartC wrote:
> 
>>> record date=# define the record
>>> var day, month, year
>>> end
>>>
>>> d := date(25,12,2015)   # create an instance
> 
>> Sure. But you've put most of the work into the compiler.
> 
> Into the language so that it's always available and consistent rather
> than leaving it to individuals to somehow build something on top of
> existing language features.

Right. And there's little difference between that and making the feature
available from a standard library module, like namedtuple.

If the Python community rallies around this "record" functionality and takes
to it like they took too namedtuple, it could be added to the stdlib. In at
least one way that's better than making it part of the language: you can
backport the module to older versions of the interpreter.

[snip example of a Python "records" factory]
> That's pretty good actually. Although I noticed you used the __slots__
> feature that you were scathing about earlier on! (Also that you've
> thrown in examples of using decorators, and using exec(), free of
> charge..)

I wasn't scathing about __slots__. I said that it was not *added* to the
language in order to support enforcement of "these attributes, and no
others". It was added to the language as a memory optimization.

If you, or Lawrence, wish to (ab)use __slots__ to get a kind of poor mans
attribute declaration, that's your prerogative. I'm on the fence: I can see
that it is, perhaps, sometimes useful, but I wouldn't want to see it become
a widespread habit.


> There are a number of ways this approach differs from the native record
> example (but I acknowledge your example was put together as a quick demo):
> 
> * The fields in my record are known at compile time; using the wrong
> name will usually be picked immediately. As will using the wrong number
> of initialisers.

There's nothing like that in Python. But the difference between compile-time
and run-time is not that significant in practice (as opposed to theory,
where it is critical).


> * (My record fields have other features: aliases for any field; the
> ability to access by index, doing len() etc; fast conversions to and
> from a list; also the ability to create packed records that exactly
> match C structs, and so on.)

I'm not sure what you mean by aliases, or how you would use them. Got an
example?

As for the rest, if I were planning to make this a polished product, I'd
certainly go for access by index and support for len(). Given access by
index, that gives me list conversion and iteration for free.


> * Each defined record in my scheme ('date' and so on) is a distinct
> type. 

As is mine.

> If I use the Python record() to create two records R and S, then 
> type(R) and type(S) seem to give the same result (both 'type').

Of course: the type of a class is "type":

py> type(str), type(int), type(list), type(type)
(, , , )


This is called the metaclass; the class of a class. And yes, type is its own
type. What you should be doing is comparing the types of record *instances*
instead:

py> x = record('Spam', 'breakfast lunch dinner')('spam', 
... 'spam and eggs', 'spam and eggs and spam with a side-dish of spam')
py> y = record('Date', 'year month day')(1999, 'August', 14)
py> type(x), type(y)
(.Inner'>,
.Inner'>)


Hmmm. I didn't expect that. I expected to see the names of the classes:

py> type(x).__name__, type(y).__name__
('Spam', 'Date')


If I was publishing this as a polished product, I'd want to fix that.





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Chris Angelico]

On Sun, Aug 14, 2016 at 2:13 PM, Steven D'Aprano
 wrote:
> What you should be doing is comparing the types of record *instances*
> instead:
>
> py> x = record('Spam', 'breakfast lunch dinner')('spam',
> ... 'spam and eggs', 'spam and eggs and spam with a side-dish of spam')
> py> y = record('Date', 'year month day')(1999, 'August', 14)
> py> type(x), type(y)
> (.Inner'>,
> .Inner'>)
>
>
> Hmmm. I didn't expect that. I expected to see the names of the classes:
>
> py> type(x).__name__, type(y).__name__
> ('Spam', 'Date')
>
>
> If I was publishing this as a polished product, I'd want to fix that.

But at this point, you're at the level of minor tweaks, not core
functionality - and more importantly, proof of concept is successful.
You have a working class factory, which is downright *impossible* in
many languages.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Chris Angelico]

On Sun, Aug 14, 2016 at 2:20 PM, Chris Angelico  wrote:
> You have a working class factory, which is downright *impossible* in
> many languages.

(Unless you count "metaprogramming" to include "programs that write
other programs", of course. That is a legit form of metaprogramming,
in a sense, and does have its benefits, but it's not nearly as simple
as this.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Lawrence D’Oliveiro]

On Sunday, August 14, 2016 at 4:21:16 PM UTC+12, Chris Angelico wrote:
> You have a working class factory, which is downright *impossible* in
> many languages.

If good old, plain old C can do this:

/*prints itself*/void main(void){int c=34;char*s="/*prints itself*/void 
main(void){int c=34;char*s=%c%s%c;printf(s,c,s,c);}";printf(s,c,s,c);}

it can do class factories. :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[Paul Rubin]

Steven D'Aprano  writes:
> If the Python community rallies around this "record" functionality and
> takes to it like they took too namedtuple

I like namedtuple and I think that it's a feature that they're modified
by making a new copy.  I know that has overhead but it's palpably
bug-avoidant.  I've used them extensively in some programs and they took
a considerable burden off my mind compared to using something like
structs or records.
-- 
https://mail.python.org/mailman/listinfo/python-list