Re: [rotatingloghandler]: How to read the logs produced ?

[Michael Ricordeau]

I suggest SyslogHandler in logging package to centralize all logs .
 http://docs.python.org/library/logging.html#sysloghandler


In my opinion, rotating, parsing, filtering logs is a different task (for a 
sysadmin not a developper). 
I'm doing this for all my projects at work :
 - using SyslogHandler for logging application servers
 - using one syslog server to get all logs from application servers



Le Tue, 18 Jan 2011 23:45:36 -0800,
Chris Rebert  a écrit :

> On Tue, Jan 18, 2011 at 11:27 PM, Low Kian Seong
>  wrote:
> > On Jan 19, 2011, at 3:25 PM, Chris Rebert  wrote:
> >> On Tue, Jan 18, 2011 at 10:02 PM, low kian seong
> >>  wrote:
> >>> Dear people,
> >>> I am currently using concurrentrotatingfilehandler to handle my Python 
> >>> logs.
> >>> The situation is okay when it's only one log, but when it needs to spill
> >>> over to the next log (I configured to have 2) say test.log.2 then I see 
> >>> that
> >>> the output is sort of shared between the first log test.log and 
> >>> test.log.2.
> >>> Am I supposed to concatenate all the logs together to get my logs back ?
> >>> Google hasn't brought back any results, so I am wondering is it just me
> >>> using or reading the resultant logs wrong?
> >>
> >> Since this is apparently a 3rd-party library
> >> (http://pypi.python.org/pypi/ConcurrentLogHandler/ ), have you tried
> >> asking the maintainer? (Who is evidently Lowell Alleman  >> at_sign gmail period com>.) Could very well be a bug.
> >>
> > Actually the default concurrent log handler produces similar results.
> 
> That wouldn't be particularly surprising:
> 
> "15.7.10. Logging to a single file from multiple processes
> 
> Although logging is thread-safe, and logging to a single file from
> multiple threads in a single process is supported, logging to a single
> file from multiple processes is **not** supported [...]"
> -- http://docs.python.org/library/logging.html
> 
> Cheers,
> Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Stefan Behnel]

Octavian Rasnita, 19.01.2011 07:10:

aren't the Pyton bytecode-compiled files considered secure enough?
Can they be easily decompiled?


Yes.

Stefan

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

Re: __pycache__, one more good reason to stck with Python 2?

[H₂0 . py]

On Jan 18, 4:04 am, Peter Otten <__pete...@web.de> wrote:
>
> What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'?

Portability. Running the '-exec' version will work fine in a directory
with a relatively small number of files, but will fail on a large one.
'xargs', which is designed to handle exactly that situations, splits
the returned output into chunks that can be handled by 'rm' and such.
'|xargs' is always the preferred option when you don't know how large
the output is going to be.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "rantingrick" 

You know we Python programmers are professional debaters. This has
been my take on the Python community. However without the virtues of
compromise and community spirit all we are going to do is fight like
cats and dogs forever to the very detriment of the very community we
wish to muster

We need to look at these problems from a community perspective and
tone down the rhetoric. The layer of thick sarcasm that exists is so
viscous and putrid that any semblance of civility is completely
impervious to it's gelatinous all encompassing mass. We need to get
more folks involved in the decision process. We need more community
discussion and less community corruption. Currently we have a small
subset of the community making a large proportion of the decisions. We
did have a monarchy ruled by our beloved dictator however it has
degenerated into a banana republic! We need democracy and we need it
now!





Well, those who work have the latest word and they will decide what they 
will want to do. We can just show our opinions and hope that they will care 
and take the best decision.
The problem is that some people don't care and want to demonstrate that this 
is very normal and that they are right, which is not good at all.


Octavian

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

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Octavian Rasnita]

From: "Stefan Behnel" 

Octavian Rasnita, 19.01.2011 07:10:

aren't the Pyton bytecode-compiled files considered secure enough?
Can they be easily decompiled?


Yes.

Stefan




Would it be hard to introduce the possibility of adding encryption of the 
bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for 
Perl?


Octavian




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

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Stefan Behnel]

Octavian Rasnita, 19.01.2011 11:31:

From: "Stefan Behnel"

Octavian Rasnita, 19.01.2011 07:10:

aren't the Pyton bytecode-compiled files considered secure enough?
Can they be easily decompiled?


Yes.


FYI, just take a look at the 'dis' module. There are also decompilers 
available. IIRC, one is called "decompyle".




Would it be hard to introduce the possibility of adding encryption of the
bytecode similar to what the Zend encoder does for PHP or Filter::Crypto
for Perl?


You can use an import hook to do anything you like. That includes 
decrypting a file and extracting a normal .pyc from it that can then be 
imported. However, that won't prevent users from inspecting the code at 
runtime if they get a handle at it (which they likely will if they try).


Stefan

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

Re: UTF-8 question from Dive into Python 3

[Tim Harig]

On 2011-01-19, Tim Roberts  wrote:
> Tim Harig  wrote:
>>On 2011-01-17, carlo  wrote:
>>
>>> 2- If that were true, can you point me to some documentation about the
>>> math that, as Mark says, demonstrates this?
>>
>>It is true because UTF-8 is essentially an 8 bit encoding that resorts
>>to the next bit once it exhausts the addressible space of the current
>>byte it moves to the next one.  Since the bytes are accessed and assessed
>>sequentially, they must be in big-endian order.
>
> You were doing excellently up to that last phrase.  Endianness only applies
> when you treat a series of bytes as a larger entity.  That doesn't apply to
> UTF-8.  None of the bytes is more "significant" than any other, so by
> definition it is neither big-endian or little-endian.

It depends how you process it and it doesn't generally make much
difference in Python.  Accessing UTF-8 data from C can be much trickier
if you use a multibyte type to store the data.  In that case, if happen
to be on a little-endian architecture, it may be necessary to remember
that the data is not in the order that your processor expects it to be
for numeric operations and comparisons.  That is why the FAQ I linked to
says yes to the fact that you can consider UTF-8 to always be in big-endian
order.  Essentially all byte based data is big-endian.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 18, 3:23 pm, "Octavian Rasnita"  wrote:
> From: "Alexander Kapps" 
>
> > Tkinter causes damage? Very bad damage? What are you talking about?
>
> I am talking about the fact that Python promotes Tkinter, and many beginners 
> will start using it, and they will start creating applications with it, and 
> they will learn to use it better than WxPython, and they will start believing 
> that Tkinter is better because it is easier to use than WxPython, so they 
> will start convincing others that Tkinter is the best, and they will start 
> finding many reasons that show that Tkinter is better. And after this, they 
> will say that they don't care about the real problems generated by GUIs like 
> Tk.
> And a very big problem is that the applications that use Tk/GTK are not 
> accessible for screen readers, so those applications will be just blank for 
> people with visual impairments which need to use a screen reader.

If you want functional accessibility support, you're going to have to
write it in Python yourself, and get the accessibility manufacturers
to support it.  All of the cross-platform toolkits have poor to non-
existent accessibility support.  Accessibility issues aren't going to
be fixed by going to a different GUI toolkit in the standard library.
The alternative is to fix the accessibility support issues in the
underlying library, and Tk is no less amenable to that than
wxWidgets.  If that's what you want, start coding then.  You have a
long climb ahead of you.

Accessibility will never be a particular good argument for switching
toolkits.  All of the cross-platform offerings with Python bindings
are far too broken to be even remotely interesting.

> Why do we like the portable GUIS and don't really like the native interfaces 
> that don't work on other platforms?
> Because we want our programs to be usable by as many people as possible. 
> Well, some platforms render the output as sound and Tkinter are not 
> "portable" on those platforms (screen readers).

Or we have cross-platform support as a requirement and no desire to
develop the GUI interface three times over.  Hence the continued
popularity of Java GUIs.

Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 19, 1:37 am, "Octavian Rasnita"  wrote:
>
> The users shouldn't want something better. Everyone should create GUIs which
> are accessible for everyone by default, without making any special effort
> for doing this.

Accessibility always requires special effort, and I don't see how
changing toolkits gets away from this.

Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 19, 1:37 am, "Octavian Rasnita"  wrote:
>
> Most of the programmers don't know that and they don't even need to know
> that, but if a lib that create accessible GUIS would be promoted, most of
> the Python programmers would use that lib and would create good apps by
> default, without even knowing this.

Have you written an accessible application in any toolkit whatsoever?
It is not magic, and it does not happen by default, even when solely
using the standard widgets.

Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 question from Dive into Python 3

[Antoine Pitrou]

On Wed, 19 Jan 2011 11:34:53 + (UTC)
Tim Harig  wrote:
> That is why the FAQ I linked to
> says yes to the fact that you can consider UTF-8 to always be in big-endian
> order.

It certainly doesn't. Read better.

> Essentially all byte based data is big-endian.

This is pure nonsense.


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

Re: UTF-8 question from Dive into Python 3

[Tim Harig]

Considering you post contained no information or evidence for your
negations, I shouldn't even bother responding.  I will bite once.
Hopefully next time your arguments will contain some pith.

On 2011-01-19, Antoine Pitrou  wrote:
> On Wed, 19 Jan 2011 11:34:53 + (UTC)
> Tim Harig  wrote:
>> That is why the FAQ I linked to
>> says yes to the fact that you can consider UTF-8 to always be in big-endian
>> order.
>
> It certainly doesn't. Read better.

- Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If
- yes, then can I still assume the remaining UTF-8 bytes are in big-endian
^^
- order?
  ^^
- 
- A: Yes, UTF-8 can contain a BOM. However, it makes no difference as
 ^^^ 
- to the endianness of the byte stream. UTF-8 always has the same byte
    ^^
- order. An initial BOM is only used as a signature -- an indication that
  ^^
- an otherwise unmarked text file is in UTF-8. Note that some recipients of
- UTF-8 encoded data do not expect a BOM. Where UTF-8 is used transparently
- in 8-bit environments, the use of a BOM will interfere with any protocol
- or file format that expects specific ASCII characters at the beginning,
- such as the use of "#!" of at the beginning of Unix shell scripts.

The question that was not addressed was whether you can consider UTF-8
to be little endian.  I pointed out why you cannot always make that
assumption in my previous post.

UTF-8 has no apparent endianess if you only store it as a byte stream.
It does however have a byte order.  If you store it using multibytes
(six bytes for all UTF-8 possibilites) , which is useful if you want
to have one storage container for each letter as opposed to one for
each byte(1), the bytes will still have the same order but you have
interrupted its sole existance as a byte stream and have returned it
to the underlying multibyte oriented representation.  If you attempt
any numeric or binary operations on what is now a multibyte sequence,
the processor will interpret the data using its own endian rules.

If your processor is big-endian, then you don't have any problems.
The processor will interpret the data in the order that it is stored.
If your processor is little endian, then it will effectively change the
order of the bytes for its own evaluation.

So, you can always assume a big-endian and things will work out correctly
while you cannot always make the same assumption as little endian
without potential issues.  The same holds true for any byte stream data.
That is why I say that byte streams are essentially big endian.  It is
all a matter of how you look at it.

I prefer to look at all data as endian even if it doesn't create
endian issues because it forces me to consider any endian issues that
might arise.  If none do, I haven't really lost anything.  If you simply
assume that any byte sequence cannot have endian issues you ignore the
possibility that such issues might not arise.  When an issue like the
above does, you end up with a potential bug.

(1) For unicode it is probably better to convert to characters to
UTF-32/UCS-4 for internal processing; but, creating a container large
enough to hold any length of UTF-8 character will work.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Mark Roseman]

Octavian,

Thank you for clearly articulating your concern that Tk does not provide 
any support for screen readers.

While I believe that people can have legitimate differences of opinion 
as to whether this merits its removal/replacement from stdlib, there is 
no question that this is a serious and significant limitation of Tk.

I will attempt to find out if there has been any work done in this area 
with Tk, and what it would take to address this important issue.

Thanks again
Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 question from Dive into Python 3

[Antoine Pitrou]

On Wed, 19 Jan 2011 14:00:13 + (UTC)
Tim Harig  wrote:
> 
> - Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If
> - yes, then can I still assume the remaining UTF-8 bytes are in big-endian
> ^^
> - order?
>   ^^
> - 
> - A: Yes, UTF-8 can contain a BOM. However, it makes no difference as
>  ^^^ 
> - to the endianness of the byte stream. UTF-8 always has the same byte
> ^^
> - order.
>   ^^

Which certainly doesn't mean that byte order can be called "big
endian" for any recognized definition of the latter. Similarly, ASCII
test has its own order which certainly can't be characterized as either
"little endian" or "big endian".

> UTF-8 has no apparent endianess if you only store it as a byte stream.
> It does however have a byte order.  If you store it using multibytes
> (six bytes for all UTF-8 possibilites) , which is useful if you want
> to have one storage container for each letter as opposed to one for
> each byte(1)

That's a ridiculous proposition. Why would you waste so much space?
UTF-8 exists *precisely* so that you can save space with most scripts.
If you are ready to use 4+ bytes per character, just use UTF-32 which
has much nicer properties.

Bottom line: you are not describing UTF-8, only your own foolish
interpretation of it. UTF-8 does not have any endianness since it is a
byte stream and does not care about "machine words".

Antoine.


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

Re: __pycache__, one more good reason to stck with Python 2?

