Re: Packaging and deployment of standalone Python applications?

[Christian Gollwitzer]

Am 14.09.15 um 08:58 schrieb Kristian Rink:

Folks;

coming from a server-sided Java background, I'm recently exploring
frameworks such as cherrypy or webpy for building RESTful services,
which is quite a breeze and a pretty pleasant experience; however one
thing so far bugs me: Using Java tooling and libraries such as
DropWizard, it is pretty straightforward to build an "all-inclusive"
application containing (a) all code of my own, (b) all required
dependencies, (c) all other resources and, if required, even (d) a
Java virtual machine in one large .zip file which can easily be
copied to a clean Linux VM, unzipped and started there.

Are there ways of doing so using Python, too? I'd like to set up a
project structure / working environment that includes all Python 3rd
party libraries, my own code and maybe even a "standard" Python
runtime for 64bit Linux systems (to not depend too much on what
version a certain Linux distribution actually ships) and focus on
doing deployment to various machines at best by simply copying these
packages around.

Any pointers, ideas, inspirations on that greatly appreciated - even
in total different ways if what I am about to do is completely off
anyone would do it in a Python environment. ;)


Look at pyinstaller. It creates monsters (i.e. really huge single file
or single directory builds), but it works for my projects.

Christian

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

Re: Packaging and deployment of standalone Python applications?

[dieter]

Kristian Rink  writes:

> Folks;
>
> coming from a server-sided Java background, I'm recently exploring frameworks 
> such as cherrypy or webpy for building RESTful services, which is quite a 
> breeze and a pretty pleasant experience; however one thing so far bugs me: 
> Using Java tooling and libraries such as DropWizard, it is pretty 
> straightforward to build an "all-inclusive" application containing (a) all 
> code of my own, (b) all required dependencies, (c) all other resources and, 
> if required, even (d) a Java virtual machine in one large .zip file which can 
> easily be copied to a clean Linux VM, unzipped and started there.
>
> Are there ways of doing so using Python, too?

I do not think that the Python support in this regard is as
sophisticated as in the Java world.

Have a look at "distribute/setuptools". It supports (a) and (b)
(event though you must write a "setup.py" without the help of an UI)
and allows to state the dependencies (part of (c)). It can generate
a so called "egg" (a distribution unit) representing one distributable
component.

On installation, you still need a local Python (with its runtime
environment) and the installation process will try
to resolve the stated dependencies - potentially requiring internet access.


In order to get one executable containing the Python interpreter
and all required packages, there is "freeze" (and when I remember
right a solution provided by "eGenix"). However, you must manually prepare
the application such that "freeze" learns about the "required packages".
"freeze" is likely too old that it already would interprete the dependency
declarations.

You might also have a look at "zc.buildout". Its primary task is
to ensure the setup of a consistent development/deployment environment
across different environments (hosts). It relies on a local Python
installation - but can handle almost everything else.
Again - without UI support.

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

Re: Python handles globals badly.

[Skybuck Flying]

"Ned Batchelder"  wrote in message 
news:180fe671-7bf9-4544-a3ad-d98a4a497...@googlegroups.com...


On Sunday, September 13, 2015 at 8:11:13 AM UTC-4, Skybuck Flying wrote:

I don't even understand how python interpreter works but I can understand 
it

better than you guys do apperently hahaha.


"
As tempting as it is to respond to Skybuck, with a brief pause to consider,
and a deep breath, I'm sure we can all agree that there is no point in it.

Skybuck: go in peace, and thanks for being part of the Python community.
"

Go in Peace yourself

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

kivy editable multicolumn list

[Paulo da Silva]

Hi all.
Not sure if this is the place to ask about kivy ...
I apologize if not.

I am playing with the example here
https://gist.github.com/geojeff/4442405

Now I would like to change the background color the editable field.

So I added
def __init__(self,**kwargs):
super(EditableLabel,self).__init__(**kwargs)
with self.canvas.before:
Color(0,1,0)
Rectangle(pos=self.pos,size=self.size)
print(self.pos,self.size)

to class EditableLabel.

But when entering __init__ self.pos and self.size do not have the
correct pos/size for the EditableLabel.

How can I fix this? Please no kv solutions. I need dynamic change it in
a real example.

Thanks for any help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

Alexander Belopolsky  writes:

> No credit for anything other than the "extra credit" section.  Partial
> credit for that.  Study that printout and you should understand what
> Tim was saying.

My original claim was that the pickler can't know and doesn't care if a
byte string value merely happens to be 10 bytes long for this object, or
is 10 bytes long every time, it will encode it with SHORT_BINBYTES ["C",
count of bytes, string of bytes] regardless.

The datetime constructor itself does care what value is passed to it,
but what I was saying was the class could have been written originally
to accept optionally longer strings and ignore the extra values, so that
future versions could pickle as longer strings and be compatible.

In such a case, the actual pickle format would _still_ have consisted of
__reduce__() == (datetime, (b"..", [optional tzinfo])), just
with the option of accepting (and ignoring) longer byte strings encoded
by later versions of the datetime class.

The pickle format is versatile enough to pass any (pickleable) value at
all to a constructor (or to __setstate__). Designing the datetime
constructor/setstate in the past to be able to accept a byte string of a
length other than exactly 10 would have allowed the representation to be
extended in the present, rather than smuggling a single extra bit into
one of the existing bytes. But it would not have changed the actual
representation that would have been produced by pickle back then, not
one bit.

And, now, to answer my own question from a previous message...
>>> class C():
...  def __reduce__(self):
...   return (datetime, (b"\x07\xdf\t\x0e\x155'\rA\xb2",))
...
>>> pickle.loads(pickle.dumps(C()))
datetime.datetime(2015, 9, 14, 21, 53, 39, 868786)
>>> class C():
...  def __reduce__(self):
...   return (datetime, (b"\x07\xdf\t\x0e\x955'\rA\xb2",))
...
>>> pickle.loads(pickle.dumps(C()))
datetime.datetime(2015, 9, 14, 149, 53, 39, 868786)
>>> datetime.strftime(pickle.loads(pickle.dumps(C())), '%Y%m%d%H%M%S')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: hour out of range

That was the bit we were talking about, right?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Tim]
>> Sorry, I'm not arguing about this any more.  Pickle doesn't work at
>> all at the level of "count of bytes followed by a string".

[Random832 ]
> The SHORT_BINBYTES opcode consists of the byte b'C', followed by *yes
> indeed* "count of bytes followed by a string".

Yes, some individual opcodes do work that way.


>> If you
>> want to make a pickle argument that makes sense, I'm afraid you'll
>> need to become familiar with how pickle works first.  This is not the
>> place for a pickle tutorial.
>>
>> Start by learning what a datetime pickle actually is.
>> pickletools.dis() will be very helpful.

> 0: \x80 PROTO  3
> 2: cGLOBAL 'datetime datetime'
>21: qBINPUT 0
>23: CSHORT_BINBYTES b'\x07\xdf\t\x0e\x15\x06*\x00\x00\x00'
>35: qBINPUT 1
>37: \x85 TUPLE1
>38: qBINPUT 2
>40: RREDUCE
>41: qBINPUT 3
>43: .STOP
>
> The payload is ten bytes, and the byte immediately before it is in fact
> 0x0a. If I pickle any byte string under 256 bytes long by itself, the
> byte immediately before the data is the length. This is how I initially
> came to the conclusion that "count of bytes followed by a string" was
> valid.

Ditto.

> I did, before writing my earlier post, look into the high-level aspects
> of how datetime pickle works - it uses __reduce__ to create up to two
> arguments, one of which is a 10-byte string, and the other is the
> tzinfo. Those arguments are passed into the date constructor and
> detected by that constructor - for example, I can call it directly with
> datetime(b'\x07\xdf\t\x0e\x15\x06*\x00\x00\x00') and get the same result
> as unpickling.

Good job!  That abuse of the constructor was supposed to remain a secret ;-)


> At the low level, the part that represents that first argument does
> indeed appear to be "count of bytes followed by a string". I can add to
> the count, add more bytes, and it will call the constructor with the
> longer string. If I use pickletools.dis on my modified value the output
> looks the same except for, as expected, the offsets and the value of the
> argument to the SHORT_BINBYTES opcode.
>
> So, it appears that, as I was saying, "wasted space" would not have been
> an obstacle to having the "payload" accepted by the constructor (and
> produced by __reduce__ ultimately _getstate) consist of "a byte string
> of >= 10 bytes, the first 10 of which are used and the rest of which are
> ignored by python <= 3.5" instead of "a byte string of exactly 10
> bytes", since it would have accepted and produced exactly the same
> pickle values, but been prepared to accept larger arguments pickled from
> future versions.

Yes, if we had done things differently from the start, things would
work differently today.  But what's the point?  We have to live now
with what _was_ done.  A datetime pickle carrying a string payload
with anything other than exactly 10 bytes will almost always blow up
under older Pythons. and would be considered "a bug" if it didn't.
Pickles are not at all intended to be forgiving (they're enough of a
potential security hole without going out of their way to ignore
random mysteries).

It may be nicer if Python had a serialization format more deliberately
designed for evolution of class structure - but it doesn't.  Classes
that need such a thing now typically store their own idea of a
"version" number as part of their pickled state  datetime never did.


> ...
> So have I shown you that I know enough about the pickle format to know
> that permitting a longer string (and ignoring the extra bytes) would
> have had zero impact on the pickle representation of values that did not
> contain a longer string?

Yes.  If we had a time machine, it might even have proved useful ;-)


> I'd already figured out half of this before
> writing my earlier post; I just assumed *you* knew enough that I
> wouldn't have to show my work.

It's always best to show your work on a public list.  Thanks for
finally ;-) doing so!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 18:09, Tim Peters wrote:
> Sorry, I'm not arguing about this any more.  Pickle doesn't work at
> all at the level of "count of bytes followed by a string". 

The SHORT_BINBYTES opcode consists of the byte b'C', followed by *yes
indeed* "count of bytes followed by a string".

> If you
> want to make a pickle argument that makes sense, I'm afraid you'll
> need to become familiar with how pickle works first.  This is not the
> place for a pickle tutorial.
> 
> Start by learning what a datetime pickle actually is.
> pickletools.dis() will be very helpful.

0: \x80 PROTO  3
2: cGLOBAL 'datetime datetime'
   21: qBINPUT 0
   23: CSHORT_BINBYTES b'\x07\xdf\t\x0e\x15\x06*\x00\x00\x00'
   35: qBINPUT 1
   37: \x85 TUPLE1
   38: qBINPUT 2
   40: RREDUCE
   41: qBINPUT 3
   43: .STOP

The payload is ten bytes, and the byte immediately before it is in fact
0x0a. If I pickle any byte string under 256 bytes long by itself, the
byte immediately before the data is the length. This is how I initially
came to the conclusion that "count of bytes followed by a string" was
valid.

I did, before writing my earlier post, look into the high-level aspects
of how datetime pickle works - it uses __reduce__ to create up to two
arguments, one of which is a 10-byte string, and the other is the
tzinfo. Those arguments are passed into the date constructor and
detected by that constructor - for example, I can call it directly with
datetime(b'\x07\xdf\t\x0e\x15\x06*\x00\x00\x00') and get the same result
as unpickling.

At the low level, the part that represents that first argument does
indeed appear to be "count of bytes followed by a string". I can add to
the count, add more bytes, and it will call the constructor with the
longer string. If I use pickletools.dis on my modified value the output
looks the same except for, as expected, the offsets and the value of the
argument to the SHORT_BINBYTES opcode.

So, it appears that, as I was saying, "wasted space" would not have been
an obstacle to having the "payload" accepted by the constructor (and
produced by __reduce__ ultimately _getstate) consist of "a byte string
of >= 10 bytes, the first 10 of which are used and the rest of which are
ignored by python <= 3.5" instead of "a byte string of exactly 10
bytes", since it would have accepted and produced exactly the same
pickle values, but been prepared to accept larger arguments pickled from
future versions.

For completeness: Protocol version 2 and 1 use BINUNICODE on a
latin1-to-utf8 version of the byte string, with a similar "count of
bytes followed by a string" (though the count of bytes is of UTF-8
bytes). Protocol version 0 uses UNICODE, terminated by \n, and a literal
\n is represented by \\u000a. In all cases some extra data around the
value sets it up to call "codecs.encode(..., 'latin1')" upon unpickling.

So have I shown you that I know enough about the pickle format to know
that permitting a longer string (and ignoring the extra bytes) would
have had zero impact on the pickle representation of values that did not
contain a longer string? I'd already figured out half of this before
writing my earlier post; I just assumed *you* knew enough that I
wouldn't have to show my work.

