Re: Trees
In article , rustompm...@gmail.com says... > > Yeah python has trees alright. > > Heres' some simple tree-code Didn't you just demonstrate that Python has no trees and instead you have to implement them yourself (or use a third-party implementation)? I don't know what's the point of all this vain and misleading play with words. Not only most languages don't implement trees in their standard libraries (its no shame, it's no sin), but also it's quite evident that there's a big difference between implementing a data structure yourself through the application of language facilities and seeing that data structure already implemented for you in the standard library. -- https://mail.python.org/mailman/listinfo/python-list
HELP Printing with wxPython
Hello all, I'm trying hard to make possible to print some simple text from
python to the default printer using wxPython, after days of internet
searches I found this page: http://wiki.wxpython.org/index.cgi/Printing but
is impossible to use this script even if I do exactly as said there. I think
the script is buggy or I am not able to use it, even if seems very simple to
use...
Anyone can give me an hint on how to easily and simply print some text? Is
there a library ready to download and use? Something like SendPrinter("some
text\n")?
Thanks in advance if anyone can give any help.
Mario
--
http://mail.python.org/mailman/listinfo/python-list
Re: HELP Printing with wxPython
"Tim G" <[EMAIL PROTECTED]> wrote: > Essentially, if you're on Windows (and have no need > to run on anything else) then consider some of the > solutions here: > > http://tgolden.sc.sabren.com/python/win32_how_do_i/print.html That was exactly what I needed! Thanks SO MUCH! :) I tested all the different things and worked perfectly with no problem. Thanks again, I was trying to do the printing since a lot but never seen that windows api thing before. Mario -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP Printing with wxPython
"Larry Bates" <[EMAIL PROTECTED]> ha scritto nel messaggio news:[EMAIL PROTECTED] > Mario, > > Here is a function stripped from a working program that uses printpreview > from wxWindows to print out cells from a grid that the user is working > on. Hopefully this can point you in the proper direction. Thank you very much for the help, I will study all the code that you sent me for a future and a more professional programming, for now I used a very simple win32api call, not very evolved but working fine for what I needed, since what I am doing needs to run only on a windows machine. Thanks again :) Mario -- http://mail.python.org/mailman/listinfo/python-list
Re: HELP Printing with wxPython
"James Carroll" <[EMAIL PROTECTED]> wrote: >I especially like the HtmlEasyPrinting write-up here: > http://wiki.wxpython.org/index.cgi/Printing Thank you for your suggestion but I'm just not able to make it work, as i said on the original post, I do exactly what is wrote there, but it gives errors, I think the script is not updated and not working fine with the latest versions of python or wxpython. Mario -- http://mail.python.org/mailman/listinfo/python-list
unicode(s, enc).encode(enc) == s ?
I have checks in code, to ensure a decode/encode cycle returns the original string. Given no UnicodeErrors, are there any cases for the following not to be True? unicode(s, enc).encode(enc) == s mario -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode(s, enc).encode(enc) == s ?
On Dec 27, 7:37 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Certainly. ISO-2022 is famous for having ambiguous encodings. Try
> these:
>
> unicode("Hallo","iso-2022-jp")
> unicode("\x1b(BHallo","iso-2022-jp")
> unicode("\x1b(JHallo","iso-2022-jp")
> unicode("\x1b(BHal\x1b(Jlo","iso-2022-jp")
>
> or likewise
>
> unicode("[EMAIL PROTECTED]","iso-2022-jp")
> unicode("\x1b$BBB","iso-2022-jp")
>
> In iso-2022-jp-3, there are even more ways to encode the same string.
Wow, that's not easy to see why would anyone ever want that? Is there
any logic behind this?
In your samples both of unicode("\x1b(BHallo","iso-2022-jp") and
unicode("\x1b(JHallo","iso-2022-jp") give u"Hallo" -- does this mean
that the ignored/lost bytes in the original strings are not illegal
but *represent nothing* in this encoding?
I.e. in practice (in a context limited to the encoding in question)
should this be considered as a data loss, or should these strings be
considered "equivalent"?
Thanks!
mario
--
http://mail.python.org/mailman/listinfo/python-list
different encodings for unicode() and u''.encode(), bug?
Hello!
i stumbled on this situation, that is if I decode some string, below
just the empty string, using the mcbs encoding, it succeeds, but if I
try to encode it back with the same encoding it surprisingly fails
with a LookupError. This seems like something to be corrected?
$ python
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> s = ''
>>> unicode(s, 'mcbs')
u''
>>> unicode(s, 'mcbs').encode('mcbs')
Traceback (most recent call last):
File "", line 1, in
LookupError: unknown encoding: mcbs
Best wishes to everyone for 2008!
mario
--
http://mail.python.org/mailman/listinfo/python-list
Re: different encodings for unicode() and u''.encode(), bug?
On Jan 2, 9:30 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Use "mbcs" in the second call, not "mcbs".
Ooops, sorry about that, when i switched to test it in the interpreter
I mistyped "mbcs" with "mcbs". But remark I did it consistently ;-)
I.e. it was still teh same encoding, even if maybe non-existant.. ?
If I try again using "mbcs" consistently, I still get the same error:
$ python
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> unicode('', 'mbcs')
u''
>>> unicode('', 'mbcs').encode('mbcs')
Traceback (most recent call last):
File "", line 1, in
LookupError: unknown encoding: mbcs
>>>
mario
--
http://mail.python.org/mailman/listinfo/python-list
Re: different encodings for unicode() and u''.encode(), bug?
On Jan 2, 10:44 am, John Machin <[EMAIL PROTECTED]> wrote:
>
> Two things for you to do:
>
> (1) Try these at the Python interactive prompt:
>
> unicode('', 'latin1')
> unicode('', 'mbcs')
> unicode('', 'raboof')
> unicode('abc', 'latin1')
> unicode('abc', 'mbcs')
> unicode('abc', 'raboof')
$ python
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> unicode('', 'mbcs')
u''
>>> unicode('abc', 'mbcs')
Traceback (most recent call last):
File "", line 1, in
LookupError: unknown encoding: mbcs
>>>
Hmmn, strange. Same behaviour for "raboof".
> (2) Read what the manual (Library Reference -> codecs module ->
> standard encodings) has to say about mbcs.
Page at http://docs.python.org/lib/standard-encodings.html says that
mbcs "purpose":
Windows only: Encode operand according to the ANSI codepage (CP_ACP)
Do not know what the implications of encoding according to "ANSI
codepage (CP_ACP)" are. Windows only seems clear, but why does it only
complain when decoding a non-empty string (or when encoding the empty
unicode string) ?
mario
--
http://mail.python.org/mailman/listinfo/python-list
Re: different encodings for unicode() and u''.encode(), bug?
On Jan 2, 12:28 pm, John Machin <[EMAIL PROTECTED]> wrote: > On Jan 2, 9:57 pm, mario <[EMAIL PROTECTED]> wrote: > > > Do not know what the implications of encoding according to "ANSI > > codepage (CP_ACP)" are. > > Neither do I. YAGNI (especially on darwin) so don't lose any sleep > over it. > > > Windows only seems clear, but why does it only > > complain when decoding a non-empty string (or when encoding the empty > > unicode string) ? > > My presumption: because it doesn't need a codec to decode '' into u''; > no failed codec look-up, so no complaint. Any realistic app will try > to decode a non-empty string sooner or later. Yes, I suspect I will never need it ;) Incidentally, the situation is that in a script that tries to guess a file's encoding, it bombed on the file ".svn/empty-file" -- but why it was going so far with an empty string was really due to a bug elsewhere in the script, trivially fixed. Still, I was curious about this non-symmetric behaviour for the empty string by some encodings. Anyhow, thanks a lot to both of you for the great feedback! mario -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode(s, enc).encode(enc) == s ?
Thanks a lot Martin and Marc for the really great explanations! I was wondering if it would be reasonable to imagine a utility that will determine whether, for a given encoding, two byte strings would be equivalent. But I think such a utility will require *extensive* knowledge about many bizarrities of many encodings -- and has little chance of being pretty! In any case, it goes well beyond the situation that triggered my original question in the first place, that basically was to provide a reasonable check on whether round-tripping a string is successful -- this is in the context of a small utility to guess an encoding and to use it to decode a byte string. This utility module was triggered by one that Skip Montanaro had written some time ago, but I wanted to add and combine several ideas and techniques (and support for my usage scenarios) for guessing a string's encoding in one convenient place. I provide a write-up and the code for it here: http://gizmojo.org/code/decodeh/ I will be very interested in any remarks any of you may have! Best regards, mario -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode(s, enc).encode(enc) == s ?
On Jan 2, 9:34 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > In any case, it goes well beyond the situation that triggered my > > original question in the first place, that basically was to provide a > > reasonable check on whether round-tripping a string is successful -- > > this is in the context of a small utility to guess an encoding and to > > use it to decode a byte string. This utility module was triggered by > > one that Skip Montanaro had written some time ago, but I wanted to add > > and combine several ideas and techniques (and support for my usage > > scenarios) for guessing a string's encoding in one convenient place. > > Notice that this algorithm is not capable of detecting the ISO-2022 > encodings - they look like ASCII to this algorithm. This is by design, > as the encoding was designed to only use 7-bit bytes, so that you can > safely transport them in Email and such (*) Well, one could specify decode_heuristically(s, enc="iso-2022-jp") and that encoding will be checked before ascii or any other encoding in the list. > If you want to add support for ISO-2022, you should look for escape > characters, and then check whether the escape sequences are among > the ISO-2022 ones: > - ESC ( - 94-character graphic character set, G0 > - ESC ) - 94-character graphic character set, G1 > - ESC * - 94-character graphic character set, G2 > - ESC + - 94-character graphic character set, G3 > - ESC - - 96-character graphic character set, G1 > - ESC . - 96-character graphic character set, G2 > - ESC / - 96-character graphic character set, G3 > - ESC $ - Multibyte >( G0 >) G1 >* G2 >+ G3 > - ESC % - Non-ISO-2022 (e.g. UTF-8) > > If you see any of these, it should be ISO-2022; see > the Wiki page as to what subset may be in use. > > G0..G3 means what register the character set is loaded > into; when you have loaded a character set into a register, > you can switch between registers through ^N (to G1), > ^O (to G0), ESC n (to G2), ESC o (to G3) (*) OK, suppose we do not know the string is likely to be iso-2022, but we still want to detect it if it is. I have added a "may_do_better" mechanism to the algorithm, to add special checks on a *guessed* algorithm. I am not sure this will not however introduce more or other problems than the one it is addressing... I have re-instated checks for iso-8859-1 control chars (likely to be cp1252), for special symbols in iso-8859-15 when they occur in iso-8859-1 and cp1252, and for the iso-2022-jp escape sequences. To flesh out with other checks is mechanical work... If you could take a look at the updated page: > >http://gizmojo.org/code/decodeh/ I still have issues with what happens in situations when for example a file contains iso-2022 esc sequences but is anyway actally in ascii or utf-8? e.g. this mail message! I'll let this issue turn for a little while... > > I will be very interested in any remarks any of you may have! > > From a shallow inspection, it looks right. I would have spelled > "losses" as "loses". Yes, corrected. Thanks, mario -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode(s, enc).encode(enc) == s ?
Thanks again. I will chunk my responses as your message has too much
in it for me to process all at once...
On Jan 2, 9:34 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Thanks a lot Martin and Marc for the really great explanations! I was
> > wondering if it would be reasonable to imagine a utility that will
> > determine whether, for a given encoding, two byte strings would be
> > equivalent.
>
> But that is much easier to answer:
>
> s1.decode(enc) == s2.decode(enc)
>
> Assuming Unicode's unification, for a single encoding, this should
> produce correct results in all cases I'm aware of.
>
> If the you also have different encodings, you should add
>
> def normal_decode(s, enc):
> return unicode.normalize("NFKD", s.decode(enc))
>
> normal_decode(s1, enc) == normal_decode(s2, enc)
>
> This would flatten out compatibility characters, and ambiguities
> left in Unicode itself.
Hmmn, true, it would be that easy.
I am now not sure why I needed that check, or how to use this version
of it... I am always starting from one string, and decoding it... that
may be lossy when that is re-encoded, and compared to original.
However it is clear that the test above should always pass in this
case, so doing it seems superfluos.
Thanks for the unicodedata.normalize() tip.
mario
--
http://mail.python.org/mailman/listinfo/python-list
Re: different encodings for unicode() and u''.encode(), bug?
On Jan 2, 2:25 pm, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
> Apparently for the empty string the encoding is irrelevant as it will not
> be used. I guess there is an early check for this special case in the code.
In the module I an working on [*] I am remembering a failed encoding
to allow me, if necessary, to later re-process fewer encodings. In the
case of an empty string AND an unknown encoding this strategy
failed...
Anyhow, the question is, should the behaviour be the same for these
operations, and if so what should it be:
u"".encode("non-existent")
unicode("", "non-existent")
mario
[*] a module to decode heuristically, that imho is actually starting
to look quite good, it is at http://gizmojo.org/code/decodeh/ and any
comments very welcome.
--
http://mail.python.org/mailman/listinfo/python-list
Re: different encodings for unicode() and u''.encode(), bug?
On Jan 4, 12:02 am, John Machin <[EMAIL PROTECTED]> wrote: > On Jan 4, 8:03 am, mario <[EMAIL PROTECTED]> wrote: > > On Jan 2, 2:25 pm, Piet van Oostrum <[EMAIL PROTECTED]> wrote: > > > > Apparently for the empty string the encoding is irrelevant as it will not > > > be used. I guess there is an early check for this special case in the > > > code. > > > In the module I an working on [*] I am remembering a failed encoding > > to allow me, if necessary, to later re-process fewer encodings. > > If you were in fact doing that, you would not have had a problem. What > you appear to have been doing is (a) remembering a NON-failing > encoding, and assuming that it would continue not to fail Yes, exactly. But there is no difference which ones I remember as the two subsets will anyway add up to always the same thing. In this special case (empty string!) the unccode() call does not fail... > (b) not > differentiating between failure reasons (codec doesn't exist, input > not consistent with specified encoding). There is no failure in the first pass in this case... if I do as you suggest further down, that is to use s.decode(encoding) instead of unicode(s, encoding) to force the lookup, then I could remember the failure reason to be able to make a decision about how to proceed. However I am aiming at an automatic decision, thus an in-context error message would need to be replaced with a more rigourous info about how the guessing should proceed. I am also trying to keep this simple ;) > In any case, a pointless question (IMHO); the behaviour is extremely > unlikely to change, as the chance of breaking existing code outvotes > any desire to clean up a minor inconsistency that is easily worked > around. Yes, I would agree. The work around may not even be worth it though, as what I really want is a unicode object, so changing from calling unicode() to s.decode() is not quite right, and will anyway require a further check. Less clear code, and a little unnecessary performance hit for the 99.9 majority of cases... Anyhow, I have improved a little further the "post guess" checking/refining logic of the algorithm [*]. What I'd like to understand better is the "compatibility heirarchy" of known encodings, in the positive sense that if a string decodes successfully with encoding A, then it is also possible that it will encode with encodings B, C; and in the negative sense that is if a string fails to decode with encoding A, then for sure it will also fail to decode with encodings B, C. Any ideas if such an analysis of the relationships between encodings exists? Thanks! mario [*] http://gizmojo.org/code/decodeh/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it explicitly specified?
On Feb 3, 12:35 pm, TeroV <[EMAIL PROTECTED]> wrote:
> Jorge Godoy wrote:
> > mario ruggier wrote:
>
> >> Is there any way to tell between whether a keyword arg has been explicitly
> >> specified (to the same value as the default for it) or not... For example:
>
> >> def func(key=None):
> >> do something with key
>
> >> But the following two usages give same results:
>
> >> func()
> >> func(key=None)
>
> >> It may sometimes be useful to make use of the conceptual difference
> >> between these two cases, that is that in one case the user did not specify
> >> any key and in the other the user explicitly specified the key to be None.
>
> >> Is there any way to tell this difference from within the called function?
> >> And if so, would there be any strong reasons to not rely on this
> >> difference? Would it be maybe a little abusive of what a keyword arg
> >> actually is?
>
> > If you change the idiom you use to:
>
> >>>> def myfunc(**kwargs):
> > ... something = kwargs.get('something', None)
> > ... print something
> > ...
> >>>> myfunc()
> > None
> >>>> myfunc(something='Something')
> > Something
>
> > Then you can test if 'something' is in kwargs dict or not. If it isn't,
> > then you used the default value. If it is, then the user
> > supplied 'something' to you, no matter what its value is.
>
> Exactly, and if you use idiom func(*args, **kwargs) you can distinguish
> all the usage cases:
>
> >>> def func(*args, **kwargs):
> ... print(args, kwargs)
> ...
> >>> func()
> () {}
> >>> func(key='alabama')
> () {'key': 'alabama'}
> >>> func('alabama')
> ('alabama',) {}
Nice... but I would still like to be able to specify the key's default
value in the func signature, and in this case this would not be
possible:
>>> def func(key=None, *args, **kwargs):
... print(key, args, kwargs)
...
>>> func()
(None, (), {})
>>> func(None)
(None, (), {})
>>> func(key=None)
(None, (), {})
>>>
I would still need an additional object, as Arnaud suggests.
mario
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it explicitly specified?
On Feb 3, 4:19 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> Diez B. Roggisch wrote:
> > Bjoern Schliessmann schrieb:
> >> mario ruggier wrote:
>
> >>> It may sometimes be useful to make use of the conceptual
> >>> difference between these two cases, that is that in one case the
> >>> user did not specify any key and in the other the user explicitly
> >>> specified the key to be None.
> >> Do you have an example where this might be useful?
>
> > Any situation in which there would otherwise lots of documentation
> > needed to inform the user that the sentinel value is something else than
> > None.
>
> > Take something like this as an example:
>
> > def update_user(some, values, nullable_value=sentinel):
> > # first, work with some and values
> > ...
> > # then, on something actually being passed to nullable_value
> > if nullable_value is not sentinel:
> > connection.cursor().execute("update table set value = ?",
> > nullable_value)
>
> > I've seen this before, in code from e.g. Alex Martelli.
>
> Sure, but the OP's question was "Is there any way to tell between
> whether a keyword arg has been explicitly specified (to the same value
> as the default for it)". We've drifted a long way from that, since the
> code you demonstrate doesn't detect an explicit call with
> nullable_value==sentinel -- the reason being, I submit, that there is no
> use case for such code.
I think you are all very much on target, and not drifted at all. The
real issue with this situation is None, as there is ambiguity there,
whether a caller wants something to be None or whtehr it is simpy None
because it is not set...
My use case is that I have an object that is part of a collection. The
collection sets what the preferred defaults are for specific object
attributes, but individual objects may override some of these. Thus,
if an object does not set any of these attributes, then the default as
per the collection's settings is to be used.
In one case, the collection attributes a specific meaning to
attr=None, but the actual default for attr is something else. However,
if an object explicitly wants to state that his attr=None (that is a
valid value, and has specific meaning) I would like to use that as
value, but if no value is supplied for attr by the object, then I
would like to use the default value from the collection.
mario
--
http://mail.python.org/mailman/listinfo/python-list
Ideas to optimize this getitem/eval call?
Hi,
below is the essence of a an expression evaluator, by means of a
getitem lookup. The expression codes are compiled and cached -- the
lookup is actually recursive, and the first time around it will always
fail.
import sys
class GetItemEval(object):
def __init__(self):
self.globals = globals() # some dict (always the same)
self.locals = {} # some other dict (may be different between
evaluations)
self.codes = {} # compiled code expressions cache
def __getitem__(self, expr):
try:
return eval(self.codes[expr], self.globals, self.locals)
except:
# KeyError, NameError, AttributeError, SyntaxError,
ValueError,
# TypeError, IOError
#
# Special case if a KeyError is coming from the self.codes
[name]
# lookup (traceback should consist of a single frame
only):
if sys.exc_info()[2].tb_next is None:
if sys.exc_info()[0] is KeyError:
self.codes[expr] = compile(expr, '',
'eval')
return self[expr]
# otherwise handle eval error in some way...
This class could be used in a way as follows:
# define some expressions
def f(s): return "["+s+"]"
exprs = ["1+2+3", "2*3*5", "f(__name__)"]
# instantiate one
gie = GetItemEval()
# use it to lookup/eval each expression
for x in exprs:
print x, "=", gie[x]
And, fwiw, some sample timeit code:
import timeit
print timeit.Timer("for x in exprs: gie[x]",
"from __main__ import gie, exprs").timeit(50)
I had done various poking to discover if it could be made to go
faster, and in the end I settled on the version above.
mario
Incidentally this constitutes the lion's share of the evaluation
runtime of evoque templating... http://evoque.gizmojo.org/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Ideas to optimize this getitem/eval call?
On Jan 3, 7:16 am, Steven D'Aprano wrote: > I was about to make a comment about this being a security hole, Strange that you say this, as you are also implying that *all* the widely-used templating systems for python are security holes... Well, you would be right to say that of course ;-) Infact, evoque is really one of the few (or even the only one?) that was conceived from the start to support restricted evaluation. > but I see from here > > http://evoque.gizmojo.org/usage/restricted/ > > that you are aware of at least some of the issues. > > I must say though, your choice of builtins to prohibit seems rather > arbitrary. What is dangerous about (e.g.) id() and isinstance()? Preventive, probably. I also feel that temlates should have any business with info such as the memory addressed returnred by id(). For isinstance, becuase it is somewhat related to __subclasses__ that is known to be insecure. Incidentally, I updated the page you point to clarify what is going on. I also added a link to Brett Cannon's inspiration paper on the topic of securing the python interpreter... > > except: > > # KeyError, NameError, AttributeError, SyntaxError, > > # ValueError, TypeError, IOError > > If you want to capture seven exceptions, then capture seven exceptions, > not any exception. Absolutely not. I want to catch ALL evaluation exceptions... it would actually *be* a secuity hole to allow any exception to bubble. hey will however be handled appropriately as per the application policy/ config/deployment. > You should write: > > except (KeyError, NameError, ..., IOError): > > instead of a bare except clause. That will capture exceptions that > represent bugs in your code as well as exceptions that should propbably > be allowed to propagate, such as KeyboardInterupt and SystemExit. Again, no. Template presentational logic has no business issuing SystemExits or so. And, of course, there are no bugs in my code ;-) > > # Special case if a KeyError is coming from the self.codes[name] > > # lookup (traceback should consist of a single frame only): > > if sys.exc_info()[2].tb_next is None: > > if sys.exc_info()[0] is KeyError: > > self.codes[expr] = compile(expr, '', 'eval') > > return self[expr] > That seems awfully complicated for no good reason. Yes, you are probably right. I wanted to be precise in that if the KeyError originates strictly from the codes lookup and not from the actual eval of the expr itself -- in which case the expr should be compiled and added to codes (yes, this is the "first-time failure" I referred to in the first message). I tested the performance of your 2 variations in context, and there seems to be no noticeable performance gain (something like less than 1% gain). But note the two variations as you code them do not quite do exactly the same test. I have adjusted to use this code now: def __getitem__(self, expr): try: return eval(self.codes[expr], self.globals, self.locals) except: # We want to catch **all** evaluation errors! # KeyError, NameError, AttributeError, SyntaxError, V # alueError, TypeError, IOError, ... # # Special case: # if KeyError is coming from self.codes[expr] lookup, # then we add the compiledentry and try again: if not name in self.codes: self.codes[expr] = compile(name, '', 'eval') return self[expr] # handle any other error... This retains the correctness of the check, and has the same marginal perf improvement (that is basically negligible, but at least it is not slower) and has teh advantage that the code is clearer. Thanks for the remarks! mario > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Ideas to optimize this getitem/eval call?
correction: the code posted in previous message should have been: def __getitem__(self, expr): try: return eval(self.codes[expr], self.globals, self.locals) except: # We want to catch **all** evaluation errors! # KeyError, NameError, AttributeError, SyntaxError, V # alueError, TypeError, IOError, ... # # Special case: # if KeyError is coming from self.codes[expr] lookup, # then we add the compiledentry and try again: if not expr in self.codes: self.codes[expr] = compile(expr, '', 'eval') return self[expr] # handle any other error... -- http://mail.python.org/mailman/listinfo/python-list
Tools for web applications
What easyToLearn tools you suggest for creating: 1. powerfull web applications 2. desktop applications -- http://mail.python.org/mailman/listinfo/python-list
Re: Tools for web applications
On Tue, 28 Apr 2009 17:37:57 -0700, Daniel Fetchinson wrote: >> What easyToLearn tools you suggest for creating: 1. powerfull web >> applications > > Have a look at http://wiki.python.org/moin/WebFrameworks > > You will find that there are many options each with its own fan crowd > emphasizing the advantages and downplaying the disadvantages of their > favorite framework. You will pretty much have to decide for yourself > which suits you best. I'm personally very happy with turbogears. > >> 2. desktop applications > > Dabo is a desktop application framework: http://dabodev.com/ Or you > perhaps mean a GUI framework? Have a look at > http://wiki.python.org/moin/GuiProgramming The same comments as above > apply, you need to detail your requirements before an informed advice > can be given. > > Cheers, > Daniel And what IDE you suggest ? I need an information about tools for a quick start, so that I can decide about learning Ruby, python or something else. My field of interest is a small business applications (desktop and web), so that I have a practical tool for practical use of accounting and financial methods. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tools for web applications
On Wed, 29 Apr 2009 13:38:53 +, Mario wrote: > On Tue, 28 Apr 2009 17:37:57 -0700, Daniel Fetchinson wrote: > >>> What easyToLearn tools you suggest for creating: 1. powerfull web >>> applications >> >> Have a look at http://wiki.python.org/moin/WebFrameworks >> >> You will find that there are many options each with its own fan crowd >> emphasizing the advantages and downplaying the disadvantages of their >> favorite framework. You will pretty much have to decide for yourself >> which suits you best. I'm personally very happy with turbogears. >> >>> 2. desktop applications >> >> Dabo is a desktop application framework: http://dabodev.com/ Or you >> perhaps mean a GUI framework? Have a look at >> http://wiki.python.org/moin/GuiProgramming The same comments as above >> apply, you need to detail your requirements before an informed advice >> can be given. >> >> Cheers, >> Daniel > > And what IDE you suggest ? I need an information about tools for a quick > start, so that I can decide about learning Ruby, python or something > else. My field of interest is a small business applications (desktop and > web), so that I have a practical tool for practical use of accounting > and financial methods. Is it NetBeans suitable for Python ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tools for web applications
I used JCreator LE, java IDE for windows because, when I add documentation of some new library, I have it on a F1 and index. So how you manage documentation and code completion ? I asume that you are geek but not even geeks could know every method of every class. "Daniel Fetchinson" wrote in message news:mailman.4767.1241024136.11746.python-l...@python.org... What easyToLearn tools you suggest for creating: 1. powerfull web applications >>> >>> Have a look at http://wiki.python.org/moin/WebFrameworks >>> >>> You will find that there are many options each with its own fan crowd >>> emphasizing the advantages and downplaying the disadvantages of their >>> favorite framework. You will pretty much have to decide for yourself >>> which suits you best. I'm personally very happy with turbogears. >>> 2. desktop applications >>> >>> Dabo is a desktop application framework: http://dabodev.com/ Or you >>> perhaps mean a GUI framework? Have a look at >>> http://wiki.python.org/moin/GuiProgramming The same comments as above >>> apply, you need to detail your requirements before an informed advice >>> can be given. >>> >>> Cheers, >>> Daniel >> >> And what IDE you suggest ? > > I use vi, I like it much more than any IDE (or is vi an IDE?). Your > needs might be different though. I'd suggest using something you are > already familiar with, most IDEs work with different languages so if > you used one already chances are it will understand python too. > >> I need an information about tools for a quick >> start, so that I can decide about learning Ruby, python or something >> else. > > This will give you a good start: > http://docs.python.org/tutorial/index.html > And also this: http://diveintopython.org/ > >> My field of interest is a small business applications (desktop and >> web), so that I have a practical tool for practical use of accounting and >> financial methods. > > Well, pretty much any modern dynamical language will be suitable for > what you describe. I would personally recommend python but that > doesn't mean ruby or anything else can't do the job, you have to > decide which language "feels" right for you. > > Cheers, > Daniel > > -- > Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: How to split a string containing nested commas-separated substrings
I have actually highlighted a small neat recipe for doing such
unpacking, that I use for parsing arbitrary parameters in Evoque
Templating. I never needed to handle "callable" parameters though, as
you do in your 3rd string example, so the little "unpack_symbol"
recipe I have publiched earlier does not handle it... anyhow, what I
referring to are:
Evoque Templating: http://evoque.gizmojo.org/
Code highlight: http://gizmojo.org/code/unpack_symbol/
However, a little variation of the aboverecipe can do what you are
looking for, in a rather cute way. The difference is to make the
original recipe handle "callable strings", and I achieve this by
modifying the recipe like so:
class callable_str(str):
def __call__(s, *args):
return s+str(args)
class _UnpackGlobals(dict):
def __getitem__(self, name):
return callable_str(name)
def unpack_symbol(symbol, globals=_UnpackGlobals()):
""" If compound symbol (list, tuple, nested) unpack to atomic
symbols """
return eval(symbol, globals, None)
Now, calling unpack_symbol() on each sample string gives the following
tuple of strings:
>>> unpack_symbol('foo, bar, baz')
('foo', 'bar', 'baz')
>>> unpack_symbol('foo, "bar, baz", blurf')
('foo', 'bar, baz', 'blurf')
>>> unpack_symbol('foo, bar(baz, blurf), mumble')
('foo', "bar('baz', 'blurf')", 'mumble')
>>>
Mario Ruggier
--
http://mail.python.org/mailman/listinfo/python-list
Re: Mako vs. Cheetah?
A small and ultra-lightweight system, with all the power of any fully featured text-based templating system (such as mako or cheetah) and then some (no constraints on template file names or formats, restricted execution, automatic XSS protection, ...) that can be used in a web context or standalone, while being also incredibly fast, is Evoque Templating: http://evoque.gizmojo.org/ And the simplicity of the system means you can assimilate the entire thing in a single sitting, and thereafter easily remember the few key things to continue using it without constant re-consulting of the docs (that, actually, are also pretty good ;-) So yes, agree with you entirely, that shameless personal preference is important for choosing your templating system... ;) mario -- http://mail.python.org/mailman/listinfo/python-list
Re: Using just the Mako part of Pylons?
You would need a controller of some sort to connect the web request/ response with your template handling. This is the key task of the web application layer. This is also the area that WSGI atttemps to standardize in so far as making the basic objects framework independent. You can thus supply a generic wsgi app to act as your controller... see wsgiref package docs. Or, you can of course use any app framework of your choice. But, as a small, ultra-lightweight templating system that can be used in a web context or as standalone, you should really take a look at Evoque Templating: http://evoque.gizmojo.org/ All the power of any fully featured text-based templating system and then some (no constraints on template file names or formats, restricted execution, automatic XSS protection, ...) while being also incredibly fast. And the simplicity of the system means you can learn it really quickly, and remember it... Btw, you may be interested in a small example of wsgi based app that uses evoque -- one of the examples of how to use evoque under various contexts: http://evoque.gizmojo.org/ext/ mario -- http://mail.python.org/mailman/listinfo/python-list
Re: eval() == evil? --- How to use it safely?
On Aug 28, 11:51 pm, Fett <[EMAIL PROTECTED]> wrote:
> I am creating a program that requires some data that must be kept up
> to date. What I plan is to put this data up on a web-site then have
> the program periodically pull the data off the web-site.
>
> My problem is that when I pull the data (currently stored as a
> dictionary on the site) off the site, it is a string, I can use eval()
> to make that string into a dictionary, and everything is great.
> However, this means that I am using eval() on some string on a web-
> site, which seems pretty un-safe.
>
> I read that by using eval(code,{"__builtins__":None},{}) I can prevent
> them from using pretty much anything, and my nested dictionary of
> strings is still allowable. What I want to know is:
>
> What are the dangers of eval?
> - I originally was using exec() but switched to eval() because I
> didn't want some hacker to be able to delete/steal files off my
> clients computers. I assume this is not an issue with eval(), since
> eval wont execute commands.
> - What exactly can someone do by modifying my code string in a command
> like: thing = eval(code{"__builtins__":None},{}), anything other than
> assign their own values to the object thing?
If you like to look at a specific attempt for making eval() safe(r)
take a look at how the **eval-based** Evoque Templating engine does
it, for which a short overview is here:
http://evoque.gizmojo.org/usage/restricted/
While it does not provide protection against DOS type attacks, it
should be safe against code that tries to pirate tangible resources
off your system, such as files and disk. Actually, any problems anyone
may find are greatly appreciated...
--
http://mail.python.org/mailman/listinfo/python-list
cant upload the python window popup
I delete by error the python window inteface and now i cant reupload again some advice is apreciated thanks -- http://mail.python.org/mailman/listinfo/python-list
IDE of the all python version installed cant uploaded
I have from time ago installed Python 2.6, 2.7, 3.2 and the last 3.3 beta but now I can upload the window version not the prompt command some advice is needed i desintalled and reinstall and nothing!! thanks in advance Mario -- http://mail.python.org/mailman/listinfo/python-list
Re: Get Path of current Script
On Mar 14, 10:25 am, Alexander Schatten wrote:
> Hi,
>
> could someone help me with a small problem? I wrote a Python script
> that does some RegEx... transformations. Now, this script loads some
> configuration data from a file located in the same directory:
>
> open ('config.txt', 'r').
>
> However, this only works when I execute the script being in the
> directory where the script is locates, because otherwise, of course,
> this config file is not found, as the path is relative. Now my
> question: is there an easy way (API) to get the directory of the
> currently running script? Something along the line of:
>
> open (API.getCurrentPath + 'config.txt', 'r').
>
> thanks a lot,
>
> cheers
>
> Alex
os.path.join(sys.path[0], 'config.txt')
If the script and config.txt are in /tmp this will return '/tmp/
config.txt' no matter from which directory you started the script.
Mario
--
http://mail.python.org/mailman/listinfo/python-list
Problem with wxPython 2.6.1
Hello! Im newbie in Linux, I have instaled Ubuntu 5.04, but I couldt install the wxPython 2.6.1, anybody help me?? For this reason I dont do my Job , because I use SpeIde and Boa Constructor, and both dont run with the old v wxPython 2.5.3 Thanks in advance!! -- Saludos / Best regards Mario Lacunza Desarrollador de Sistemas - Webmaster Email: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] Messenger MSN: [EMAIL PROTECTED] Website: http://www.lacunza.tk Lima - Peru -- http://mail.python.org/mailman/listinfo/python-list
Some questions...
Hello, Im new in Python, please I need some information: - Somebody know if: is possible use Python within Net Framework in windows environment?? - Where found info about reports in Python? exist some program like Crystal Reports?? - Database access: Firebird , I dont found correct information about this tools and his conection/working with Python. Thanks!!! -- Saludos / Best regards Mario Lacunza Email: [EMAIL PROTECTED] Lima - Peru -- http://mail.python.org/mailman/listinfo/python-list
Re: Trees
In article , zacharygilmar...@gmail.com says... > > Why aren't there trees in the python standard library? I don't know much about python development process and strategies, but I suspect it shouldn't be much different from any other language I know of. So here's my tentative answer: Once general purpose programming languages become established, the STL maintainers tend to greatly decrease additions to the standard library, except when this is required to support new language features. Most of development on the STL shifts to code maintenance in order to improve the quality of the code (usually to address memory usage and performance concerns) and solve any existing bugs on the STL. Instead the language maintainers start to rely on third-party libraries as a continuation of the effort to extend the programming language further. Any new additions to the STL are carefully pondered. The reason is twofold: 1) Just like with the matter of data structures, many additions are implementation-contentious. Trees, for instance, can be implemented in any number of ways, some with an emphasis on performance, others on memory usage. The decision of which implementation to choose isn't easy. And if users can already choose different types of implementations from the external libraries, then this is is probably motivation enough to delay the decision for another day. 2) A standard library should focus first and foremost on support of the language features. If for some reason this takes time away from adding new entries into the STL, that's fine. There's also the problem of how one should look at a standard library. Some maintainers don't look very well at the idea of a monolithic approach, while others, like Guido, like to think of a "batteries- included" programming language, indicating a desire to build a large STL. And this is why perhaps your question arises. But "batteries included" doesn't mean build a "Total Library". That would be a vain attempt for any general purpose language. -- https://mail.python.org/mailman/listinfo/python-list
Re: Trees
Hello Terry, It is not play with words. A tree is a recursive - nested - hierachical data structure with the restriction of no cycles or alternate pathways. Python collections whose members are general objects, including collections, can be nested. The resulting structures *are* tree structures, if not more general directed graphs. They are quite commonly used in Python. Let's get somethig clear. Tree data structures have an associated logic that justifies their name as a de facto Tree Data Structure. If your low level description was how you described a tree to someone new to the concept, they would be none the wiser about what a Tree represents or what uses they could have for them. This logic is no different from the internal logic that diferentiates a dictionary from a list and helps carry their distinct operations. Despite a dictionary being nothing more than a glorified list. Just as well, tree data structures only make sense along with their logic. Storage, traversal, insertion, random searches, retrieval, etc, all these algorithms are what in the end define a Tree data structure and what will help categorize it. Python standard library doesn't have any tree data structure implementation. It has lists, dictionaries, and other base structures that in the end will help define storage patterns for tree data structures. And that's it. A simple binary tree needs to be implemented in Python as a binary tree, if it wants to be recognized as such. All your code examples illustrate exactly that. And if you care about code reuse, you will want to define a number of associated algorithms to take advantage of your storage model and answer your performance or memory requirements. Along with your list pattern for storage, you will probably also want to implement an insertion/search/update/traversal algorithms. That's when you have a tree. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to "wow" someone new to Python
Chris, Scenario: You're introducing someone to Python for the first time. S/he may have some previous programming experience, or may be new to the whole idea of giving a computer instructions. You have a couple of minutes to show off how awesome Python is. What do you do? Some ideas where given by others already. I especially liked the variable swap one liner by Emile van Sebille. That's a little simple gem that will impress any seasoned developer of other programming languages. But speaking about impressing more experient programmers, I personally don't think Python has a wow factor in any of its features and syntax. At least in the way I understand the word "wow". Python shares its own brand of idiosyncracies with any other programming languages. Little gotchas and caveats that have you scratch your head and sometimes annoy you slightly. Python is it too cropped here and there with things worth criticizing. Meanwhile some of its interesting language features, like Comprehensions and Generators, aren't really that impressive to a seasoned developer of functional programming languages or programming languages like C# with its highly powerful and expressive LINQ. This means that, alone, Python won't really standout. But this is ok. No language does it on the merits of its syntax or feature set. What does make Python standout in my opinion -- what gave me the wow -- is its interoperability. Here we have a general purpose scripting language with more hooks to other systems that any other programming language in existence. With just Python, I can build a modern GUI interface on any of the most popular operating systems, use it on PostgreSQL to build stored procedures and move most of my business rules to the database server and attach dynamic behavior to a system developed in some other programming language. I apologize if my post was to long, but I lacked the time to make it shorter. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to "wow" someone new to Python
In article , alan@scooby- doo.csail.mit.edu says... > Even in a 64-bit Java, the _type_ returned by String.length() is > 'int', and is thus at most (2**31 - 1). This isn't a problem for > strings, which never get that long in practice, but for some other > Java datatypes (e.g., Buffer) it is a real problem. Score one for > untyped languages. Still, assuming you have enough heap size, you can still create a 500 million character string buffer. That's one of a heck large buffer. Nearly twice the online encyclopedia Britannica(1), and roughly 50 times the longest novel ever produced (2). And considering you can always flush the buffer, I'm finding an hard time looking at unlimited string length in Python as wow factor. Even if we consider unicode strings. (1) http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons#Comparison_of_en cyclopedias (2) http://en.wikipedia.org/wiki/List_of_longest_novels -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
In article , ros...@gmail.com says... > > Bad idea. Better to pick a language that makes it easy to get things > right, and then work on the fun side with third-party libraries, than > to tempt people in with "hey look how easy it is to do X" and then > have them stuck with an inferior or flawed language. Too many people > already don't know the difference between UTF-16 and Unicode. Please, > educators, don't make it worse. > > ChrisA Indeed. If games and funnies is what drive beginners into programming, that's fine. But the educational principles of programming shouldn't be trashed in the process. We need serious developers in today's complex application systems. Not uneducated programmers with nary a knowledge of Software Engineering. Besides if games and funnies are the only thing that can drive someone into programming, I'd rather not see that person become a developer. "I want to become a programmer so I can make games" is, on the vast majority of cases, the quote of someone who will never become a programmer. Why should teachers reward that kind of thought? -- https://mail.python.org/mailman/listinfo/python-list
Re: What killed Smalltalk could kill Python
In article <873873ae91@jester.gateway.sonic.net>, no.email@nospam.invalid says... > > Steven D'Aprano writes: > > In 2009, Robert Martin gave a talk at RailsConf titled "What Killed > > Smalltalk Could Kill Ruby"... http://www.youtube.com/watch?v=YX3iRjKj7C0 > > That's an hour-long video; could someone who's watched it give a brief > summary? > In a nutshell, he argues, along with Ward Cunningham, that what killed Smalltalk was how easy you could create unclean code with it. "Unclean" in this context means Smalltalk didn't punish bad software design decisions that would eventually lead into complex code and unmanageable systems with zero options of code maintenance. I don't have an opinion. I didn't know Smalltalk. I started my programming carrer around the early nineties as a Dbase and later Clipper programmer. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article <54c0a571$0$13002$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > > The point isn't that there are no other alternative interpretations > possible, or that annotations are the only syntax imaginable, but that > they're not hard to guess what they mean, and if you can't guess, they're > not hard to learn and remember. Possibly one common use case will be Unions. And that factory syntax is really awful and long when you look at a function definition with as little as 3 arguments. The one below has only 2 arguments. def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee], None]: That's for a generic list-like container. Have fun with the Mapping union. Meanwhile there's quite a few more generics like the Sequence one above you may want to take a look at and try and remember. And that's just one factory (the generics support factory). You may also want to take a look at TypeVar and Callable for more syntactic hell. Meanwhile, there's the strange decision to implement type hints for local variables # comment lines. I have an hard time wrapping my head around this one. Really, comments!? Finally, remember all this is being added to your code just to facilitate static analysis. Strangely enough though I was taught from the early beginning that once I start to care about types in Python, I strayed from the pythonic way. I'm confused now... What is it then? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Rick, Python is the only thing that is pure in the programming world. The only language that offers the cleanest and most intuit-able syntax, AND YOU"RE JUST GOING TO THROW IT ALL AWAY SO YOU CAN BE A LAPDOG OF SATAN? Nonsense. You are just used to it. I can read C with the same feeling of intuitiveness as you do Python. There's nothing inherently more intuitive about python and I just wished that meme died already. Besides it's all in the eye of the beholder. Some people, for intance, aren't all that comfortable about python white space as much as many die-hard pythonists would like to admit. It's not even a feature that gained traction on programming languages that came after python. If you don't act now, then don't bother complaining later. Python is dangling by a thin thread, and this is your last chance to save everything we've worked for. All the lines of code we've written won't mean spit if the language takes a swan dive into obscurity! PEP 484 just becomes silly when it comes to the section where it discusses whether type hints are pythonic. If that ridiculous paragraph reflects how we are looking today at the inclusion of new features, than I agree python is walking a dangerous road. But that also means Type Hints aren't the real problem here. We have a much bigger problem about the programming language principles and phylosophy. In all honesty though, I never cared much about the ideals and zens in programming languages, especially ones want to want to adopt a batteries-included philosophy. Always seemed to me like nonsense talk. My experience taught me that you can't just have the latter without eventually breaking the former. 'import this' always read to me like wishful thinking. Python isn't going anywhere towards obscurity. Not at least until a competiting language comes (it hasn't yet). I agree though that Python complexity has increased greatly over the years and this isn't showing any signs of stopping. And that is exactly the type of thing that promotes the birth of a new and better programming language. And, interestingly enough, that is always a good thing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Chris, Hold on a moment, how often do you really do this kind of thing with "might be one of them or a sequence"? Is it really that important that I give a more real-life example, or can't you just get the problem from a ad-hoc example? I could replace the variable names with spam, ham and eggs, if you wish. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Chris, I'd rather see a real-world example that can't be solved with either better design or some simple aliases. (And yes, the type hinting does allow for aliases.) Python is a duck-typing language, Chris. It is in its nature -- and we have been taught -- to ignore types and care only about operators. This means one of the most common design decisions in Python is exactly to code functions that are type ignorant. That is exactly why we need Type Hinting, because duck-typing complicates static analysis. And that is exactly why the Unions factory are a necessary part of the type hinting mechanism in PEP 484. You will be seeing lots and lots of Unions in type annotated code once it gets implemented. And it's not because of the complexity of Unions syntax that I should now care about refactoring my code. That is a no-no. If you don't know of any real-life example of python functions that will eventually force you into annotate them with unions syntax, look no further than your standard library. And also start questioning if you aren't complicating your own code with unnecessary function overloads. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Chris, On Thu, Jan 22, 2015 at 9:46 PM, Nicholas Cole wrote: Hang on! The particular example may not make a lot of sense but there are plenty of places in ordinary Python where functions can accept different objects in arguments and return different things. The point here is that that will become rapidly messy and hard to read. Yes; but with proper use of TypeVar can simplify things a lot - have a read of the PEP. ChrisA I agree. TypeVar will help tremendously by removing the need for union in cases of object inheritance. But only on cases of object inheritance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , random...@fastmail.us says... > How is that the opposite direction? It's a short jump from there to > "pylint [or whatever tool] will consider a lack of type hinting to be > something to warn for" and "managers/customers will consider this > warning to mean your program has failed and is unacceptable". Customers don't have access to static analysis output and project managers should know better than to demand static analysis without properly contextualize it. I just don't see a project manager having no idea what static analysis means. I think you are completely of the mark here, if you think type annotations will become some sort of obligatory feature. The criticism is about the choices regarding its syntax and whether it should couple so tightly with our source code (as is suggested on the PEP) and whether it should be entirely moved to comment-like structures. No one in their right mind looks at static analysis as an obligatory feature in Python, or any other programming language. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , sturla.mol...@gmail.com says... > > On 22/01/15 20:10, Mario Figueiredo wrote: > > > Customers don't have access to static analysis output and project > > managers should know better than to demand static analysis without > > properly contextualize it. I just don't see a project manager having no > > idea what static analysis means. > > I don't know how it works in you country, but here projects managers are > selected for having any kind of skill other than technical knowledge. I > know of one who got the job because he was a professional hockey player. > So yes, they can very well be unaware what static analysis means. But > what they will do is pick up "buzzwords" from the kind of journals that > project managers read. And then they want that buzzword implemented. > > Sturla That is fine. But then the problem isn't type hinting, is it? Neither I think you are suggesting we don't introduce language because there are bad project managers out there. The problem is then bad project managers. That has nothing to do with type hinting, or Python for that matter. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , rantingrickjohn...@gmail.com says... > python was meant to be a gateway to intuitive programming bliss. > Python was meant to be the "lingua franca" of the Programming world. And it failed miserably on both instances. Like any other programming language before and after it which pretended to be the one stop solution to world hunger. No. Python most important goal is to solve software requirements, like any programming language should. Intuitiveness, simplicity, easy of use, expressiveness, and all the other waiving flags you like to carry, are secondary-only goals. You sacrifice them for the first goal if they get in the way. It's the way of any evolving language. > You argue that readability is a relative construct, and you > are correct, but what you fail to acknowledge is that while > the ability to read noisy syntaxes improves with practice, > the comprehensive abilities of neophytes will always remain > constant. Python was built for the sake of the neophytes, > not to suffer the whims of the guru! I couldn't give a rat's arse about neophytes and I consider myself a beginner in the world of python. I'm more interested in having a language that can solve my problems. Expressiveness, simplicity, intuitiveness, all are lofty goals. But they are always going to be limited by the feature set of your language. And as it grows, as it tries to incorporate more and more features in order to become more and more capable of handling all types of modern software requirements, it will loose some of that expressivness, some of that simplicity and some of that intuitiveness. It's just how it is with any programming language. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article <6eb91c4b-92ff-44a8-b5a9-6ef04c71f...@googlegroups.com>, rantingrickjohn...@gmail.com says... > > So if the purpose is "static analysis", what is the > justification for injecting new syntax into function sigs? 1. Annotations where created exactly for this purpose. So there's some preassure to put them to work on what they were always meant to be used for. 2. Docstrings are meant as source of code documentation and to fill the object's __doc__ attribute, as per PEP 257. As such they aren't good consistent candidates for type hinting for purposes of static analysis tools. 3. Decorators are meant as function transformation tools, as per PEP 318 and, as such, are them too not suitable to include type annotations for the purpose of static analysis. 4. There is no other formal annotation mechanism, other than these potential three. Arguably, you can make a case against 1. And that's my own issue with type hinting as it is being proposed on PEP 484. The real problem is annotations as they were defined are a really bad idea. To couple type annotations so tightly with code, just results in plain ugly and hard to read code. Personally I would love to see the present annotations just go away and a new docstring-like structure to emerge in their place. But that's probably not going to happen. What I agree can't be done though, is to use docstrings or decorators as a source for type annotations. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , ian.g.ke...@gmail.com says... > > On Thu, Jan 22, 2015 at 3:27 PM, Chris Kaynor > wrote: > > Or use Any, which is basically the same thing: > > > > def adder(a: Any, b: Any) -> Any: > > return a + b > > Yeah, but this just seems like extra noise since it's not going to > help the type checker at all. I agree. It's after all a fully polymorphic function. There is no reason to pass it through a static analyzer. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
In article <5afad59b-5e8c-4821-85cf-9e971c8c7...@googlegroups.com>, rantingrickjohn...@gmail.com says... > > On Thursday, January 22, 2015 at 10:04:29 PM UTC-6, Chris Angelico wrote: > > > It's worth pointing out, too, that the idea isn't > > panaceaic - it's just another tool in the box. Any time > > you break related things into separate places, especially > > separate files, the tendency for them to get out of sync > > grows dramatically. > > I wonder how that "poor python interpreter" keeps all those > .pyc and .pyo files in sync with constantly changing source > code? It should be tantamount to torture! Will someone > *PLEASE* start a charity site titled: "Python's sanity fund"? > The process is automatic and based exclusively on timestamps. What you propose is manual labor and therein lies the rub. You have to remember to update your static analysis files when you update your code. And it is not always easy to do it, especially in team development environments. This is also going to complicate user work and the static analysis parser work. Function headers need to be matched with the annotated description in another file. Because of namespaces this will leave room for ambiguity, unless you mirror in the type hinting file the complete function signature, which must include its namespace. That is, you need a syntax that at the very least includes class declarations, but should probably also consider local namespaces and modules. All because you are not matching directly a type annotation with the type declaration in the code. ... In any case, I agree entirely with you that type annotation is one ugly syntax to a programming language that is touted everywhere as being simple and easy to read. I would say that the mistake started 5 years ago, and I am surprised how you guys let that horrible PEP pass. I wasn't around then, so I'm off the hook. Some folks in here argue that complex type annotations will be rare, since functions should be designed as straightforward units of code with simple requirements and respecting certain best practices, like separation of concerns, low cyclomatic complexity, adapt well to simple unit tests, bla bla bla. But the actual practice of coding software is very different. We generally code bad software and generally avoid best practices if they get in the way of our schedules, our knowledge, and even our ability. And there is always the problem of OOP, which is a magnificent source of complex function declarations in terms of the types they receive and output. I think that you are right in that we shouldn't pollute our code with static analysis shit. We shouldn't pollute our code period. But There's better ways of doing it without resorting to external files. I'd say Steven D'Aprano example of Cobra hit my sweet spot. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
In article <12d74fb6-f7d7-4ff0-88d3-6076a5dc7...@googlegroups.com>, rantingrickjohn...@gmail.com says... > > Injecting polarity into debates is dangerous, because, then > we get off into the emotional weeds and a solution may never > be found -- just observe the polarization of American > politics if you don't believe me --> *PUKE* I agree entirely. But you have to excuse me... weren't you the one calling Guido lapdog (you used worse names) to anyone who agreed with the PEP? ;) Don't been an hypocrit also, when Rantingrick is good enough. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
In article <4b3b498a-c9b0-443d-8514-87ccd8e98...@googlegroups.com>, rantingrickjohn...@gmail.com says... > > (Example modified for PEP8 compliance ;-) > > @typehint(arg1:str, arg2:int, returns:bool) > def myfunction(arg1, arg2): > return True > > Of course "@typehint" could be an extension of the decorator > syntax, a keyword, a build-in function or whatever, i don't > care. I'd rather it'd be a docstring parameter. - Decorators are transformation tools. Which type hints are not. - keywords should be few and used only for language features. Static analysis isn't and should never be a language feature. It's an extension, perhaps. - Same with built-in functions... although a case could be made for a static analysis package, hmmm. So I'd rather see: def myfunction(arg1, arg2): """ Normal docstring. """ "@typehint: (str, int) -> bool" return True This conforms to PEP 258, but not to PEP 8, but you can always use the triple quotes. I would just use the single-quote myself for matters of taste. I removed the arguments names on purpose. They are only necessary on the PEP because type hinting is a part of the function header there. However, when using a documentation like pattern as above (or as in your own example), they can be safely removed, with the added benefit of making the syntax simpler. Alternatively, because dangling strings are always considered documentation and completely ignored by the interpreter (PEP 258), one could also do: "@typehint: (str, int) -> bool" def myfunction(arg1, arg2): """ Normal docstring. """ return True Again the choice of triple quotes or not is something not worth debating. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
In article , mar...@gmail.com says... > > > So I'd rather see: > > def myfunction(arg1, arg2): > """ > Normal docstring. > """ > "@typehint: (str, int) -> bool" > return True > Actually that is idiotic. Much better is: def myfunction(arg1, arg2): """ Normal docstring... @typehint: (str, int) -> bool """ return True Why would I need to insert an extra docstring, if I'm already defining a parameter? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
In article , sohcahto...@gmail.com says... > > > def myfunction(arg1, arg2): > > """ > > Normal docstring... > > @typehint: (str, int) -> bool > > """ > > return True > > > > I really like that implementation. > > Its unobtrusive and doesn't clutter the function definition, and > putting in the docstring makes it get colored like a comment (At > least, with my IDE setup it does) so it is easily ignored by my eyes > as I'm scrolling through. It has the side effect of being included in __doc__. A purist may have an issue with that, since type hinting, for the purposes of static analysis, should have no place in that attribute. But you could always fall back to the previous version: def myfunction(arg1, arg2): """ Normal docstring... """ "@typehint: (str, int) -> bool" return True And __doc__ would be free of it. It would be up to the user to choose. For something completely different, I like @hint: better than @typehint: -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
Steven D'Aprano, Rick, you seem to be under the misapprehension that a reductio ad absurdum argument is a fallacy. It is not. From Webster's dictionary: Indirect demonstration, or Negative demonstration (called also reductio ad absurdum), in which the correct conclusion is an inference from the demonstration that any other hypothesis must be incorrect. And from Wordnet: reductio ad absurdum n 1: (reduction to the absurd) a disproof by showing that the consequences of the proposition are absurd; or a proof of a proposition by showing that its negation leads to a contradiction [syn: reductio ad absurdum, reductio] Example: Argument: Human population growth can continue forever, without any limits at all. There shall never come a time where lack of resources will constrain growth. Refutation by reductio ad absurdum: If human population doubles every fifty years, in 718 years every square metre of the world's land surface will have a person in it. In 840 years we will be jammed shoulder-to-shoulder. In 2335 years there will be a million people per square inch of the planet's surface (including oceans). Before that, after just 2155 years, the entire mass of the planet will be converted to human flesh. In 6760 years, the entire solar system will be a solid sphere of humans, expanding outward at 15840400 km per hour. Since this is clearly absurd, something (war, famine, disease, reduced fertility) must reduce or halt population growth. (Aside: those numbers are more or less correct, as best as I can calculate them.) Reductio arguments can, of course, be fallacious. "The world cannot be a sphere. If the world was a sphere, people on the bottom would fall off!" This argument is fallacious because it fails to understand that gravity acts towards the centre of the Earth, not "down" relative to outer space. And that's cherry picking. Another fallacy. That is, presenting only results that support your argument. When Reductio ad absurdum fails to respect the principle of non-contradition it is no longer a proof by contradiction devise, but a proper fallacy. Reductio ad absurdum becomes then one of the well know forms of straw man argument. Your argument that the 70s things were bad and Rick wanted to go back to those times is both debatable (the 70s brought much of what we use today as gospel, like design patterns, for instance). You also try to reduce rick argument to the absurd by insinuating he is trying to support the idea that we should declare function names in one file, function parameters in another file and the function body in another file. That's a proper reductio ad absurdum straw man argument if I ever saw one. -- https://mail.python.org/mailman/listinfo/python-list
__bases__ misleading error message
Consider the following code at your REPL of choice class Super: pass class Sub: pass foo = Sub() Sub.__bases__ foo.__bases__ The last statement originates the following error: AttributeError: 'Sub' object has no attribute '__bases__' Naturally the 'Sub' object has an attribute __bases__. It's the instance that has not. So shouldn't the error read like: AttributeError: 'Sub' instance has no attribute '__bases__', or AttributeError: 'foo' object has no attribute '__bases__' -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
In article <54c39e48$0$12996$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > > I'm not sure if you're making a general observation or one which is > specific > to Python. Plenty of languages have static analysis as a language feature. > Are you arguing they are wrong to do so? > No. I'm arguing static analysis should not consume a programming language keyword space. Static analysis is just a development tool. > > def myfunction(arg1, arg2): > """ > Normal docstring. > @typehint: (str, int) -> bool""" > return True > > One of the problems with this is that it put the information about > parameters far away from the parameter list itself. Then move it to the first line of the docstring... > > I removed the arguments names on purpose. They are only necessary on > > the > > PEP because type hinting is a part of the function header there. > > However, when using a documentation like pattern as above (or as in your > > own example), they can be safely removed, with the added benefit of > > making the syntax simpler. > > Only at the cost of making it hard to read. If you want the redundancy and a potential source of new bugs by having a type hint in a docstring include argument names... You see, there's always a downside to everything. Meanwhile, object names have nothing to do with type analsys, which makes arguments names rather irrelevant in the context of static analysis. I'd rather promote types than names. Remove names and you will. > > > > "@typehint: (str, int) -> bool" > > def myfunction(arg1, arg2): > > That's somewhat better, in that at least the hint is close to the function > signature. But it has a lot of disadvantages: it is compile-time only, the > type hints aren't available at runtime. It's static analysis. You don't need runtime execution. > It requires extra complexity to the > parser, so that decorators may be separated from the function by a hint: > > @decorate > "@typehint: (str, int) -> bool" > def myfunction(arg1, arg2): > > No doubt some people will get them the wrong way around, and the type > checker may silently ignore their hints: > > "@typehint: (str, int) -> bool" > @decorate > def myfunction(arg1, arg2): > > And others will write: > > @decorate > @typehint(str, int) -> bool > def myfunction(arg1, arg2): > That seems like you are fishing. What is exactly your point? That people will not be able to understand the rules of type hinting? And that somehow is going to be an universal problem? > Some syntax will be a bug magnet. This is one. You think? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Sanity Proposal: Type Hinting Solution
In article , mar...@gmail.com says... > > In article <54c39e48$0$12996$c3e8da3$54964...@news.astraweb.com>, > steve+comp.lang.pyt...@pearwood.info says... > > > > def myfunction(arg1, arg2): > > """ > > Normal docstring. > > @typehint: (str, int) -> bool""" > > return True > > > > One of the problems with this is that it put the information about > > parameters far away from the parameter list itself. > > Then move it to the first line of the docstring... Here's a more concrete example of what can be done in the docstring, taken from one of the examples in PEP 484. (Remember, we just moving the whole structure of type hinting to a new docstring parameter, instead of having it in the function header. "PEP 484" def handle_employees(e: Union[Employee, Sequence[Employee]]): if isinstance(e, Employee): e = [e] ... "My proposal:" def handle_employees(e): """ Handles an employee or list of employees by firing the whole bunch of 'em lazy sods. @hint: Union[Employee, Sequence[Employee]] :param e: A single employee or a list of employees :return: None """ if isinstance(e, Employee): e = [e] ... If you find that hard to read or feel you still can't match type hints to their respective arguments in the function header... then, yeah, there's no convincing you. My only pet peevee with this is that @int: becomes part of __doc__ and some pundits may argue against that inclusion. I don't have a real answer to that problem. I personally see that as a minor consequence, but can understand static analysis isn't really a part of a function documentation. -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article , tjre...@udel.edu says... > > AttributeError: 'Sub' object has no attribute '__bases__' > > In this message, 'Sub' is an adjective, modifying 'object, not naming > it. If you attend to the last line of the traceback > My first reaction is to look at 'Sub' as a noun, not an adjective, since I know that NAME well on my code as being a noun. Meanwhile I know that objects may be qualified (adjectivized) as class objects or instance objects. So, I also happen to look at the word "object" as an adjective, as Python object semantics would me do. What you propose is that I look at that phrase the other way around, which is kind of contrarian to how you actually use them in your code. > > AttributeError: 'Sub' instance has no attribute '__bases__', > > 'Sub' is an instance of 'type', so "'Sub' instance" could also be taken > to mean the class if the traceback were ignored. I agree. Sub instance is still somewhat ambiguous. So, maybe: AttributeError: Instance of object 'Sub' has no attribute '__bases__' -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article <54c39366$0$13006$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > > AttributeError: 'Sub' instance has no attribute '__bases__', > > AttributeError: 'foo' object has no attribute '__bases__' > > The first would be nice. The second is impossible: objects may have no name, > one name, or many names, and they do not know what names they are bound to. > So the Sub instance bound to the name 'foo' doesn't know that its name > is 'foo', so it cannot display it in the error message. Thanks for the information! :) But that begs the OT question: How does Python maps names to memory addresses in the interpreter? "__main__" from module import a_name y = a_name + 1 How does python interpreter know how to map 'name' to the correct memory location, if this __main__ code is only ran after 'module' code? -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article , tjre...@udel.edu says... > > > "__main__" > > from module import a_name > > A module is a namespace associating names with objects. This statememt > says to import the a_name to object association from module and add it > to __main__ > > > y = a_name + 1 > > This statement uses the imported association in __main__ to access the > object and add 1, and bind 'y' to the resulting object. But I'm being told the interpreter has no knowledge of a variable name. So, how does the interpreter know, once it reaches the assigment line above, how to map a_name to the correct object in memory? -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article , ian.g.ke...@gmail.com says... > > On Sat, Jan 24, 2015 at 2:14 PM, Mario Figueiredo wrote: > > But that begs the OT question: > > No, it doesnt. http://en.wikipedia.org/wiki/Begging_the_question Cute. > I'm not sure I'm understanding what you're asking, but the import > statement imports the module, looks up "a_name" in that module's > globals dict, and binds the same object to a_name in the current > module's globals dict. Meaning the interpreter knows a variable's name. Which would allow it to produce an error message such as: AttributeError: 'foo' object has no attribute '__bases__' For the following code: class Sub: pass foo = Sub() foo.__bases__ -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article , ros...@gmail.com says... > > Let me explain by way of analogy. [snipped] Gotcha! Thanks for the explanation :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article <54c2299d$0$13005$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > > I don't think that a raise of 0.10001 (10%), > 0.035003 (3.5%) or 0.070007 (7%) is quite what > people intended. > > (Don't use binary floating point numbers for anything related to > money. Just don't.) Few rules are written in stone and that rule isn't either. It all depends on the context. People often read these bits of well intentioned advise and go on to immediately make some kind of gospel out of it. Why is that? And why is that? Why do you think I can't ever use floats for money? Is there some kind of unspoken rule that money must always be dealt with with enough precision to give a microscope an headache? - What if I am storing money as an integer or a 2 decimal place Decimal to manage my electrical bill and I use a float to express a percentage? - What if the float operation is not a repetitive operation that would indeed invariably lead to round errors, but instead a once in a lifetime operation? I'm not saying I don't agree we should avoid it. I'm saying we need also to properly contextualize it before we decide to do so. If I'm writing a banking system, or a POS, you will be damn sure it will be hard to spot a float in my code. But if I'm writing my household electrical bill yearly report, or I'm writting a damn code snippet on a python group to illustrate how type hinting mangles your code, who gives a flying arse if I'm using a float to express money? Sheesh! -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article , ian.g.ke...@gmail.com says... > > No, you're being told that the *object* doesn't know the names of the > variables that it's bound to. In the context above, the variable is > right there under that name in the globals dict, as can be seen in the > disassembly: [snipped] Yes. I got it now. I misinterpreted Steven words. -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article , ros...@gmail.com says... > Awesome! I'm always a bit wary of analogies... sometimes they're > really helpful, other times they're unhelpful and confusing. Yeah. Your's was all it took :) The thing with analogies is to never take them literally. They are analogies, after all. But there is this old funny thing we humans seem to share that an analogy should be dissected like it was a scientific paper. - You say shoes in a box? Why, but memory addresses aren't boxes. Besides a box can only take shoes this big. Memory addresses can take any size object. - No I meant.. Look, just imagine shoes in a box. - Alright... - Now the other person will be handed the shoe you asked. They don't know what box it came from. What this mea... - How come? - How come what? - Why don't they know? They could just agree to know what box the shoe came from. Problem solved. - No, but I am trying to illustrate how it works. Not how it could work. - I still don't get it. Why does it work like that. Seems stupid... - It's not. There are specific reasons to not know. It's got to do with the process stack and efficiency and... - Right. And there's also the most annoying of all, the smartasses that like to stay hidden in the shadows and as soon as they see an analogy they jump in and tada! "It's not true that memory spaces can hold any object size. It is limited by the computer available memory" -- well, duh! "Is that a float you are using to compute a salary raise in your code snippet meant as an example to illustrate code syntax? Hahaha" -- Sigh! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , ros...@gmail.com says... > > On Sun, Jan 25, 2015 at 10:20 AM, Rick Johnson > wrote: > > Besides, why does he need *ME* to lick his boots when he > > already has plenty of fan-boys over at python-ideas and > > python-dev lining up. This community is *NOT*, and should > > never be, a homogeneous block -- for we would be doing > > ourselves a disservice. > > Wow. You think that, without you, python-ideas is homogeneous? I don't > think so. If it were, it would be called python-idea. He didn't say python-ideas is homogeneous. He didn't say either that he is the only one who dissents. There's already too much of "not wanting to listen to what the other person is saying" by both sides of this debate. Let's not add more... -- https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article <54c4606a$0$13002$c3e8da3$54964...@news.astraweb.com>,
steve+comp.lang.pyt...@pearwood.info says...
>
> It doesn't.
Your explanation was great Steven. Thank you. But raises one question...
>
> Assigning a value to a variable ("m = 42", hex 2A) results in the compiler
> storing that value in the bucket; assignment makes a copy: "n = m" leads to
> two independent buckets with the same value:
>
> m = [002A]
> n = [002A]
I'm still in the process of learning Python. So, that's probably why
this is unexpected to me.
I was under the impression that what python did was keep a lookup table
pointing to memory. Every variable gets an entry as type descriptor and
a pointer to a memory address, where the variable data resides.
(UDTs may be special in that they would have more than one entry, one
for each enclosing def and declared attribute)
In the example above, the n and m buckets would hold pointers, not
binary values. And because they are immutable objects, n and m pointers
would be different. Not equal. But in the case of mutable objects, n = m
would result in m having the same pointer address as n.
--
https://mail.python.org/mailman/listinfo/python-list
Re: __bases__ misleading error message
In article <54c4dae1$0$13005$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > [...] Most excellent. Thanks for the hard work, explaining this to me. :) Knowing Python internals is something that will end benefiting me in the long run. There's much to be gained by knowing the inner working of your programming language... Python is missing an under-the-hood book, I suppose. Tracing through Python source code to learn this stuff isn't easy unless we know what we are looking for. -- https://mail.python.org/mailman/listinfo/python-list
Object destruction delayed on interactive prompt
Consider the following class:
class A:
def __init__(self, value):
self.value = value
def __del__(self):
print("'A' instance being collected...")
def __repr__(self):
return str(self.value)
If ran as a script, the destructor behavior works as expected:
if __name__ == '__main__':
x1 = A(12)
print(x1) # __repr__()
x1 = 2 # __del__()
print(x1)
But if I run it interactively, a weird behavior comes up:
>>> x1 = A(12)
>>> x1 = 'string'
A instance being collected...# __del__() as expected
>>> x1 = A(12) # Recreate x1
>>> x1 # __repr__()
12
>>> x1 = 'string'# __del__() isn't executed!
>>> x1 # it is delayed until here
A instance being collected...
'string'
This is reproducible in IDLE and at the system command prompt. Is this a
REPL specific behavior?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Object destruction delayed on interactive prompt
In article , mar...@gmail.com says... > [...] Forgot to mention this is Python 3.4.2 -- https://mail.python.org/mailman/listinfo/python-list
Re: Object destruction delayed on interactive prompt
In article , pyt...@mrabarnett.plus.com says... > In the REPL, the result of an expression is bound to '_': > > >>> x1 = A(12) > >>> x1 # _ will be bound to the result. > 12 > >>> x1 = 'string' > >>> # At this point, _ is still bound to the object. > >>> 0 # This will bind _ to another object, so the previous object can > be collected. > 'A' instance being collected... > 0 Aha! Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , random...@fastmail.us says... > > On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote: > > random...@fastmail.us wrote: > > - lexical analysis has to look for twice as many files (it has to > > hit the hard drive for a stub file before looking at the source), > > and we know from importing that file system access is a > > significant and expensive part of the process. > > The idea is that the type hinting files would not participate in > execution at all, only static analysis, so the interpreter doesn't need > to look for these things at all, it only needs to ignore them. Like Steven, I do not agree with the idea of adding files for the purposes of static analysis. But you make an important point. Static analysis cannot and should not clutter executable code. Static analysis doesn't require code execution. The Python interpreter doesn't need to be called in. It is for this reason that it makes absolutely no sense to for type hints to be mixed with our code. Let them reside in comments, docstrings, external files, whatever. But never in our code. I'm actually baffled that PEP 484 came into existence, let alone it having any kind of supporter. Here we have a syntax that even requires changes to the interpreter so it can safely ignore all the type hinting clutter that is going to be added by anyone wanting to perform static analysis. And we should also be careful around the argument that type hints are optional. An optional feature says nothing of its requirements. The requirements for PEP 484 are heavy. Not only will they force an update to the interpreter, but will also force many users to reformate their function headers in order for them to become bareable to the eye. In fact, no longer will you look at function definitions like you did before. And an optional feature says nothing of its usage patterns. Type hints may be optional, but they may become a requirement for many projects. In fact, the more complex your project, the more likely you are of wanting to perform static analysis. It's not because type hints are optional that I have some kind of choice about the matter. I may force myself, or be forced, to use them. And if that is the case, I would rather prefer having a syntax that doesn't clutter my ezxecutable code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to spell this?
In article , jpiit...@ling.helsinki.fi says... > > If you mean literally some_predicate, then perhaps this. > > if some_predicate: >for x in seq: > handle(x) > Careful. See Chris Warrick answer for the correct position of the 'if' statement. -- https://mail.python.org/mailman/listinfo/python-list
An object is an instance (or not)?
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. >>> class Sub: >>> pass >>> foo = Sub() >>> foo.__bases__ [...] AttributeError: 'Sub' object has no attribute '__bases__' I'm making this into a new thread, because the particular discussion of whether an object is an instance in Python seems more interesting than discussing whether that error message should be changed or not. Here's another example where the terminology keeps indicating that in Python an object is an instance: >>> class Sub: pass >>> x = Sub() >>> x <__main__.Sub object at 0x02631690> The problem is that I personally cannot agree with this terminology and I would like to hear arguments that could convince me to adopt the Python way. But before your replies, here's my argumentation: An instance IS an object. On that we can agree. After all, everything in Python is an object. Even classes are. We can even pass them as function arguments: >>> class Sub: pass >>> def show(aClass): print(type(aClass)) >>> show(Sub) The problem is that an object isn't always an instance. The word instance in OOP has a very formal meaning. In programming languages in which the classes aren't fully realized objects, it is ok to speak of 'instance' and 'object' interchangeably. But even then, sometimes the term 'object instance' is preferred, as a way to separate these 'instances' from other variable instances that may not be created from class definitions (e.g. C++ built-in types). The fact that in Python classes are objects, should not just eliminate this distinction. The OOP terminology should exist beyond the language implementing it. It facilitates discourse and helps transmiting concepts when describing your ideas to another programmer. And because in python, classes are of the type 'type' and they exist as fully realized objects, is no excuse to make a distinction between them and their own fully realized instances. The language implementation details should not exist as a way for us to freely reformulate long standing terms. Because, from my own study of Python, I've came to realize that the distinction between objects and instances of objects actually exists. In Python, class objects cannot participate in OOP, only their instances. This is why I say that even in Python, where a class is an object, an object is not always an instance. The language itself forces that distinction. ... I don't think that any of this is reason enough to rewrite error messages in Python. Seems unnecessary. What I'm arguing thought is that error messages in Python cannot become the source of new terminology. The language itself implements a very clear distinction between class objects and their instances. And it is thus wrong of us to say that Object = Instance. At least from an OOP perspective. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , ros...@gmail.com says... > > On Wed, Jan 28, 2015 at 4:59 AM, Mario Figueiredo wrote: > > An optional feature says nothing of its requirements. The requirements > > for PEP 484 are heavy. Not only will they force an update to the > > interpreter, but will also force many users to reformate their function > > headers in order for them to become bareable to the eye. In fact, no > > longer will you look at function definitions like you did before. > > What updates are needed to the interpreter? > > https://www.python.org/dev/peps/pep-3107/ > > Already happened, long ago. I wasn't aware the interpreter was already able to parse PEP 484. Thank you. Strike that phrase of that paragraph. But what a royal mess! Looking at PEP 3107, i'm left wondering: what if I have for instance already annotated my functions for parameter marshalling, following the syntax expected of that specific library, and now I want to annotate them for type hinting for the purposes of static analysis? -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article <80a9f882-6b13-45a7-b514-8c47b3a4c...@googlegroups.com>, andre.robe...@gmail.com says... > > You keep writing "an object is not an instance", making statements > such as "the terminology keeps indicating that in Python an object is > an instance" and yet, none of the examples you show from Python > (tracebacks or repr outputs) include the word "instance". I think you misread my argument. Look at the first example on my post, or follow the discussion on "__bases__ misleading error message" here on the newsgroups. 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. Some of the answers that were given argued that in Python object = instance. > Yet > **you** claim that "Python" states that objects are instances That is no my claim. I said that much. You should probably read my post more carefully. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , ros...@gmail.com says... > > On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo wrote: > > Looking at PEP 3107, i'm left wondering: what if I have for instance > > already annotated my functions for parameter marshalling, following the > > syntax expected of that specific library, and now I want to annotate > > them for type hinting for the purposes of static analysis? > > This is the kind of argument that keeps on coming up. Everyone has a > "What if" scenario about function annotations... and almost nobody > actually has a codebase that uses them. It's equivalent to asking: > "What if I already used docstrings to control URL routing, and now I > want to use them for function documentation?". Well, simple. You move > your other-use-of-annotations out to something else (probably a > decorator) before you add type hints. Until that time, you're welcome > to continue using annotations for something other than type hinting; > you just can't do both at once on the same function. > > ChrisA I'm sorry Chris. But that's a weak argument and you know it. If I use those decorators inside properly formated docstrings, I can do both things, and more! And I don't have to move anything anywhere. def func(a, b, c): """ This function does something very interesting and returns a surprise :a: an integer, also known as whole number (lies!) :b: a float on a string so it can't escape :c: an unicode string with some bad language @typehint@ some crazy syntax for static analysis @marshallib@ more crazy syntax for the marshall lib @anotherlib@ Whoohoo! a 3rd annotation for another lib """ Are you telling me this is not a viable alternative. That somehow we should ignore the possibility of potentially different annotations having to coexist on a project? C'mon! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , ros...@gmail.com says... > > Sure you can! But this is *itself* a weak argument, unless you > actually have a codebase that uses it. Wait. Are you saying that unless I show you a codebase that requires marshalling and static analysis, you will ignore the fact that a project, no matter its size, may require more than one annotation type? In other words, lets suggest function annotations as a restrictive feature, instead of a feature that can adapt to more than one use case. > YAGNI comes to mind. When do > you actually need to annotate with multiple styles like this, and > should everyone pay the price (the disconnect from from the function > name) even though this is almost never needed? That is your price. My price is seeing my executable code cluttered with static fluff. Very pythonesc, I suppose... -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
I can now start to understand the criticism of how Python is evolving coming from many corners, either long term python educators like Mark Lutz. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , andre.robe...@gmail.com says... > > It is appropriate to refer to an instance as an object. It might not > be appropriate to refer to an object as an instance ... but Python > does not do so as your explicit examples demonstrate, and contrary to > your claim. I'll try one more time: It - Is - Not - My - Claim. It is the claim of a few users in here that replied to that thread. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article <9a2cf6ca-2eb8-4a87-9e83-e87d90d5f...@googlegroups.com>, andre.robe...@gmail.com says... > > **This is a follow up from a previous discussion in which it is argued > that the following code produces the correct error message terminology ** > > I pointed out to you that the word object WAS used correctly: hence, the > correct terminology was used in that error message. > > You are just wasting people's time. That is just rude! I'm still trying to understand what is the problem you are having with my post. Have you followed the previous thread? Is there anything you are not understanding? People were saying to me that in Python object = instance. I'm trying to argue why I believe it isn't and asking for arguments to convince me otherwise. And that's the best you can do? Python does imply that an object is an instance, btw. It is why I got that answer from more than one person. Or so they say. By referring to an instance of Sub as "Sub object", there's an implicit affirmation that an object is an instance. Bye. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , n...@nedbatchelder.com 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. > 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. 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 Master: def func(self): pass >>> class Sub(Master): pass >>> Sub.func() TypeError: func() missing 1 required positional argument: 'self' But somehow I think you knew the answer to all these questions and were instead being snarky. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , ben+pyt...@benfinney.id.au says... > > > This is why I say that even in Python, where a class is an object, > > > an object is not always an instance. The language itself forces that > > > distinction. > > You have not, to my knowledge, shown any object (in Python 2.2 or later) > which is not an instance of some class. Python objects are always an > instance of some specific class. It is true that a class object is an instance of 'type'. But this is a special type (can't avoid the pun). A class object is not an instance of the type it implements. That is what I mean by an object that isn't an instance. In other words, the object know as "Sub class" is not an instance object. True, it is an instance of the object 'type'. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , ros...@gmail.com says... > > On Wed, Jan 28, 2015 at 10:22 AM, Ned Batchelder > wrote: > > 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. > > My understanding is that "instance" is meaningless unless followed by > "of". That is to say, 123.45 is an object, and it is an instance *of* > the 'float' class. Everything in Python is an instance *of something*, > so in a sense, you can say that everything is an instance, but that's > like saying that everything has a color. Sure it does, but you need to > be more specific. > In programming languages in which class definitions aren't first-class objects, the terms are in fact used interchangeably. And rightly so, because an object is in fact always an instance of some class. Python and a few other languages implement class definitions as first- class objects. In this case, the distinction between an object and an instance is actually an implementation detail and comes with its own semantics. This is why I object to the notion that in Python object = instance. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , ros...@gmail.com says... > > On Wed, Jan 28, 2015 at 11:17 AM, Mario Figueiredo wrote: > > 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 Master: > > def func(self): > > pass > > > > >>> class Sub(Master): > > pass > > > > >>> Sub.func() > > TypeError: func() missing 1 required positional argument: 'self' > > > I have no idea what you're proving here. You just showed that the > class has a function attached to it, and you didn't provide enough > arguments to it. And types have their own set of attributes and > methods: > I admit it was a contrived example. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , breamore...@yahoo.co.uk says... > > Mario and Andre, when you have to write code to meet the deadline to get > the stage payment, does either of your bosses really care whether or not > you are dealing with an object, an instance, or a piece of dead meat > dropped by the neighbour's cat? That is valuable input. You don't care how a type or an instance of a type differ. Should be intersting to ask you to make a Cat object. I wonder if you are not going to ask if they mean a class or an instance of that class. Anyways, more to the point, this is simply a debate on language and how to express Python concepts. If that bothers you, I'll take note. -- https://mail.python.org/mailman/listinfo/python-list
Re: An object is an instance (or not)?
In article , ben+pyt...@benfinney.id.au says... > > Mario Figueiredo writes: > > > It is true that a class object is an instance of 'type'. But this is a > > special type (can't avoid the pun). > > Nevertheless it is a class, and can do everything that classes do. > > And every class is an object, and can do everything that objects do. > > You seem to agree with those, so please stop claiming that classes are > not objects. Python classes are always objects, and always have been. > > > A class object is not an instance of the type it implements. > > You keep introducing hurdles that are irrelevant. Yes, a class is not an > instance of itself. That doesn't impact the fact a class is an object. > > > That is what I mean by an object that isn't an instance. > > That's incoherent. It's an instance of a class, and simultaneously is > not an instance? > > > In other words, the object know as "Sub class" is not an instance > > object. True, it is an instance of the object 'type'. > > You've tied yourself in knots with concepts that are not coherent, and > even if they were do not appear to be relevant to Python. Very well. I'm failing at putting my point across. I will not discuss this further. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to spell this?
In article <54c8339f$0$13008$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > (3) _ is also commonly used as a "don't care" variable name: > > a, _, b, _ = get_four_items() # but I only care about two of them > According to the following link, it is actually a double underscore: http://docs.python-guide.org/en/latest/writing/style/#idioms -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there a more elegant way to spell this?
In article , ben+pyt...@benfinney.id.au 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)?
In article , breamore...@yahoo.co.uk 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: Python is DOOMED! Again!
In article <54c83ab4$0$12982$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info 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
Re: Python is DOOMED! Again!
In article , breamore...@yahoo.co.uk says... > > 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. > Indeed. I confused strongly/weakly with static. I feel a a bit embarrased by it. My apologies. But no. Nothing that follows from that paragraph is wrong, just because of that mistake. It still stands that list was artifically created to make it look like type annotations on top of executable code is a feature of nearly every language in the book. When it is not! Most particularly when it comes to statically typed languages, wich Steven didn't feel guilty of including there. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article <54c980cd$0$12981$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > > 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* The sarcasm is unnecessary. They are different yes. Are you on purpose confusing the syntax of a feature with its meaning? Because while you have a very similar syntax between Julia, Scala and Python. Their meanings are very different. I think it is obvious to anyone that if a feature like type annotations are meant to be EVALUATED AT RUNTIME (and I myself gave you another example of Julia), it makes every sense for that feature to be a part of the programming language syntax. I could never argue against Julia or Scala type annotations on that basis. The syntax is an integral part of the executable code. But when a feature is not meant for runtime evaluation, why should it clutter your executable code? Make me understand your reasoning? Your list of programming languages is just plain wrong. To my knowledge (there's a few languages there I don't know and never used), none of those languages implement anything like Python. Type annotations in python are entirely ignored by the interpreter except to make them available to external libraries. This is a feature that I have seen implemented in numerous languages as a part of doc-like comments. Never, ever, as a part ofthe language syntax. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article <54ca5bbf$0$12992$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > > Why should I feel guilty? You wrote: > > > "Static analysis cannot and should not clutter executable code." > > > But what are type declarations in statically typed languages like C, Pascal, > Haskell, etc.? They are used by the compiler for static analysis. The same > applies to type declarations in dynamically typed languages like Cobra and > Julia. And yet, there they are, in the executable code. > > So there are a whole lot of languages, going all the way back to 1950s > languages like Fortran, to some of the newest languages which are only a > few years old like Go, both dynamically typed and statically typed, which > do exactly what you say languages "cannot and should not" do: they put type > information used for static analysis there in the code. You are confusing static analysis with compile time checking which produces side-effects like implicit conversion for instance and that affects the resulting binary code. Something that Python won't do with type annotations. And something that Julia, Scala or C does. This is also the first time I hear compilation time mentioned as static analysis. To be clear, type declarations in Julia, Scala, C have the potential to produce side-effects, can result in optimized code and can result in compile time errors or warnings. Type annotations in Python are instead completely ignored by the interpreter. They do nothing of the above. They do not participate in code execution. > As I said, these languages disagree with you. You are not just arguing > against Guido, but against the majority of programming language designers > for 60+ years. You are right. I'm not arguing against Guido. I have yet to hear his opinion on your or mine arguments. I'm not arguing against the majority of programming languages either, because they agree with me. I'm arguing with you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article <54ca5bbf$0$12992$c3e8da3$54964...@news.astraweb.com>, steve+comp.lang.pyt...@pearwood.info says... > > > Why should I feel guilty? You wrote: > > > "Static analysis cannot and should not clutter executable code." > > > But what are type declarations in statically typed languages like C, Pascal, > Haskell, etc.? They are used by the compiler for static analysis. The same > applies to type declarations in dynamically typed languages like Cobra and > Julia. And yet, there they are, in the executable code. > > So there are a whole lot of languages, going all the way back to 1950s > languages like Fortran, to some of the newest languages which are only a > few years old like Go, both dynamically typed and statically typed, which > do exactly what you say languages "cannot and should not" do: they put type > information used for static analysis there in the code. (Sorry if I'm late...) You are comparing static analysis with compile time checking which can result in implicit conversions and that can affect the resulting binary code. Something that Python won't do with type annotations. And something that Julia, Scala or C does. This is also the first time I hear compilation mentioned as static analysis. But I suppose... After all it does perform a crude form of static analysis as a natural consequence of compile time checks, besides doing a whole bunch of other things that aren't static analysis. A dog has four legs and two eyes. So does an elephant. I suppose you are going to argue with me that a dog is an elephant after all. To be clear, type declarations in Julia, Scala, C have the potential to produce side-effects, can result in optimized code and can result in compile time errors or warnings. They also affect runtime evaluation as you could easily attest if you input a float into a function expecting an int, whereas in Python the float will be gladly accepted and will only fail at the point in code where its interface won't match the statement. Meanwhile, type annotations in Python are instead completely ignored by the interpreter. They do nothing of the above. They do not participate in code generation and execution. > As I said, these languages disagree with you. You are not just arguing > against Guido, but against the majority of programming language designers > for 60+ years. You are right. I'm not arguing against Guido. I have yet to hear his opinion on what you are saying, so I don't even know if I should want to argue with him. And I'm not arguing against the majority of programming languages either, because as much as you try I have yet to hear an argument from you that convinces me they don't agree with me. No. I'm arguing with you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is DOOMED! Again!
In article , breamore...@yahoo.co.uk says... > > No, they're not always weakly typed. The aim of the spreadsheet put up > by Skip was to sort out (roughly) which languages belong in which camp. > I do not regard myself as suitably qualified to fill the thing out. > Perhaps by now others have? It would help that if instead of weakly typed or strongly typed box, they could be classified comparatively to each other. The terms are better suited to describe two languages as they stand to each other. Weakly Typed --> Strongly Typed >From C to Lisp (arguably) with languages closer to each other indicating a more similar type system model. -- https://mail.python.org/mailman/listinfo/python-list
Dictionary from sqlite3.Row and PyCharm unresolved reference
Currently i'm using the following code to transform a row fetched from an
sqlite database into a dictionary property:
def __init__(self, id_):
self.id = id_
self.data = None
...
conn = sqlite3.connect('data')
conn.row_factory = sqlite3.Row
row = conn.execute(query, {'id': str(id_)}).fetchone()
conn.close()
if row:
self.data = dict(zip(row.keys(), tuple(row)))
I have two questions:
1. Is this an acceptable idiom for the construction of self.data dictionary,
or do I have a better and more readable option?
2. How can I stop PyCharm from giving me an unresolved reference warning
at row.keys()? It's not a big deal, but slightly annoying. But I'd rather
prefer
a method that doesn't completely disable other valid cases.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dictionary from sqlite3.Row and PyCharm unresolved reference
In article , __pete...@web.de says... > > self.data = dict(row) I didn't realize from the documentation it could be this simple. Thanks. > > And now an unsolicited remark: if you have more than one instance of Unknown > you might read the data outside the initialiser or at least keep the > connection open and pass a connection or cursor object to the initialiser. Yes, thank you. Later I am moving the code to a factory. -- https://mail.python.org/mailman/listinfo/python-list