[Steven D'Aprano]

On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote:

> It is now practically impossible to launch a Python application via a
> .pyc file. 


When has that ever been possible?


.pyc files are Python byte-code. You can't run them directly using Python 
(except via the import machinery), you can't run them as a script, 
they're not machine code. Unless you write a wrapper to import the file 
as a module, you can't directly execute .pyc files.


> (For the fun, try to add the "parent directory" of a cached
> file to the sys.path).

I don't understand what you're getting at there.

 
> About the caches, I'am just fearing,  they will become finally garbage
> collectors of orphan .pyc files, Python has seed/seeded(?). The .pyc
> files may not be very pleasant, but at least you can use them and you
> have that "feeling" of their existence. I my "computer experience", once
> you start to cache/hide something for simplicity, the problems start.

I will say that in general I'm not very happy with what seems like every 
second application creating huge disk caches in random locations. It's a 
PITA, and I wish they'd standardize on a single cache location, to make 
it easy to exclude them from backups, to sanitize the bred-crumbs and 
data trails applications leave, and so forth.

But having said that, the __pycache__ idea isn't too bad. If you have 
this directory structure:

./module.py
./module.pyc

and import module, the top-level .pyc file will continue to be used. If 
you delete module.py, leaving only the top-level .pyc, it will still 
continue to be used. That much hasn't changed.

The only difference is if you start with only a .py file:

./module.py

and import it, the cached version will be placed into __pycache__ 
instead. Unlike orphaned .pyc files in the top level, orphaned .pyc in 
the __pycache__ are considered stale and will be ignored. So they're safe 
to ignore, and safe to delete, at any time.

Nothing is stopping you from moving the .pyc file into the top level and 
deleting the .py file, if you so desire.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)

[python]

Mark/Octavian,

It sounds like Tka11y (spelled with the digit '1' vs. the letter 'L')
addresses this problem for Linux users.

According to its website, adding accessability support is as simple as
changing one import statement.

Details follow my signature.

Malcolm


Tka11y - Tk Accessibility
http://tkinter.unpythonic.net/wiki/Tka11y


Note: Currently, accessibility is only available via ATK <=> AT-SPI on
Linux. Sorry, no Windows MSAA support.

Download
http://pypi.python.org/pypi/Tka11y

A modification to Tkinter to make widgets visible to the AT-SPI layer so
that tools like dogtail and Accerciser can see them. Tka11y uses Papi,
the Python Accessibility Programming Interface, which in turn uses ATK,
the GNOME Accessibility Toolkit, to expose Tkinter widgets to AT-SPI,
the Assistive Technologies Service Provider Interface. This allows a
Tkinter application's widgets to be viewed and/or controlled by a
variety of assistive technologies such as Orca and Accerciser, and
automated GUI testing tools such as dogtail and LDTP. These client tools
usually use either cspi (C) or pyatspi (Python).

Typical usage:

import Tka11y as Tkinter

or

from Tka11y import *

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

Re: __pycache__, one more good reason to stck with Python 2?

[Antoine Pitrou]

On 19 Jan 2011 14:42:14 GMT
Steven D'Aprano  wrote:
> On Tue, 18 Jan 2011 00:58:14 -0800, jmfauth wrote:
> 
> > It is now practically impossible to launch a Python application via a
> > .pyc file. 
> 
> 
> When has that ever been possible?
> 
> 
> .pyc files are Python byte-code. You can't run them directly using Python 
> (except via the import machinery), you can't run them as a script, 
> they're not machine code. Unless you write a wrapper to import the file 
> as a module, you can't directly execute .pyc files.

It seems to work here:

$ echo "print 'foo'" > toto.py
$ python -m compileall -l .
Listing . ...
Compiling ./toto.py ...
$ rm toto.py
$ python toto.pyc
foo


But it still works under 3.2 even though the incantation is less pretty:

$ echo "import sys; print(sys.version)" > toto.py
$ __svn__/python -m compileall -l .
Listing . ...
Compiling ./toto.py ...
$ rm toto.py
$ __svn__/python __pycache__/toto.cpython-32.pyc
3.2rc1+ (py3k:88095M, Jan 18 2011, 17:12:15)
[GCC 4.4.3]


Regards

Antoine.


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

Re: UTF-8 question from Dive into Python 3

[Adam Skutt]

On Jan 19, 9:00 am, Tim Harig  wrote:
>
> So, you can always assume a big-endian and things will work out correctly
> while you cannot always make the same assumption as little endian
> without potential issues.  The same holds true for any byte stream data.

You need to spend some serious time programming a serial port or other
byte/bit-stream oriented interface, and then you'll realize the folly
of your statement.

> That is why I say that byte streams are essentially big endian.  It is
> all a matter of how you look at it.

It is nothing of the sort.  Some byte streams are in fact, little
endian: when the bytes are combined into larger objects, the least-
significant byte in the object comes first.  A lot of industrial/
embedded stuff has byte streams with LSB leading in the sequence, CAN
comes to mind as an example.

The only way to know is for the standard describing the stream to tell
you what to do.

>
> I prefer to look at all data as endian even if it doesn't create
> endian issues because it forces me to consider any endian issues that
> might arise.  If none do, I haven't really lost anything.  
> If you simply assume that any byte sequence cannot have endian issues you 
> ignore the
> possibility that such issues might not arise.

No, you must assume nothing unless you're told how to combine the
bytes within a sequence into a larger element.  Plus, not all byte
streams support such operations!  Some byte streams really are just a
sequence of bytes and the bytes within the stream cannot be
meaningfully combined into larger data types. If I give you a series
of 8-bit (so 1 byte) samples from an analog-to-digital converter, tell
me how to combine them into a 16, 32, or 64-bit integer.  You cannot
do it without altering the meaning of the samples; it is a completely
non-nonsensical operation.

Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: move to end, in Python 3.2 Really?

[Grant Edwards]

On 2011-01-19, geremy condra  wrote:
> On Tue, Jan 18, 2011 at 3:54 PM, rantingrick  wrote:
>>
>> And were the hell is Steve Holden? Why has he not weighed in on these
>> (or any) discussions. He (Steve Holden) is second in command to the
>> entire community. Yet we have yet to hear a peep from this fella. What
>> gives Steve?
>>
>> And if Steve is too busy, who is next in the chain of command? Who is
>> going to take responsibility for this catastrophe we call c.l.py? Is
>> there no one is man enough to step up for this community? Are all of
>> our leaders just sticking their heads in the sand hoping for this to
>> "solve" itself?
>
> There's no chain of command here, genius. It's a mailing list.

And an unmoderated Usenet newsgroup (which has even less of a chain of
command than a mailing list).

-- 
Grant Edwards   grant.b.edwardsYow! I hope something GOOD
  at   came in the mail today so
  gmail.comI have a REASON to live!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 question from Dive into Python 3

[Tim Harig]

On 2011-01-19, Adam Skutt  wrote:
> On Jan 19, 9:00 am, Tim Harig  wrote:
>> That is why I say that byte streams are essentially big endian.  It is
>> all a matter of how you look at it.
>
> It is nothing of the sort.  Some byte streams are in fact, little
> endian: when the bytes are combined into larger objects, the least-
> significant byte in the object comes first.  A lot of industrial/
> embedded stuff has byte streams with LSB leading in the sequence, CAN
> comes to mind as an example.

You are correct.  Point well made.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 question from Dive into Python 3

[Tim Harig]

On 2011-01-19, Antoine Pitrou  wrote:
> On Wed, 19 Jan 2011 14:00:13 + (UTC)
> Tim Harig  wrote:
>> UTF-8 has no apparent endianess if you only store it as a byte stream.
>> It does however have a byte order.  If you store it using multibytes
>> (six bytes for all UTF-8 possibilites) , which is useful if you want
>> to have one storage container for each letter as opposed to one for
>> each byte(1)
>
> That's a ridiculous proposition. Why would you waste so much space?

Space is only one tradeoff.  There are many others to consider.  I have
created data structures with much higher overhead than that because
they happen to make the problem easier and significantly faster for the
operations that I am performing on the data.

For many operations, it is just much faster and simpler to use a single
character based container opposed to having to process an entire byte
stream to determine individual letters from the bytes or to having
adaptive size containers to store the data.

> UTF-8 exists *precisely* so that you can save space with most scripts.

UTF-8 has many reasons for existing.  One of the biggest is that it
is compatible for tools that were designed to process ASCII and other
8bit encodings.

> If you are ready to use 4+ bytes per character, just use UTF-32 which
> has much nicer properties.

I already mentioned UTF-32/UCS-4 as a probable alternative; but, I might
not want to have to worry about converting the encodings back and forth
before and after processing them.  That said, and more importantly, many
variable length byte streams may not have alternate representations as
unicode does.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
On Jan 18, 3:23 pm, "Octavian Rasnita"  wrote:
> From: "Alexander Kapps" 
>
> > Tkinter causes damage? Very bad damage? What are you talking about?
>
> I am talking about the fact that Python promotes Tkinter, and many beginners 
> will start using it, and they will start creating applications with it, and 
> they will learn to use it better than WxPython, and they will start believing 
> that Tkinter is better because it is easier to use than WxPython, so they 
> will start convincing others that Tkinter is the best, and they will start 
> finding many reasons that show that Tkinter is better. And after this, they 
> will say that they don't care about the real problems generated by GUIs like 
> Tk.
> And a very big problem is that the applications that use Tk/GTK are not 
> accessible for screen readers, so those applications will be just blank for 
> people with visual impairments which need to use a screen reader.

> If you want functional accessibility support, you're going to have to
> write it in Python yourself, and get the accessibility manufacturers
> to support it.  All of the cross-platform toolkits have poor to non-
> existent accessibility support.  Accessibility issues aren't going to
> be fixed by going to a different GUI toolkit in the standard library.


Not true. WxPython uses wxWIDGETS which uses the default OS widgets which 
usually offer the accessibility features.
(At least under Windows, but most users that need accessibility use Windows 
anyway).


> The alternative is to fix the accessibility support issues in the
> underlying library, and Tk is no less amenable to that than
> wxWidgets.  If that's what you want, start coding then.  You have a
> long climb ahead of you.

The underlying libraries for Windows offer the necessary accessibility and 
WxPython uses it, but Tkinter uses Tk not those libraries.

> Accessibility will never be a particular good argument for switching
> toolkits.  All of the cross-platform offerings with Python bindings
> are far too broken to be even remotely interesting.


WxPython is not perfect but most of the objects it offers are accessible so 
this is not true. Only Tk and GTK are bad.

> Why do we like the portable GUIS and don't really like the native interfaces 
> that don't work on other platforms?
> Because we want our programs to be usable by as many people as possible. 
> Well, some platforms render the output as sound and Tkinter are not 
> "portable" on those platforms (screen readers).

> Or we have cross-platform support as a requirement and no desire to
> develop the GUI interface three times over.  Hence the continued
> popularity of Java GUIs.


Java GUIS are accessible. Maybe that's the reason.
SWT offers the same kind of accessibility as WxPython and for SWING there is 
Java Access Bridge. So they are not as accessible as the native Windows GUI 
objects, but they are accessible, unlike Tk and GTK which are not.

Octavian

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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
On Jan 19, 1:37 am, "Octavian Rasnita"  wrote:
>
> Most of the programmers don't know that and they don't even need to know
> that, but if a lib that create accessible GUIS would be promoted, most of
> the Python programmers would use that lib and would create good apps by
> default, without even knowing this.

> Have you written an accessible application in any toolkit whatsoever?
> It is not magic, and it does not happen by default, even when solely
> using the standard widgets.
> 
> Adam



Of course I did. Using WxPerl, Win32::GUI Perl module, SWT and DotNet.
(And without doing absolutely anything special for making them accessible).

But it is very simple to test this. You can download a demo version of JAWS 
screen reader from
www.freedomscientific.com
that will run for 40 minutes or so and then you will need to reboot the 
computer to make it work again.

It is the most used and most powerful screen reader. You will be able to see 
how accessible (or not accessible) are the applications made with any GUI lib.

Octavian

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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Mark Roseman" 
> Octavian,
> 
> Thank you for clearly articulating your concern that Tk does not provide 
> any support for screen readers.
> 
> While I believe that people can have legitimate differences of opinion 
> as to whether this merits its removal/replacement from stdlib, there is 
> no question that this is a serious and significant limitation of Tk.
> 
> I will attempt to find out if there has been any work done in this area 
> with Tk, and what it would take to address this important issue.
> 
> Thanks again
> Mark


Thank you Mark. I don't have anything against Tk, Gtk or QT or other GUI libs, 
but I just shown why some interfaces are much better than others, for very 
important reasons, which unfortunately can't be seen, so many programmers don't 
know about them and promote the discrimination without wanting to do that.

Octavian

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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
On Jan 19, 1:37 am, "Octavian Rasnita"  wrote:
>
> The users shouldn't want something better. Everyone should create GUIs which
> are accessible for everyone by default, without making any special effort
> for doing this.

> Accessibility always requires special effort, and I don't see how
> changing toolkits gets away from this.
> 
> Adam



This is the most false thing I ever heard and the most dangerous.
The GUIS like wxWIDGETS and SWT (at least under Windows), Win32 GUI, MFC, 
WindowsForms (.Net), are accessible out of the box and they don't require any 
effort from the programmer. The programmer doesn't even know that the 
application will also offer accessibility features.
Java SWING is not accessible out of the box, but Sun offers Java Access Bridge, 
a program which can be installed by the user which needs accessibility, so 
finally SWING GUIS are also pretty accessible (also without any effort from the 
programmer).