Extra credit:
0: \x80 PROTO  3
2: cGLOBAL 'datetime datetime'
   21: qBINPUT 0
   23: (MARK
   24: MBININT22014
   27: KBININT19
   29: KBININT114
   31: KBININT121
   33: KBININT16
   35: KBININT142
   37: tTUPLE  (MARK at 23)
   38: qBINPUT 1
   40: RREDUCE
   41: qBINPUT 2
   43: .STOP
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[rurpy--- via Python-list]

On Monday, September 14, 2015 at 5:23:32 PM UTC-6, Laura Creighton wrote:
>[...]
> I don't know about the others, but I am finding this rather more
> entertaining than another round of 'python -- does it have pointers'
> in python-list.

Could we please dispense with the gratuitous "what I'm interested 
in is more important that what you are interested in" posts please?
Almost all mail readers have a filter ability that will address the
problem more effectively.

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Laura Creighton]

On Mon, Sep 14, 2015, at 16:01, Carl Meyer wrote:
>> Can we please stop cross-posting this thread to python-list and move it
>> to datetime-sig only? I think anyone here on python-list who is
>> sufficiently interested in it can subscribe to datetime-sig.
>> 
>> Or the other way around, whatever. I'd just like to stop getting all the
>> messages twice.

I don't know about the others, but I am finding this rather more
entertaining than another round of 'python -- does it have pointers'
in python-list.

Laura

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Laura Creighton]

In a message of Mon, 14 Sep 2015 15:35:28 -0400, Random832 writes:
>As far as I know, the position of the tzdata people is that while this
>belief is held almost everywhere that does not observe DST but is
>surrounded by places that do (I should know; I live in Indiana, which
>was such a place until 2006), almost nowhere does it have any formal
>legitimacy, and systems that use the data therefore, by design, will not
>actually generate "CST/MDT" timestamps.

It been many, many years since I cared about this, but I used to see
a lot of timestamp fiddling among people who ran online services.
Because otherwise the natives would wake up in the morning and
fire off bug reports 'you are supposed to change the time to
Mountain' ...

>When exactly is this transition supposed to take place? At 2AM, Manitoba
>springs forward, but Alberta remains on MST for another hour - nowhere
>else in North America *but* Saskatchewan uses an offset of -06:00 for
>this hour-long period.

Which is why I ended up putting my faith in offsets.  As you might guess,
when this transition takes place was locally determined by whoever had
to make the switch.  Every year we got to hear why it was best (and
maybe even legally required) to make the switch at 02:00.  Others
insisted that the nameswap should happen at 03:00.  And, in a time
when a lot of this absolutely had to be done by hand (think Fidonet
systems running on user pcs that had no automatic clock at all) the
real answer was 'The time will always be right, I will change the
timezone to mountain when I get up in the morning'.  

Things may be different now.

Laura

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Random832 ]
> Would allowing a 16-byte string in the future have increased the storage
> occupied by a 10-byte string today? Would allowing a third argument in
> the future have increased the storage occupied by two arguments today?
> As far as I can tell the pickle format for non-primitive types isn't
> _that_ fixed-width.

Sorry, I'm not arguing about this any more.  Pickle doesn't work at
all at the level of "count of bytes followed by a string".  If you
want to make a pickle argument that makes sense, I'm afraid you'll
need to become familiar with how pickle works first.  This is not the
place for a pickle tutorial.

Start by learning what a datetime pickle actually is.
pickletools.dis() will be very helpful.


>>> That you didn't makes me wonder just where you're finding the space to put 
>>> the
>>> fold bit.

>> PEP 495 gives all the details.  Short course:  there are bits that are
>> _always_ 0 now within some datetime pickle bytes.  `fold` will abuse
>> one of those always-0-now pickle bits.

> And what happens to older implementations if that bit is 1?

Unpickling will raise an exception, complaining that the minute value
is out of range.


>> Aware datetimes _within_ a zone also follow the naive time model.
>> It's unfortunate that they're nevertheless called "aware" datetimes.
>>
>> So, sorry, even when sorting a list of aware datetimes, if they share
>> a common zone it is wholly intended that they all work in naive time.

> And if some of them share a common zone, then some of them will work in
> naive time, and some of them will work in aware time, and some pairs
> (well, triples) of them will cause problems for sort/bisect algorithms.

All sorts of things may happen, yes.  As I said, if you need to care,
convert to UTC first.  Most apps do nothing like this.


> Maybe it'd be best to simply ban interzone comparisons.

We cannot.  Backward compatibility.  If would have been better had
interzone comparisons and subtraction not been supported from the
start.  Too late to change that.


> Or have some sort of context manager to determine how arithmetic and 
> comparisons
> work.

Write a PEP ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 17:34, Tim Peters wrote:
> Yes, we "could have" done that for all pickle formats for all types.
> But why on Earth would we?  Pickle size is important to many apps
> (e.g., Zope applications can store billions of pickles in databases.
> and it may not be purely coincidence ;-) that Zope Corp paid for
> datetime development), and there would have been loud screaming about
> any "wasted" bytes.

Would allowing a 16-byte string in the future have increased the storage
occupied by a 10-byte string today? Would allowing a third argument in
the future have increased the storage occupied by two arguments today?
As far as I can tell the pickle format for non-primitive types isn't
_that_ fixed-width.

> > That you didn't makes me wonder just where you're finding the space to put 
> > the
> > fold bit.
> 
> PEP 495 gives all the details.  Short course:  there are bits that are
> _always_ 0 now within some datetime pickle bytes.  `fold` will abuse
> one of those always-0-now pickle bits.

And what happens to older implementations if that bit is 1?

> Aware datetimes _within_ a zone also follow the naive time model.
> It's unfortunate that they're nevertheless called "aware" datetimes.
> 
> So, sorry, even when sorting a list of aware datetimes, if they share
> a common zone it is wholly intended that they all work in naive time.

And if some of them share a common zone, then some of them will work in
naive time, and some of them will work in aware time, and some pairs
(well, triples) of them will cause problems for sort/bisect algorithms.

Maybe it'd be best to simply ban interzone comparisons. Or have some
sort of context manager to determine how arithmetic and comparisons
work.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Tim]
>> Because all versions of Python expect a very specific pickle layout
>> for _every_ kind of pickled object (including datetimes)..  Make any
>> change to the pickle format of any object, and older Pythons will
>> simply blow up (raise an exception) when trying to load the new pickle
>> - or do something insane with the pickle bits.  It's impossible for
>> older Pythons to know anything about what "the new bits" are supposed
>> to mean, and there is no way to spell, in the pickle engine, "but if
>> you're an older version, skip over the next N bytes".

[Random832 ]
> Well, you could have put some reserved bits in the original pickle
> format for datetime back when it was first defined, or even just allowed
> passing in a longer string for future extension purposes.

Yes, we "could have" done that for all pickle formats for all types.
But why on Earth would we?  Pickle size is important to many apps
(e.g., Zope applications can store billions of pickles in databases.
and it may not be purely coincidence ;-) that Zope Corp paid for
datetime development), and there would have been loud screaming about
any "wasted" bytes.


> That you didn't makes me wonder just where you're finding the space to put the
> fold bit.

PEP 495 gives all the details.  Short course:  there are bits that are
_always_ 0 now within some datetime pickle bytes.  `fold` will abuse
one of those always-0-now pickle bits.


>> It's not so much a "good idea" as that it's the only idea consistent
>> with Python's "naive time" model.  Folds and gaps don't exist in naive
>> time.  Indeed, the _concept_ of "time zone" doesn't really exist in
>> naive time.  There's _inherent_ tension between the naive time model
>> and the way multi-offset time zones actually behave.  So it goes.

> But why does it need to be consistent? You can't compare naive datetimes
> with aware ones. If you want to sort/bisect a list of datetimes, they
> have to either all be naive or all be aware. So when we're talking about
> how ordering works, we're fundamentally talking about how it works for
> aware datetimes.

Aware datetimes _within_ a zone also follow the naive time model.
It's unfortunate that they're nevertheless called "aware" datetimes.

So, sorry, even when sorting a list of aware datetimes, if they share
a common zone it is wholly intended that they all work in naive time.

Apps that can't tolerate naive time should convert to UTC first.  End
of problems.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 16:45, Tim Peters wrote:
> Because all versions of Python expect a very specific pickle layout
> for _every_ kind of pickled object (including datetimes)..  Make any
> change to the pickle format of any object, and older Pythons will
> simply blow up (raise an exception) when trying to load the new pickle
> - or do something insane with the pickle bits.  It's impossible for
> older Pythons to know anything about what "the new bits" are supposed
> to mean, and there is no way to spell, in the pickle engine, "but if
> you're an older version, skip over the next N bytes".

Well, you could have put some reserved bits in the original pickle
format for datetime back when it was first defined, or even just allowed
passing in a longer string for future extension purposes. That you
didn't makes me wonder just where you're finding the space to put the
fold bit.

> It's not so much a "good idea" as that it's the only idea consistent
> with Python's "naive time" model.  Folds and gaps don't exist in naive
> time.  Indeed, the _concept_ of "time zone" doesn't really exist in
> naive time.  There's _inherent_ tension between the naive time model
> and the way multi-offset time zones actually behave.  So it goes.

But why does it need to be consistent? You can't compare naive datetimes
with aware ones. If you want to sort/bisect a list of datetimes, they
have to either all be naive or all be aware. So when we're talking about
how ordering works, we're fundamentally talking about how it works for
aware datetimes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alexander Belopolsky]

On Mon, Sep 14, 2015 at 4:22 PM, Tim Peters  wrote:

> > faster
> > than CPython can look up the .utcoffset method. (At least for times
> > within a few years around now.) A programmer who makes it slower should
> > be fired.
>
> So any programmer who implements .utcoffset() in Python should be
> fired?  That's the only way I can read that.


No, no!  I've already conceded that caching UTC offset will probably help
pure Python implementations.  PyPy folks have established this fact for
hash and I am willing to extrapolate their results to UTC offset.  I am
only trying to say that if we decide to bring a fast TZ database to
CPython, pure python tzinfo interface will likely become our main
bottleneck, not the speed with which C code can compute the offset value.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alexander Belopolsky]

On Mon, Sep 14, 2015 at 3:49 PM, Tim Peters  wrote:

> It depends on how expensive .utcoffset()
> is, which in turn depends on how the tzinfo author implements it.
>

No, it does not.  In most time zones, UTC offset in seconds can be computed
by C code as a 4-byte integer faster than CPython can look up the
.utcoffset method. (At least for times within a few years around now.) A
programmer who makes it slower should be fired.  Yet I agree,
"'premature optimization'
applies at this time."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alexander Belopolsky]

On Mon, Sep 14, 2015 at 3:44 PM, Random832  wrote:

> It is an
> invariant that is true today, and therefore which you can't rely on any
> of the consumers of this 12 years old widely deployed code not to assume
> will remain true.
>

Sorry, this sentence does not parse.  You are missing a "not" somewhere.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alexander Belopolsky]

On Mon, Sep 14, 2015 at 4:08 PM, Random832  wrote:

> On Mon, Sep 14, 2015, at 15:48, Alexander Belopolsky wrote:
> > On Mon, Sep 14, 2015 at 3:44 PM, Random832 
> > wrote:
> >
> > > It is an
> > > invariant that is true today, and therefore which you can't rely on any
> > > of the consumers of this 12 years old widely deployed code not to
> assume
> > > will remain true.
> > >
> >
> > Sorry, this sentence does not parse.  You are missing a "not" somewhere.
>
> Nope. I am asserting that:
>
> This invariant is true today.
>

You've never specified "this invariant", but I'll assume you are talking
about "a < b implies a.astimezone(UTC) < b.astimezone(UTC)."  This is *not*
true today:

>>> from datetime import *
>>> from datetimetester import Eastern
>>> UTC = timezone.utc
>>> a = datetime(2002, 4, 7, 1, 40, tzinfo=Eastern)
>>> b = datetime(2002, 4, 7, 2, 20, tzinfo=Eastern)
>>> a < b
True
>>> a.astimezone(UTC) < b.astimezone(UTC)
False



> Therefore, it is likely that at least some consumers of datetime will
> assume it is true.
>

Obviously, if Random832 is a real person, the last statement is true.  This
does not make the assumption true, just proves that at least one user is
confused about the current behavior. :-)


> Therefore, you cannot rely on there not being any consumers which assume
> it will remain true.
>

