Re: An object is an instance (or not)?
Ben Finney wrote: > * In the distant past of Python, some objects were not instances of any > class; the terminology in the documentation and messages shows some > confusing legacies from that ancient time. I presume you are referring to the type/class distinction? That is, in Python 1.5 (for example), the *instance* 23 was an instance of the *type* int but not of any class, as classes (created with the "class" keyword) were distinct from types. If you mean something else, can you explain please? -- Steve -- https://mail.python.org/mailman/listinfo/python-list
python on mobile mailing list
Hi all, the mobile-sig mailing list is alive: https://mail.python.org/pipermail/mobile-sig/2015-January/thread.html If you are interested in python on smart phones that's the place to go! Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to spell this?
In article , [email protected] says... > > More accurately (and as acknowledged in that guide), a single underscore > *is* a common name for a ?don't care? name, but is better avoided for > that purpose because it's also commonly used for other purposes. > > In other words: That guide is correct in its admonition, but that > doesn't challenge what Steven said about common usage. I was not trying to challenge his assertion. Only adding more information to it. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
[email protected] wrote: > On Tue, Jan 27, 2015, at 16:06, Mario Figueiredo wrote: >> That error message has me start that thread arguing that the error is >> misleading because the Sub object does have the __bases__ attribute. >> It's the Sub instance object that does not have it. > > What do you think "Sub object" means? I think it means the Sub class, which is an object. And Python 3.3 agrees with me: py> class Sub(object): ... pass ... py> isinstance(Sub, object) True Sub is also an instance of type. And object is an instance of type, type is an instance of object, and type is a subclass of object. But object is not a subclass of type. However it is an instance of type. Are we confused yet? There is a sense, taken from Java in particular, that "object" is synonymous for "instance". For example, Oracle's documentation for classes says: "A class contains constructors that are invoked to create objects from the class blueprint." http://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html But you won't find any Java documentation referring to the class itself as an object. Java has no metaclasses, classes are not instances of a metaclass, and so classes are never instances. Classes are classes, objects are instances of a class, and that is all there is to it. But in Python, "object" and "instance" are more ambiguous, thanks to metaclasses. Instances of a metaclass are classes, hence classes are instances as well as classes: py> isinstance(Sub, type) True Sub is an instance of the class "type". And because classes themselves are first-class (ha ha!) values, like ints, strings, lists etc., classes are objects. All classes (in Python 3) are instances of a class (the metaclass), but not all instances are classes. Obviously this is rather confusing, but fortunately metaclasses (other than type itself) are rare, so *most of the time* we can get away with Java-like terminology, and pretend that classes are distinct from instances rather than being just another kind of instance (of the metaclass). But what we cannot do is pretend that "object" means instance, because all classes are objects. Alas, habits from other languages leak in, and the Javaesque terminology "Foo object" meaning an instance of Foo sometimes gets used, even though "Foo object" should refer to the object called Foo, namely the class object itself. The unfortunate ambiguity is that sometimes "Foo object" gets used to mean Foo, and other times it gets used to me some instance of Foo. We say: "the None object has no state" and "the function requires an int object as argument". > Sub itself is not a Sub object, Sub itself is not *a* Sub object, it is *the* Sub object, just as 42 is *the* object with type int and value forty-two. > it is a type object. "instance" is > implicit in the phrase "foo object". Alas, classes *are* instances, of their metaclass, so "Sub object" could refer to an instance of Sub (using the Javaesque terminology) or Sub itself (using more Pythonistic terminology). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
[email protected] wrote: > On Wed, Jan 28, 2015, at 00:43, Devin Jeanpierre wrote: >> On Tue, Jan 27, 2015 at 9:37 PM, wrote: >> > Sub itself is not a Sub object, it is a type object. "instance" is >> > implicit in the phrase "foo object". >> >> Yes. Unfortunately, it's still not really completely clear. "Sub >> instance" would avoid this confusion for everyone. > > It really is completely clear. Nobody is confused but you. Ironically, your denial of a pretty clear case of ambiguity demonstrates that if anyone is confused, it is you. In an earlier thread, Mario demonstrated an obvious example of confusing error message due to the object/instance ambiguity, where the error message states that Sub doesn't have a method when it actually does. It is an *instance of Sub*, not the Sub object itself, which lacks the method. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Ben Finney wrote: > Ned Batchelder writes: > >> On 1/27/15 3:12 PM, Mario Figueiredo wrote: >> > This is a follow up from a previous discussion in which it is argued >> > that the following code produces the correct error message terminology, >> > considering that in Python an object is also an instance. >> >> I don't know what the difference is between "object" and "instance". >> An object is an instance of a class. The two words are >> interchangeable as far as I know. > > Not in English grammar, IMO. To say “foo is an instance” implies the > sentence isn't finished; the term “instance” only makes sense in the > context of a relationship to some class. To say “foo is an object” > doesn't have that implication. I'm sure that there is a grammatical term for this, but I don't know it. Regardless of the terminology though, "foo is an instance" is a complete sentence fragment: "foo is an instance" (of some unspecified class) is the same grammatical construct as: "George is a soldier" (of some unspecified army) "Pluto is a cartoon animal" (of some unspecified species) "Bearhugger's Old Peculiar is a drink" (of some unspecified type) "Herbie is a car" (of some unspecified make and model) etc. In Java, the term "object" as a synonym for "instance" is unambiguous, because in Java all classes are subclasses of Object, and no classes are themselves instances of a class. But that's not the case with Python. >> A common mistake is to believe that "OOP" is a well-defined term. >> It's not it's a collection of ideas that are expressed slightly >> differently in each language. > > Right. The common meaning of “object” shared by all OOP systems is > surprisingly small. Agreed. There really is no widespread agreement on what OOP means *precisely*. Wikipedia states: "Attempts to find a consensus definition or theory behind objects have not proven very successful" and there is little agreement of the fundamental features of OOP: http://en.wikipedia.org/wiki/Object- oriented_programming#Fundamental_features_and_concepts [...] > In Python, every class is an object. Every class has the full range of > behaviour that we expect of objects. A class just has the additional > feature that it can be instantiated. We can also define an "is-a" relationship between classes and their instances: [1, 2, "spam"] is-a list; but not list is-a [1, 2, "spam"] However, in Python that breaks down at the very bottom of the inheritance hierarchy, thanks to the circular relationship between type and object: py> isinstance(type, object) True py> isinstance(object, type) True type is-a object object is-a type -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Ned Batchelder wrote: > Do you have a reference that defines these terms? *A* reference is not sufficient. It has to be a reference which all other references agree with. I'll be kind, and lower the requirement to one where *the majority* of other references agree. The OP still won't find one :-) Or perhaps that should be a sad face smiley :-( How much time we would all save if academics and language designers would only stick to a single consistent terminology across all languages. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Mario Figueiredo wrote: > In other words, the object know as "Sub class" is not an instance > object. True, it is an instance of the object 'type'. Can you not see the contradiction there? The object known as 42 is not an instance object. True, it is an instance of the object "int". Er, then surely that means that 42 *is* an instance object? I agree that in *common situations*, it is useful to pretend that Python is like Java, and draw a distinction between classes and instances. I don't think it is useful to deny that classes are instances. The discussion depends on context, in the same way that depending on context sometimes it is useful to include Homo sapiens in the group "Animals" and sometimes not: "Sit up straight and stop eating like an animal!" "Like all animals, human beings rely on the environment for their survival." -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
[email protected] wrote: > I think his objection is to the use of the phrase "'Sub' object" to > refer only to instances of the Sub type, when 'Sub' is the name of the > type object itself and therefore (he thinks) "'Sub' object" should refer > to it instead. (I can only assume he wants "'x' object" for x = Sub().) Yes, that's exactly what Mario asked for in the original thread that started this. Sadly Python cannot do this. But the docs could consistently use "class" or "type" to refer to classes and types (in Python 3, they are the same thing), and "instance" to refer to instances which are not classes, and "object" to refer to both. And then I would be sooo happyy :-) -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Mario Figueiredo wrote: > In article , > [email protected] says... >> >> A common mistake is to believe that "OOP" is a well-defined term. It's >> not it's a collection of ideas that are expressed slightly differently >> in each language. > > A common mistake is thinking just because OOP has different > implementations, it doesn't have a cohesive set of well described rules > and its own well defined terminology. Alas, this is not a mistake. As I posted in a reply to Ben, OOP does not have a cohesive set of rules and well-defined terminology. >> I don't know what a "not fully realized object" is. > > A fully realized object, in an object oriented paradigm, is an object > containing or pointing to data and the methods to act on that data. It's > an instance of a class. In Python, classes meet that definition too. A class in Python is a value which can contain data (or point to data), and it has methods which act on that data. Classes in Python themselves have a class, which we call the metaclass, and classes inherit behaviour from their class just as integer instances inherit behaviour from their class, int. > A *not* fully realized object is possible in Python, since Classes are > first-class objects, despite not being able to participate in OOP. > >> >> What does "participate in OOP" mean? > > Means the object is capable of participating in inheritance and/or > polymorphism. An instance of an object is capable of doing so, per its > class definitions. Whereas a Python class object is not. Class objects are capable of participating in inheritance. A class can have multiple metaclasses. They can even have multiple inheritance of metaclasses. I'm not sure what relevance polymorphism has. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
On Wed, Jan 28, 2015 at 8:16 PM, Steven D'Aprano wrote: > Or perhaps that should be a sad face smiley :-( How much time we would all > save if academics and language designers would only stick to a single > consistent terminology across all languages. That's like wishing that every human spoke the same language, instead of having English, French, Italian, Polish, Serbian, Korean, and a host of others. The problem isn't the languages; the variety of languages reflects a variety of concepts being communicated, and to unify the languages spoken would entail dispensing with that variety. The terminology isn't consistent because there are myriad variations between the concepts. Is it useful to talk about "multiple inheritance" as a concept? I believe I've yet to meet two distinct languages that have identical MI semantics. Does each language need its own word for that term so we don't have any sort of inconsistencies? Or do all languages have to implement the exact same functionality? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
parsing tree from excel sheet
Hi everyone, I've a document structure which is extremely simple and represented on a spreadsheet in the following way (a made up example): subsystem | chapter | section | subsection | subsubsec | A | | || | | func0 | || | | |interface|| | | |latency || | | |priority || | | func1 | || | | |interface|| | | |latency || | | |priority || | | |depend || | | | | variables | | | | || static| | | || global| | | | functions | | | | || internal | | | || external | And I'd like to get a tree like this: A +---> func0 | +---> interface | +---> latency | \---> priority \---> func1 +---> interface +---> latency +---> priority \---> depend +---> variables | +---> static | \---> local \---> functions +---> internal \---> external I know about the xlrd module to get data from excel and I'm also aware about the ETE toolkit (which is more specific for bioinformatics, but I guess can suitable fill the need). Does anyone recommend any other path other than scripting through these two modules? Is there any more suitable module/example/project out there that would achieve the same result? The reason for parsing is because the need behind is to create documents edited in excel but typeset in LaTeX, therefore my script will spill out \chapter, \section and so forth based on the tree structure. Every node will have some text and some images with a very light markup like mediawiki that I can easily convert into latex. Hope I've not been too confusing. Thanks for any pointer/suggestion/comment. Al p.s.: I'm not extremely proficient in python, actually I'm just starting with it! -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Mario Figueiredo wrote: I couldn't think of a way to demonstrate that a class object does not participate in its own inheritance rules. Only instances of it can. I think I may see where your reasoning is going astray. You think that an instance "inherits" methods from its class in the same way that a subclass inherits methods from its base class. But thinking of the instance-class relationship as an inheritance relationship is misleading. It's more accurate to say that a class *defines* the methods that its instances have. The class inherits methods from its base class, but those methods still apply to instances of the class, not the class itself. That doesn't mean the class itself can't be given methods, though. The methods of the class are defined by its metaclass, and the metaclass inherits methods from *its* base class, etc. Here's a diagram: +--+ ++ | type | | base class | +--+ ++ ^ ^ | subclass of | subclass of | | +---+ +---+ +--+ | metaclass |<-| class |<-| instance | +---+ instance of +---+ instance of +--+ It should be clear from this that the relationship between an instance and its class is exactly the same as that between a class and its metaclass, including inheritance relationships. The diagram can be extended indefinitely far to the left -- the metaclass could be an instance of a meta-metaclass, etc. (Although there's an old standing joke in the Python world that metaclasses make your head explode, so I hate to think what a meta-metaclass would do -- probably take out a whole floor of the office building you work in. Meta-meta-metaclasses are right out.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Mario Figueiredo wrote:
An instance of an object is capable of doing so, per its
class definitions. Whereas a Python class object is not.
>>> class Master:
def func(self):
pass
>>> class Sub(Master):
pass
>>> Sub.func()
TypeError: func() missing 1 required positional argument: 'self'
But Sub is not an *instance* of Master here, it's
a *subclass* of Master, which is quite a different
thing:
>>> Sub.__class__
To make Sub be an *instance* of Master, you need to
do this. (NOTE: This is Python 3 syntax; the same
thing can be done in Python 2, but the syntax is
slightly different.)
>>> class Master(type):
... def func(self):
... print("func of", self, "called")
...
>>> class Sub(metaclass = Master):
... pass
...
>>> Sub.__class__
>>> Sub.func()
func of called
So, you see, Python classes *can* participate in OOP
just as fully as any other object. You just need to
know how to do it correctly.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , [email protected] says... > > The thing that bothers me is that many people, some of them with maybe > 20 years of Python experience, have repeatedly stated Python concepts > with respect to the terms class, instance and object. Instead of > accepting their knowledge of the language and gracefully stepping back, > you've carried on until the twist of knots would make any boy scout proud. Condescending much? I'm not one to lower to arguments from authority. Sorry. Never have, never will. Neither I adopt such attitude on those programming languages in which I am myself an authoritative source. I respect knowledge as anyone else. But I also specifically asked for arguments that could show me the Python way. I have a desire to understand. It's not just a matter of accepting the word of someone who is more experienced than me. That does not do any good to anyone. I'm not trying to change anything, neither I'm a OOP fanatic like some tried to accuse me. I'm just trying to understand. Do *you* understand that? I may have sounded ignorant to you. It's something I cannot avoid, because while I try to argue this issue, I do it from the position of someone who is still learning the Python language syntax and semantics. But I'm much more than what you may think. And I would like to be treated with a little more respect. Like you I'm a software developer and, probably like you, I have decades of software development as a profession on my back. But some of the arguments in here (and yours too) have done very little to help me understand the language semantics on this particular issue. Purportedly, or perhaps innocently due to my clumsiness, some folks in here argue with little more than "but a class object is an instance of 'type'". They choose to ignore that class objects are clearly a special type of object unlike the instances they help define. Like in so many debates, there's unfortunately always a desire to ignore or avoid other side that is arguing with us. Thankfully, I am now starting to understand the semantics. Folks like Ben, Steven or Ian (apologies to a couple others I am missing. Can't remember your names and having an hard time looking through past posts) have helped tremendously by leaving smugness aside, adopting an educational attitude towards a clearly confused person, and -- I would wager -- understanding that I'm asking questions, not trying to set new ways. Don't feel so bothered by my person, sir. Just ignore me if that makes you feel better. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Steven D'Aprano writes: > Ben Finney wrote: > > > * In the distant past of Python, some objects were not instances of any > > class; the terminology in the documentation and messages shows some > > confusing legacies from that ancient time. > > > I presume you are referring to the type/class distinction? > > That is, in Python 1.5 (for example), the *instance* 23 was an > instance of the *type* int but not of any class, as classes (created > with the "class" keyword) were distinct from types. That's what I was referring to, yes. All ancient history now. In all current versions of Python, every type is a class and every class is a type, and every type is an object and every class is an object, and every object is an instance of a class and is an instance of a type (and you are me and all are we together). -- \ “I like to reminisce with people I don't know. Granted, it | `\ takes longer.” —Steven Wright | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Gregory Ewing wrote:
> Mario Figueiredo wrote:
>> I couldn't think of a way to
>> demonstrate that a class object does not participate in its own
>> inheritance rules. Only instances of it can.
>
> I think I may see where your reasoning is going astray.
> You think that an instance "inherits" methods from its
> class in the same way that a subclass inherits methods
> from its base class.
In fairness, "inherit" is standard terminology for the way instances get
their behaviour from their class.
Also, you can override methods *on the instance*:
py> class Parrot(object):
... def talk(self):
... print("Polly wants a cracker!")
...
py> polly = Parrot()
py> polly.talk()
Polly wants a cracker!
py> from types import MethodType
py> polly.talk = MethodType(
... lambda self: print("Polly wants a spam sandwich!"), polly)
py> polly.talk()
Polly wants a spam sandwich!
> But thinking of the instance-class relationship as
> an inheritance relationship is misleading. It's more
> accurate to say that a class *defines* the methods
> that its instances have. The class inherits methods
> from its base class, but those methods still apply to
> instances of the class, not the class itself.
I won't speak for other OOP models, but I don't think that is true in
Python. In Python, obj.talk performs the following (grossly simplified)
process:
* search the instance for an attribute "talk"
* search the class
* search all the base classes
* fail
(simplified because I have ignored the roles of __getattr__ and
__getattribute__, of metaclasses, and the descriptor protocol)
That's more or less the same as what happens whether obj is a class object
or a non-class object. I don't know what attribute lookup *literally* uses
the exact same code for looking up attributes on an instance or a class,
but it wouldn't surprise me if it does.
> That doesn't mean the class itself can't be given
> methods, though. The methods of the class are defined
> by its metaclass, and the metaclass inherits methods
> from *its* base class, etc.
The normal way of giving a class methods that are callable from the class is
to define them on the class with the classmethod or staticmethod
decorators. Using a metaclass is usually overkill :-)
> Here's a diagram:
>
> +--+ ++
> | type | | base class |
> +--+ ++
> ^ ^
> | subclass of | subclass of
> | |
> +---+ +---+ +--+
> | metaclass |<-| class |<-| instance |
> +---+ instance of +---+ instance of +--+
>
> It should be clear from this that the relationship
> between an instance and its class is exactly the same
> as that between a class and its metaclass, including
> inheritance relationships.
>
> The diagram can be extended indefinitely far to the
> left -- the metaclass could be an instance of a
> meta-metaclass, etc. (Although there's an old standing
> joke in the Python world that metaclasses make your
> head explode, so I hate to think what a meta-metaclass
> would do -- probably take out a whole floor of the
> office building you work in. Meta-meta-metaclasses are
> right out.)
An early essay on Python metaclasses was subtitled "The Killer-Joke".
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Beginner question - class definition error
Hi
I am just getting started with Python 3.3.3 and Kivy 1.8.
I am using the Kivy development environment on Windows (open a command prompt
and call kivy.bat).
With this minimal code:
import kivy
kivy.require('1.8.0')
from kivy.app import App
from kivy.uix.label import Label
class MyApp(App):
def build(self):
return Label(text='Hello World')
if __name__ == '__main__':
MyApp().run()
I get this error when I run it:
C:\>python MinimalApplication.py
[INFO ] Kivy v1.8.0
[INFO ] [Logger ] Record log in
[INFO ] [Factory ] 157 symbols loaded
[DEBUG ] [Cache ] register with limit=None,
timeout=Nones
[DEBUG ] [Cache ] register with limit=None,
timeout=60s
[DEBUG ] [Cache ] register with limit=None,
timeout=Nones
[INFO ] [Image ] Providers: img_tex, img_dds, img_pygame,
img_gif (img_pil ignored)
[DEBUG ] [Cache ] register with limit=1000,
timeout=60s
[DEBUG ] [Cache ] register with limit=1000,
timeout=3600s
[INFO ] [Text] Provider: pygame
Traceback (most recent call last):
File "MinimalApplication.py", line 7, in
class MyApp(App):
File "MinimalApplication.py", line 12, in MyApp
MyApp().run()
NameError: name 'MyApp' is not defined
How can I fix this please?
Best regards
David
--
https://mail.python.org/mailman/listinfo/python-list
Re: Beginner question - class definition error
On 2015-01-28 11:10, David Aldrich wrote:
Hi
I am just getting started with Python 3.3.3 and Kivy 1.8.
I am using the Kivy development environment on Windows (open a command prompt
and call kivy.bat).
With this minimal code:
import kivy
kivy.require('1.8.0')
from kivy.app import App
from kivy.uix.label import Label
class MyApp(App):
def build(self):
return Label(text='Hello World')
if __name__ == '__main__':
MyApp().run()
I get this error when I run it:
C:\>python MinimalApplication.py
[INFO ] Kivy v1.8.0
[INFO ] [Logger ] Record log in
[INFO ] [Factory ] 157 symbols loaded
[DEBUG ] [Cache ] register with limit=None,
timeout=Nones
[DEBUG ] [Cache ] register with limit=None,
timeout=60s
[DEBUG ] [Cache ] register with limit=None,
timeout=Nones
[INFO ] [Image ] Providers: img_tex, img_dds, img_pygame,
img_gif (img_pil ignored)
[DEBUG ] [Cache ] register with limit=1000,
timeout=60s
[DEBUG ] [Cache ] register with limit=1000,
timeout=3600s
[INFO ] [Text] Provider: pygame
Traceback (most recent call last):
File "MinimalApplication.py", line 7, in
class MyApp(App):
File "MinimalApplication.py", line 12, in MyApp
MyApp().run()
NameError: name 'MyApp' is not defined
How can I fix this please?
Unindent the 'if' statement. Currently, it's indented inside the class
definition, so MyApp isn't defined yet.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Beginner question - class definition error
> Unindent the 'if' statement. Currently, it's indented inside the class > definition, so MyApp isn't defined yet. Thanks very much. That fixed it. Best regards David -- https://mail.python.org/mailman/listinfo/python-list
write file to a server
Hello i'm under windows, i have to write a file from my computer to a local server like taht "\\DOCUMENTALE\my_folder\". How i have to proceed ? Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: write file to a server
On 2015-01-28 13:22, luca72 wrote: Hello i'm under windows, i have to write a file from my computer to a local server like taht "\\DOCUMENTALE\my_folder\". How i have to proceed ? That's a path to a folder that just happens to be on another computer on your network. Treat it the same way you would for a 'local' folder, eg "C:\my_folder". -- https://mail.python.org/mailman/listinfo/python-list
Re: Beginner question - class definition error
> from kivy.app import App > from kivy.uix.label import Label > > class MyApp(App): > def build(self): > return Label(text='Hello World') > > if __name__ == '__main__': > MyApp().run() > > > > I get this error when I run it: > > > Traceback (most recent call last): > File "MinimalApplication.py", line 7, in > class MyApp(App): > File "MinimalApplication.py", line 12, in MyApp > MyApp().run() > NameError: name 'MyApp' is not defined > > How can I fix this please? Try removing beginning indentation from if __name__ == '__main__': if __name__ == '__main__': -- Stanley C. Kitching Human Being Phoenix, Arizona -- https://mail.python.org/mailman/listinfo/python-list
Re: parsing tree from excel sheet
alb wrote:
> Hi everyone,
>
> I've a document structure which is extremely simple and represented on a
> spreadsheet in the following way (a made up example):
>
> subsystem | chapter | section | subsection | subsubsec |
> A | | || |
> | func0 | || |
> | |interface|| |
> | |latency || |
> | |priority || |
> | func1 | || |
> | |interface|| |
> | |latency || |
> | |priority || |
> | |depend || |
> | | | variables | |
> | | || static|
> | | || global|
> | | | functions | |
> | | || internal |
> | | || external |
>
> And I'd like to get a tree like this:
>
> A
> +---> func0
> | +---> interface
> | +---> latency
> | \---> priority
> \---> func1
> +---> interface
> +---> latency
> +---> priority
> \---> depend
> +---> variables
> | +---> static
> | \---> local
> \---> functions
>+---> internal
>\---> external
>
> I know about the xlrd module to get data from excel and I'm also aware
> about the ETE toolkit (which is more specific for bioinformatics, but I
> guess can suitable fill the need).
>
> Does anyone recommend any other path other than scripting through these
> two modules?
>
> Is there any more suitable module/example/project out there that would
> achieve the same result?
>
> The reason for parsing is because the need behind is to create documents
> edited in excel but typeset in LaTeX, therefore my script will spill out
> \chapter, \section and so forth based on the tree structure.
>
> Every node will have some text and some images with a very light markup
> like mediawiki that I can easily convert into latex.
>
> Hope I've not been too confusing.
> Thanks for any pointer/suggestion/comment.
>
> Al
>
> p.s.: I'm not extremely proficient in python, actually I'm just starting
> with it!
You can save the excel sheet as csv so that you an use the csv module which
may be easier to use than xlrd. The rest should be doable by hand. Here's
what I hacked together:
$ cat parse_column_tree.py
import csv
def column_index(row):
for result, cell in enumerate(row, 0):
if cell:
return result
raise ValueError
class Node:
def __init__(self, name, level):
self.name = name
self.level = level
self.children = []
def append(self, child):
self.children.append(child)
def __str__(self):
return "\%s{%s}" % (self.level, self.name)
def show(self):
yield [self.name]
for i, child in enumerate(self.children):
lastchild = i == len(self.children)-1
first = True
for c in child.show():
if first:
yield ["\---> " if lastchild else "+---> "] + c
first = False
else:
yield [" " if lastchild else "| "] + c
def show2(self):
yield str(self)
for child in self.children:
yield from child.show2()
def show(root):
for row in root.show():
print("".join(row))
def show2(root):
for line in root.show2():
print(line)
def read_tree(rows, levelnames):
root = Node("#ROOT", "#ROOT")
old_level = 0
stack = [root]
for i, row in enumerate(rows, 1):
new_level = column_index(row)
node = Node(row[new_level], levelnames[new_level])
if new_level == old_level:
stack[-1].append(node)
elif new_level > old_level:
if new_level - old_level != 1:
raise ValueError
stack.append(stack[-1].children[-1])
stack[-1].append(node)
old_level = new_level
else:
while new_level < old_level:
stack.pop(-1)
old_level -= 1
stack[-1].append(node)
return root
def main():
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("infile")
parser.add_argument("--latex", action="store_true")
args = parser.parse_args()
with open(args.infile) as f:
rows = csv.reader(f)
levelnames = next(rows) # sk
Re: Python is DOOMED! Again!
On Tue, Jan 27, 2015 at 7:26 PM, Steven D'Aprano < [email protected]> wrote: > (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, > Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens > (hundreds?) of other languages disagree with you. > Well, sure. But that's always been one of the nice things about Python, less visual clutter. While I understand where all the type hinting activity is coming from (and accept it as inevitable), I'm also sympathetic to Mario's perspective. Python-1.5-anyone?-ly, y'rs, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: write file to a server
On Thu, Jan 29, 2015 at 12:38 AM, MRAB wrote: > On 2015-01-28 13:22, luca72 wrote: >> >> Hello i'm under windows, i have to write a file from my computer to a >> local server like taht "\\DOCUMENTALE\my_folder\". >> How i have to proceed ? >> > That's a path to a folder that just happens to be on another computer on > your network. Treat it the same way you would for a 'local' folder, > eg "C:\my_folder". And if you've done that and it isn't working, one likely cause is that Windows uses backslashes in path names, but Python string literals treat backslashes specially. Use a raw string literal: path = r"\\DOCUMENTALE\my_folder\some_file_name" with open(path, "wb") as f: ... write to file ... If you have other problems, the best thing to do is to post your code and the exact output it produces, especially if that's a traceback. Those are incredibly helpful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: parsing tree from excel sheet
Hi Peter, Peter Otten <[email protected]> wrote: [] > You can save the excel sheet as csv so that you an use the csv module which > may be easier to use than xlrd. The rest should be doable by hand. Here's > what I hacked together: > > $ cat parse_column_tree.py > import csv > > def column_index(row): >for result, cell in enumerate(row, 0): >if cell: >return result >raise ValueError > > > class Node: >def __init__(self, name, level): >self.name = name >self.level = level >self.children = [] > >def append(self, child): >self.children.append(child) > >def __str__(self): >return "\%s{%s}" % (self.level, self.name) > >def show(self): >yield [self.name] >for i, child in enumerate(self.children): >lastchild = i == len(self.children)-1 >first = True >for c in child.show(): >if first: >yield ["\---> " if lastchild else "+---> "] + c >first = False >else: >yield [" " if lastchild else "| "] + c >def show2(self): >yield str(self) >for child in self.children: >yield from child.show2() > > def show(root): >for row in root.show(): >print("".join(row)) > > def show2(root): >for line in root.show2(): >print(line) > > def read_tree(rows, levelnames): >root = Node("#ROOT", "#ROOT") >old_level = 0 >stack = [root] >for i, row in enumerate(rows, 1): > >new_level = column_index(row) >node = Node(row[new_level], levelnames[new_level]) > >if new_level == old_level: >stack[-1].append(node) >elif new_level > old_level: >if new_level - old_level != 1: >raise ValueError > >stack.append(stack[-1].children[-1]) >stack[-1].append(node) >old_level = new_level >else: >while new_level < old_level: >stack.pop(-1) >old_level -= 1 >stack[-1].append(node) >return root > > def main(): >import argparse >parser = argparse.ArgumentParser() >parser.add_argument("infile") >parser.add_argument("--latex", action="store_true") > >args = parser.parse_args() > >with open(args.infile) as f: >rows = csv.reader(f) >levelnames = next(rows) # skip header >tree = read_tree(rows, levelnames) > >show_tree = show2 if args.latex else show >for node in tree.children: >show_tree(node) >print("") > > if __name__ == "__main__": >main() > $ cat data.csv > subsystem,chapter,section,subsection,subsubsec, > A, > ,func0 > ,,interface,,, > ,,latency,,, > ,,priority,,, > ,func1 > ,,interface,,, > ,,latency,,, > ,,priority,,, > ,,depend,,, > ,,,variables,, > static, > global, > ,,,functions,, > internal, > external, > $ python3 parse_column_tree.py data.csv > A > +---> func0 > | +---> interface > | +---> latency > | \---> priority > \---> func1 > +---> interface > +---> latency > +---> priority > \---> depend >+---> variables >| +---> static >| \---> global >\---> functions > +---> internal > \---> external > > $ python3 parse_column_tree.py data.csv --latex > \subsystem{A} > \chapter{func0} > \section{interface} > \section{latency} > \section{priority} > \chapter{func1} > \section{interface} > \section{latency} > \section{priority} > \section{depend} > \subsection{variables} > \subsubsec{static} > \subsubsec{global} > \subsection{functions} > \subsubsec{internal} > \subsubsec{external} WOW! I didn't really want someone else to write what I needed but thanks a lot! That's a lot of food to digest in a single byte, so I'll first play a bit with it (hopefully understanding what is doing) and then come back with comments. I really appreciated your time and effort. Al -- https://mail.python.org/mailman/listinfo/python-list
Re: parsing tree from excel sheet
On 2015-01-28 10:12, alb wrote: > I've a document structure which is extremely simple and represented > on a spreadsheet in the following way (a made up example): > > subsystem | chapter | section | subsection | subsubsec | > A | | || | > | func0 | || | > | |interface|| | > | |latency || | > | |priority || | > | func1 | || | > | |interface|| | > | |latency || | > | |priority || | > > And I'd like to get a tree like this: > > A > +---> func0 > | +---> interface > | +---> latency > | \---> priority > \---> func1 > +---> interface > +---> latency > +---> priority > > I know about the xlrd module to get data from excel If I have to get my code to read Excel files, xlrd is usually my first and only stop. > Does anyone recommend any other path other than scripting through > these two modules? Well, if you export from Excel as CSV, you can use the "csv" module in the standard library. This is actually my preferred route because it prevents people (coughclientscough) from messing up the CSV file with formatting, joined cells, and other weirdnesses that can choke my utilities. > Is there any more suitable module/example/project out there that > would achieve the same result? I don't believe there's anything that will natively do the work for you. Additionally, you'd have to clarify what should happen if two rows in the same section had different sub-trees but the same content/name. Based on your use-case (LaTex export using these as headers) I suspect you'd want a warning so you can repair the input and re-run. But it would be possible to default to either keeping or squashing the duplicates. > p.s.: I'm not extremely proficient in python, actually I'm just > starting with it! Well, you've come to the right place. Most of us are pretty fond of Python here. :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article <[email protected]>, [email protected] says... > > Mario Figueiredo wrote: > > > Static analysis cannot and should not clutter executable code. > > (1) It isn't clutter. The human reader uses that information as well as the > compiler, interpreter, type-checker, IDE, text editor, correctness tester, > etc. > > (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, > Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens > (hundreds?) of other languages disagree with you. > Sorry. Somehow I missed this post. Only realized now from the Skip answer. This is simply not true! For most of the strongly typed languages (e.g. static typed languages) in that list -- C, C++, C# and Scala, the ones I know best from that list -- require little to no annotations in the code (and certainly no new explicit function or class based syntax) in order for static analysers to perform their thing, except perhaps on the most exotic static analysers. Being a strongly typed language, there is no need for added information in the function signatures. From that list you can safely exclude all strongly-typed languages. For dynamically typed languages, what I have seen being implemented on almost all cases is doc-like features for type annotation. Of the list you provide (few there are dynamically typed, btw) Julia is the one I know of. Julia implements a similar type annotation to type annotations in Python. In fact I see a lot of Julia in PEP 484. But with different objectives: function add(a::Int, b::Int) a + b end Here the :: annotation is meant to attribute a type in an otherwise dynamically typed language and that function signature is executed at runtime with all the implications of a statically typed signature. Static analysis in Julia admitedly can only be performed if those annotations are present, and of the entire list you provide this is the only example language that more closely matches your argument. The others simply are not true. But in any case, in Julia type annotations, contrary to Python, are evaluated at runtime. It then makes all sense for them to coexist with the language syntax. -- https://mail.python.org/mailman/listinfo/python-list
Open file in default app and exit in Windows
I am using the following to open a file in its default application in Windows 7:
from subprocess import call
filename = 'my file.csv'
call('"%s"' % filename, shell=True)
This still leaves a python process hanging around until the launched app is
closed. Any idea how to get around?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Open file in default app and exit in Windows
On 28/01/2015 15:50, [email protected] wrote: > I am using the following to open a file in its default application in > Windows 7: > > from subprocess import call > > filename = 'my file.csv' call('"%s"' % filename, shell=True) > > This still leaves a python process hanging around until the launched > app is closed. Any idea how to get around? > This is somewhat clumsy. The built-in way is: import os os.startfile("my file.csv") TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Open file in default app and exit in Windows
On Wednesday, January 28, 2015 at 10:07:25 AM UTC-6, Tim Golden wrote: > On 28/01/2015 15:50, [email protected] wrote wrote: > > I am using the following to open a file in its default application in > > Windows 7: > > > > from subprocess import call > > > > filename = 'my file.csv' call('"%s"' % filename, shell=True) > > > > This still leaves a python process hanging around until the launched > > app is closed. Any idea how to get around? > > > > This is somewhat clumsy. The built-in way is: > > import os > os.startfile("my file.csv") > > TJG Thank you. That is what I was looking for. -- https://mail.python.org/mailman/listinfo/python-list
Re: Open file in default app and exit in Windows
On 2015-01-28 07:50, [email protected] wrote: > I am using the following to open a file in its default application > in Windows 7: > > from subprocess import call > > filename = 'my file.csv' > call('"%s"' % filename, shell=True) You can try import os filename = 'my file.csv' os.startfile(filename) which works on Windows systems. For other platforms, you'd have to manually spawn either "open" on Macs or "xdg-open" on Linux. Not sure if there's a similar application on the BSDs. -tkc -- https://mail.python.org/mailman/listinfo/python-list
SUBMIT "ACCEPT" button - Python - beautifulsoap
I am totally new to Python and please accept my apologies upfront for potential
newbie errors. I am trying to parse a 'simple' web page: http://flow.gassco.no/
When opening the page first time in my browser I need to confirm T&C with an
accept button. After accepting T&C I would like to scrape some data from that
follow up page. It appears that when opening in a browser directly
http://flow.gassco.no/acceptDisclaimer I would get around that T&C.
But not when I open the URL via beautifulsoap
My parsing/scraping tool is implemented in bs, but I fail to parse the content
as I am not getting around T&C. When printing "response.text" from BS, I get
below code. How do I get around this form for accepting terms & conditions so
that I can parse/scrape data from that page?
Here is what I am doing:
#!/usr/bin/env python
import requests
import bs4
index_url='http://flow.gassco.no/acceptDisclaimer'
def get_video_page_urls():
response = requests.get(index_url)
soup = bs4.BeautifulSoup(response.text)
return soup
print(get_video_page_urls())
PRINTOUT from response.text:
http://www.gassco.no'" type="button" value="Decline"/>
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-30727768-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript';
ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' :
'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
})();
--
https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
On Wed, Jan 28, 2015, at 01:59, Ben Finney wrote: > You have no justification to claim that, and it's hostile and dismissive > to claim it so assertively. Sorry about that - I was tired and had just read through the whole thread at once. > I'll freely admit to finding “'Foo' object” ambiguous. It can reasonably > be interpreted to mean either “a 'Foo' object” (⇒ “an object of class > 'Foo'”), or “the 'Foo' object” (⇒ “the object referred to by the name > 'Foo'”). The error message which inspired this thread needs improvement, > as I've said already. Most objects do not have an idea of their name, though. Assigning an object to a new name doesn't change the object, either. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Wed, Jan 28, 2015 at 8:04 AM, Mario Figueiredo wrote: > In article <[email protected]>, > [email protected] says... >> >> Mario Figueiredo wrote: >> >> > Static analysis cannot and should not clutter executable code. >> >> (1) It isn't clutter. The human reader uses that information as well as the >> compiler, interpreter, type-checker, IDE, text editor, correctness tester, >> etc. >> >> (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, >> Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens >> (hundreds?) of other languages disagree with you. >> > > Sorry. Somehow I missed this post. Only realized now from the Skip > answer. > > This is simply not true! > > For most of the strongly typed languages (e.g. static typed languages) Python is a strongly typed language. It checks types at runtime and does little implicit type conversion. Strong != static. > in that list -- C, C++, C# and Scala, the ones I know best from that > list -- require little to no annotations in the code (and certainly no > new explicit function or class based syntax) in order for static > analysers to perform their thing, except perhaps on the most exotic > static analysers. The languages you cite don't require extra type annotations because they already have the types in the function signatures. Here's an example function signature in Scala: def addInt( a:Int, b:Int ) : Int How is that significantly different from a Python function that uses the proposed annotations? -- https://mail.python.org/mailman/listinfo/python-list
multiprocessing module backport from 3 to 2.7 - spawn feature
List, I've been searching around for a multiprocessing module backport from 3 to 2.7.x and the closest thing I've found was celery's billiard [0] which seems to be a work in progress. The feature I'm specially interested in is the ability to spawn processes [1] instead of forking, which is not present in the 2.7 version of the module. Anyone knows about a working backport of the multiprocessing 3k module? [0] https://github.com/celery/billiard [1] https://docs.python.org/3.4/library/multiprocessing.html#multiprocessing.set_start_method Regards, -- Andrés Riancho Project Leader at w3af - http://w3af.org/ Web Application Attack and Audit Framework Twitter: @w3af GPG: 0x93C344F3 -- https://mail.python.org/mailman/listinfo/python-list
Python on armv7l router: C++ exceptions issue
I run Python on an arm-brcm-linux-uclibcgnueabi router. Python was cross-compiled using hndtools-arm-linux-2.6.36-uclibc-4.5.3 toolchain. While trying to use deluge, I realised that there's something wrong with handling C++ exceptions in C++ extension modules: they're not being caught at all. I tested whether C++ exception handling works on my system in general, and concluded it does work fine. I then wrote a simple C++ extension module with a try-catch block in the init function, that has a "throw 1" in the try section and a "catch (...)" section (see module.cpp), and I got "terminate called after throwing an instance of 'int'" when trying to load the module. Tested this with Python 2.7.9 and 3.4.2, however I had similar issues with other versions, such as 2.7.3 and 2.6.9. Does anyone happen to know what I can try here? Any help is greatly appreciated! Thanks in advance, Alex module.cpp Description: Binary data -- https://mail.python.org/mailman/listinfo/python-list
Re: write file to a server
On 28/01/2015 14:12, Chris Angelico wrote: On Thu, Jan 29, 2015 at 12:38 AM, MRAB wrote: On 2015-01-28 13:22, luca72 wrote: Hello i'm under windows, i have to write a file from my computer to a local server like taht "\\DOCUMENTALE\my_folder\". How i have to proceed ? That's a path to a folder that just happens to be on another computer on your network. Treat it the same way you would for a 'local' folder, eg "C:\my_folder". And if you've done that and it isn't working, one likely cause is that Windows uses backslashes in path names, but Python string literals treat backslashes specially. Use a raw string literal: path = r"\\DOCUMENTALE\my_folder\some_file_name" with open(path, "wb") as f: ... write to file ... If you have other problems, the best thing to do is to post your code and the exact output it produces, especially if that's a traceback. Those are incredibly helpful. ChrisA Windows will accept forward slashes in path names. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing module backport from 3 to 2.7 - spawn feature
On Wed, Jan 28, 2015 at 7:07 AM, Andres Riancho wrote: > The feature I'm specially interested in is the ability to spawn > processes [1] instead of forking, which is not present in the 2.7 > version of the module. > Can you explain what you see as the difference between "spawn" and "fork" in this context? Are you using Windows perhaps? I don't know anything obviously different between the two terms on Unix systems. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
Last night I accidentally deleted a group of *.py files (stupid-stupid-stupid!). Thanks to unpyc3 I have reconstructed all but one of them so far from the *.pyc files that were in the directory __pycache__. Many thanks!!! -- Nico -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On 28/01/2015 15:04, Mario Figueiredo wrote: In article <[email protected]>, [email protected] says... Mario Figueiredo wrote: Static analysis cannot and should not clutter executable code. (1) It isn't clutter. The human reader uses that information as well as the compiler, interpreter, type-checker, IDE, text editor, correctness tester, etc. (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens (hundreds?) of other languages disagree with you. Sorry. Somehow I missed this post. Only realized now from the Skip answer. This is simply not true! For most of the strongly typed languages (e.g. static typed languages) in that list -- C, C++, C# and Scala, the ones I know best from that list -- require little to no annotations in the code (and certainly no new explicit function or class based syntax) in order for static analysers to perform their thing, except perhaps on the most exotic static analysers. C and C++ are weakly and statically typed languages. Python is a strongly and dynamically typed language. Therefore anything following based on the above paragraph alone is wrong. Being a strongly typed language, there is no need for added information in the function signatures. From that list you can safely exclude all strongly-typed languages. For dynamically typed languages, what I have seen being implemented on almost all cases is doc-like features for type annotation. Of the list you provide (few there are dynamically typed, btw) Julia is the one I know of. Julia implements a similar type annotation to type annotations in Python. In fact I see a lot of Julia in PEP 484. But with different objectives: function add(a::Int, b::Int) a + b end Here the :: annotation is meant to attribute a type in an otherwise dynamically typed language and that function signature is executed at runtime with all the implications of a statically typed signature. Static analysis in Julia admitedly can only be performed if those annotations are present, and of the entire list you provide this is the only example language that more closely matches your argument. The others simply are not true. But in any case, in Julia type annotations, contrary to Python, are evaluated at runtime. It then makes all sense for them to coexist with the language syntax. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Wed, Jan 28, 2015 at 12:16 PM, Mark Lawrence wrote: > C and C++ are weakly and statically typed languages. Python is a strongly > and dynamically typed language. Feel free to edit this Google spreadsheet: -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Wed, Jan 28, 2015 at 12:34 PM, Skip Montanaro wrote: > > > On Wed, Jan 28, 2015 at 12:16 PM, Mark Lawrence > wrote: >> >> C and C++ are weakly and statically typed languages. Python is a strongly >> and dynamically typed language. > > > Feel free to edit this Google spreadsheet: Man, sometimes Gmail makes me mad... Ctlr-V shouldn't send. Of course, sending is bound to Shift-Ctrl-V. Sometimes Gmail gets confused or doesn't get the "he let up on the shift key" memo. Or maybe I'm a spaz. At any rate, here's the link: http://preview.tinyurl.com/kcrcq4y Feel free to modify the spreadsheet. Should be open for anyone to edit. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
FWIW I put all my source code inside Dropbox so that even things I haven't yet committed/pushed to Bitbucket/Github are backed up. So far it's worked really well, despite using Dropbox on both Windows and Linux. (See also: Google Drive, etc.) (Free) Dropbox has a 30 day recovery time limit, and I think Google Drive has a trash bin, as well as a 29 day recovery for emptied trash items. That said, hindsight is easier than foresight. I'm glad you were able to recover your files! -- Devin On Wed, Jan 28, 2015 at 10:09 AM, wrote: > Last night I accidentally deleted a group of *.py files > (stupid-stupid-stupid!). > > Thanks to unpyc3 I have reconstructed all but one of them so far from the > *.pyc files that were in the directory __pycache__. Many thanks!!! > > -- Nico > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
why zip64_limit defined as 1<<31 -1?
should not it be 1<<32 -1(4g)? normal zip archive format should be able to support 4g file. thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
On Wed, Jan 28, 2015 at 10:42 AM, Devin Jeanpierre wrote: > FWIW I put all my source code inside Dropbox so that even things I > haven't yet committed/pushed to Bitbucket/Github are backed up. So far > it's worked really well, despite using Dropbox on both Windows and > Linux. (See also: Google Drive, etc.) > > (Free) Dropbox has a 30 day recovery time limit, and I think Google > Drive has a trash bin, as well as a 29 day recovery for emptied trash > items. > > That said, hindsight is easier than foresight. I'm glad you were able > to recover your files! I use Google Drive for it for all the stuff I do at home, and use SVN for all my personal projects, with the SVN depots also in Drive. The combination works well for me, I can transfer between my desktop and laptop freely, and have full revision history for debugging issues. > > -- Devin > > On Wed, Jan 28, 2015 at 10:09 AM, wrote: >> Last night I accidentally deleted a group of *.py files >> (stupid-stupid-stupid!). >> >> Thanks to unpyc3 I have reconstructed all but one of them so far from the >> *.pyc files that were in the directory __pycache__. Many thanks!!! >> >> -- Nico -- https://mail.python.org/mailman/listinfo/python-list
Re: SUBMIT "ACCEPT" button - Python - beautifulsoap
On Wednesday, January 28, 2015 at 8:36:59 AM UTC-8, [email protected] wrote: > I am totally new to Python and please accept my apologies upfront for > potential newbie errors. I am trying to parse a 'simple' web page: > http://flow.gassco.no/ > > When opening the page first time in my browser I need to confirm T&C with an > accept button. After accepting T&C I would like to scrape some data from that > follow up page. It appears that when opening in a browser directly > http://flow.gassco.no/acceptDisclaimer I would get around that T&C. > But not when I open the URL via beautifulsoap > > My parsing/scraping tool is implemented in bs, but I fail to parse the > content as I am not getting around T&C. When printing "response.text" from > BS, I get below code. How do I get around this form for accepting terms & > conditions so that I can parse/scrape data from that page? > > Here is what I am doing: > > #!/usr/bin/env python > import requests > import bs4 > index_url='http://flow.gassco.no/acceptDisclaimer' > > def get_video_page_urls(): > response = requests.get(index_url) > soup = bs4.BeautifulSoup(response.text) > return soup > print(get_video_page_urls()) > > > > PRINTOUT from response.text: > > > > http://www.gassco.no'" type="button" value="Decline"/> > > > > var _gaq = _gaq || []; > _gaq.push(['_setAccount', 'UA-30727768-1']); > _gaq.push(['_trackPageview']); > > (function() { > var ga = document.createElement('script'); ga.type = > 'text/javascript'; ga.async = true; > ga.src = ('https:' == document.location.protocol ? 'https://ssl' : > 'http://www') + '.google-analytics.com/ga.js'; > var s = document.getElementsByTagName('script')[0]; > s.parentNode.insertBefore(ga, s); > })(); > > Try clearing your browser cookies and then reopening the page, it should spit you back to the TOC screen. You can use the Session class to keep track of your cookies between requests: with requests.Session() as s: # Request sessionid cookie and store it in the current session response = s.get('http://flow.gassco.no') # Subsequent gets will now include the session cookie response = s.get('http://flow.gassco.no/acceptDisclaimer') A good place to start when debugging something like this is to open up the developer tools in your browser (F12 in chrome/firefox) and observe the GET requests that get sent out as you click on different buttons. -- https://mail.python.org/mailman/listinfo/python-list
Re: multiprocessing module backport from 3 to 2.7 - spawn feature
On Wed, Jan 28, 2015 at 10:06 AM, Skip Montanaro wrote: > On Wed, Jan 28, 2015 at 7:07 AM, Andres Riancho > wrote: >> The feature I'm specially interested in is the ability to spawn >> processes [1] instead of forking, which is not present in the 2.7 >> version of the module. > > Can you explain what you see as the difference between "spawn" and "fork" in > this context? Are you using Windows perhaps? I don't know anything obviously > different between the two terms on Unix systems. On Unix, if you fork without exec*, and had threads open, threads abruptly terminate, resulting in completely broken mutex state etc., which leads to deadlocks or worse if you try to acquire resources in the forked child process. So in such circumstances, multiprocessing (in 2.7) is not a viable option. But 3.x adds a feature, "spawn", that lets you fork+exec instead of just forking. I too would be interested in such a backport. I considered writing one, but haven't had a strong enough need yet. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: why zip64_limit defined as 1<<31 -1?
On Thu, Jan 29, 2015 at 5:53 AM, jesse wrote: > should not it be 1<<32 -1(4g)? > > normal zip archive format should be able to support 4g file. > > thanks 1<<31-1 is the limit for a signed 32-bit integer. You'd have to look into the details of the zip file format to see whether that's the official limit or not; it might simply be that some (un)archivers have problems with >2GB files, even if the official stance is that it's unsigned. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: write file to a server
On Thu, Jan 29, 2015 at 5:05 AM, Mark Lawrence wrote: > Windows will accept forward slashes in path names. Normally, yes. Does that work for UNC names too? //server/share/pathname ? In any case, that's an alternative solution to the same problem. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
On Thu, Jan 29, 2015 at 5:47 AM, Chris Kaynor wrote: > I use Google Drive for it for all the stuff I do at home, and use SVN > for all my personal projects, with the SVN depots also in Drive. The > combination works well for me, I can transfer between my desktop and > laptop freely, and have full revision history for debugging issues. I just do everything in git, no need for either Drive or something as old as SVN. Much easier. :) Using a more modern source control system (I'd normally recommend people use either git or Mercurial, though there are a few others that are also viable) saves you the trouble of "oops, I'm offline and can't reach the Subversion server" and other issues. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: why zip64_limit defined as 1<<31 -1?
On Wed, Jan 28, 2015 at 11:53 AM, jesse wrote: > should not it be 1<<32 -1(4g)? > > normal zip archive format should be able to support 4g file. Bugs can be filed at http://bugs.python.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
On Wed, Jan 28, 2015 at 1:40 PM, Chris Angelico wrote: > On Thu, Jan 29, 2015 at 5:47 AM, Chris Kaynor > wrote: >> I use Google Drive for it for all the stuff I do at home, and use SVN >> for all my personal projects, with the SVN depots also in Drive. The >> combination works well for me, I can transfer between my desktop and >> laptop freely, and have full revision history for debugging issues. > > I just do everything in git, no need for either Drive or something as > old as SVN. Much easier. :) Git doesn't help if you lose your files in between commits, or if you lose the entire directory between pushes. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
On Thu, Jan 29, 2015 at 8:52 AM, Devin Jeanpierre wrote: > Git doesn't help if you lose your files in between commits, or if you > lose the entire directory between pushes. So you commit often and push immediately. Solved. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode question
On Wed, Jan 28, 2015 8:21 AM CET Terry Reedy wrote: >On 1/27/2015 12:17 AM, Rehab Habeeb wrote: >> Hi there python staff >> does python support arabic language for texts ? and what to do if it >> support it? >> i wrote hello in Arabic using codeskulptor and the powershell just for >> testing and the same error appeared( a sytanx error in unicode)!! > >I do not know how complete the support is, but this is copied from 3.4.2, >which uses tcl/tk 8.6. >>> t = "الحركات" >>> for c in t: print(c) # Prints rightmost char above first >ا >ل >ح >ر >ك >ا >ت Wow, I never knew this was so clever. Is that with or without an RTL marker? >The following StackOverflow question and response indicate that there may b >more issue, but it was asked before tcl/tk 8.6 was available, so the answer >may be partially obsolete. > > >-- Terry Jan Reedy > > >-- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
I distrust any backup strategy that requires explicit action by the user. I've seen users fail too often. (Including myself.) -- Devin On Wed, Jan 28, 2015 at 2:02 PM, Chris Angelico wrote: > On Thu, Jan 29, 2015 at 8:52 AM, Devin Jeanpierre > wrote: >> Git doesn't help if you lose your files in between commits, or if you >> lose the entire directory between pushes. > > So you commit often and push immediately. Solved. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
On Wed, Jan 28, 2015 at 3:01 PM, Devin Jeanpierre wrote: > On Wed, Jan 28, 2015 at 2:02 PM, Chris Angelico wrote: >> On Thu, Jan 29, 2015 at 8:52 AM, Devin Jeanpierre >> wrote: >>> Git doesn't help if you lose your files in between commits, or if you >>> lose the entire directory between pushes. >> >> So you commit often and push immediately. Solved. > I distrust any backup strategy that requires explicit action by the > user. I've seen users fail too often. (Including myself.) That tends to be my opinion and experience as well :) And that is where Drive is quite nice: its an automatic backup to an off-site backup that requires no user action. Having some form of source control is still needed however, as you don't get all the nice history with Drive, and don't have the atomic updates - typically, every save will be uploaded, even if that change itself will break everything as you haven't made the required changes to other files. Chris K -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
On Wednesday, January 28, 2015 at 3:13:36 PM UTC-8, Chris Kaynor wrote: > On Wed, Jan 28, 2015 at 3:01 PM, Devin Jeanpierre > wrote: > > On Wed, Jan 28, 2015 at 2:02 PM, Chris Angelico wrote: > >> On Thu, Jan 29, 2015 at 8:52 AM, Devin Jeanpierre > >> wrote: > >>> Git doesn't help if you lose your files in between commits, or if you > >>> lose the entire directory between pushes. > >> > >> So you commit often and push immediately. Solved. > > I distrust any backup strategy that requires explicit action by the > > user. I've seen users fail too often. (Including myself.) > > That tends to be my opinion and experience as well :) > > And that is where Drive is quite nice: its an automatic backup to an > off-site backup that requires no user action. Having some form of > source control is still needed however, as you don't get all the nice > history with Drive, and don't have the atomic updates - typically, > every save will be uploaded, even if that change itself will break > everything as you haven't made the required changes to other files. > > Chris K I'd definitely store all of my programming projects in a Google Drive if I wasn't already using Dropbox. I recently finished my CS degree, and I had more than one professor say that they won't take "My computer crashed and I lost everything!" as an excuse for not being able to turn in homework. Dropbox and Google Drive are both free, easy to use, and will keep several versions of your files so you can even use the excuse that your most recent save got corrupted. Also, it was really nice to easily be able to save my work on my laptop, finish it on my desktop, and then print it from a school computer without dealing with a thumb drive. -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
[email protected] wrote: > I recently finished my CS degree, and I had more than one professor say > that they won't take "My computer crashed and I lost everything!" as an > excuse for not being able to turn in homework. How about "My computer crashed and died and now I can't get to Dropbox to access my files"? "My computer got infected by ransomware which encrypted all my data files and blocks access to Dropbox." "One of my housemates torrented a Linux tarball, and the MPAA wrongly identified it as a movie file. Purely on their say-so, my ISP disabled my account and banned me from the Internet. But all is not lost, if I move 45 miles away, I can sign up with a different ISP!" "Some dude I've never seen before gate-crashed our party and was smoking pot, and the police raided us and seized my computer and everybody's phones. My lawyer tells me the raid was illegal and if spend two or three hundred thousand dollars in legal fees, I'll probably be able to get my computer back within eight years or so." "My dog ate my USB stick." :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
Devin Jeanpierre wrote: > On Wed, Jan 28, 2015 at 1:40 PM, Chris Angelico wrote: >> On Thu, Jan 29, 2015 at 5:47 AM, Chris Kaynor >> wrote: >>> I use Google Drive for it for all the stuff I do at home, and use SVN >>> for all my personal projects, with the SVN depots also in Drive. The >>> combination works well for me, I can transfer between my desktop and >>> laptop freely, and have full revision history for debugging issues. >> >> I just do everything in git, no need for either Drive or something as >> old as SVN. Much easier. :) > > Git doesn't help if you lose your files in between commits, Sure it does? You just lose the changes made since the previous commit, but that's no different from restoring from backup. The restored file is only as up to date as the last time a backup was taken. > or if you > lose the entire directory between pushes. Then restore from wherever you are pushing to. But as Devin says, any backup strategy that requires the user to make a backup is untrustworthy. I'm hoping that the next generation of DVCSs will support continuous commits, the next generation of editors support continuous saves, and the only time you need interact with the editor (apart from, you know, actual editing) is to tell it "start a new branch now". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Ian Kelly wrote: > On Wed, Jan 28, 2015 at 8:04 AM, Mario Figueiredo > wrote: >> In article <[email protected]>, >> [email protected] says... >>> >>> Mario Figueiredo wrote: >>> >>> > Static analysis cannot and should not clutter executable code. >>> >>> (1) It isn't clutter. The human reader uses that information as well as >>> the compiler, interpreter, type-checker, IDE, text editor, correctness >>> tester, etc. >>> >>> (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, >>> Go, Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens >>> (hundreds?) of other languages disagree with you. >>> >> >> Sorry. Somehow I missed this post. Only realized now from the Skip >> answer. >> >> This is simply not true! >> >> For most of the strongly typed languages (e.g. static typed languages) > > Python is a strongly typed language. It checks types at runtime and > does little implicit type conversion. Strong != static. > >> in that list -- C, C++, C# and Scala, the ones I know best from that >> list -- require little to no annotations in the code (and certainly no >> new explicit function or class based syntax) in order for static >> analysers to perform their thing, except perhaps on the most exotic >> static analysers. > > The languages you cite don't require extra type annotations because > they already have the types in the function signatures. Here's an > example function signature in Scala: > > def addInt( a:Int, b:Int ) : Int > > How is that significantly different from a Python function that uses > the proposed annotations? Ian, that's obvious. Just open your eyes: Scala def addInt( a:Int, b:Int ) : Int Python def addInt( a:int, b:int ) -> int: They're COMPLETELY different. In Scala they are *type declarations*, not annotations. We're talking about annotations, not declarations. They're as different as cheese and a very slightly different cheese. Do try to keep up. *wink* -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
On Thu, Jan 29, 2015 at 11:37 AM, Steven D'Aprano wrote: > They're as > different as cheese and a very slightly different cheese. Do try to keep > up. As different as brie and camembert? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
On Wednesday, January 28, 2015 at 10:39:34 PM UTC+5:30, [email protected] wrote: > On Wed, Jan 28, 2015, at 01:59, Ben Finney wrote: > > You have no justification to claim that, and it's hostile and dismissive > > to claim it so assertively. > > Sorry about that - I was tired and had just read through the whole > thread at once. Heh Sweet! The lost art of gracefully saying sorry -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode question
On 01/28/2015 03:17 PM, Albert-Jan Roskam wrote: >> I do not know how complete the support is, but this is copied from 3.4.2, >> which uses tcl/tk 8.6. t = "الحركات" for c in t: print(c) # Prints rightmost char above first >> ا >> ل >> ح >> ر >> ك >> ا >> ت > > Wow, I never knew this was so clever. Is that with or without an RTL marker? I don't think this has anything to do with Python. Python is simply spitting out unicode characters as it sees them, starting at string position 0 and working to the end. The magic is done by whatever is displaying the utf-8 output from Python. If I copy this text to the clipboard, t = "hi there, الحركات!" and paste it in my terminal (say to Python's shell), which is not BIDI aware, I get the Arabic letters in reverse order. I tried to paste it here but no matter what I do thunderbird goes into BIDI mode and makes them appear right. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Steven D'Aprano wrote: In fairness, "inherit" is standard terminology for the way instances get their behaviour from their class. I'm not sure that's true, but even if it is, it's not the same kind of inheritance relationship as exists between a class and a base class, which was my point. Also, you can override methods *on the instance*: I wouldn't call that a method -- it's just an instance attribute that happens to be a function. You can tell it's not a method because it doesn't get a 'self' argument. In Python, obj.talk performs the following (grossly simplified) process: * search the instance for an attribute "talk" * search the class * search all the base classes * fail (simplified because I have ignored the roles of __getattr__ and __getattribute__, of metaclasses, and the descriptor protocol) By ignoring the descriptor protocol, you're simplifying away something very important. It's the main thing that makes the instance-of relation different from the subclass-of relation. The normal way of giving a class methods that are callable from the class is to define them on the class with the classmethod or staticmethod decorators. Using a metaclass is usually overkill :-) True, but I was trying to illustrate the symmetry between classes and instances, how the classic OOP ideas of Smalltalk et al are manifest in Python, and to show that classes *can* "participate fully in OOP" just like any other objects if you want them to. Python's "class methods" are strange beasts that don't have an equivalent in the classic OOP model, so they would only have confused matters. And there are cases where you *do* need a metaclass, such as giving a __dunder__ method to a class, so it's useful to know how to do it just in case. An early essay on Python metaclasses was subtitled "The Killer-Joke". Quick, translate this post into German before anyone sees too much of it! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: unpyc3 - a python bytecode decompiler for Python3
On 28/01/2015 23:12, Chris Kaynor wrote: On Wed, Jan 28, 2015 at 3:01 PM, Devin Jeanpierre wrote: On Wed, Jan 28, 2015 at 2:02 PM, Chris Angelico wrote: On Thu, Jan 29, 2015 at 8:52 AM, Devin Jeanpierre wrote: Git doesn't help if you lose your files in between commits, or if you lose the entire directory between pushes. So you commit often and push immediately. Solved. I distrust any backup strategy that requires explicit action by the user. I've seen users fail too often. (Including myself.) That tends to be my opinion and experience as well :) s/any backup strategy/anything/ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
Gregory Ewing wrote:
> Steven D'Aprano wrote:
>
>> In fairness, "inherit" is standard terminology for the way instances get
>> their behaviour from their class.
>
> I'm not sure that's true, but even if it is, it's
> not the same kind of inheritance relationship as
> exists between a class and a base class, which was
> my point.
I suspect that in Python it actually is, but I don't understand the
implementation of attribute look-ups well enough to be sure.
>> Also, you can override methods *on the instance*:
>
> I wouldn't call that a method -- it's just an instance
> attribute that happens to be a function. You can tell
> it's not a method because it doesn't get a 'self' argument.
Actually, if you look at my example, you will see that it is a method and it
does get the self argument. Here is the critical code again:
from types import MethodType
polly.talk = MethodType(
lambda self: print("Polly wants a spam sandwich!"), polly)
The MethodType constructor takes a function and an instance, and returns a
method bound to that instance.
>> In Python, obj.talk performs the following (grossly simplified)
>> process:
>>
>> * search the instance for an attribute "talk"
>> * search the class
>> * search all the base classes
>> * fail
>>
>> (simplified because I have ignored the roles of __getattr__ and
>> __getattribute__, of metaclasses, and the descriptor protocol)
>
> By ignoring the descriptor protocol, you're simplifying
> away something very important. It's the main thing that
> makes the instance-of relation different from the
> subclass-of relation.
That's certainly not correct, because Python had classes and instances
before it had descriptors! Classes and instances go back to pre-1.5 days,
while descriptors were only introduced in 2.2. Besides, descriptors are
handled by the metaclass, so we could write a metaclass that doesn't handle
them.
>> The normal way of giving a class methods that are callable from the class
>> is to define them on the class with the classmethod or staticmethod
>> decorators. Using a metaclass is usually overkill :-)
>
> True, but I was trying to illustrate the symmetry
> between classes and instances, how the classic OOP
> ideas of Smalltalk et al are manifest in Python,
> and to show that classes *can* "participate fully
> in OOP" just like any other objects if you want them
> to. Python's "class methods" are strange beasts that
> don't have an equivalent in the classic OOP model,
> so they would only have confused matters.
Fair point about classmethods.
I think you're actually underestimating how close the symmetry between new-
style classes and instances actually is in Python.
> And there are cases where you *do* need a metaclass,
> such as giving a __dunder__ method to a class, so it's
> useful to know how to do it just in case.
I don't understand this. I write dunder methods all the time. Ah wait, I
think I've got it. If you want (say) your class object itself to support
(say) the + operator, it isn't enough to write a __add__ method on the
class, you have to write it on the metaclass.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: write file to a server
thanks for the reply i have resolve with the r'.' i have another question on linux i write cp -Ruv source destination There is one way to do it in python? with shutil there is copythree but if the dest dir exist he give back an error. Can you give me some ideas Thanks Luca -- https://mail.python.org/mailman/listinfo/python-list