(Which is not the case of Tk, Gtk and QT.)

Octavian


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

Re: UTF-8 question from Dive into Python 3

[Antoine Pitrou]

On Wed, 19 Jan 2011 16:03:11 + (UTC)
Tim Harig  wrote:
> 
> For many operations, it is just much faster and simpler to use a single
> character based container opposed to having to process an entire byte
> stream to determine individual letters from the bytes or to having
> adaptive size containers to store the data.

You *have* to "process the entire byte stream" in order to determine
boundaries of individual letters from the bytes if you want to use a
"character based container", regardless of the exact representation.
Once you do that it shouldn't be very costly to compute the actual code
points. So, "much faster" sounds a bit dubious to me; especially if you
factor in the cost of memory allocation, and the fact that a larger
container will fit less easily in a data cache.

> That said, and more importantly, many
> variable length byte streams may not have alternate representations as
> unicode does.

This whole thread is about UTF-8 (see title) so I'm not sure what kind
of relevance this is supposed to have.


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

Re: __pycache__, one more good reason to stck with Python 2?

[jmfauth]

My "nightmare" was mainly due, because when I read the
the "What's new?", I did not understand too much this
caching stuff. It's only later, after testing some
applications, I really got the surprise to understand
it. (Py3.1 and Py3.2 pyc's mixture).

Having said this, to tell you the truth. I do really
not feel comfortable with it -- two "working directories",
a subdir in a working dir containing only a few scripts,
filenames, cache multiplications (I would have 1202 caches
on my hd now).

There are certainly advantages, just wondering if the
balance is positive ou negative.

Just for the story, I'm already somwehow experencing some
funny stuff. My test working dir has already a full bloated
cache. You may argue, that's my fault. I may reply: bof,
that Python which is doing it...)

(As a Windows users, I just wondering how this will
impact tools like py2exe or cx_freeze).

-

Antoine Pitrou

Yes, I can launch a pyc, when I have a single file.
But what happens, if one of your cached .pyc file import
a module with a name as defined in the parent directory?
The machinery is broken. The parent dir is not in the
sys.path.

(Unless I'm understanding nothing or I have done a huge
mistake in my tests).

jmf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)

[Octavian Rasnita]

From: 
> Mark/Octavian,
> 
> It sounds like Tka11y (spelled with the digit '1' vs. the letter 'L')
> addresses this problem for Linux users.
> 
> According to its website, adding accessability support is as simple as
> changing one import statement.
> 
> Details follow my signature.
> 
> Malcolm
> 
> 
> Tka11y - Tk Accessibility
> http://tkinter.unpythonic.net/wiki/Tka11y
> 
> 
> Note: Currently, accessibility is only available via ATK <=> AT-SPI on
> Linux. Sorry, no Windows MSAA support.


This project is good, a step ahead, but in order to be really useful it should 
be the one provided by the default Python package.
And of course, it should also offer support for Windows, since most of the 
computer users use Windows, especially those who need accessibility features.

Octavian





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

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 19, 10:41 am, "Octavian Rasnita"  wrote:
>
> Not true. WxPython uses wxWIDGETS which uses the default OS widgets which 
> usually offer the accessibility features.
> (At least under Windows, but most users that need accessibility use Windows 
> anyway).
>

Right, under Windows, which is a problem.  By your line of reasoning,
you really should be supporting PySide / PyQt and not wxWidgets, since
they at least play at cross-platform support.

> > The alternative is to fix the accessibility support issues in the
> > underlying library, and Tk is no less amenable to that than
> > wxWidgets.  If that's what you want, start coding then.  You have a
> > long climb ahead of you.
>
> The underlying libraries for Windows offer the necessary accessibility and 
> WxPython uses it, but Tkinter uses Tk not those libraries.

wxWidgets' support is completely inadequate for a true cross-platform
system, the developers are aware of this and acknowledge this and
believe a rewrite is necessary.  Thus, it is currently really in no
better state than Tk.

> > Or we have cross-platform support as a requirement and no desire to
> > develop the GUI interface three times over.  Hence the continued
> > popularity of Java GUIs.
>
> Java GUIS are accessible. Maybe that's the reason.

No, the reason is as I stated, no more, no less.  Accessibility
doesn't enter into most designs.

Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 19, 11:09 am, "Octavian Rasnita"  wrote:
> From: "Adam Skutt" 
> > Accessibility always requires special effort, and I don't see how
> > changing toolkits gets away from this.

>
> This is the most false thing I ever heard and the most dangerous.

O RLY?  http://www.wxwidgets.org/docs/technote/wxaccesstips.htm sure
looks like there's a whole host of things that I, the application
programmer, must do manually to enable an accessible application[1].
I can't just plop down controls and have an accessible application.

> The programmer doesn't even know that the application will also offer 
> accessibility features.

No, accessibility requires consideration in the design and
implementation of the GUIs, in all of those toolkits.  It is not
transparent, nor can it be transparent.  It requires both
consideration when laying out the widgets, but also ensuring that the
widgets have specific properties set.  How many applications have you
ever used that had focus order bugs?  That's an accessibility issue
that requires programmer intervention to get right.

Adam

[1] That list is not comprehensive by a long shot.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Grant Edwards]

On 2011-01-19, Octavian Rasnita  wrote:
> From: "Adam Skutt" 

>> If you want functional accessibility support, you're going to have to
>> write it in Python yourself, and get the accessibility manufacturers
>> to support it.  All of the cross-platform toolkits have poor to non-
>> existent accessibility support.  Accessibility issues aren't going to
>> be fixed by going to a different GUI toolkit in the standard library.
>
>
> Not true. WxPython uses wxWIDGETS which uses the default OS widgets

There's no such thing as "default OS widgets" on Linux/Unix/BSD/etc.

> which usually offer the accessibility features. (At least under
> Windows, but most users that need accessibility use Windows anyway).

[...]

> WxPython is not perfect but most of the objects it offers are
> accessible so this is not true. Only Tk and GTK are bad.

On all of my computers, wxPython uses Gtk.  There are other choices
for wxWidget backends on Linux, but Gtk is by far the most common.
IOW, if Gtk is bad, then wxPython is bad.

-- 
Grant Edwards   grant.b.edwardsYow! People humiliating
  at   a salami!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[geremy condra]

On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita  wrote:
> From: "Stefan Behnel" 
>>
>> Octavian Rasnita, 19.01.2011 07:10:
>>>
>>> aren't the Pyton bytecode-compiled files considered secure enough?
>>> Can they be easily decompiled?
>>
>> Yes.
>>
>> Stefan
>>
>
>
> Would it be hard to introduce the possibility of adding encryption of the
> bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for
> Perl?
>
> Octavian

The iron law of cryptography: there is no cryptographic solution to a
problem in which the attacker and intended recipient are the same
person.

Schemes like this are at most an annoyance to people willing to
reverse engineer your code.

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Detecting Remaining Thread

[Damian Johnson]

Hi, I've been trying to track down a familiar concurrency problem
without any success:
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

I realize that this is due to a background thread still being alive
and kicking when the application terminates (ie, a missing join() on a
helper thread). However, threading.enumerate() is reporting that
nothing except for the main thread is running at that point:
1/19/2011 09:30:41 [INFO] Arm is shutting down. Remaining threads:
[<_MainThread(MainThread, started -1217079616)>]

What other methods are there for troubleshooting this sort of issue?
I've triple checked that my threads are daemons and joined when
quitting but I must be missing something...

As would be expected of a timing issue, this happens intermittently
(1/5 of the time) and goes away if I add a short sleep at the end. Any
help would be much appreciated. Thanks! -Damian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

[Sherm Pendley]

H₂0.py  writes:

> On Jan 18, 4:04 am, Peter Otten <__pete...@web.de> wrote:
>>
>> What's the advantage of 'find ... | xargs ...' over 'find ... -exec ...'?
>
> Portability. Running the '-exec' version will work fine in a directory
> with a relatively small number of files, but will fail on a large one.

How? -exec passes each file name to a separate invocation of the given
command - it doesn't build one large command line with multiple args.

sherm--

-- 
Sherm Pendley
   
Cocoa Developer
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

[Antoine Pitrou]

On Wed, 19 Jan 2011 08:30:12 -0800 (PST)
jmfauth  wrote:
> Yes, I can launch a pyc, when I have a single file.
> But what happens, if one of your cached .pyc file import
> a module with a name as defined in the parent directory?
> The machinery is broken. The parent dir is not in the
> sys.path.

Well, you don't have to launch a pyc file anyway. Put all your code in
some (pyc) modules on the standard Python path, and use a clear-text
script with some trivial code to invoke a function from the compiled
modules.

Otherwise you can customize sys.path a little from your script,
using __file__ and os.path.dirname. Nothing complicated AFAICT.

(by the way, the fact that pyc files are version-specific should
discourage any use outside of version-specific directories,
e.g. /usr/lib/pythonX.Y/site-packages)

Regards

Antoine.


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

Re: UTF-8 question from Dive into Python 3

[Tim Harig]

On 2011-01-19, Antoine Pitrou  wrote:
> On Wed, 19 Jan 2011 16:03:11 + (UTC)
> Tim Harig  wrote:
>> 
>> For many operations, it is just much faster and simpler to use a single
>> character based container opposed to having to process an entire byte
>> stream to determine individual letters from the bytes or to having
>> adaptive size containers to store the data.
>
> You *have* to "process the entire byte stream" in order to determine
> boundaries of individual letters from the bytes if you want to use a
> "character based container", regardless of the exact representation.

Right, but I only have to do that once.  After that, I can directly address
any piece of the stream that I choose.  If I leave the information as a
simple UTF-8 stream, I would have to walk the stream again, I would have to
walk through the the first byte of all the characters from the beginning to
make sure that I was only counting multibyte characters once until I found
the character that I actually wanted.  Converting to a fixed byte
representation (UTF-32/UCS-4) or separating all of the bytes for each
UTF-8 into 6 byte containers both make it possible to simply index the
letters by a constant size.  You will note that Python does the former.

UTF-32/UCS-4 conversion is definitly supperior if you are actually
doing any major but it adds the complexity and overhead of requiring
the bit twiddling to make the conversions (once in, once again out).
Some programs don't really care enough about what the data actually
contains to make it worth while.  They just want to be able to use the
characters as black boxes.

> Once you do that it shouldn't be very costly to compute the actual code
> points. So, "much faster" sounds a bit dubious to me; especially if you

You could I suppose keep a separate list of pointers to each letter so that
you could use the pointer list for indexing or keep a list of the
character sizes so that you can add them and calculate the variable width
index; but, that adds overhead as well.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 question from Dive into Python 3

[Antoine Pitrou]

On Wed, 19 Jan 2011 18:02:22 + (UTC)
Tim Harig  wrote:
> On 2011-01-19, Antoine Pitrou  wrote:
> > On Wed, 19 Jan 2011 16:03:11 + (UTC)
> > Tim Harig  wrote:
> >> 
> >> For many operations, it is just much faster and simpler to use a single
> >> character based container opposed to having to process an entire byte
> >> stream to determine individual letters from the bytes or to having
> >> adaptive size containers to store the data.
> >
> > You *have* to "process the entire byte stream" in order to determine
> > boundaries of individual letters from the bytes if you want to use a
> > "character based container", regardless of the exact representation.
> 
> Right, but I only have to do that once.

You only have to decode once as well.

> If I leave the information as a
> simple UTF-8 stream,

That's not what we are talking about. We are talking about the supposed
benefits of your 6-byte representation scheme versus proper decoding
into fixed width code points.

> UTF-32/UCS-4 conversion is definitly supperior if you are actually
> doing any major but it adds the complexity and overhead of requiring
> the bit twiddling to make the conversions (once in, once again out).

"Bit twiddling" is not something processors are particularly bad at.
Actually, modern processors are much better at arithmetic and logic
than at recovering from mispredicted branches, which seems to suggest
that discovering boundaries probably eats most of the CPU cycles.

> Converting to a fixed byte
> representation (UTF-32/UCS-4) or separating all of the bytes for each
> UTF-8 into 6 byte containers both make it possible to simply index the
> letters by a constant size.  You will note that Python does the
> former.

Indeed, Python chose the wise option. Actually, I'd be curious of any
real-world software which successfully chose your proposed approach.


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

Re: Tkinter: The good, the bad, and the ugly!

[patty]

> On Jan 18, 9:54 pm, Adam Skutt  wrote:
>> On Jan 18, 9:27 pm, Corey Richardson  wrote:
>> At which point, it's pretty damn
>> small.  Not as small as all of the Tk functionality, I think, but well
>> under 10MiB compressed.
>
> Yea but look at all your gaining. I would rather sacrifice a few megs
> for the rich functionality and scalability any day.
>
>
>> The problem to me isn't the size (though some might find it
>> objectionable), but the system dependencies you have to take:
>> wxWidgets requires GTK+ on UNIX
>
> UNIX? are you kidding? Even if these dependancies are needed the
> "UNIX" folks are damn capable of finding and installing them with
> great ease. Besides most ship with this out the box already! We are
> not talking about the lemmings who use windows or even the weekend
> linuxers here. If they are using UNIX then there is no need for "hand
> holding".
>
>> , which requires a whole mess of crap
>> in term, plus swig, plus whatever else I may or may not be missing.
>
> Thats quite an exaggeration Adam.
>
>> I'm also not 100% certain as to whether it's as portable as Tk is
>> today.
>
> Wx is just as portable as Tk
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>