That's where we are now.  Some users make baseless assumptions.  This will
probably remain true. :-(


> It's awkward, since when I go back to analyze it it turns out that the
> "not" after 'code' actually technically modifies "any" earlier in the
> sentence, but the number of negatives is correct.


Writing in shorter sentences may help.


> (Though, it actually
> works out even without that change, since the question of *which*
> consumers rely on the invariant is unknown.)
>

True.  We will never know how many users rely on false assumptions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Random832 ]
> A) I'm still not sure why, but I was talking about adding an int, not a
> timedelta and a string.
>
> B) Older python versions can't make use of either utcoffset or fold, but
> can ignore either of them. I don't even see why they couldn't ignore a
> timedelta and a string if we felt like adding those.

Because all versions of Python expect a very specific pickle layout
for _every_ kind of pickled object (including datetimes)..  Make any
change to the pickle format of any object, and older Pythons will
simply blow up (raise an exception) when trying to load the new pickle
- or do something insane with the pickle bits.  It's impossible for
older Pythons to know anything about what "the new bits" are supposed
to mean, and there is no way to spell, in the pickle engine, "but if
you're an older version, skip over the next N bytes".


> C) What value fold "should" have can be inferred from the time, the
> utcoffset, and the tzinfo.

So you are proposing to add ... something ... _instead_ of adding
`fold`.  Already addressed that.  See above.

> I'm saying that *today*, even with no 495, it [utcoffset] does provide
> *a* value in all cases (even if that's sometimes the "wrong" value
> for an ambiguous time).

Sure.

> And that value is, for any plausible tzinfo, ordered the same for
> any given pair of datetimes with the same tzinfo as the datetimes
> considered as naive datetimes.

Yes.

> There is, or appears to be, a faction that is proposing to change that
> by sorting fold=1 2:15 before fold=0 2:45 even though the former is
> *actually* 30 minutes later than the latter, and I am *utterly baffled*
> at why they think this is a good idea.

It's not so much a "good idea" as that it's the only idea consistent
with Python's "naive time" model.  Folds and gaps don't exist in naive
time.  Indeed, the _concept_ of "time zone" doesn't really exist in
naive time.  There's _inherent_ tension between the naive time model
and the way multi-offset time zones actually behave.  So it goes.


>> It is true that the earlier and later of an ambiguous time in a fold
>> will compare equal in their own zone, but compare not equal after
>> conversion to UTC (or to any other zone in which they're not in one of
>> the latter zone's folds).  Is that what you're talking about?

> Yes. Or two different ambiguous times, where the properly earlier one
> compares greater and vice versa. I have no idea why anyone thinks this
> is reasonable or desirable behavior.

>From which I can guess, without asking, that you think "naive time"
itself is unreasonable and undesirable ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Ned Batchelder  writes:

> On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote:
>> Ned Batchelder  writes:
>> ...
>> > What do you feel is missing from Steven's diagram?
>> 
>> I don't feel anything missing because I don't expect the model to be
>> more detailed.
>
> Akira, you said, "neither models are detailed enough to describe
> meaningfully the behavior of Python code in the general case."   
>
> I'm wondering what aspect of the code's behavior isn't captured
> in this model?  I know you didn't expect it to be complete, but I'm
> not sure what you think is missing.
>

I don't understand what you are talking about.

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 16:15, Tim Peters wrote:
> [Random832 ]
> 
> Whether or not datetimes stored  tm_gmtoff and tm_zone workalikes has
> no effect on semantics I can see.  If, in your view, they're purely an
> optimization, they're just a distraction for now.  If you're proposing
> to add them _instead_ of adding `fold`, no, that can't work, for the
> pickle compatibility reasons already explained.  Whether something is
> in a fold needs to preserved across pickling, but "almost all" pickles
> need to be readable by older Pythons too.  This is doable adding one
> bit, but not doable at all if we need to add arbitrary timedelta and
> string objects _instead_ of that bit.

A) I'm still not sure why, but I was talking about adding an int, not a
timedelta and a string.

B) Older python versions can't make use of either utcoffset or fold, but
can ignore either of them. I don't even see why they couldn't ignore a
timedelta and a string if we felt like adding those.

C) What value fold "should" have can be inferred from the time, the
utcoffset, and the tzinfo.

> >> Well, you lost me there.  In a post-495 world, conversion to UTC will
> >> work correctly in all cases.  It cannot today.;
> 
> > It'll provide *a* value in all cases.
> 
> It will provide the correct UTC offset in all cases.

I'm saying that *today*, even with no 495, it does provide *a* value in
all cases (even if that's sometimes the "wrong" value for an ambiguous
time). And that value is, for any plausible tzinfo, ordered the same for
any given pair of datetimes with the same tzinfo as the datetimes
considered as naive datetimes.

There is, or appears to be, a faction that is proposing to change that
by sorting fold=1 2:15 before fold=0 2:45 even though the former is
*actually* 30 minutes later than the latter, and I am *utterly baffled*
at why they think this is a good idea.

> It is true that the earlier and later of an ambiguous time in a fold
> will compare equal in their own zone, but compare not equal after
> conversion to UTC (or to any other zone in which they're not in one of
> the latter zone's folds).  Is that what you're talking about?

Yes. Or two different ambiguous times, where the properly earlier one
compares greater and vice versa. I have no idea why anyone thinks this
is reasonable or desirable behavior.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Tim]
>> It depends on how expensive .utcoffset()
>> is, which in turn depends on how the tzinfo author implements it.

[Alex]
> No, it does not.  In most time zones, UTC offset in seconds can be computed
> by C code as a 4-byte integer

Which is a specific implementation of .utcoffset().  Which likely has
nothing to do with how most tzinfo authors will implement _their_
.utcoffset().  For example, look at any tzinfo.utcoffset()
implementation that currently exists ;-)


> faster
> than CPython can look up the .utcoffset method. (At least for times
> within a few years around now.) A programmer who makes it slower should
> be fired.

So any programmer who implements .utcoffset() in Python should be
fired?  That's the only way I can read that.


> Yet I agree,  "'premature optimization' applies at this time."

I'm more worried now about premature firing ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ned Batchelder]

On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote:
> Ned Batchelder  writes:
> ...
> > What do you feel is missing from Steven's diagram?
> 
> I don't feel anything missing because I don't expect the model to be
> more detailed.

Akira, you said, "neither models are detailed enough to describe
meaningfully the behavior of Python code in the general case."   

I'm wondering what aspect of the code's behavior isn't captured
in this model?  I know you didn't expect it to be complete, but I'm
not sure what you think is missing.

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Random832 ]

Whether or not datetimes stored  tm_gmtoff and tm_zone workalikes has
no effect on semantics I can see.  If, in your view, they're purely an
optimization, they're just a distraction for now.  If you're proposing
to add them _instead_ of adding `fold`, no, that can't work, for the
pickle compatibility reasons already explained.  Whether something is
in a fold needs to preserved across pickling, but "almost all" pickles
need to be readable by older Pythons too.  This is doable adding one
bit, but not doable at all if we need to add arbitrary timedelta and
string objects _instead_ of that bit.

...

>>>  (No, I don't *care* how that's not how it's defined,

>> ?  How what is defined?:

> Just trying, unsuccessfully apparently, to head off the "no, it's
> defined as working the same as a naive datetime if the tzinfo values are
> the same" argument that got brought up the *last* time I made this
> claim.

Sorry, I still don't know what this is about.


>>> it is *in fact* true for the UTC value that you will ever actually get
>>> from converting the values to UTC *today*, and it's the only total
>>> ordering that actually makes any sense)

>> Well, you lost me there.  In a post-495 world, conversion to UTC will
>> work correctly in all cases.  It cannot today.;

> It'll provide *a* value in all cases.

It will provide the correct UTC offset in all cases.


> The sort order today is equivalent to using that value in all
> cases unless you've got a pathological tzinfo
> specifically crafted to break it. I think that's an important enough
> invariant to be worth keeping, since it is the only possible way to
> provide a total order in the presence of interzone comparisons.

Show some code?  I don't know what you're talking about.

It is true that the earlier and later of an ambiguous time in a fold
will compare equal in their own zone, but compare not equal after
conversion to UTC (or to any other zone in which they're not in one of
the latter zone's folds).  Is that what you're talking about?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 16:01, Carl Meyer wrote:
> Can we please stop cross-posting this thread to python-list and move it
> to datetime-sig only? I think anyone here on python-list who is
> sufficiently interested in it can subscribe to datetime-sig.
> 
> Or the other way around, whatever. I'd just like to stop getting all the
> messages twice.

Er, sorry. To compound the issue, i've also had problems with some of my
replies accidentally only going to python-list due to my email client
having a "reply list" button that identifies python-list as the primary.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 15:48, Alexander Belopolsky wrote:
> On Mon, Sep 14, 2015 at 3:44 PM, Random832 
> wrote:
> 
> > It is an
> > invariant that is true today, and therefore which you can't rely on any
> > of the consumers of this 12 years old widely deployed code not to assume
> > will remain true.
> >
> 
> Sorry, this sentence does not parse.  You are missing a "not" somewhere.

Nope. I am asserting that:

This invariant is true today.
Therefore, it is likely that at least some consumers of datetime will
assume it is true.
Therefore, you cannot rely on there not being any consumers which assume
it will remain true.

It's awkward, since when I go back to analyze it it turns out that the
"not" after 'code' actually technically modifies "any" earlier in the
sentence, but the number of negatives is correct. (Though, it actually
works out even without that change, since the question of *which*
consumers rely on the invariant is unknown.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Carl Meyer]

Can we please stop cross-posting this thread to python-list and move it
to datetime-sig only? I think anyone here on python-list who is
sufficiently interested in it can subscribe to datetime-sig.

Or the other way around, whatever. I'd just like to stop getting all the
messages twice.

Carl



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 15:30, Tim Peters wrote:
> You're assuming much more than POSIX - and the ISO C standard -
> requirs.  My description was quite explicitly about how POSIX has done
> it all along.  tm_gmtoff and tm_zone are extensions to the standards,
> introduced (IIRC) by BSD.  Portable code (including Python's
> implementation) can't assume they're available.

No, but that doesn't mean it's not in fact true (what was under
discussion was "your own machine", not "a minimal POSIX
implementation"). And it doesn't mean it's not a best practice that
python can and should copy. I'm not talking about *using* it, I'm
talking about working the same way independently, so this has nothing to
do with assuming it's available.

> It was off the table because, for backward compatibility, we need to
> mess with the pickle format as little as possible.  It's vital that
> datetimes obtained from old pickles continue to work fine, and that
> pickles obtained from new datetime objects work fine when loaded by
> older Pythons unless they actually require the new fold=1 possibility.

I don't see how this would prevent that. Aware datetimes have a tzinfo
*right there* that can be asked for a value to populate utcoffset with
if there isn't a pickled one.

> > (No, I don't *care* how that's not how it's defined,
> 
> ?  How what is defined?:

Just trying, unsuccessfully apparently, to head off the "no, it's
defined as working the same as a naive datetime if the tzinfo values are
the same" argument that got brought up the *last* time I made this
claim.

> > it is *in fact* true for the UTC value that you will ever actually get
> > from converting the values to UTC *today*, and it's the only total
> > ordering that actually makes any sense)
> 
> Well, you lost me there.  In a post-495 world, conversion to UTC will
> work correctly in all cases.  It cannot today.;

It'll provide *a* value in all cases. The sort order today is equivalent
to using that value in all cases unless you've got a pathological tzinfo
specifically crafted to break it. I think that's an important enough
invariant to be worth keeping, since it is the only possible way to
provide a total order in the presence of interzone comparisons.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 15:25, Alexander Belopolsky wrote:
> This is a fine attitude when you implement your own brand new datetime
> library.  As an author of a new library you have freedoms that developers
> of a 12 years old widely deployed code don't have.

I'm talking about the real behavior of datetime as it exists *today*,
and has existed for the past 12 years, before any of this "add fold flag
but sort 2:15 fold1 before 2:45 fold0" nonsense gets in. It is an
invariant that is true today, and therefore which you can't rely on any
of the consumers of this 12 years old widely deployed code not to assume
will remain true.

Enforcing an invariant that all ordering is done according to UTC
timestamps would not break any backward compatibility, because there is
not a *single* pair of timestamps that can be represented today with any
*remotely* plausible tzinfo whose order is different from that. For that
matter, a tzinfo where two possible values for fold aren't sufficient to
disambiguate timestamps is *more* plausible than one where the naive
ordering of any two non-fold timestamps is reversed from the UTC order,
yet that case apparently isn't being considered.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Tim]
>> It would be nice to have!  .utcoffset() is an expensive operation
>> as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
>> instead.

[Alex]
> If it  is just a question of optimization,

Yes.  If it's more than just that, then 495 doesn't actually solve the
problem of getting the correct UTC offset in all cases.


> datetime objects can be extended to cache utcoffset.  Note that PyPy
> have recently added caching of the hash values in datetime objects.  I
> merged their changes in our datetime.py, but it did not look like C
> implementation would benefit from it as much as pure python did.  I
> expect something similar from caching utcoffset: a measurable
> improvement for tzinfos implemented in Python and a wash for those
> implemented in C.  (A more promising optimization approach is to define a C
> API for tzinfo interface.)

There's no answer to this.  It depends on how expensive .utcoffset()
is, which in turn depends on how the tzinfo author implements it.

I don't care now fast it is.  But, even if I did, "premature
optimization" applies at this time ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alexander Belopolsky]

On Mon, Sep 14, 2015 at 3:13 PM, Random832  wrote:

> (No, I don't
> *care* how that's not how it's defined, it is *in fact* true for the UTC
> value that you will ever actually get from converting the values to UTC
> *today*, and it's the only total ordering that actually makes any sense)
>

This is a fine attitude when you implement your own brand new datetime
library.  As an author of a new library you have freedoms that developers
of a 12 years old widely deployed code don't have.
-- 
https://mail.python.org/mailman/listinfo/python-list

need help with selenium

[shiva upreti]

I wrote this code in python for submitting a login form: 

 
from selenium import webdriver 
from selenium.webdriver.common.keys import Keys 
driver = webdriver.Firefox() 

driver.get('some url') 

elem = driver.find_element_by_name("username") 
elem.send_keys('13103666') 
elem = driver.find_element_by_name("password") 
elem.send_keys('as') 
driver.find_element_by_name("btnSubmit").click() 
#nothing happens from here 
print driver.page_source 
print "test" 
 

After clicking on submit button, a message is displayed on the same page 
whether login was successful or not. 
However after clicking on submit button, I lose control over the web page. I 
can't use any selenium functions now like 'driver.find_element_by_name()'. 

Initially everything works fine. I can enter username and password using 
selenium as written in my code, but once I click on submit button or press 
return key(tried both using selenium), any script written after that(involving 
web driver) doesnt seem to work. Even driver.close() doesnt work. 
This is the form I am trying to submit: 
 

The submission is successful, however after submission I cant verify if login 
was successful or not because of the issue I posted above. 
Do I need to switch web handle? If, then how. 

Any help will be highly appreciated. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alexander Belopolsky]

On Mon, Sep 14, 2015 at 3:30 PM, Tim Peters  wrote:

> > make it much cheaper to maintain global invariants like a sort order
> > according to the UTC value
>
> It would be nice to have!  .utcoffset() is an expensive operation
> as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
> instead.


If it  is just a question of optimization, datetime objects can be extended
to cache utcoffset.  Note that PyPy have recently added caching of the hash
values in datetime objects.  I merged their changes in our datetime.py, but
it did not look like C implementation would benefit from it as much as pure
python did.  I expect something similar from caching utcoffset: a
measurable improvement for tzinfos implemented in Python and a wash for
those implemented in C.  (A more promising optimization approach is to
define a C API for tzinfo interface.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Ned Batchelder  writes:
...
> What do you feel is missing from Steven's diagram?

I don't feel anything missing because I don't expect the model to be
more detailed.

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 04:53, Laura Creighton wrote:
> But this is not quite the complete story.  In many (most?) places in
> Saskatchewan, the rule is understood differently.  Instead of 'we keep
> to CST all year long' is is understood that  'we keep central time in
> the winter and mountain time in the summer'.

As far as I know, the position of the tzdata people is that while this
belief is held almost everywhere that does not observe DST but is
surrounded by places that do (I should know; I live in Indiana, which
was such a place until 2006), almost nowhere does it have any formal
legitimacy, and systems that use the data therefore, by design, will not
actually generate "CST/MDT" timestamps.

When exactly is this transition supposed to take place? At 2AM, Manitoba
springs forward, but Alberta remains on MST for another hour - nowhere
else in North America *but* Saskatchewan uses an offset of -06:00 for
this hour-long period.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Tim]
>> So, on your own machine, whenever daylight time starts or ends, you
>> manually change your TZ environment variable to specify the newly
>> appropriate eternally-fixed-offset zone?  Of course not.

[Random832 ]
> No, but the hybrid zone isn't what gets attached to the individual
> struct tm value when you convert a time from utc (or from a POSIX
> timestamp) to a timezone local value. A single fixed utc offset is
> (along with the name and, yes, isdst flag).

You're assuming much more than POSIX - and the ISO C standard -
requirs.  My description was quite explicitly about how POSIX has done
it all along.  tm_gmtoff and tm_zone are extensions to the standards,
introduced (IIRC) by BSD.  Portable code (including Python's
implementation) can't assume they're available.


> And pytz doesn't involve manually changing anything, it involves (as
> best it can) automatically applying the value to attach to each
> individual datetime value.

.normalize() is a manual step.  It doesn't invoke itself by magic
(although I believe Stuart would like Python to add internal hooks so
pytz _could_ get it invoked by magic).


>> A datetime object is the Python spelling of a C struct tm, but never
>> included the tm_isdst flag.

> And no-one behind this proposal seems to be contemplating adding an
> equivalent to tm_gmtoff,

It was off the table because, for backward compatibility, we need to
mess with the pickle format as little as possible.  It's vital that
datetimes obtained from old pickles continue to work fine, and that
pickles obtained from new datetime objects work fine when loaded by
older Pythons unless they actually require the new fold=1 possibility.

> despite that it would serve the same disambiguation purpose and
> make it much cheaper to maintain global invariants like a sort order
> according to the UTC value

It would be nice to have!  .utcoffset() is an expensive operation
as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
instead.


> (No, I don't *care* how that's not how it's defined,

?  How what is defined?:


> it is *in fact* true for the UTC value that you will ever actually get
> from converting the values to UTC *today*, and it's the only total
> ordering that actually makes any sense)

Well, you lost me there.  In a post-495 world, conversion to UTC will
work correctly in all cases.  It cannot today.;
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Guido]
>> Wouldn't it be sufficient for people in Creighton to set their timezone to
>> US/Central? IIUC the Canadian DST rules are the same as the US ones. Now,
>> the question may remain how do people know what to set their timezone to.
>> But neither pytz nor datetime can help with that -- it is up to the
>> sysadmin.

[Laura Creighton]
> The Canadian DST rules are not the same as the US ones, wherein lies
> the rub.

?   All US locations observing DST switch at 2AM on the local clock on
the 2nd Sunday of March and the 1st Sunday of November (since 2007).
Best I can tell, exactly the same is true of all zones observing DST
in Canada and in Mexico.

  The province of Saskatchewan has a few areas which prefer to
> be on Mountain time, which we will ignore in this mail.  The bulk of
> them prefer to be on Central time, which is the same as Winnipeg and
> Chicago.  But what happens on DST start day (early March) in
> Saskachewan?  Provincial law mandates that you do not change your
> clock, and do not adopt daylight savings time.  The people in
> Saskachewan thus stick to CST all year round.  And this is how
> sites like http://www.timeanddate.com/worldclock/canada/saskatoon
> record things, with them at CST.

I'm sure Guido is only talking about places in Canada that _do_
observe DST.  There are also places in the US that don't observe DST.
Of course "the DST rules" only apply to locations that do observe DST,
and that's what Guido is asking about.


> However, the people of Creighton have decided to keep DST, in
> violation of the law, so they set their clocks forward.
> http://www.timeanddate.com/worldclock/canada/creighton does this
> properly as well, showing them with CDT.
>
> But this is not quite the complete story.  In many (most?) places in
> Saskatchewan, the rule is understood differently.  Instead of 'we keep
> to CST all year long' is is understood that  'we keep central time in
> the winter and mountain time in the summer'.
>
> This makes parsing log files from all over Saskachewan, where sometime
> in March things often stop saying CST and say MDT instead rather more
> interesting than the adverage person might suspect.

Read question as "in general" ;-)  There are plenty of exceptions to
the general rules all over the world.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 14:53, Tim Peters wrote:
> So, on your own machine, whenever daylight time starts or ends, you
> manually change your TZ environment variable to specify the newly
> appropriate eternally-fixed-offset zone?  Of course not.

No, but the hybrid zone isn't what gets attached to the individual
struct tm value when you convert a time from utc (or from a POSIX
timestamp) to a timezone local value. A single fixed utc offset is
(along with the name and, yes, isdst flag).

And pytz doesn't involve manually changing anything, it involves (as
best it can) automatically applying the value to attach to each
individual datetime value.

> A datetime object is the Python spelling of a C struct tm, but never
> included the tm_isdst flag.

And no-one behind this proposal seems to be contemplating adding an
equivalent to tm_gmtoff, despite that it would serve the same
disambiguation purpose and make it much cheaper to maintain global
invariants like a sort order according to the UTC value (No, I don't
*care* how that's not how it's defined, it is *in fact* true for the UTC
value that you will ever actually get from converting the values to UTC
*today*, and it's the only total ordering that actually makes any sense)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[Tim]
>> pytz solves it by _never_ creating a hybrid tzinfo.  It only uses
>> eternally-fixed-offset tzinfos.  For example, for a conceptual zone
>> with two possible total UTC offsets (one for "daylight", one for
>> "standard"), there two distinct eternally-fixed-offset tzinfo objects
>> in pytz.  Then an ambiguous time is resolved by _which_ specific
>> tzinfo object is attached.  Typically the "daylight" tzinfo for the
>> first time a repeated local time appears, and the "standard" tzinfo
>> for its second appearance

[Laura Creighton ]
> Yes.  I think this is a really great idea.  I have no idea why other
> people disagree.

Really?


>> In return, you have to use .localize() and .normalize() at various
>> times, because pytz's tzinfo objects themselves are completely blind
>> to the possibility of the total UTC offset changing. .localize() and
>> .normalize() are needed to possibly _replace_ the tzinfo object in
>> use, depending on the then-current date and time.

> Yes.

>>OTOH, `dateutil` does create hybrid tzinfo objects.  No dances are
>>ever needed to possibly replace them.  But it's impossible for
>>dateutil's tzinfos to disambiguate times in a fold.  Incidentally,
>>dateutil also makes no attempt to account for transitions other than
>>DST (e.g., sometimes a zone may change its _base_ ("standard") offset
>>from UTC).

> I find this totally unacceptable.

The precise referent for "this" isn't clear to me.  The lack of
knowledge of base-offset transitions is a property of dateutil's
implementation, due to inheriting the default .fromutc() instead of
implementing its own to take advantage of all the transition info a
tzfile records.  It's not _inherent_ to hybrid tzinfos.  Just an
omission in this specific zoneinfo wrapping.


> My conclusion was that hybrid tzinfo
> objects were a _really stupid idea_ proposed by somebody who misunderstood
> the problem, or rather only understood the most common case.  Smack them
> with a dead fish,  https://www.youtube.com/watch?v=i9SSOWORzw4
> and get back to work.

So, on your own machine, whenever daylight time starts or ends, you
manually change your TZ environment variable to specify the newly
appropriate eternally-fixed-offset zone?  Of course not.  Your OS
doesn't change it for you by magic either.  Your OS implements a
hybrid tzinfo:   it knows all by itself what the appropriate current
total UTC offset is, by consulting the tzfile (or hybrid POSIX TZ
rule) you attached to your account the last time you set it, however
many years ago that may have been.  Indeed, I don't know of any
software package _other_ than pytz doing it the "switch
eternally-fixed-offset zones" way.  Not that it's impossible Stuart is
the first person in history not to implement it in a "really stupid"
way ;-)  But it was more that Stuart made heroic efforts to leap the
datetime design gap explained next:

In all POSIX-ish OSes, hybrid tzinfos are just business as usual:  a
struct tm's tm_isdst flag distinguishes ambiguous times.  localtime()
(UTC->local) sets tm_isdst by magic for you, and mktime() (local->UTC)
consults tm_isdst to disambiguate local times in a fold.

A datetime object is the Python spelling of a C struct tm, but never
included the tm_isdst flag.  PEP 495 aims to supply a similar bit.
When it does, hybrid tzinfos will do cross-zone conversions correctly
in all cases.  Before then, pytz uses eternally-fixed-offset zones
primarily to overcome the current lack of that bit.

C's localtime() and mktime() are both spelled .astimezone(...) in
Python, but under the covers localtime() is essentially Python's
fromutc() (which will set the new bit appropriately after 495) and
mktime() is essentially .utcoffset() (which will consult the new bit
after 495).

That's all there is to it.  "In theory" ;-)  datetime will become
more-or-less exactly as stupid as POSIX has been for some decades.


>> So, yup, if you're thoroughly indoctrinated in pytz behavior, you will
>> be accurate but appear insane to Guido ;-)  At a semantic level, a
>> pytz tzinfo doesn't capture the notion of a zone with offset changes -
>> it doesn't even try to.  All knowledge about offset changes is inside
>> the .localize() and .normalize() dances.