Now I think I understand a little better where you all are coming from --
I am a Unix person and I guess I expected to have to learn GUI's using
whatever is provided for me by default. Which isn't a bad thing.   And if
I had to add additional software - and learn that - so be it.  I am using
a Windows XP system and a Windows 7 system presently.  Some day I would
like to switch out the Windows XP for Unix.

Thanks for the link to the Python page about the various packages, that
was enlightening.

Who or what group is actually in charge of what libraries (and programming
commands/methods such as the Python 3.x rewrite of 'print') goes into
Python?  Is this huge discussion really a few feature requests for
additional libraries to be included for Windows programming?  And aren't
some of these libraries developed by 3rd parties?  And how is that handled
by the people in charge?  Do they have to pay to license it or is this all
freely contributed software?

Patty

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

Re: __pycache__, one more good reason to stck with Python 2?

[jmfauth]

On Jan 19, 7:03 pm, Antoine Pitrou  wrote:
> On Wed, 19 Jan 2011 08:30:12 -0800 (PST)
>
> jmfauth  wrote:
> > Yes, I can launch a pyc, when I have a single file.
> > But what happens, if one of your cached .pyc file import
> > a module with a name as defined in the parent directory?
> > The machinery is broken. The parent dir is not in the
> > sys.path.
>
> Well, you don't have to launch a pyc file anyway. Put all your code in
> some (pyc) modules on the standard Python path, and use a clear-text
> script with some trivial code to invoke a function from the compiled
> modules.

That's not the point. I'm toying. And the "behaviour" from now
is deeply different from what it was.

> Otherwise you can customize sys.path a little from your script,
> using __file__ and os.path.dirname. Nothing complicated AFAICT.

That's not as simple. You have too prepare the py file in such a way,
that it recognizes the path of its ancestor py file. The "home dir"
is no more the same.


> (by the way, the fact that pyc files are version-specific should
> discourage any use outside of version-specific directories,
> e.g. /usr/lib/pythonX.Y/site-packages)

Here we are. I'm just wondering if all this stuff is not just
here in order to satisfy the missmatched Python installation on
*x platforms compared to Windows whre each Python version
lives cleanely in its isolated space. (Please no os war).

jmf



compared to
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Grant Edwards]

On 2011-01-19, geremy condra  wrote:
> On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita  wrote:

>> Would it be hard to introduce the possibility of adding encryption of the
>> bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for
>> Perl?
>
> The iron law of cryptography: there is no cryptographic solution to a
> problem in which the attacker and intended recipient are the same
> person.
>
> Schemes like this are at most an annoyance to people willing to
> reverse engineer your code.

And they somehow usually end up being an annoyance to customers who
are not trying to reverse engineer your code but are merely trying to
use it legally.

-- 
Grant Edwards   grant.b.edwardsYow! I'd like MY data-base
  at   JULIENNED and stir-fried!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 question from Dive into Python 3

[Tim Harig]

On 2011-01-19, Antoine Pitrou  wrote:
> On Wed, 19 Jan 2011 18:02:22 + (UTC)
> Tim Harig  wrote:
>> Converting to a fixed byte
>> representation (UTF-32/UCS-4) or separating all of the bytes for each
>> UTF-8 into 6 byte containers both make it possible to simply index the
>> letters by a constant size.  You will note that Python does the
>> former.
>
> Indeed, Python chose the wise option. Actually, I'd be curious of any
> real-world software which successfully chose your proposed approach.

The point is basically the same.  I created an example because it
was simpler to follow for demonstration purposes then an actual UTF-8
conversion to any official multibyte format.  You obviously have no
other purpose then to be contrary, so we ended up following tangents.

As soon as you start to convert to a multibyte format the endian issues
occur.  For UTF-8 on big endian hardware, this is anti-climactic because
all of the bits are already stored in proper order.  Little endian systems
will probably convert to a native native endian format.  If you choose
to ignore that, that is your perogative.  Have a nice day.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

[Carl Banks]

On Jan 19, 6:42 am, Steven D'Aprano  wrote:
> But having said that, the __pycache__ idea isn't too bad. If you have
> this directory structure:
>
> ./module.py
> ./module.pyc
>
> and import module, the top-level .pyc file will continue to be used.

Nope.  PEP 3147 says it now always uses __pycache__.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[geremy condra]

On Wed, Jan 19, 2011 at 10:22 AM,   wrote:
>
> Now I think I understand a little better where you all are coming from --
> I am a Unix person and I guess I expected to have to learn GUI's using
> whatever is provided for me by default. Which isn't a bad thing.   And if
> I had to add additional software - and learn that - so be it.  I am using
> a Windows XP system and a Windows 7 system presently.  Some day I would
> like to switch out the Windows XP for Unix.

Just dual boot, it isn't hard.

> Thanks for the link to the Python page about the various packages, that
> was enlightening.
>
> Who or what group is actually in charge of what libraries (and programming
> commands/methods such as the Python 3.x rewrite of 'print') goes into
> Python?

Python's developers. There isn't really any other formal structure beyond that.

>  Is this huge discussion really a few feature requests for
> additional libraries to be included for Windows programming?

No, it's about other operating systems too, but what it comes down to
is that rantingrick has been on the warpath about tkinter for a while,
and hasn't proposed a particularly viable alternative. The sad thing
is that if he weren't so unhinged his proposal would probably fare
much better- I know I

>  And aren't some of these libraries developed by 3rd parties?

Any library to replace tkinter would come from a third party, yes.

>And how is that handled by the people in charge?

Again, there aren't really people 'in charge' on this. Whoever wanted
to push for this would have to do the legwork to make sure that the
library on offer was good enough to win a lot of support from the
community, was cross-platform, etc. They'd also have to convince
someone with commit privs that it was a great idea, convince the rest
of the dev group not to oppose it. After that would come the difficult
task of slowly phasing tkinter out, which would involve substantial
long-term commitment.

In other words, whoever wants to push for this is in for a hard,
multi-year slog. Nobody has stepped up to the plate to do any real
work towards that goal.

> Do they have to pay to license it or is this all freely contributed software?

I can't imagine non-free code making it in.

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[geremy condra]

On Wed, Jan 19, 2011 at 11:37 AM, geremy condra  wrote:
> No, it's about other operating systems too, but what it comes down to
> is that rantingrick has been on the warpath about tkinter for a while,
> and hasn't proposed a particularly viable alternative. The sad thing
> is that if he weren't so unhinged his proposal would probably fare
> much better- I know I

Sorry for the truncation. I was going to say that I know I would be
more supportive of it if he was building support for something instead
of tearing everything else down.

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 question from Dive into Python 3

[Antoine Pitrou]

On Wed, 19 Jan 2011 19:18:49 + (UTC)
Tim Harig  wrote:
> On 2011-01-19, Antoine Pitrou  wrote:
> > On Wed, 19 Jan 2011 18:02:22 + (UTC)
> > Tim Harig  wrote:
> >> Converting to a fixed byte
> >> representation (UTF-32/UCS-4) or separating all of the bytes for each
> >> UTF-8 into 6 byte containers both make it possible to simply index the
> >> letters by a constant size.  You will note that Python does the
> >> former.
> >
> > Indeed, Python chose the wise option. Actually, I'd be curious of any
> > real-world software which successfully chose your proposed approach.
> 
> The point is basically the same.  I created an example because it
> was simpler to follow for demonstration purposes then an actual UTF-8
> conversion to any official multibyte format.  You obviously have no
> other purpose then to be contrary [...]

Right. You were the one who jumped in and tried to lecture everyone on
how UTF-8 was "big-endian", and now you are abandoning the one esoteric
argument you found in support of that.

> As soon as you start to convert to a multibyte format the endian issues
> occur.

Ok. Good luck with your "endian issues" which don't exist.


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

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Tim Delaney]

On 20 January 2011 06:16, Grant Edwards  wrote:

> On 2011-01-19, geremy condra  wrote:
> > On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita 
> wrote:
>
> >> Would it be hard to introduce the possibility of adding encryption of
> the
> >> bytecode similar to what the Zend encoder does for PHP or Filter::Crypto
> for
> >> Perl?
> >
> > The iron law of cryptography: there is no cryptographic solution to a
> > problem in which the attacker and intended recipient are the same
> > person.
> >
> > Schemes like this are at most an annoyance to people willing to
> > reverse engineer your code.
>
> And they somehow usually end up being an annoyance to customers who
> are not trying to reverse engineer your code but are merely trying to
> use it legally.


Absolutely.

If you feel you absolutely *must* obfuscate your object code more than the
python bytecode, just put it all into a separate module and compile it with
Cython . Then you end up with machine-specific object
code which is somewhat harder to reverse engineer for most people (but quite
a few people are experts at doing so).

As a bonus, Cython might speed it up too.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Patty]

- Original Message - 
From: "geremy condra" 

To: 
Cc: "rantingrick" ; 
Sent: Wednesday, January 19, 2011 11:37 AM
Subject: Re: Tkinter: The good, the bad, and the ugly!


On Wed, Jan 19, 2011 at 10:22 AM,   wrote:


Now I think I understand a little better where you all are coming from --
I am a Unix person and I guess I expected to have to learn GUI's using
whatever is provided for me by default. Which isn't a bad thing. And if
I had to add additional software - and learn that - so be it. I am using
a Windows XP system and a Windows 7 system presently. Some day I would
like to switch out the Windows XP for Unix.


Just dual boot, it isn't hard.


True.  I have a Compaq Presario that is so old hardware-wise that I don't 
think it could handle Unix or Linux.



Thanks for the link to the Python page about the various packages, that
was enlightening.

Who or what group is actually in charge of what libraries (and programming
commands/methods such as the Python 3.x rewrite of 'print') goes into
Python?


Python's developers. There isn't really any other formal structure beyond 
that.



Is this huge discussion really a few feature requests for
additional libraries to be included for Windows programming?


No, it's about other operating systems too, but what it comes down to
is that rantingrick has been on the warpath about tkinter for a while,
and hasn't proposed a particularly viable alternative. The sad thing
is that if he weren't so unhinged his proposal would probably fare
much better- I know I


And aren't some of these libraries developed by 3rd parties?


Any library to replace tkinter would come from a third party, yes.


And how is that handled by the people in charge?


Again, there aren't really people 'in charge' on this. Whoever wanted
to push for this would have to do the legwork to make sure that the
library on offer was good enough to win a lot of support from the
community, was cross-platform, etc. They'd also have to convince
someone with commit privs that it was a great idea, convince the rest
of the dev group not to oppose it. After that would come the difficult
task of slowly phasing tkinter out, which would involve substantial
long-term commitment.

In other words, whoever wants to push for this is in for a hard,
multi-year slog. Nobody has stepped up to the plate to do any real
work towards that goal.


Do they have to pay to license it or is this all freely contributed 
software?


I can't imagine non-free code making it in.

Geremy Condra


From my past experience - I think you are right, this is the course of 

events that
would have to happen and yes, it would literally take years.

Patty


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

Re: Tkinter: The good, the bad, and the ugly!

[Emile van Sebille]

On 1/19/2011 11:37 AM geremy condra said...

On Wed, Jan 19, 2011 at 10:22 AM,  wrote:



  And aren't some of these libraries developed by 3rd parties?


Any library to replace tkinter would come from a third party, yes.


And how is that handled by the people in charge?


Again, there aren't really people 'in charge' on this. Whoever wanted
to push for this would have to do the legwork to make sure that the
library on offer was good enough to win a lot of support from the
community, was cross-platform, etc. They'd also have to convince
someone with commit privs that it was a great idea, convince the rest
of the dev group not to oppose it.


... and that they'd forevermore support it, which is likely to be as 
much of an obstacle.  I suspect that's why even established libraries 
like PIL, numpy, mxDateTime or win32all never made it into the standard 
library.


Emile

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

Re: __pycache__, one more good reason to stck with Python 2?