> I can see why people would like to modify it to spit out this information
> when asked.  I don't understand why they would like to have a hybrid
> tzinfo.  The notion of replacing tzinfos when they become inappropriate
> fills their souls with revulsion, or something?

Because, e.g., a hybrid tzinfo (after 495) _can_ do it correctly all
the time, with no need for user interventions ever.  Same as your OS
does.  That's about usability and lack of surprise.  It didn't take
much web cruising, e.g., to find baffled new pytz users wondering why
the zone displayed "was wrong" sometimes in utterly unexceptional
cases (nowhere near a fold or a gap).  "Read the docs!  normalize()!"
Why should they _have_ to?  The only other things in their life that
demand they manual

Re: Terminology: "reference" versus "pointer"

[Ned Batchelder]

On Monday, September 14, 2015 at 1:26:39 PM UTC-4, Akira Li wrote:
> My point is that neither models are detailed enough to describe
> meaningfully the behavior of Python code in the general case.

This is of course true, because a model is never detailed enough to
fully describe the real thing.

I'm curious what aspect of the example here isn't meaningfully
described by the boxes and arrows notation?  It seems to me that
usually the problem is that the diagram is simplified at a certain
level of detail.  For example, the range objects here are presented
as atomic, without revealing that they hold references to other
objects.

What do you feel is missing from Steven's diagram?

--Ned.

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

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:

> On Mon, Sep 14, 2015, at 13:45, Akira Li wrote:
>>[box + arrow pointing to] + object == parcel tag + object
>
> The problem is that if there are multiple namespaces, or if you've also
> got to include references from within other objects such as list, then
> you've got to write all that somehow on the parcel tag, instead of just
> having different places the arrows can start from.
>
> The box and arrow model easily extends to this, and the fact that no-one
> can make up their mind on what to *call* the thing the arrows represent
> doesn't mean they don't exist.

box has arrow, parcel tag has string/thread.
We could attach an arrow instead of a string to the parcel tag.

The box does not contain anything inside (we can attach the arrow
outside the box -- nothing changes).

If the box does not contain anything then we could use a parcel tag
instead.


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

Re: How to set the history commands visible ?

[Ian Kelly]

On Mon, Sep 14, 2015 at 3:55 AM, Laura Creighton  wrote:
> It definitely was with replying to me with the regular, not browser
> app.  I will be overjoyed to hear that gmail respects text-only
>
> Thread stats here:
> https://mail.python.org/pipermail/python-list/2015-July/694572.html
>
> On the other hand, it may be related to one particular gmail user's
> emacs settings:
> https://mail.python.org/pipermail/python-list/2015-July/694657.html
>
> except that I got the same behaviour from a different user, I forget
> whom I asked to check this.  Clearly wasn't you ...
>
> This may be a case of 'how pleasant to be wrong' ...

I remember that thread, and as I recall the user was apparently using
Emacs Gnus to post to Gmane. Gmail was not involved at all.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 13:51, Emile van Sebille wrote:
> Actually, boxes with integers in them isn't the appropriate analogy. 
> Consider the naming of cats.  My cat is known to me as Paddy.  My next 
> door neighbor sometimes feeds her and is known to her as Stripes.  The 
> cat also is known as kitty to my youngest daughter.  The cat has no idea 
> what its name is, it just is and eats.  So three labels, one object. 
> Putting the object in three boxes isn't right

The point is that with immutable objects no-one cares if they are three
objects with the same value, or three references to the same object.
Your cat is not an integer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 13:45, Akira Li wrote:
>[box + arrow pointing to] + object == parcel tag + object

The problem is that if there are multiple namespaces, or if you've also
got to include references from within other objects such as list, then
you've got to write all that somehow on the parcel tag, instead of just
having different places the arrows can start from.

The box and arrow model easily extends to this, and the fact that no-one
can make up their mind on what to *call* the thing the arrows represent
doesn't mean they don't exist.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Tue, Sep 15, 2015 at 3:51 AM, Emile van Sebille  wrote:
> Actually, boxes with integers in them isn't the appropriate analogy.
> Consider the naming of cats.  My cat is known to me as Paddy.  My next door
> neighbor sometimes feeds her and is known to her as Stripes.  The cat also
> is known as kitty to my youngest daughter.  The cat has no idea what its
> name is, it just is and eats.

Thanks for that. As someone who shares a house with a cat (not my
own), I find this apt and amusing. :)

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

Re: Cannot create a virtualenv

[Kev Dwyer]

paul.hermeneu...@gmail.com wrote:

> - I downloaded and installed Python 3.5 64-bit onto a Windows 7 64-bit
> machine. - Using `pip install virtualenv` worked fine.
> - Now, it is time to create a virtualenv, but it is not working fine.
> - I had to add Python 3.5 to the PATH.
> - Any suggestions?
> 
> C:\ve>virtualenv -p "\Program Files\Python 3.5\python.exe" ve33
> Running virtualenv with interpreter C:\Program Files\Python 3.5\python.exe
> Using base prefix 'C:\\Program Files\\Python 3.5'
> New python executable in ve33\Scripts\python.exe
> Installing setuptools, pip, wheel...
>   Complete output from command C:\ve\ve33\Scripts\python.exe -c
> "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel:
>   Ignoring indexes: https://pypi.python.org/simple
> Collecting setuptools
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   The repository located at None is not a trusted or secure host and
> is being ignored. If this repository is available via HTTPS it is
> recommended to use HTTPS instead, otherwis
> e you may silence this warning and allow it anyways with '--trusted-host
> None'.
>   Could not find a version that satisfies the requirement setuptools
> (from versions: )
> No matching distribution found for setuptools
> 
> ...Installing setuptools, pip, wheel...done.
> Traceback (most recent call last):
>   File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
> line 2363, in 
> main()
>   File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
> line 832, in main
> symlink=options.symlink)
>   File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
> line 1004, in create_environment
> install_wheel(to_install, py_executable, search_dirs)
>   File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
> line 969, in install_wheel
> 'PIP_NO_INDEX': '1'
>   File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
> line 910, in call_subprocess
> % (cmd_desc, proc.returncode))
> OSError: Command C:\ve\ve33\Scripts\python.exe -c "import sys, pip;
> sys...d\"] + sys.argv[1:]))" setuptools pip wheel failed with error
> code 1


Have you tried using the venv module?

https://docs.python.org/3/library/venv.html

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

Re: Terminology: "reference" versus "pointer"

[Emile van Sebille]

On 9/14/2015 10:34 AM, Random832 wrote:


Personally I think it's a bit silly to insist on a diagram model where a
box with an arrow in it pointing at an int object can't be represented
by a box with an integer in it (where 'int' is any immutable type -
string, tuple, even range), but people don't like boxes with integers in
them for some reason.


Actually, boxes with integers in them isn't the appropriate analogy. 
Consider the naming of cats.  My cat is known to me as Paddy.  My next 
door neighbor sometimes feeds her and is known to her as Stripes.  The 
cat also is known as kitty to my youngest daughter.  The cat has no idea 
what its name is, it just is and eats.  So three labels, one object. 
Putting the object in three boxes isn't right -- how could you know 
(other than checking the id()) that they're the same?


Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,

Emile



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

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:

> On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
>> start, stop, step attributes (corresponding Python ints) may not exist
>> ("the objects we've talking about have never been created") until you
>> request them explicitly.
>
> That's not true in CPython. In fact, the range object in python contains
> *four* reference boxes - one more for length.

Even if it true in CPython. Specific implementations are irrelevant for
the discussions. Python -- the language -- does not mandate any
reference boxes (and given how you interpret the term "box" -- boxes are
not used anywhere).

>> I've mentioned it in another message but to be clear, I consider "parcel
>> tags" [1] and "box and arrows" [2] (boxes are always empty, they only
>> point to objects) models to be the same and different from "labelled
>> box" [3] model (boxes contain objects).
>
> See, I consider the box and arrow to be the same as the labeled box
> model - only the object the boxes contain is an arrow. Except for
> special kinds of boxes implemented in some other language, such as the
> elements of an array from the array module

   [box + arrow pointing to] + object == parcel tag + object

I could draw a picture but it won't be pretty.

"labelled box" model that assumes that objects are inside boxes is
clearly wrong -- it fails if you have two names that refer to the same
object in Python (you can't put the same object into different
boxes).

If a box contains nothing then there is no need for the box. If you
think the box contains "something" then find me the corresponding term
in Python language reference. I don't understand what is "arrow" that
the box might contain exactly. For example I can find what "name",
"object" mean in Python.

> The problem with "parcel tags" is that it represents namespaces - or one
> particular namespace, I've never seen any version of it that even
> clearly talks about locals, let alone different modules - differently
> from other kinds of objects.

I don't understand what are you trying to say here. If you have a
specific example when the "parcel tags" [1] model predicts a _wrong_
behavior; please do provide it. If your point is that "parcel tag" does
not describe in full detail all aspect of the behavior of an arbitrary
Python code then I agree with you (though none of the discussed models
can or should do it).

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

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote:
> On Tue, 15 Sep 2015 01:10 am, Random832 wrote:
> > That's not true in CPython. In fact, the range object in python contains
> > *four* reference boxes - one more for length.
> 
> I really don't see why any of this is relevant to the business being
> discussed.

When you're drawing this sort of diagram then what references are held
by an object are more important than what interfaces it implements.

Personally I think it's a bit silly to insist on a diagram model where a
box with an arrow in it pointing at an int object can't be represented
by a box with an integer in it (where 'int' is any immutable type -
string, tuple, even range), but people don't like boxes with integers in
them for some reason.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Steven D'Aprano  writes:

> On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote:
>
>> Steven D'Aprano  writes:
>> 
>>> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
 Look at the last example:
 http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>>>
>>>
>>> I'm afraid that page is broken in my browser. Can you not summarise, or
>>> link to the specific message? I may be able to use another browser in a
>>> day or two, but hopefully the discussion will have moved on by then.
>> 
>> https://mail.python.org/pipermail/python-list/2015-September/696631.html
>
> Thanks. You mean this example?
>
>   lst = [range(1, 3) for _ in range(3)]
>   a = [lst[0], lst[0]]
>   b = [lst[1], lst[2]]
>
>
> I don't see what's difficult about this example. Here's a simple ASCII
> drawing:
>
>
> lst > [ range-object-1 , range-object-2 , range-object-3 ]
>
> a --> [ range-object-1 , range-object-1 ]
>
> b --> [ range-object-2 , range-object-3 ]
>

I should have mentioned that lst plays the role of range-object-X in
your diagram i.e., only *a*, *b* names actualy exits (I should add `del
lst` to the example) -- as the original example requires.


> Trying to draw an arrow diagram using text is not my idea of a good time,
> but I'll give it a go. Requires a monospaced font and an email client that
> won't reflow the text:
>
>   +-+--+
>   | |  | <--- a
>   +--|--+---|--+
>  |  |
>  |  |
>  V  |
>   +-+ <-+ ++
>   |range| <---|-   |< lst 
>   +-+ ++
>   +---|-   |
>   +-+ |   ++
>   +-> |range| <---++--|-   |
>   |   +-+  |  ++
>   ||
>   |   +-+  |
>   |   |range| <+
>   |   +-+
>   |  ^
> +-|-+|
> |   ||
> +---+|
> |  -|+
> +---+
>   ^
>   |
>   +--- b
>
>
> Out of the two, I know which one I prefer.

I don't know what it means. If you mean "box and arrows" is superior
somehow then I don't see any difference from the "parcel tags" model
here.

My point is that neither models are detailed enough to describe
meaningfully the behavior of Python code in the general case.

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Laura Creighton]

In a message of Mon, 14 Sep 2015 09:30:43 -0400, Random832 writes:
>On Mon, Sep 14, 2015, at 04:27, Laura Creighton wrote:
>> I find this totally unacceptable.  My conclusion was that hybrid tzinfo
>> objects were a _really stupid idea_ proposed by somebody who
>> misunderstood
>> the problem, or rather only understood the most common case.
>
>"Hybrid tzinfo objects" _in isolation_ are not bad. The problem isn't
>the objects themselves, it's the whole design:
>
>1. Hybrid tzinfo objects
>2. Attached tzinfo object as the _only_ way to identify the timezone of
>a datetime (no offset member)
>3. Datetime itself stored in local time.

Ah, thank you for explaining.  I thought the only reason you would
want a hybrid tzinfo number is that you absolutely did not want
an offset number.  Which is the part I found, ah, nutty.

I see now that it doesn't have to be this way.

Laura

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

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote:

> Steven D'Aprano  writes:
> 
>> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
>>> Look at the last example:
>>> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>>
>>
>> I'm afraid that page is broken in my browser. Can you not summarise, or
>> link to the specific message? I may be able to use another browser in a
>> day or two, but hopefully the discussion will have moved on by then.
> 
> https://mail.python.org/pipermail/python-list/2015-September/696631.html

Thanks. You mean this example?

  lst = [range(1, 3) for _ in range(3)]
  a = [lst[0], lst[0]]
  b = [lst[1], lst[2]]


I don't see what's difficult about this example. Here's a simple ASCII
drawing:


lst > [ range-object-1 , range-object-2 , range-object-3 ]

a --> [ range-object-1 , range-object-1 ]

b --> [ range-object-2 , range-object-3 ]



Trying to draw an arrow diagram using text is not my idea of a good time,
but I'll give it a go. Requires a monospaced font and an email client that
won't reflow the text:

  +-+--+
  | |  | <--- a
  +--|--+---|--+
 |  |
 |  |
 V  |
  +-+ <-+ ++
  |range| <---|-   |< lst 
  +-+ ++
  +---|-   |
  +-+ |   ++
  +-> |range| <---++--|-   |
  |   +-+  |  ++
  ||
  |   +-+  |
  |   |range| <+
  |   +-+
  |  ^
+-|-+|
|   ||
+---+|
|  -|+
+---+
  ^
  |
  +--- b



Out of the two, I know which one I prefer.



-- 
Steven

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

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Tue, 15 Sep 2015 01:10 am, Random832 wrote:

> On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
>> start, stop, step attributes (corresponding Python ints) may not exist
>> ("the objects we've talking about have never been created") until you
>> request them explicitly.
> 
> That's not true in CPython. In fact, the range object in python contains
> *four* reference boxes - one more for length.

I really don't see why any of this is relevant to the business being
discussed.

A range object is an object. It has an interface, e.g. it is sized (has a
length), it has start, stop and step attributes.

But the *implementation* of that interface is (1) irrelevant and (2) subject
to change. Maybe the __len__ method calculates the length on the fly. Maybe
start, stop and step are virtual attributes that extract the appropriate
values from a C-level datastructure inaccessible to pure Python code.

Unless you are the author of the range class, you don't really have any
business worrying about whether range.start is a "reference" to the start
value, or something computed on the fly as needed. It could be either.


-- 
Steven

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

Re: how to build windows extensions for python 3.5

[Mark Lawrence]

On 14/09/2015 16:52, Robin Becker wrote:

I understand there have been changes to the way that extensions are
supposed to be built for windows. Is there any user documentation
regarding these changes? Last time I looked the appropriate Visual
Studio hadn't been release so I guess I will need to use my MSDN skills
(or incantations) to first get that installed.


http://stevedower.id.au/blog/building-for-python-3-5-part-two/

The most important thing is to have something to do while the Visual
Studio installation takes up 8G of your disk space and several hours of 
elapsed time.  At least the installation went smoothly.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: how to build windows extensions for python 3.5

[Zachary Ware]

On Mon, Sep 14, 2015 at 10:52 AM, Robin Becker  wrote:
> I understand there have been changes to the way that extensions are supposed
> to be built for windows. Is there any user documentation regarding these
> changes? Last time I looked the appropriate Visual Studio hadn't been
> release so I guess I will need to use my MSDN skills (or incantations) to
> first get that installed.

Visual Studio 2015 has been released for about 7 weeks now.  Community
Edition (the free one) should be plenty to compile Python extensions
in either 32 or 64 bit.  In general, if you build your extensions
using distutils, it should still 'just work', but some truly exotic
situations may be different (or broken, in which case please file
bugs!).  Unfortunately I don't have any kind of documentation quick to
hand for this.

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

how to build windows extensions for python 3.5

[Robin Becker]

I understand there have been changes to the way that extensions are supposed to 
be built for windows. Is there any user documentation regarding these changes? 
Last time I looked the appropriate Visual Studio hadn't been release so I guess 
I will need to use my MSDN skills (or incantations) to first get that installed.

--
Robin Becker

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

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
> start, stop, step attributes (corresponding Python ints) may not exist
> ("the objects we've talking about have never been created") until you
> request them explicitly.

That's not true in CPython. In fact, the range object in python contains
*four* reference boxes - one more for length.

> I've mentioned it in another message but to be clear, I consider "parcel
> tags" [1] and "box and arrows" [2] (boxes are always empty, they only
> point to objects) models to be the same and different from "labelled
> box" [3] model (boxes contain objects).

See, I consider the box and arrow to be the same as the labeled box
model - only the object the boxes contain is an arrow. Except for
special kinds of boxes implemented in some other language, such as the
elements of an array from the array module

The problem with "parcel tags" is that it represents namespaces - or one
particular namespace, I've never seen any version of it that even
clearly talks about locals, let alone different modules - differently
from other kinds of objects.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:
...
> Why can't it describe range(1)? A range object in my model would include
> the start, stop, and step; _not_ the contents of what you would get by
> iterating over it; since that's not part of the physical structure of
> the object, but the consequences of calling methods on it.

start, stop, step attributes (corresponding Python ints) may not exist
("the objects we've talking about have never been created") until you
request them explicitly.

I've mentioned it in another message but to be clear, I consider "parcel
tags" [1] and "box and arrows" [2] (boxes are always empty, they only
point to objects) models to be the same and different from "labelled
box" [3] model (boxes contain objects).

[1]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names
[2]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A&mode=display&origin=opt-frontend.js&cumulative=false&heapPrimitives=false&textReferences=false&py=3&rawInputLstJSON=%5B%5D&curInstr=6
[3]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
 

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Random832]

On Mon, Sep 14, 2015, at 04:27, Laura Creighton wrote:
> I find this totally unacceptable.  My conclusion was that hybrid tzinfo
> objects were a _really stupid idea_ proposed by somebody who
> misunderstood
> the problem, or rather only understood the most common case.

"Hybrid tzinfo objects" _in isolation_ are not bad. The problem isn't
the objects themselves, it's the whole design:

1. Hybrid tzinfo objects
2. Attached tzinfo object as the _only_ way to identify the timezone of
a datetime (no offset member)
3. Datetime itself stored in local time.

There's a reason that other languages store the offset explicitly -
because it causes the datetime+offset object to uniquely identify a
specific moment in time, and _without_ having to call in to any complex
logic [i.e. the tzinfo object's utcoffset method]. Normalizing the
results of "classic arithmetic" could (and should) be solved by
providing a hook that calls a method on the tzinfo object to find the
new offset for the result of the operation.

A "hybrid tzinfo object" is itself, in principle, exactly the same kind
of thing that, in C, is returned by tzalloc and used by localtime_rz, on
systems that have those functions. The difference is, this object is
explicitly managed rather than being "attached" to struct tm objects.

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

Re: RPI.GPIO Help

[hakugin . gin]

On Sunday, September 13, 2015 at 2:09:11 AM UTC-4, John McKenzie wrote:
> Hello, there.



> 
>  Hakugin, thank you you as well. I took the basic ideas you showed me for 
> improvement and used them. The pulse settings variable was not liked by 
> the interpreter, so I simplified it. I turned it into a hex value for 
> each button press, then in the main loop I inserted the whole line for 
> the LED pulse command, but put "pulse_settings" after "hex=" in the 
> arguments. This worked.
> 

I realized the error with my example after I got home and forgot to update it. 
The issue was with:

(red=255, green=0, blue=0, repeats=1, duration=2000, steps=50)

I had copied and pasted that and should have removed the "red=", "green=", etc. 
I'm glad you were able to work it out.

>  I added a few green blinks of the LED to indicate the starting and 
> stopping of the script. Also, I got the log files score print outs upon 
> exit working. Very important, and also importantly, I have it so it stops 
> after a certain amount of time. For testing, I have it at 60 seconds, but 
> games will be 3600 seconds on average when really being used.
> 
>  The stopping after a certain amount of time was done in a way that 
> apparently technically works, but seems very weird and probably wrong to 
> me. You may freak out when you see it. I used an else statement inside a 
> while loop and it just feels so strange. At least it works.
> 
>  Hoping I might be able to make it so I boot the Pi, it loads the script, 
> script waits for the user to tell it how long to make a game, game 
> starts, scripts ends game at appropriate time, saves dated log file with 
> scores, then waits for user to enter new game length to start new game. 
> This is probably way to much to hope to accomplish in time. For next year 
> for sure though. It would be better for the referees to operate that way.
> 

Having the game load when the Pi starts is fairly easy, but I'd recommend 
searching the official Raspberry Pi forums. Last time I was there I saw quite a 
few posts on various ways to accomplish this.

As for allowing someone to enter a game time limit you can change your 
"gamelength" variable assignment to something along the lines of:

gamelength = None

while not isinstance(gamelength, int):
gamelength = raw_input("Please enter a game time limit:\n")
try:
gamelength = int(gamelength) # Converts to integer
except:
print("Invalid entry. Time limit must be a number.\n")
pass # ignore error and allow the loop to start over

I was able to test this code, and you will want to add it before your main game 
loop.

>  Next I will try and integrate wireless communications. If anyone here 
> knows Synapse RF modules well, or at all, PLEASE contact me.
> 
> 
>  Here is the code I did up most recently. Again, thanks for all the 
> suggestions, code examples, and general help.
> 



> 
> while time.time() < gamestart + gamelength:
>

This is actually how I personally would have accomplished the task of having it 
end at a specific time. There may be other ways though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to set the history commands visible ?

[Oscar Benjamin]

On 14 September 2015 at 09:24, Chris Angelico  wrote:
> On Mon, Sep 14, 2015 at 6:01 PM, Laura Creighton  wrote:
>> Since you are a gmail user, you should be able to see this:
>>
> import sys
> import os
> import tkinter
> from __future__ import print_function
> for i in range(3):
>> ... print (i)
>> ...
>> 0
>> 1
>> 2
>>
>> Now try to reply to me, quoting this in gmail.  Gmail will happily reflow
>> the lines above.
>>
>
> I, too, am using Gmail, and I simply selected those lines and clicked
> into the Reply box.

I've also just done the same but this is only possible if you've
enabled the "quote selected text" extension from the labs part of your
gmail settings. Perhaps it works differently if you just reply to the
whole thing...

> No wrapping in evidence.

There's no wrapping but now that Laura's repl session has two extra >
characters it looks like a mix of text at 5 and 2 level quoting depth.
This is why I would put spaces at the start of those lines. Not just
gmail but other mail clients will confuse this with different levels
of quoted text and it gets harder to read than it would if it were
indented.

> Is it a problem specific
> to the mobile app? I'm using the regular in-browser form.

A further confounding point is google's new "inbox" which is a
different interface to a gmail account. It has a number of features
that actually make it useful for _reading_ mailing lists but it's not
very good for replying: no plain text mode, top-post by default
(without even showing the ... to represent the quoted text - pop-out
reply to see that) and it quotes using a vertical line rather than >
characters and so on. From the mailing list end I'm not sure if it's
possible to tell whether someone has sent their reply from regular
gmail (like this one) or from inbox.

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

Re: How to set the history commands visible ?

[Laura Creighton]

In a message of Mon, 14 Sep 2015 18:24:42 +1000, Chris Angelico writes:
>On Mon, Sep 14, 2015 at 6:01 PM, Laura Creighton  wrote:
>> Since you are a gmail user, you should be able to see this:
>>
> import sys
> import os
> import tkinter
> from __future__ import print_function
> for i in range(3):
>> ... print (i)
>> ...
>> 0
>> 1
>> 2
>>
>> Now try to reply to me, quoting this in gmail.  Gmail will happily reflow
>> the lines above.
>>
>
>I, too, am using Gmail, and I simply selected those lines and clicked
>into the Reply box. No wrapping in evidence. Is it a problem specific
>to the mobile app? I'm using the regular in-browser form.
>
>Or does the wrapping occur at the next stage?
>
>ChrisA

It definitely was with replying to me with the regular, not browser
app.  I will be overjoyed to hear that gmail respects text-only

Thread stats here:
https://mail.python.org/pipermail/python-list/2015-July/694572.html

On the other hand, it may be related to one particular gmail user's
emacs settings:
https://mail.python.org/pipermail/python-list/2015-July/694657.html

except that I got the same behaviour from a different user, I forget
whom I asked to check this.  Clearly wasn't you ...

This may be a case of 'how pleasant to be wrong' ...

Laura


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

Re: Can't use Python Launcher on Windows after update to 3.5

[Laura Creighton]

In a message of Sun, 13 Sep 2015 23:46:37 +0100, Mark Lawrence writes:

>Exactly the same thing happened when I upgraded to 3.5.0. so raised 
>http://bugs.python.org/issue25089 just in case it hurts other people 
>more than it hurts me.
>
>-- 
>My fellow Pythonistas, ask not what our language can do for you, ask
>what you can do for our language.
>
>Mark Lawrence

Thank you.

Laura

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

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Laura Creighton]