[Steven D'Aprano]

On Wed, 19 Jan 2011 16:00:20 +0100, Antoine Pitrou wrote:
 
>> .pyc files are Python byte-code. You can't run them directly using
>> Python (except via the import machinery), you can't run them as a
>> script, they're not machine code. Unless you write a wrapper to import
>> the file as a module, you can't directly execute .pyc files.
> 
> It seems to work here:

[snip incantation]

Then I stand corrected, thank you.

I know I've seen problems executing .pyc files from the shell in the 
past... perhaps I was conflating details of something else. Ah, I know!

[steve@sylar ~]$ chmod u+x toto.pyc
[steve@sylar ~]$ ./toto.pyc
: command not found ��
./toto.pyc: line 2: syntax error near unexpected token `('
./toto.pyc: line 2: `P7Mc@s dGHdS(tfooNs./
toto.pys'



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Octavian Rasnita]

From: "geremy condra" 
> On Wed, Jan 19, 2011 at 2:31 AM, Octavian Rasnita  wrote:
>> From: "Stefan Behnel" 
>>>
>>> Octavian Rasnita, 19.01.2011 07:10:

 aren't the Pyton bytecode-compiled files considered secure enough?
 Can they be easily decompiled?
>>>
>>> Yes.
>>>
>>> Stefan
>>>
>>
>>
>> Would it be hard to introduce the possibility of adding encryption of the
>> bytecode similar to what the Zend encoder does for PHP or Filter::Crypto for
>> Perl?
>>
>> Octavian
> 
> The iron law of cryptography: there is no cryptographic solution to a
> problem in which the attacker and intended recipient are the same
> person.
> 
> Schemes like this are at most an annoyance to people willing to
> reverse engineer your code.
> 
> Geremy Condra


I don't know how the Python bytecode works... how it is executed.

I thought that Python parses the .py file and generates the bytecode that 
doesn't contain all the necessary information for re-creating the source code.
(But that I agree, that might mean real compilation which is not the case...)

Octavian




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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
> wxWidgets' support is completely inadequate for a true cross-platform
> system, the developers are aware of this and acknowledge this and
> believe a rewrite is necessary.  Thus, it is currently really in no
> better state than Tk.

It depends on what you mean by a "true cross-platform" system. wxWIDGETS run on 
more platforms, so it is cross-platform and it is also accessible for more 
categories of users.
Other systems are bad not only because they are not accessible for everyone, 
but also because they don't use the underlying GUI of the operating system they 
are used on, so they have a different look and feel. Even the accessibility, 
the possibility of accessing the GUIs with a keyboard also means look and feel.

> > Or we have cross-platform support as a requirement and no desire to
> > develop the GUI interface three times over. Hence the continued
> > popularity of Java GUIs.
>
> Java GUIS are accessible. Maybe that's the reason.

> No, the reason is as I stated, no more, no less.  Accessibility
> doesn't enter into most designs.

Which are those "most designs"? I've shown you that the most used GUIS are made 
to be accessible out of the box and all the GUIS should offer these facilities.

Octavian

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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Grant Edwards" 
> On 2011-01-19, Octavian Rasnita  wrote:
>> From: "Adam Skutt" 
> 
>>> If you want functional accessibility support, you're going to have to
>>> write it in Python yourself, and get the accessibility manufacturers
>>> to support it.  All of the cross-platform toolkits have poor to non-
>>> existent accessibility support.  Accessibility issues aren't going to
>>> be fixed by going to a different GUI toolkit in the standard library.
>>
>>
>> Not true. WxPython uses wxWIDGETS which uses the default OS widgets
> 
> There's no such thing as "default OS widgets" on Linux/Unix/BSD/etc.
> 
>> which usually offer the accessibility features. (At least under
>> Windows, but most users that need accessibility use Windows anyway).
> 
> [...]
> 
>> WxPython is not perfect but most of the objects it offers are
>> accessible so this is not true. Only Tk and GTK are bad.
> 
> On all of my computers, wxPython uses Gtk.  There are other choices
> for wxWidget backends on Linux, but Gtk is by far the most common.
> IOW, if Gtk is bad, then wxPython is bad.


Not true. Gtk is accessible under Linux but it is not accessible under Windows.

I am not talking from the perspective of what the GUI creators say, but about 
the reality.

Adobe and Microsoft say that Flash and Silverlight are accessible because they 
offer accessibility features, but this is practically absolutely unimportant 
for the users, because the current screen readers don't offer support for them, 
so they are hard accessible respectively not accessible.

I don't know why Gtk is not accessible under Windows but it can be accessed 
fine under Linux with Orca screen reader.

Either it doesn't offer the accessibility features in its Windows version, or 
it offers the same thing under Windows but the screen readers that work under 
Windows don't offer support for it.
I'd say that Silverlight is pretty new and it is expected that it is not 
accessible, but Gtk, QT and Tk are old enough but there is no support for them 
yet.
Under Windows there are open source screen readers also, one of them beeing 
NVDA, which is made in Python, so we are not talking only about commercial 
programs that might not offer this support because of a commercial interest, 
however those screen readers don't offer support for those GUIS.

Orca, the most used screen reader used under Linux is also made in Python, but 
under Linux it can access fine the Gtk interface.

So I don't know why, but maybe it is hard for the screen reader manufacturers 
to make them support absolutely all the possible interfaces so they choose to 
support only the most used GUI under each OS.

So the better term would be "the most used GUI type" and not "the default GUI 
type" for each OS.

But I as I said, all these things can be tested using that screen reader I told 
you about.
If you use Windows, and you have an application which is made using QT, Tk or 
Gtk, you can download JAWS from www.freedomscientific.com, install it and try 
to see what you hear when you use that application and you will see that you 
won't hear anything, while in an application that uses wxWIDGETS or standard 
Win32 GUI or MFC, the most used controls are perfectly accessible.

Octavian

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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" On Jan 19, 11:09 am, "Octavian Rasnita" 
 wrote:
> From: "Adam Skutt" 
> > Accessibility always requires special effort, and I don't see how
> > changing toolkits gets away from this.

>
> This is the most false thing I ever heard and the most dangerous.

O RLY?  http://www.wxwidgets.org/docs/technote/wxaccesstips.htm sure
looks like there's a whole host of things that I, the application
programmer, must do manually to enable an accessible application[1].
I can't just plop down controls and have an accessible application.


Well, to be sincere, I thought that you don't care, or even worse, and I am 
sorry because I was thinking that way, but I see that you don't understand what 
accessible means.

A GUI can be more or less accessible and the most accessible is the standard 
Win32 GUI / MFC. wxWIDGETS is not perfect because it has some controls that 
steal the focus and don't allow moving it to another control by using the tab 
key, or it has the HTML widget which is not accessible at all, but the most 
used controls like the buttons, list boxes, list views, text fields, radio 
buttons, check boxes... are perfectly accessible out of the box.

Those rules for creating an accessible application are obvious; like the fact 
that a button need to contain a text label and not only an image, or that an 
image needs to have a tooltip defined, or that a radio button needs to have a 
label attached to it, but all those things can be solved by the programmer and 
usually the programmer create those text labels.

If the programmer doesn't create those labels, the application won't be totally 
inaccessible. The users will tab around and they will hear that there is a 
button without name, or a radio button without name, but the user can use the 
application and by trial and error he/she might learn that the second button 
does this and the third button does that.

But the interfaces created with Tk, Gtk and QT are completely inaccessible.
This means that no object confirms that it got the focus, no text field returns 
the text it contains, and so on. Those applications are like an opened 
notepad.exe program with an empty file in which you try to tab around to move 
the cursor, but of course, nothing happends and you can't find any button, or 
list box in it.
In the Tk applications only the menus are accessible but that's the entire 
accessibility it offers.

> The programmer doesn't even know that the application will also offer 
> accessibility features.

No, accessibility requires consideration in the design and
implementation of the GUIs, in all of those toolkits.  It is not
transparent, nor can it be transparent.  It requires both
consideration when laying out the widgets, but also ensuring that the
widgets have specific properties set.  How many applications have you
ever used that had focus order bugs?  That's an accessibility issue
that requires programmer intervention to get right.

Adam


Yes, those things should be followed for creating a better app, but what I 
wanted to say is that no matter if you do those things or not in a Tk, Gtk or 
QT GUI, they will be useless, because the screen readers can't understand those 
GUIS even they have text labels, and even if you will see a focus rectangle 
around buttons. They don't report that those objects have the focus so the 
screen readers won't speak anything.

Octavian

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

Re: Tkinter: The good, the bad, and the ugly!

[Steven D'Aprano]

On Wed, 19 Jan 2011 12:45:22 -0800, Patty wrote:

> On Wed, Jan 19, 2011 at 10:22 AM,   wrote:
>>
>> Now I think I understand a little better where you all are coming from
>> -- I am a Unix person and I guess I expected to have to learn GUI's
>> using whatever is provided for me by default. Which isn't a bad thing.
>> And if I had to add additional software - and learn that - so be it. I
>> am using a Windows XP system and a Windows 7 system presently. Some day
>> I would like to switch out the Windows XP for Unix.
> 
> Just dual boot, it isn't hard.
> 
> 
> True.  I have a Compaq Presario that is so old hardware-wise that I
> don't think it could handle Unix or Linux.


I think you have that backwards. You can usually run recent Linux on 
*much* older and cruftier hardware than will run recent Windows.

You may have to forgo using the two heavyweight window managers, Gnome 
and KDE, in favour of a lightweight window manager, but some people would 
argue that's a benefit rather than a loss :)

Here's an article that might be of interest:

http://www.desktoplinux.com/articles/AT6185716632.html



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 19, 12:22 pm, pa...@cruzio.com wrote:

> Who or what group is actually in charge of what libraries (and programming
> commands/methods such as the Python 3.x rewrite of 'print') goes into
> Python?  

Well it comes down to "Guido, some Guys, and a mailing list". see this
link fro more detail...

http://www.python.org/dev/intro/



> Is this huge discussion really a few feature requests for
> additional libraries to be included for Windows programming?

No, this HUGE discussion is primarily about the worth of Tkinter as
our chosen GUI module and whether or not we should replace it. It also
contains (and rightly so!) undertones as to the lost vision within
this community as a whole. Not to mention the missing cohesiveness to
move forward in the correct direction.


>  And aren't
> some of these libraries developed by 3rd parties?  

Yes Python has many 3rd party packages available. You should
familiarize yourself with both the current stdlib AND the packages
list. Both are here...

http://pypi.python.org/pypi?:action=index
http://docs.python.org/release/3.0.1/modindex.html


> And how is that handled
> by the people in charge?  Do they have to pay to license it or is this all
> freely contributed software?

This statement needs clarification because i cannot decide if you are
asking from a Python stdlib perspective or a 3rd party package
perspective. In any event Python and the stdlib should be all free and
open software. And shame on anyone who releases closed source
software!

Shame on you greedies! Shame on you! >:(


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

Re: Tkinter: The good, the bad, and the ugly!

[Martin Gregorie]

On Wed, 19 Jan 2011 12:45:22 -0800, Patty wrote:

> - Original Message -
> From: "geremy condra"  To: 
> On Wed, Jan 19, 2011 at 10:22 AM,   wrote:
>>
>> Now I think I understand a little better where you all are coming from
>> -- I am a Unix person and I guess I expected to have to learn GUI's
>> using whatever is provided for me by default. Which isn't a bad thing.
>> And if I had to add additional software - and learn that - so be it. I
>> am using a Windows XP system and a Windows 7 system presently. Some day
>> I would like to switch out the Windows XP for Unix.
> 
> Just dual boot, it isn't hard.
>

IME you'll find that networking a Windows box to an older, slower PC thats 
rescued from the attic will be much more useful than a single dual-boot 
arrangement. 

Linux will run at a usable speed on a PC with 512 MB RAM  and an 866 MHz 
P3, though some things, such as logging in, will be slow with a graphical 
desktop (runlevel 5), but if it has more RAM or you run an X-server on 
another PC, which could be running Windows, you'll execute commands, 
including graphical ones - provided you have X.11 forwarding enabled, a 
lot faster. The Linux box can also be headless if you haven't a screen 
and keyboard to spare. In short, Linux will run well on a PC that can't 
run anything more recent than Win98 at an acceptable speed. It doesn't 
need a lot of disk either - anything more than 30 GB will do. However, an 
optical drive is needed for installation. You can install Fedora from a 
CD drive provided the box is networked so it can retrieve most of its 
packages over the net, but using a DVD drive would be easier for a first 
install.
 
> True.  I have a Compaq Presario that is so old hardware-wise that I
> don't think it could handle Unix or Linux.
>
What speed and type of CPU does it use? How much RAM? What's about disk 
and optical drives?

FWIW my house server is an IMB Netvista that is at least 10 years old - 
866MHz P3, 512 GB RAM, LG DVD drive, new 160GB hdd and runs Fedora 13. It 
is a bit slow at runlevel 5 (graphical desktop) when driven from its own 
console, but I usually access it over the house net from a more modern 
Core Duo laptop that runs Fedora 14. The NetVista is more than adequate 
for web and RDBMS development (Apache and PostgreSQL) in Python or Java 
and very fast for C compilation.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __pycache__, one more good reason to stck with Python 2?

[Steven D'Aprano]

On Wed, 19 Jan 2011 11:30:36 -0800, Carl Banks wrote:

> On Jan 19, 6:42 am, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> But having said that, the __pycache__ idea isn't too bad. If you have
>> this directory structure:
>>
>> ./module.py
>> ./module.pyc
>>
>> and import module, the top-level .pyc file will continue to be used.
> 
> Nope.  PEP 3147 says it now always uses __pycache__.


Looks like the PEP is outdated then.

[steve@sylar ~]$ rm __pycache__/*
[steve@sylar ~]$ echo "print('spam spam spam')" > spam.py
[steve@sylar ~]$ python3.2 -m compileall spam.py
Compiling spam.py ...
[steve@sylar ~]$ mv __pycache__/spam.cpython-32.pyc ./spam.pyc
[steve@sylar ~]$ python3.2 -m spam
spam spam spam
[steve@sylar ~]$ ls __pycache__/
[steve@sylar ~]$



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Grant Edwards]

On 2011-01-19, Octavian Rasnita  wrote:
> From: "Grant Edwards" 
>
>>> WxPython is not perfect but most of the objects it offers are
>>> accessible so this is not true. Only Tk and GTK are bad.
>> 
>> On all of my computers, wxPython uses Gtk.  There are other choices
>> for wxWidget backends on Linux, but Gtk is by far the most common.
>> IOW, if Gtk is bad, then wxPython is bad.
>
> Not true.

I think you're playing a bit fast and loose with your accusations.

Which of my statements was "not true"?

 1) On all of my computers wxPython uses Gtk.

 2) There are other backend choices on Linux besides Gtk.

 3) Gtk is by far the most common wxWidgets backend on Linux/Unix.

 4) If Gtk is bad then wxPython is bad.

Note that 4) follows logically from 3), so to say that 4) is "not
true" you have to show that 3) is "not true".

-- 
Grant Edwards   grant.b.edwardsYow! WHOA!!  Ken and Barbie
  at   are having TOO MUCH FUN!!
  gmail.comIt must be the NEGATIVE
   IONS!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)

[Terry Reedy]

On 1/19/2011 11:27 AM, Octavian Rasnita wrote:


Note: Currently, accessibility is only available via ATK<=>  AT-SPI on
Linux. Sorry, no Windows MSAA support.



This project is good, a step ahead, but in order to be really useful it should 
be the one provided by the default Python package.
And of course, it should also offer support for Windows, since most of the 
computer users use Windows, especially those who need accessibility features.


Octavian

Please consider adding an 'Accessibility' page to the Python wiki with 
your info and the above for those interested.


--
Terry Jan Reedy

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

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 19, 3:51 pm, Grant Edwards  wrote:
> On 2011-01-19, Octavian Rasnita  wrote:

> Which of my statements was "not true"?
>
>  1) On all of my computers wxPython uses Gtk.
>
>  2) There are other backend choices on Linux besides Gtk.
>
>  3) Gtk is by far the most common wxWidgets backend on Linux/Unix.
>
>  4) If Gtk is bad then wxPython is bad.
>
> Note that 4) follows logically from 3), so to say that 4) is "not
> true" you have to show that 3) is "not true".

All of these folks that keep blabbing about how they may need "this"
dependency or "that" dependency on Linux/Unix either need to shut up
or convert to a windows box with a nice installer exe that will hold
your wiener while you pee. Really, you're only going to fool the
lemmings with such BS arguments! Stop whining, you choose to use an
advanced OS and stop blaming the rest of the world because of your
choices!

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

Re: __pycache__, one more good reason to stck with Python 2?

[Alice Bevan–McGregor]

On 2011-01-19 13:01:04 -0800, Steven D'Aprano said:
I know I've seen problems executing .pyc files from the shell in the 
past... perhaps I was conflating details of something else. Ah, I know!


[steve@sylar ~]$ chmod u+x toto.pyc
[steve@sylar ~]$ ./toto.pyc
: command not found ��
./toto.pyc: line 2: syntax error near unexpected token `('
./toto.pyc: line 2: `P7Mc@s dGHdS(tfooNs./
toto.pys'


... don't do that.  I do not know why that would be expected to work, 
ever.  (Unless you're crafty and wrap a real shell script around the 
.pyc, in which case it's no longer a .pyc.)


— Alice.


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

Re: UTF-8 question from Dive into Python 3

[Terry Reedy]

On 1/19/2011 1:02 PM, Tim Harig wrote:


Right, but I only have to do that once.  After that, I can directly address
any piece of the stream that I choose.  If I leave the information as a
simple UTF-8 stream, I would have to walk the stream again, I would have to
walk through the the first byte of all the characters from the beginning to
make sure that I was only counting multibyte characters once until I found
the character that I actually wanted.  Converting to a fixed byte
representation (UTF-32/UCS-4) or separating all of the bytes for each
UTF-8 into 6 byte containers both make it possible to simply index the
letters by a constant size.  You will note that Python does the former.


The idea of using a custom fixed-width padded version of a UTF-8 steams 
waw initially shocking to me, but I can imagine that there are 
specialized applications, which slice-and-dice uninterpreted segments, 
for which that is appropriate. However, it is not germane to the folly 
of prefixing standard UTF-8 steams with a 3-byte magic number, 
mislabelled a 'byte-order-mark, thus making them non-standard.


--
Terry Jan Reedy

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

Re: Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 19, 4:04 pm, "Octavian Rasnita"  wrote:
> Those rules for creating an accessible application are obvious; like the fact 
> that a button need to contain a text label and not only an image, or that an 
> image needs to have a tooltip defined, or that a radio button needs to have a 
> label attached to it, but all those things can be solved by the programmer 
> and usually the programmer create those text labels.
>

The fact that /every/ toolkit provides accessibility guidelines over
and above whatever other UI guidelines they provide tells me that
creating an accessible application is hardly obvious.  Plus, if it
were really that simple, the accessibility situation wouldn't be so
poor.

> Yes, those things should be followed for creating a better app, but what I 
> wanted to say is that no matter if you do those things or not in a Tk, Gtk or 
> QT GUI, they will be useless, because the screen readers can't understand 
> those GUIS even they have text labels, and even if you will see a focus 
> rectangle around buttons. They don't report that those objects have the focus 
> so the screen readers won't speak anything.

Your "something is better than nothing" argument isn't particularly
compelling to me personally as a justification for ripping out
TkInter.  And Qt is the only toolkit with some level of functioning
accessibility support on all three major platforms, assuming the
library and software are built correctly, so again, your argument is
really for Qt, not for wxWidgets.

Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Wed, Jan 19, 2011 at 1:40 PM, geremy condra 
wrote:
> On Wed, Jan 19, 2011 at 11:37 AM, geremy condra  wrote:
>> No, it's about other operating systems too, but what it comes down to
>> is that rantingrick has been on the warpath about tkinter for a while,
>> and hasn't proposed a particularly viable alternative. The sad thing
>> is that if he weren't so unhinged his proposal would probably fare
>> much better

Look, the folks are c.l.py are far too touchy and they really need to
lighten up. Really! The fact that my speech style and delivery does
not fit some "cookie cutter" pre-directive is just BS. The Python
community is NOT a homogeneous block you know, and it should not be!
People have said to me in the past..."""Well you could participate at
python-dev or python-ideas or the tracker but NOT as ranting rick, you
need to use a better name"""... What? What does it matter what my name
is anyway. This is just being pedantic!!


> Sorry for the truncation. I was going to say that I know I would be
> more supportive of it if he was building support for something instead
> of tearing everything else down.

I am not "tearing down" anything, however that was a nice try Geremy
*wink*. The only thing that is being "torn down" is the solid wall of
rabid resistance that has been slowly built by this community over
many years. We have become too centralized and many folks are being
left out of the community decision process. You (and others) act like
my only concern is to destroy what has been built (Tkinter) and that
is not the case! But like old governments, YOU (the python elite!)
have lost all vision for the future. And you've also lost all
connection with the people. I am desperately trying to to snap you out
of this psychosis before it is too late! Tkinter will be the downfall
of Python if we cannot muster the resolve to replace it with something
that is current (or more current) technology. Stop fearing change and
re-ignite the vision that GvR once had.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 19, 4:40 pm, Adam Skutt  wrote:
> On Jan 19, 4:04 pm, "Octavian Rasnita"  wrote:
>
> > Those rules for creating an accessible application are obvious; like the 
> > fact that a button need to contain a text label and not only an image, or 
> > that an image needs to have a tooltip defined, or that a radio button needs 
> > to have a label attached to it, but all those things can be solved by the 
> > programmer and usually the programmer create those text labels.
>
> The fact that /every/ toolkit provides accessibility guidelines over
> and above whatever other UI guidelines they provide tells me that
> creating an accessible application is hardly obvious.  Plus, if it
> were really that simple, the accessibility situation wouldn't be so
> poor.
>
> > Yes, those things should be followed for creating a better app, but what I 
> > wanted to say is that no matter if you do those things or not in a Tk, Gtk 
> > or QT GUI, they will be useless, because the screen readers can't 
> > understand those GUIS even they have text labels, and even if you will see 
> > a focus rectangle around buttons. They don't report that those objects have 
> > the focus so the screen readers won't speak anything.
>
> Your "something is better than nothing" argument isn't particularly
> compelling to me personally as a justification for ripping out
> TkInter.  And Qt is the only toolkit with some level of functioning
> accessibility support on all three major platforms, assuming the
> library and software are built correctly, so again, your argument is
> really for Qt, not for wxWidgets.
>
> Adam


Adam, please use the following style when posting to this
group...Thanks.


On Jan 19, 4:04 pm, "Octavian Rasnita"  wrote:
> Those rules for creating an accessible application are obvious; like
> the fact that a button need to contain a text label and not only an
> image, or that an image needs to have a tooltip defined, or that a
> radio button needs to have a label attached to it, but all those
> things can be solved by the programmer and usually the programmer
> create those text labels.

The fact that /every/ toolkit provides accessibility guidelines over
and above whatever other UI guidelines they provide tells me that
creating an accessible application is hardly obvious.  Plus, if it
were really that simple, the accessibility situation wouldn't be so
poor.

> Yes, those things should be followed for creating a better app, but
> what I wanted to say is that no matter if you do those things or not
> in a Tk, Gtk or QT GUI, they will be useless, because the screen
> readers can't understand those GUIS even they have text labels, and
> even if you will see a focus rectangle around buttons. They don't
> report that those objects have the focus so the screen readers won't
> speak anything.

Your "something is better than nothing" argument isn't particularly
compelling to me personally as a justification for ripping out
TkInter.  And Qt is the only toolkit with some level of functioning
accessibility support on all three major platforms, assuming the
library and software are built correctly, so again, your argument is
really for Qt, not for wxWidgets.
Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Patty]

On Jan 19, 12:22 pm, pa...@cruzio.com wrote:

> Who or what group is actually in charge of what libraries (and programming
> commands/methods such as the Python 3.x rewrite of 'print') goes into
> Python? 

Well it comes down to "Guido, some Guys, and a mailing list". see this
link fro more detail...

http://www.python.org/dev/intro/

Well that explains Everything!



> Is this huge discussion really a few feature requests for
> additional libraries to be included for Windows programming?

No, this HUGE discussion is primarily about the worth of Tkinter as
our chosen GUI module and whether or not we should replace it. It also
contains (and rightly so!) undertones as to the lost vision within
this community as a whole. Not to mention the missing cohesiveness to
move forward in the correct direction.


I see why you say this.   I think I am playing catchup with what has been going 
on for some time amongst you all. 


> And aren't
> some of these libraries developed by 3rd parties? 

Yes Python has many 3rd party packages available. You should
familiarize yourself with both the current stdlib AND the packages
list. Both are here...

http://pypi.python.org/pypi?:action=index
http://docs.python.org/release/3.0.1/modindex.html


> And how is that handled
> by the people in charge? Do they have to pay to license it or is this all
> freely contributed software?

This statement needs clarification because i cannot decide if you are
asking from a Python stdlib perspective or a 3rd party package
perspective. In any event Python and the stdlib should be all free and
open software. And shame on anyone who releases closed source
software!

Shame on you greedies! Shame on you! >:(

And I am coming from background working at SCO for commercial SCO Unix and also 
commercial applications software.  So free software is not something I am used 
to :) And understand what is involved with obtaining 3rd party pieces either by 
necessity or because of an acquistion.  And the money part.  It was 
complicated.  So I was thinking from the python stdlib perspective.  But your 
comment turned my thinking around to where it should be to discuss open source 
software. 

 I don't think I am ready for the py-dev mailing list yet ;) But I do have some 
big ideas because of UCSC (University of California, Santa Cruz) being so 
close, their Computer Engineering Dept. is Really Good and I have some 
connections up there.

Patty


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

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

Re: move to end, in Python 3.2 Really?

[rantingrick]

On Jan 19, 9:18 am, Grant Edwards  wrote:

> And an unmoderated Usenet newsgroup (which has even less of a chain of
> command than a mailing list).

Moderated status has nothing to do with it. The fact is that the
"elite" no longer feel it necessary to care about the troubles of the
Python peasants. This is evident by no posting from GvR for many
years, and no posting from his subordinate (and the PSF chair!) Steve
Holden. The last time Steve and i "rubbed shoulders" was when i
chastised him for engaging in trollish behavior. So now i get it... He
has time for trolling and flaming but no time for real discussion on
topics that concern the very future evolution of this language? hmm.

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

Re: move to end, in Python 3.2 Really?

[André]

On Wednesday, January 19, 2011 7:21:53 PM UTC-4, rantingrick wrote:
> On Jan 19, 9:18 am, Grant Edwards  wrote:
> 
> > And an unmoderated Usenet newsgroup (which has even less of a chain of
> > command than a mailing list).
> 
> Moderated status has nothing to do with it. The fact is that the
> "elite" no longer feel it necessary to care about the troubles of the
> Python peasants. This is evident by no posting from GvR for many
> years, and no posting from his subordinate (and the PSF chair!) Steve
> Holden. The last time Steve and i "rubbed shoulders" was when i
> chastised him for engaging in trollish behavior. So now i get it... He
> has time for trolling and flaming but no time for real discussion on
> topics that concern the very future evolution of this language? hmm.

Perhaps it is because they are either busy programming and/or busy organizing 
Pycon 2011.

Some people do a lot, some people talk/write a lot.  It is hard to find the 
time to do both ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Patty]

On Wed, 19 Jan 2011 12:45:22 -0800, Patty wrote:

> - Original Message -
> From: "geremy condra"  To: 
> On Wed, Jan 19, 2011 at 10:22 AM,   wrote:
>>
>> Now I think I understand a little better where you all are coming from
>> -- I am a Unix person and I guess I expected to have to learn GUI's
>> using whatever is provided for me by default. Which isn't a bad thing.
>> And if I had to add additional software - and learn that - so be it. I
>> am using a Windows XP system and a Windows 7 system presently. Some day
>> I would like to switch out the Windows XP for Unix.
> 
> Just dual boot, it isn't hard.
>

IME you'll find that networking a Windows box to an older, slower PC thats 
rescued from the attic will be much more useful than a single dual-boot 
arrangement. 

Linux will run at a usable speed on a PC with 512 MB RAM  and an 866 MHz 
P3, though some things, such as logging in, will be slow with a graphical 
desktop (runlevel 5), but if it has more RAM or you run an X-server on 
another PC, which could be running Windows, you'll execute commands, 
including graphical ones - provided you have X.11 forwarding enabled, a 
lot faster. The Linux box can also be headless if you haven't a screen 
and keyboard to spare. In short, Linux will run well on a PC that can't 
run anything more recent than Win98 at an acceptable speed. It doesn't 
need a lot of disk either - anything more than 30 GB will do. However, an 
optical drive is needed for installation. You can install Fedora from a 
CD drive provided the box is networked so it can retrieve most of its 
packages over the net, but using a DVD drive would be easier for a first 
install.
 
> True.  I have a Compaq Presario that is so old hardware-wise that I
> don't think it could handle Unix or Linux.
>
What speed and type of CPU does it use? How much RAM? What's about disk 
and optical drives?

FWIW my house server is an IMB Netvista that is at least 10 years old - 
866MHz P3, 512 GB RAM, LG DVD drive, new 160GB hdd and runs Fedora 13. It 
is a bit slow at runlevel 5 (graphical desktop) when driven from its own 
console, but I usually access it over the house net from a more modern 
Core Duo laptop that runs Fedora 14. The NetVista is more than adequate 
for web and RDBMS development (Apache and PostgreSQL) in Python or Java 
and very fast for C compilation.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Martin and Geremy - thank you for the suggestions.  My Compaq Presario I know 
is maxed out on memory and I checked and my Maxtor drive says it is 28624 MB.  
I don't know if that is enough?  


I have my HP Mini Netbook running Windows 7 and do my Python programming on it. 
 It is awesome!  I don't really care if my Compaq had Windows XP plus Linux or 
just Linux.  I would be happy to just back up what I want and install Linux for 
the whole Compaq and just have the two communicate.  I really use the Compaq 
more as an email and file archive.  I would probably rethink which software 
programming tools and languages I would want on each machine.

I consider myself a C programmer and SQL and I am a linguist - several 
programming languages - so I would be more likely to want compilers and 
interpreters, favorite IDEs installed on whichever system.  

Patty-- 
http://mail.python.org/mailman/listinfo/python-list

Re: move to end, in Python 3.2 Really?

[rantingrick]

On Jan 19, 5:26 pm, André  wrote:

> Perhaps it is because they are either busy programming and/or busy
> organizing Pycon 2011. Some people do a lot, some people talk/write
> a lot. It is hard to find the time to do both ...

Well perhaps. I am not suggesting that these people are not working on
important issues. I am just pointing out an incident with Steve that
could have been better spent on real discussion and not a flame war.

Look, i am no perfect person and i do not expect that Steve is either.
However attempting to say that somehow my work --engaging the
community through lively debate in an attempt to re-energize the
Python spirit GvR created so long ago that has now waxed cold-- is
somehow less important than Steve's or anyones work is a little
condescending to say the least.

It takes many stones to build a house. And sometimes after you build
the house you find the foundation is cracking. This could be due to
poor planning in the design phase (which is not the case with
Tkinter!!) OR it could be due to soil that is grown unstable (This is
the case with Tkinter!!). Repairing a foundation after the fact is
always going to be hard work but someone has do it. Someone has to
gather the crew and create a battle plan. Well, thats me. However i
cannot do this alone. I need the rest of you guys to share the load.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[geremy condra]

On Wed, Jan 19, 2011 at 3:04 PM, rantingrick  wrote:
>
> On Wed, Jan 19, 2011 at 1:40 PM, geremy condra 
> wrote:
>> On Wed, Jan 19, 2011 at 11:37 AM, geremy condra  wrote:
>>> No, it's about other operating systems too, but what it comes down to
>>> is that rantingrick has been on the warpath about tkinter for a while,
>>> and hasn't proposed a particularly viable alternative. The sad thing
>>> is that if he weren't so unhinged his proposal would probably fare
>>> much better
>
> Look, the folks are c.l.py are far too touchy and they really need to
> lighten up. Really! The fact that my speech style and delivery does
> not fit some "cookie cutter" pre-directive is just BS. The Python
> community is NOT a homogeneous block you know, and it should not be!
> People have said to me in the past..."""Well you could participate at
> python-dev or python-ideas or the tracker but NOT as ranting rick, you
> need to use a better name"""... What? What does it matter what my name
> is anyway. This is just being pedantic!!

I'm not telling you to change your behavior. I'm telling you that the
way you're doing things isn't effective. You can take that advice or
not, just as I can decide to listen to you... or not.

I also wouldn't advise you to change your name again. I think you've
already landed on a couple of spam lists for that.

>> Sorry for the truncation. I was going to say that I know I would be
>> more supportive of it if he was building support for something instead
>> of tearing everything else down.
>
> I am not "tearing down" anything, however that was a nice try Geremy
> *wink*. The only thing that is being "torn down" is the solid wall of
> rabid resistance that has been slowly built by this community over
> many years.

I don't think this is the case, first because you aren't very good at
getting anybody to take you seriously and second because I don't think
that resistance on this issue is as mindless as you claim.

> We have become too centralized and many folks are being
> left out of the community decision process.

I disagree with the first half. The second I'm more prone to agree
with, although I don't have a lot of great ideas about how to solve
the problem. You seem to be full of ideas (most of which I think are
terrible) but very short on actually getting anything done. Until you
begin to remedy that I doubt very many people here will take you as
seriously as you seem to want.

Also, be careful with where you say 'we'- I certainly don't recognize
your authority to speak on behalf of the community, and I suspect that
an overwhelming majority of the community's other members feel the
same way.

> You (and others) act like
> my only concern is to destroy what has been built (Tkinter) and that
> is not the case!

Seems like it from where I'm sitting. YMMV, but I think you would do
much better if you focused on the problem of building a system that
addressed the concerns others have raised rather than pretending they
aren't valid concerns.

> But like old governments, YOU (the python elite!)
> have lost all vision for the future.

Hey, cool, I'm a member of the elite now. You wouldn't happen to know
how to list that on a resume, would you?

> And you've also lost all
> connection with the people. I am desperately trying to to snap you out
> of this psychosis before it is too late! Tkinter will be the downfall
> of Python if we cannot muster the resolve to replace it with something
> that is current (or more current) technology.

Citation needed.

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: move to end, in Python 3.2 Really?

[geremy condra]

On Wed, Jan 19, 2011 at 3:42 PM, rantingrick  wrote:

> Look, i am no perfect person and i do not expect that Steve is either.
> However attempting to say that somehow my work --engaging the
> community through lively debate in an attempt to re-energize the
> Python spirit GvR created so long ago that has now waxed cold-- is
> somehow less important than Steve's or anyones work is a little
> condescending to say the least.

Condescending or not, it's true.

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

collections.Set Binary Reflected Operations

[Chris Kaynor]

I am implemented a custom set-like type which interacts with some
third-party software when retrieving and mutating the set, and have derived
my custom type off of collections.MutableSet, however I have noticed that
some of the magic methods supported by the built-in set do not fully
function with my custom type. From this, I looked over the
MutableSet definition in and it seems to be missing all of the reflected
operators (__rsub__, __rand__, __ror__, __rxor__, and friends) for the
operators it has defined. I can post a simple example case if desired.

I am using Python 2.6.4 (with some in-house customizations), however a quick
look over the svn repository shown on python.org makes it appear that these
are also not implemented in Python 3. I was wondering if there is some
reason for this, or if it was merely an oversight.

Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 19, 6:01 pm, geremy condra  wrote:

> I'm not telling you to change your behavior. I'm telling you that the
> way you're doing things isn't effective. You can take that advice or
> not, just as I can decide to listen to you... or not.
>
> I also wouldn't advise you to change your name again. I think you've
> already landed on a couple of spam lists for that.

Yes i know! The whole "name" issue was blown out of proportion. Look i
think i should explain how this whole name conundrum started. When i
first came to this list you can imagine that i was not prepared to
divulge every detail about my identity and personal life (as most
should not!). So i choose a cryptic and nonsensical name. Yes, i made
it up! And at the time i never had any inclination that i would want
to get so involved with this group. Well that was then and this is
now...

However, after i became "known" within the community many folks
started to debase any of my arguments simply on the fact that my name
was anonymous. So at that time i started using my real name "Rick
Johnson" and my nickname as "rantingrick".  After this people then
accused my of "identity hopping". Even some of the same folks who
previously were complaining about my cryptic first name choice! Now
they were complain that i choose to use my REAL name. Ironic eh!

So what it boils down to is this... some people on this list just hate
me and trying to please them is a waste of time.


> > I am not "tearing down" anything, however that was a nice try Geremy
> > *wink*. The only thing that is being "torn down" is the solid wall of
> > rabid resistance that has been slowly built by this community over
> > many years.
>
> I don't think this is the case, first because you aren't very good at
> getting anybody to take you seriously

How "self absorbed" must someone be to blame *ME* because *THEY*
cannot take *ME* seriously. Is this a joke Geremy? Sadly i know it to
be true however because you are not the only person who carries this
attitude.

> and second because I don't think
> that resistance on this issue is as mindless as you claim.

i have exposed the baseless, nonsensical, and argumentative stance
taken by some in an effort to sway public opinion with FUD and BS. So
i would say that arguing with baseless facts does constitute "rabid
resistance". What else could it be?

> > We have become too centralized and many folks are being
> > left out of the community decision process.
>
> I disagree with the first half. The second I'm more prone to agree
> with, although I don't have a lot of great ideas about how to solve
> the problem.

Well maybe you are not a visionary, however i believe we still need
you in other areas.

> You seem to be full of ideas (most of which I think are
> terrible) but very short on actually getting anything done. Until you
> begin to remedy that I doubt very many people here will take you as
> seriously as you seem to want.

Look, every organization needs workers, visionaries, liaisons,
supervisors, etc. I seem to fit nicely into a Visionary role. Maybe
that bothers you? I don't know? But we all have our place Geremy. Do
you think any organization could survive simply with robotic workers
and no guidance? No, and why not? Because workers cannot see the big
picture. They are too focused (and rightly so) on some small detail
that encompasses their job duty. Only the supervisor/visionary has the
luxury of looking at the problem from a global perspective.

Think of Python-dev as a car. A car is a machine. A very complicated
machine that needs a driver to harness it's power and give it
direction and purpose. -- someone who can see "beyond" the horizon.
Someone who can read a road map and then re-calculate a path if road
construction blocks the current one. Without the car the driver is
nothing, and without the driver the car is nothing. But together, they
are a force to reckoned with. Well, unless the driver is Asian -- then
all bets are off! :-)

> Also, be careful with where you say 'we'- I certainly don't recognize
> your authority to speak on behalf of the community, and I suspect that
> an overwhelming majority of the community's other members feel the
> same way.

You see! This is the resistance i am talking about. You (and others)
don't want to accept me as part of the community. If you did accept
me, then my speaking collectively (we) would not be troubling to you.
However i do not blame you directly for this prejudice. I think it is
more of a sub-conscience undercurrent that pervades this community as
a whole. A fear of outsiders. A xenophobia if you will. We need to
change this now!

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

Re: Detecting Remaining Thread

[Damian Johnson]

Disregard, I figured it out. It turns out that the threads spawned by
"thread.start_new_thread" are unreported by threading.enumerate.
Cheers! -Damian

On Wed, Jan 19, 2011 at 9:40 AM, Damian Johnson  wrote:
> Hi, I've been trying to track down a familiar concurrency problem
> without any success:
> Unhandled exception in thread started by
> Error in sys.excepthook:
>
> Original exception was:
>
> I realize that this is due to a background thread still being alive
> and kicking when the application terminates (ie, a missing join() on a
> helper thread). However, threading.enumerate() is reporting that
> nothing except for the main thread is running at that point:
> 1/19/2011 09:30:41 [INFO] Arm is shutting down. Remaining threads:
> [<_MainThread(MainThread, started -1217079616)>]
>
> What other methods are there for troubleshooting this sort of issue?
> I've triple checked that my threads are daemons and joined when
> quitting but I must be missing something...
>
> As would be expected of a timing issue, this happens intermittently
> (1/5 of the time) and goes away if I add a short sleep at the end. Any
> help would be much appreciated. Thanks! -Damian
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[geremy condra]

On Wed, Jan 19, 2011 at 4:53 PM, rantingrick  wrote:
>> I don't think this is the case, first because you aren't very good at
>> getting anybody to take you seriously
>
> How "self absorbed" must someone be to blame *ME* because *THEY*
> cannot take *ME* seriously. Is this a joke Geremy? Sadly i know it to
> be true however because you are not the only person who carries this
> attitude.

Welcome to real life. You convince people that you're right or they
don't do what you say.

>> and second because I don't think
>> that resistance on this issue is as mindless as you claim.
>
> i have exposed the baseless, nonsensical, and argumentative stance
> taken by some in an effort to sway public opinion with FUD and BS. So
> i would say that arguing with baseless facts does constitute "rabid
> resistance". What else could it be?

Reasoned resistance seen through the eyes of someone whose judgement
should not be trusted.

>> I disagree with the first half. The second I'm more prone to agree
>> with, although I don't have a lot of great ideas about how to solve
>> the problem.
>
> Well maybe you are not a visionary, however i believe we still need
> you in other areas.

Oh, do tell.

>> You seem to be full of ideas (most of which I think are
>> terrible) but very short on actually getting anything done. Until you
>> begin to remedy that I doubt very many people here will take you as
>> seriously as you seem to want.
>
> Look, every organization needs workers, visionaries, liaisons,
> supervisors, etc. I seem to fit nicely into a Visionary role. Maybe
> that bothers you? I don't know? But we all have our place Geremy. Do
> you think any organization could survive simply with robotic workers
> and no guidance? No, and why not? Because workers cannot see the big
> picture. They are too focused (and rightly so) on some small detail
> that encompasses their job duty. Only the supervisor/visionary has the
> luxury of looking at the problem from a global perspective.
>
> Think of Python-dev as a car. A car is a machine. A very complicated
> machine that needs a driver to harness it's power and give it
> direction and purpose. -- someone who can see "beyond" the horizon.
> Someone who can read a road map and then re-calculate a path if road
> construction blocks the current one. Without the car the driver is
> nothing, and without the driver the car is nothing.

Python already has leadership. It does not have a command structure.
There is a difference, one that you would need to understand to be an
effective leader.

> But together, they
> are a force to reckoned with. Well, unless the driver is Asian -- then
> all bets are off! :-)

Hahaha, racism was so funny in the 1700's! Now it's just asinine.

>> Also, be careful with where you say 'we'- I certainly don't recognize
>> your authority to speak on behalf of the community, and I suspect that
>> an overwhelming majority of the community's other members feel the
>> same way.
>
> You see! This is the resistance i am talking about. You (and others)
> don't want to accept me as part of the community. If you did accept
> me, then my speaking collectively (we) would not be troubling to you.
> However i do not blame you directly for this prejudice. I think it is
> more of a sub-conscience undercurrent that pervades this community as
> a whole. A fear of outsiders. A xenophobia if you will. We need to
> change this now!

There's a difference between 'we should' and 'we must'. One implies
that you are trying to convince, which is what communities of equals
do. The other implies that you are trying to command, which is what
idiots think they can do to communities of equals.

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[Michael Torrie]

On 01/19/2011 05:01 PM, geremy condra wrote:
> On Wed, Jan 19, 2011 at 3:04 PM, rantingrick  wrote:
>> And you've also lost all
>> connection with the people. I am desperately trying to to snap you out
>> of this psychosis before it is too late! Tkinter will be the downfall
>> of Python if we cannot muster the resolve to replace it with something
>> that is current (or more current) technology.

I don't see the original bizarre rants for some reason (spam filter
likely), but I have to say this is the most ridiculous thing I've heard
in some time.  Tkinter the downfall of python?  Wow.  All of the python
programmers I know (we use python every day at work) would  say, "what
is tkinter?"  It's just not relevant to any of them that I know.  Google
probably uses as much Python as anyone, and their programmers would
probably agree.  Perhaps that's an argument to remove tkinter entirely,
but not really a good one.

In the meantime they happily crank out code with Django, or PyQt, or
PyGTK, or even Tkinter--whatever tool is appropriate for the job.

> Citation needed.

Perhaps a reference to Xah Lee's web site would suffice.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 19, 9:22 pm, geremy condra  wrote:

> Welcome to real life. You convince people that you're right or they
> don't do what you say.

Again you "think" (or miscomprehended rather!) that "somehow" i am
here to "make" you do anything. On the contrary Geremy, i am here to
"guide", to "foster", and to "build" a cohesive community of python
programmers united in a common goal WITH a clear vision for the
future.

> >> and second because I don't think
> >> that resistance on this issue is as mindless as you claim.
>
> > i have exposed the baseless, nonsensical, and argumentative stance
> > taken by some in an effort to sway public opinion with FUD and BS. So
> > i would say that arguing with baseless facts does constitute "rabid
> > resistance". What else could it be?
>
> Reasoned resistance seen through the eyes of someone whose judgement
> should not be trusted.

Why is my judgment in question here. As you claim i have no authority
within in this group, so why does my judgment scare you?


> > But together, they
> > are a force to reckoned with. Well, unless the driver is Asian -- then
> > all bets are off! :-)
>
> Hahaha, racism was so funny in the 1700's! Now it's just asinine.

Actually the joke is on you Geremy. Obviously you cannot tell the
difference between "stereotypes" and "racism". And there is a HUGE,
HUGE, difference! Asians are stereotypical bad drivers, just as white
guys are stereotypical bad dancers, just as black guys have
stereotypical huge cucumbers. The fact that you cannot distinguish
racism from stereotype exposes three things about your personality
(1.) You have no sense of humor and cannot laugh at yourself, (2.)
You'll jump on any bandwagon just to discredit the person you are
debating with outlandish and controversial accusations, and (3.) you
are extremely shallow. This shows lack of intelligence, humor, and
worse of all humility.

Anyhow, do you have any actual arguments or ideas on keeping Tkinter
or replacing Tkinter. Remember that is why we are here Geremy.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[rantingrick]

On Jan 19, 9:20 pm, Michael Torrie  wrote:
>
> All of the python programmers I know (we use python every day at
> work) would say, "what is tkinter?" It's just not relevant to any of
> them that I know.
>

And that is the very point i am trying to make Micheal! TclTk is SO
old and dated that most people don't even know it exists -- MUCH LESS
TKINTER!

>
> In the meantime they happily crank out code with Django, or PyQt, or
> PyGTK, or even Tkinter--whatever tool is appropriate for the job.
>

I noticed wxPython did not make your list. Was that conscience or sub-
conscience because i find it hard to believe that none of them use
wxPython... ever. However the REAL point is that they obviously prefer
*anything* except Tkinter and only use Tkinter as a last resort. This
is very interesting Micheal.

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

Re: Tkinter: The good, the bad, and the ugly!

[Brian Curtin]

On Wed, Jan 19, 2011 at 18:53, rantingrick  wrote:

> Without the car the driver is
> nothing, and without the driver the car is nothing. But together, they
> are a force to reckoned with. Well, unless the driver is Asian -- then
> all bets are off! :-)


Welcome to the auto-deletion filter.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tkinter: The good, the bad, and the ugly!

[geremy condra]

On Wed, Jan 19, 2011 at 7:56 PM, rantingrick  wrote:
>> > But together, they
>> > are a force to reckoned with. Well, unless the driver is Asian -- then
>> > all bets are off! :-)
>>
>> Hahaha, racism was so funny in the 1700's! Now it's just asinine.
>
> Actually the joke is on you Geremy. Obviously you cannot tell the
> difference between "stereotypes" and "racism". And there is a HUGE,
> HUGE, difference! Asians are stereotypical bad drivers, just as white
> guys are stereotypical bad dancers, just as black guys have
> stereotypical huge cucumbers.

Congratulations; you are the second person better than a decade to
land in my bozo bin. Don't bother replying- I won't be hearing from
you.

Geremy Condra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: collections.Set Binary Reflected Operations

[Daniel Urban]

On Thu, Jan 20, 2011 at 01:51, Chris Kaynor  wrote:
> I am implemented a custom set-like type which interacts with some
> third-party software when retrieving and mutating the set, and have derived
> my custom type off of collections.MutableSet, however I have noticed that
> some of the magic methods supported by the built-in set do not fully
> function with my custom type. From this, I looked over the
> MutableSet definition in and it seems to be missing all of the reflected
> operators (__rsub__, __rand__, __ror__, __rxor__, and friends) for the
> operators it has defined. I can post a simple example case if desired.
> I am using Python 2.6.4 (with some in-house customizations), however a quick
> look over the svn repository shown on python.org makes it appear that these
> are also not implemented in Python 3. I was wondering if there is some
> reason for this, or if it was merely an oversight.
> Chris

See http://bugs.python.org/issue8743 and also http://bugs.python.org/issue2226


Daniel
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: newb

[WellsSUZETTE21]

I received 1 st http://bestfinance-blog.com/topics/mortgage-loans";>mortgage loans 
when I was 25 and that supported my family very much. But, I need the bank loan 
once more time. 


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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Grant Edwards" 

On all of my computers, wxPython uses Gtk.  There are other choices
for wxWidget backends on Linux, but Gtk is by far the most common.
IOW, if Gtk is bad, then wxPython is bad.


Not true.


I think you're playing a bit fast and loose with your accusations.



:-)
I've made no accusations, but I only try to inform the people about the
accessibility of different GUI libs.


Which of my statements was "not true"?

1) On all of my computers wxPython uses Gtk.

2) There are other backend choices on Linux besides Gtk.

3) Gtk is by far the most common wxWidgets backend on Linux/Unix.

4) If Gtk is bad then wxPython is bad.

Note that 4) follows logically from 3), so to say that 4) is "not
true" you have to show that 3) is "not true".


The wrong conclusion is that if Gtk is bad, then WxPython is bad.
Gtk is inaccessible under Windows, not under Linux, but WxPython doesn't use
Gtk under Windows so WxPython is OK.

Under Linux Gtk is OK, but I don't know about Motif. Under Linux Motif might 
not be accessible, however note that I am not sure about Motif's 
accessibility.


Octavian





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

Re: Tkinter: The good, the bad, and the ugly!

[Octavian Rasnita]

From: "Adam Skutt" 
The fact that /every/ toolkit provides accessibility guidelines over
and above whatever other UI guidelines they provide tells me that
creating an accessible application is hardly obvious.  Plus, if it
were really that simple, the accessibility situation wouldn't be so
poor.

:-)
Where do you got the conclusion that the accessibility is so poor?
The accessibility is not so great under Mac and under Linux it is less 
advanced than under Windows, but under Windows the accessibility is usually 
very good for most apps.
All the standard Windows programs are accessible, all the DotNet programs 
are generally accessible, SWT and wxWIDGETS - based programs are accessible, 
SWING-based GUIS are also pretty accessible and even more strange interfaces 
like the one found in Winamp are accessible.
Even Flash have a very limited accessibility although I think it is too much 
to say that it is accessible.


But You keep telling me that it is hard to create accessible programs, which 
is false, but you don't know and don't want to try to see.
Try to create a WxPython app that doesn't do anything but only displays some 
menus, buttons, combo boxes, list boxes, list views, tree views, text 
fields, check boxes, radio buttons... and you will see that they are very 
accessible with that screen reader I told you about, without requiring you 
to do anything special that you wouldn't do otherwise.



Yes, those things should be followed for creating a better app, but what I 
wanted to say is that no matter if you do those things or not in a Tk, Gtk 
or QT GUI, they will be useless, because the screen readers can't 
understand those GUIS even they have text labels, and even if you will see 
a focus rectangle around buttons. They don't report that those objects 
have the focus so the screen readers won't speak anything.


Your "something is better than nothing" argument isn't particularly
compelling to me personally as a justification for ripping out
TkInter.  And Qt is the only toolkit with some level of functioning
accessibility support on all three major platforms, assuming the
library and software are built correctly, so again, your argument is
really for Qt, not for wxWidgets.


How do you came to the conclusion that QT is accessible on all operating 
system? I haven't seen any QT-based accessible interface, but WxPython 
offers that thing without any effort.


When you talk about accessibility, try it yourself and don't take the word 
of the GUI widgets developers.


Octavian

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

Re: Screen readers for Tkinter (was Re: Tkinter: The good, the bad, and the ugly!)

[Octavian Rasnita]

From: "Terry Reedy" 

On 1/19/2011 11:27 AM, Octavian Rasnita wrote:


Note: Currently, accessibility is only available via ATK<=>  AT-SPI on
Linux. Sorry, no Windows MSAA support.



This project is good, a step ahead, but in order to be really useful it 
should be the one provided by the default Python package.
And of course, it should also offer support for Windows, since most of 
the computer users use Windows, especially those who need accessibility 
features.


Octavian

Please consider adding an 'Accessibility' page to the Python wiki with 
your info and the above for those interested.


--
Terry Jan Reedy




Well, I am not sure this is an interesting thing for the programmers. The 
programmers (including me) are usually interested to have the job done as 
fast as possible, with as few efforts as possible and to be easy to 
maintain.
The GUIs should be accessible by default like in case of wxWIDGETS, SWT or 
WindowsForms. That's why I said that that lib should be included in Python 
implicitely eventually because if it is just promoted, the beginners won't 
know about it and most of the programmers won't care to add accessibility 
features with aditional efforts.


Too bad that it doesn't support the accessibility for Windows though.

Octavian




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

Re: [OT] Python like lanugages [was Re: After C++, what with Python?]

[Stefan Behnel]

Tim Harig, 18.01.2011 12:37:

On 2011-01-18, Stefan Behnel wrote:

Tim Harig, 17.01.2011 20:41:

I prefer a single language as opposed to a creolization of two.


With the possible exception of Lisp, I find it hard to think of a language
that's still alive and not the creolisation of (at least) two other
languages. They all inherited from each other, sometimes right from the
start ("lessons learned") and always during their subsequent life time.


I am not talking about language influences.  Cython effectively requires
two separate languages that interoperate.  The end result is a mix
of two code written in two separate langauges.  That is not a single
language solution.


I don't really agree with the word "separate", and especially not "two 
codes". I think of Cython more as Python with the addition of C data types, 
integrated by a smart compiler. So the language actually is Python, it's 
just that you can apply it to a broader set of data representations.


Stefan

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