In a message of Sun, 13 Sep 2015 15:21:45 -0700, Guido van Rossum writes:
>Hi Laura!
>
>Wouldn't it be sufficient for people in Creighton to set their timezone to
>US/Central? IIUC the Canadian DST rules are the same as the US ones. Now,
>the question may remain how do people know what to set their timezone to.
>But neither pytz nor datetime can help with that -- it is up to the
>sysadmin.

The Canadian DST rules are not the same as the US ones, wherein lies
the rub.  The province of Saskatchewan has a few areas which prefer to
be on Mountain time, which we will ignore in this mail.  The bulk of
them prefer to be on Central time, which is the same as Winnipeg and
Chicago.  But what happens on DST start day (early March) in
Saskachewan?  Provincial law mandates that you do not change your
clock, and do not adopt daylight savings time.  The people in
Saskachewan thus stick to CST all year round.  And this is how
sites like http://www.timeanddate.com/worldclock/canada/saskatoon
record things, with them at CST.

However, the people of Creighton have decided to keep DST, in
violation of the law, so they set their clocks forward.
http://www.timeanddate.com/worldclock/canada/creighton does this
properly as well, showing them with CDT.

But this is not quite the complete story.  In many (most?) places in
Saskatchewan, the rule is understood differently.  Instead of 'we keep
to CST all year long' is is understood that  'we keep central time in
the winter and mountain time in the summer'.

This makes parsing log files from all over Saskachewan, where sometime
in March things often stop saying CST and say MDT instead rather more
interesting than the adverage person might suspect.

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

Selenium

[shiva upreti]

I wrote this code in python for submitting a login form:


from selenium import webdriver
from selenium.webdriver.common.keys import Keys
driver = webdriver.Firefox()

driver.get('some url')

elem = driver.find_element_by_name("username")
elem.send_keys('13103666')
elem = driver.find_element_by_name("password")
elem.send_keys('as')
driver.find_element_by_name("btnSubmit").click()
#nothing happens from here
print driver.page_source
print "test"


After clicking on submit button, a message is displayed on the same page 
whether login was successful or not. 
However after clicking on submit button, I lose control over the web page. I 
can't use any selenium functions now like 'driver.find_element_by_name()'.

Initially everything works fine. I can enter username and password using 
selenium as written in my code, but once I click on submit button or press 
return key(tried both using selenium), any script written after that(involving 
web driver) doesnt seem to work. Even driver.close() doesnt work.
This is the form I am trying to submit:


The submission is successful, however after submission I cant verify if login 
was successful or not because of the issue I posted above.
Do I need to switch web handle? If, then how.

Any help will be highly appreciated.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 12-09-15 om 05:48 schreef Steven D'Aprano:
> I believe I already acknowledged that assignment-as-expression was fine if
> it avoided the = versus == error, from the perspective of avoiding errors.
> But from the perspective of a clean and logical programming model, perhaps
> not so much. Assignment is imperative, not functional, and requiring it to
> return a result is somewhat unclean.

I thought practicallity beats purity? AFAICS python doesn't use such a clean
and logical programming model and it isn't given much critique over it.
So I don't think it is fair to critique assignment as an expression because
of this aspect.

> Look at it this way: suppose you had a robot servant that always, without
> fail or misunderstanding, did what you instructed. There are broadly two
> sorts of things that you can give as instructions: questions, and commands.
> Questions always require an answer: "What's the length of this list?" is
> functional. Commands are imperative, not functional, and don't necessarily
> require an answer: "Move the small red pyramid onto the large green cube."
> Some commands arguable might require an answer, but arguable they are
> better served by an out-of-band error condition (an exception). *Requiring*
> all commands to give an answer is silly, given that the robot servant is
> infallible.

But we are not talking about all commands, we are just talking about 
assignments.
Sure an assignment has a side effect. But so has ls.pop(). So something having
a side-effect and a value is not unheard of even within a python context.

-- 
Antoon Pardon

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

ANN: eGenix mxODBC Plone/Zope Database Adapter 2.2.3

[eGenix Team: M.-A. Lemburg]

ANNOUNCING

  mxODBC Plone/Zope Database Adapter

Version 2.2.3

  for the Plone CMS and Zope server platform

  Available for Plone 4.0-4.3 and Plone 5.0,
Zope 2.12 and 2.13, on
Windows, Linux, Mac OS X, FreeBSD and other platforms

This announcement is also available on our web-site for online reading:
http://www.egenix.com/company/news/eGenix-mxODBC-Zope-DA-2.2.3-GA.html


INTRODUCTION

The eGenix mxODBC Zope DA allows you to easily connect your Zope or
Plone CMS installation to just about any database backend on the
market today, giving you the reliability of the commercially supported
eGenix product mxODBC and the flexibility of the ODBC standard as
middle-tier architecture.

The mxODBC Zope Database Adapter is highly portable, just like Zope
itself, and provides a high performance interface to all your ODBC
data sources, using a single well-supported interface on Windows,
Linux, Mac OS X, FreeBSD and other platforms.

This makes it ideal for deployment in ZEO Clusters and Zope hosting
environments where stability and high performance are a top priority,
establishing an excellent basis and scalable solution for your Plone
CMS.

Product page:

http://www.egenix.com/products/zope/mxODBCZopeDA/


NEWS

The 2.2.3 release of our mxODBC Zope/Plone Database Adapter product is
a patch level release of the popular ODBC database interface for Plone
and Zope. It includes these enhancements and fixes:

Feature Updates
---

 * We have integrated a new option to force serialized connects on a
   per Zope connection object basis. This can be used to work around
   bugs in ODBC drivers which are not fully thread-safe in the connect
   phase. The option is disabled per default.

Driver Compatibility Enhancements
-

 * ODBC driver compatibility updated. Upgraded to the latest mxODBC
   3.3.5 release, adding compatibility enhancements for MS SQL
   Server. See the mxODBC 3.3.5 release announcements for full
   details.

Installation Enhancements
-

 * Added pip install compatibility to mxODBC Zope DA by creating
   prebuilt archives and uploading a web installer to PyPI. This can
   be useful if you are installing Zope or Plone using a
   requirements.txt type approach, e.g. using

   pip install ThreadLock Products.ZSQLMethods egenix-mxodbc-zopeda

 * Enabled creating wheels from the prebuilt archives, which helps
   when running pip with the wheels package installed. pip then tries
   to build wheels during installation and caches them for future
   reuse.

The complete list of changes is available on the mxODBC Zope DA
changelog page.

http://www.egenix.com/products/zope/mxODBCZopeDA/changelog.html

mxODBC Zope DA 2.2.0 was released on 2014-12-11. Please see the mxODBC
Zope DA 2.2.0 release announcement for all the new features we have
added.

http://www.egenix.com/company/news/eGenix-mxODBC-Zope-DA-2.2.0-GA.html

For the full list of features, please see the mxODBC Zope DA feature
list:

http://www.egenix.com/products/zope/mxODBCZopeDA/#Features

The complete list of changes is available on the mxODBC Zope DA
changelog page.



UPGRADING

Users are encouraged to upgrade to this latest mxODBC Plone/Zope
Database Adapter release to benefit from the new features and updated
ODBC driver support. We have taken special care not to introduce
backwards incompatible changes, making the upgrade experience as
smooth as possible.

For major and minor upgrade purchases, we will give out 20% discount
coupons going from mxODBC Zope DA 1.x to 2.2 and 50% coupons for
upgrades from mxODBC 2.x to 2.2. After upgrade, use of the original
license from which you upgraded is no longer permitted. Patch level
upgrades (e.g. 2.2.0 to 2.2.3) are always free of charge.

Please contact the eGenix.com Sales Team with your existing license
serials for details for an upgrade discount coupon.

If you want to try the new release before purchase, you can request
30-day evaluation licenses by visiting our web-site or writing to
sa...@egenix.com, stating your name (or the name of the company) and
the number of eval licenses that you need.

http://www.egenix.com/products/python/mxODBCZopeDA/#Evaluation


DOWNLOADS

Please visit the eGenix mxODBC Zope DA product page for downloads,
instructions on installation and documentation of the packages:

http://www.egenix.com/company/products/zope/mxODBCZopeDA/

If you want to try the package, please jump straight to the download
instructions:

http://www.egenix.com/produ

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Laura Creighton]

In a message of Sun, 13 Sep 2015 16:58:09 -0500, Tim Peters writes:
>[Tim]
>>> Whatever time zone the traveler's railroad schedule uses, so long as
>>> it sticks to just one
>
>[Laura]
>> This is what does not happen.  Which is why I have written a python
>> app to perform conversions for my parents, in the past.
>
>So how did they get the right time zone rules for Creighton?

I was fortunate enough that they were never going there.  But in
investigating the problem I had it filed away under 'really ugly hacks
I might have to write in the future'.  Pre-parsing the file with
special mappings for special lookups seemed the only way to fix this,
at the time, but we have newer databases now than I had then ...
some of which might already know about Creighton.

>pytz solves it by _never_ creating a hybrid tzinfo.  It only uses
>eternally-fixed-offset tzinfos.  For example, for a conceptual zone
>with two possible total UTC offsets (one for "daylight", one for
>"standard"), there two distinct eternally-fixed-offset tzinfo objects
>in pytz.  Then an ambiguous time is resolved by _which_ specific
>tzinfo object is attached.  Typically the "daylight" tzinfo for the
>first time a repeated local time appears, and the "standard" tzinfo
>for its second appearance.

Yes.  I think this is a really great idea.  I have no idea why other
people disagree.

>In return, you have to use .localize() and .normalize() at various
>times, because pytz's tzinfo objects themselves are completely blind
>to the possibility of the total UTC offset changing. .localize() and
>.normalize() are needed to possibly _replace_ the tzinfo object in
>use, depending on the then-current date and time.

Yes.  

>OTOH, `dateutil` does create hybrid tzinfo objects.  No dances are
>ever needed to possibly replace them.  But it's impossible for
>dateutil's tzinfos to disambiguate times in a fold.  Incidentally,
>dateutil also makes no attempt to account for transitions other than
>DST (e.g., sometimes a zone may change its _base_ ("standard") offset
>from UTC).

I find this totally unacceptable.  My conclusion was that hybrid tzinfo
objects were a _really stupid idea_ proposed by somebody who misunderstood
the problem, or rather only understood the most common case.  Smack them
with a dead fish,  https://www.youtube.com/watch?v=i9SSOWORzw4
and get back to work.

>So, yup, if you're thoroughly indoctrinated in pytz behavior, you will
>be accurate but appear insane to Guido ;-)  At a semantic level, a
>pytz tzinfo doesn't capture the notion of a zone with offset changes -
>it doesn't even try to.  All knowledge about offset changes is inside
>the .localize() and .normalize() dances.

I can see why people would like to modify it to spit out this information
when asked.  I don't understand why they would like to have a hybrid
tzinfo.  The notion of replacing tzinfos when they become inappropriate
fills their souls with revulsion, or something?

But, as I said, once you know the pytz way you may be ruined for
appreciating other solutions.



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

Re: How to set the history commands visible ?

[Chris Angelico]

On Mon, Sep 14, 2015 at 6:01 PM, Laura Creighton  wrote:
> Since you are a gmail user, you should be able to see this:
>
 import sys
 import os
 import tkinter
 from __future__ import print_function
 for i in range(3):
> ... print (i)
> ...
> 0
> 1
> 2
>
> Now try to reply to me, quoting this in gmail.  Gmail will happily reflow
> the lines above.
>

I, too, am using Gmail, and I simply selected those lines and clicked
into the Reply box. No wrapping in evidence. Is it a problem specific
to the mobile app? I'm using the regular in-browser form.

Or does the wrapping occur at the next stage?

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

Re: How to set the history commands visible ?

[Laura Creighton]

In a message of Sun, 13 Sep 2015 23:35:01 +0200, Glus Xof writes:
>If I'm not wrong, in a later interpreter versions, when an enter key was
>pressed after writing something requiring some indentated statement(s)...
>like in:
>
 for i in range (0,3):
>
>the system used to suggest "one tab" placing the cursor automatically after.
>
>I don't know why this feature doesn't remain yet... or maybe I don't know
>how activate this...
>
>Glus

I think you must have had some sort of custom startup script here.
Maybe even this one:
https://github.com/brandoninvergo/python-startup/blob/master/python-startup.py

though I found it annoying as anything as it only does the tab indent
after you have started typing.

If you decide to hack on custom startup scripts you may be interested in
https://bitbucket.org/pypy/pyrepl

PyPy needed to make a pure python replacement for readline, and did so.
It has some nice support for multi-line editing and a lot of emacs
style keybindings.  I like it.

Also, if you paste output from the interpreter into mail to other
people, you should edit your python startup file to reset sys.PS1 to
not be '>>>' right at the margin.  (mine is ' >>>').  The arrogant
idiots at Google have decided that people who ask for plain text mail
(which you currently cannot do using gmail on android) in no way
should be trusted to know what they are doing.  Thus any text that
begins with some number of '>' can be reflowed, at will, by gmail.

Since you are a gmail user, you should be able to see this:

>>> import sys
>>> import os
>>> import tkinter
>>> from __future__ import print_function
>>> for i in range(3):
... print (i)
...
0
1
2

Now try to reply to me, quoting this in gmail.  Gmail will happily reflow
the lines above.


But it will respect these ones.

 >>> import sys
 >>> import os
 >>> import tkinter
 >>> from __future__ import print_function
 >>> for i in range(3):
... print (i)
...
0
1
2

sys.PS1 is what is giving me ' >>>' and sys.PS2 is ...

If you want sys.PS2 to be a tab, then you can do this as well, but
note that it does not stick a tab into your input buffer for you,
so you will still need to type one -- or whatever number of spaces
you use as an indent.

If I have misunderstood, and your problem is that your editor
no longer suggests tabs, then you have lost your python-mode
settings for that editor.  But we need to know what editor that
is, before we can tell you how to fix it.

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

Re: Terminology: "reference" versus "pointer"

[Random832]

On Sun, Sep 13, 2015, at 19:17, Akira Li wrote:
> "do not physically exist" does not make sense. Objects are *never*
> destroyed explicitly in Python (you can only make them
> *unreachable*).

But the objects we've talking about have never been created, because the
__getitem__ method has not been called, because we're talking about the
structure of what _is there_, not the idea of what will happen after you
call some method. The (range, or whatever) object holds no
reference/pointer/whatever (maybe we should just call them arrows?) to
the objects that it will create when you call __getitem__, or even to
the ones that it has created when you've called it, so it doesn't make
sense to put a box in it that will have an arrow pointing to those
objects.

> You can disable garbage collection completely and it is
> still will be Python. Immutable objects can be considered immortal e.g.:
> 
>  (1+1) -- question: does the object that represents int(2) exist before
> the expression is evaluated?
> 
> The correct answer: it does not matter: int(2) can be created on the
> fly, a cached int(2) can be reused by a specific implementation --
> Python doesn't care.
> 
> I don't see why the model that can't describe range(1) in Python 3
> pretends to be complete.

Why can't it describe range(1)? A range object in my model would include
the start, stop, and step; _not_ the contents of what you would get by
iterating over it; since that's not part of the physical structure of
the object, but the consequences of calling methods on it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Cannot create a virtualenv

[paul . hermeneutic]

- I downloaded and installed Python 3.5 64-bit onto a Windows 7 64-bit machine.
- Using `pip install virtualenv` worked fine.
- Now, it is time to create a virtualenv, but it is not working fine.
- I had to add Python 3.5 to the PATH.
- Any suggestions?

C:\ve>virtualenv -p "\Program Files\Python 3.5\python.exe" ve33
Running virtualenv with interpreter C:\Program Files\Python 3.5\python.exe
Using base prefix 'C:\\Program Files\\Python 3.5'
New python executable in ve33\Scripts\python.exe
Installing setuptools, pip, wheel...
  Complete output from command C:\ve\ve33\Scripts\python.exe -c
"import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel:
  Ignoring indexes: https://pypi.python.org/simple
Collecting setuptools
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  The repository located at None is not a trusted or secure host and
is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwis
e you may silence this warning and allow it anyways with '--trusted-host None'.
  Could not find a version that satisfies the requirement setuptools
(from versions: )
No matching distribution found for setuptools

...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
  File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
line 2363, in 
main()
  File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
line 832, in main
symlink=options.symlink)
  File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
line 1004, in create_environment
install_wheel(to_install, py_executable, search_dirs)
  File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
line 969, in install_wheel
'PIP_NO_INDEX': '1'
  File "c:\program files\python 3.5\lib\site-packages\virtualenv.py",
line 910, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command C:\ve\ve33\Scripts\python.exe -c "import sys, pip;
sys...d\"] + sys.argv[1:]))" setuptools pip wheel failed with error
code 1
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to set the history commands visible ?

[Glus Xof]

Laura,

2015-09-13 22:15 GMT+02:00 Laura Creighton :

> In a message of Sun, 13 Sep 2015 19:15:19 +0200, Glus Xof writes:
> >Hi guys,
> >
> >Today, a new python stable version was released (thanks for your job)...
> >and I write to ask you for the recommended method to compile the sources
> >(in Debian GNU/Linux platfom) in order to the arrow keys emit the history
> >commands instead of... it seems that escape sequences...
> >
> >Python 3.5.0 (default, Sep 13 2015, 17:58:38)
> >[GCC 4.9.2] on linux
> >Type "help", "copyright", "credits" or "license" for more information.
>  ^[[A^[[A^[[B^[[B
> >
> >(I run the configure, make, make test & make install scripts)
>
> It seems your python is not installed with readline support, if
> the arrow keys are not working.
>
> You don't need to recompile python for this.
> Instead you need to install this.
> https://pypi.python.org/pypi/readline
>
> But I am surprised that you need this, as my debian linux unstable
> system has this out of the box, more or less always.
>
> I think this is because I have this package installed
> https://packages.debian.org/stretch/readline-common
> (there are versions for testing and stable as well).
>
> If I were you I would install this first and see if your
> arrow problems go away.  If not, get out pip.
>

Thanks, that's it !!


>
> >Furthermore, I'd like also to ask a simple additional questions:
> >
> >Is yet an automatic indentation system implemented ?
> >How to activate them ?
>
> I am not sure what you mean by this.
> If you, as I, was unhappy as anything about tab in the
> interactive console (at the far margin) meaning 'tab complete
> every builtin on the planet' rather than 'I'd like another level
> of indent please' -- then, 3.5, you are good to go. :)  tabs typed
> flush to the margin just indent.  tabs complete if you type them
> in the middle of an identifier.
>
> If you mean something else, then, well, explain it a little more, ok?
>

If I'm not wrong, in a later interpreter versions, when an enter key was
pressed after writing something requiring some indentated statement(s)...
like in:

>>> for i in range (0,3):

the system used to suggest "one tab" placing the cursor automatically after.

I don't know why this feature doesn't remain yet... or maybe I don't know
how activate this...

Glus



> >Glus
>
> Laura
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Alexander Belopolsky]

On Sun, Sep 13, 2015 at 6:21 PM, Guido van Rossum  wrote:
>
> Now, the question may remain how do people know what to set their
timezone to. But neither pytz nor datetime can help with that -- it is up
to the sysadmin.


Note that this question is also out of the scope of "tzdist", IETF Time
Zone Data Distribution Service Working Group:

"""
The following are Out of scope for the working group:
...
- Lookup protocols or APIs to map a location to a time zone.
""" 

I am not aware of any effort to develop such service. On the other hand,
stationary ISPs have means to distribute TZ information to the hosts.  See
for example, RFC 4833 ("Timezone Options for DHCP").
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Putting the main program in a main function

[Ben Finney]

"ast"  writes:

> The author says that with this structure there are no global variables
> (except when using "global' keyword) and that the program can be
> loaded as a module without be ran to test the function in the python
> shell.
>
> is it advised to always write programs like that ?

Writing all the code in functions makes your code more reliably tested:
you can write a unit test that exercises the code and know whether it is
behaving correctly.

Writing all the code in functions makes your code more understandable:
the possible interactions between different parts of the program are
more explicitly and strictly defined.

So yes, it's advisable to write a ‘main’ function for the application
and keep to absolute minimum the ‘if __name__ == "__main__"’ block.

That said, your ‘main’ function can be slightly more self-contained. The
paradigm for invoking a command-line program is that its input
parameters are the process's command-line arguments, and its return
value is the process's exit status.

So you can write a ‘main’ function that explicitly allows those input
and output to be handled as for a normal function::

import sys

def main(argv=None):
""" Mainline code for this module.

:param argv: The sequence of command-line arguments used to
invoke this program. Defaults to `sys.argv`.
:return: ``None``.

"""
if argv is None:
argv = sys.argv

try:
handle_the_command_line(argv)
do_various_things()

except SystemExit as exc:
exit_status = exc.code
else:
# No exit requested; return “success” status.
exit_status = 0

return exit_status

if __name__ == "__main__":
exit_status = main(sys.argv)
sys.exit(exit_status)

That way, the ‘if __name__ == "__main__"’ block will use the
conventional input (command-line arguments) and output (process exit
status); the rest of the application code may call ‘sys.exit’ or raise
‘SystemExit’ as normal; but your code will wrap it all up as the inputs
and outputs of the ‘main’ function, making it much easier to control for
testing.

Python's BDFL wrote an article many years ago describing this pattern
http://www.artima.com/weblogs/viewpost.jsp?thread=4829>, mine is a
small refinement of that.

-- 
 \ “It is the fundamental duty of the citizen to resist and to |
  `\  restrain the violence of the state.” —Noam Chomsky, 1971 |
_o__)  |
Ben Finney

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

Re: Putting the main program in a main function

[Nobody]

On Mon, 14 Sep 2015 09:13:47 +0200, ast wrote:

> is it advised to always write programs like that ?

If global (module-scope) variables are initialised by main, then those
variables won't exist unless main() is run, which means that you can't use
it as a module, only as a script.

IMHO, global variables whose initial values can be evaluated without
depending upon or modifying external state should be initialised at the
top level.

If a module has variables which cannot be so initialised, the module needs
to provide an initialisation function which must be called explicitly by
any program or module which imports it.

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

Putting the main program in a main function

[ast]

Hi

I saw here http://inventwithpython.com/pygame/chapter3.html
a program where the main program is put in a function.

So the structure is:

def main():
  main code here

def f1():
   function 1 code

def f2():
  function 2 code

..

if __name__ == '__main__':
   main()



The author says that with this structure there are no
global variables (except when using "global' keyword)
and that the program can be loaded as a module without
be ran to test the function in the python shell.

is it advised to always write programs like that ?

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

Re: Python handles globals badly.

[Antoon Pardon]

Op 11-09-15 om 13:59 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> I just don't get why people want to introduce special cases in python.
>> Why allow such a construct only in while and if? Why not just allow
>> it generally as an assignment expression?
>>
>> Why not allow:
>>
>>   while (f(x) as fx) > 5:
>> proces(fx)
>>
>> or
>>
>>   if check(nextvalue() as new):
>> treat(new)
> Hey, I know, I know!... Let's allow:
>
>while (fx = f(x)) > 5:
>process(fx)
>
>if check(new = nextvalue()):
>treat(new)
>
> Seriously, though, I share your distaste of special cases, Antoon. Only
> I don't like too much syntax (just look at Perl).

This proposal would have as an effect less syntax. The 'as ...' syntax
already exists, but as special cases. Making 'as ...' a general assignment
operator would eliminated the special cases and collect them all in the
expression syntax. So less syntax.

>  There's nothing wrong
> in:
>
>while True:
>fx = f(x)
>if fx <= 5:
>break
>process(fx)

There was also nothing wrong with:

  if b > c:
a = 5
  else:
a = 2

>new = nextvalue()
>if check(new):
>treat(new)

Except that it would need an extra indentation level if
it was an elif.

-- 
Antoon Pardon

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

Packaging and deployment of standalone Python applications?

[Kristian Rink]

Folks;

coming from a server-sided Java background, I'm recently exploring frameworks 
such as cherrypy or webpy for building RESTful services, which is quite a 
breeze and a pretty pleasant experience; however one thing so far bugs me: 
Using Java tooling and libraries such as DropWizard, it is pretty 
straightforward to build an "all-inclusive" application containing (a) all code 
of my own, (b) all required dependencies, (c) all other resources and, if 
required, even (d) a Java virtual machine in one large .zip file which can 
easily be copied to a clean Linux VM, unzipped and started there.

Are there ways of doing so using Python, too? I'd like to set up a project 
structure / working environment that includes all Python 3rd party libraries, 
my own code and maybe even a "standard" Python runtime for 64bit Linux systems 
(to not depend too much on what version a certain Linux distribution actually 
ships) and focus on doing deployment to various machines at best by simply 
copying these packages around. 

Any pointers, ideas, inspirations on that greatly appreciated - even in total 
different ways if what I am about to do is completely off anyone would do it in 
a Python environment. ;)

TIA and all the best,
Kristian
-- 
https://mail.python.org/mailman/listinfo/python-list