Re: f-string error message

[Random832 via Python-list]

On Sun, Aug 27, 2023, at 17:19, Rob Cliffe via Python-list wrote:
> I understand that this is an error: I'm telling the f-string to expect 
> an integer when in fact I'm giving it a Decimal.
> And indeed f"{x:3}" gives ' 42' whether x is an int or a Decimal.
> However, to my mind it is not the format string that is invalid, but the 
> value supplied to it.
> Would it be possible to have a different error message, something like
>
> ValueError: int expected in format string but decimal.Decimal found
>
> Or am I missing something?

It's up to the type what format strings are valid for it, so you can't really 
go "int expected". However, a more detailed error string like "invalid format 
string '3d' for object Decimal('42')" might be useful.

right now we have some inconsistencies:
- float object [same for str, int, etc]
ValueError: Unknown format code 'd' for object of type 'float' [if it thinks 
it's identified a single-letter 'code' in the usual microlanguage]
ValueError: Invalid format specifier '???' for object of type '[type]'
- arbitrary object that doesn't override __format__, ipaddress
TypeError: unsupported format string passed to [type].__format__
- datetime, decimal
ValueError: Invalid format string

neither shows the value of the offending object, only its type. incidentally, 
ipaddress and object don't support the usual field width, padding, etc 
specifiers

[int supports code 'f' just fine, by the way, but has the same message as float 
if you give it 's']

Going beyond that, it *might* be viable to have some sort of "guess what 
numeric type the format string was intended for", shared across at least all 
numeric types of objects. Alternatively, we could require all numeric types to 
support all numeric formats, even ones that don't make a lot of sense.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pre-Pre-PEP: The datetime.timedeltacal class

[Random832]

On Sat, Apr 16, 2022, at 13:35, Peter J. Holzer wrote:
> When adding a timedeltacal object to a datetime, the fields are added
> from most to least significant: First a new date is computed by
> advancing the number of months specified [TODO: Research how other
> systems handle overflow (e.g. 2022-01-31 + 1 month: 2022-02-31 doesn't
> exist)], then advance the number of days. Finally add the number of
> seconds and microseconds, taking into accout daylight savings time
> switches if the datetime is time zone aware.
>
> Subtracting a timedeltacal object from a datetime is the same, just in
> the opposite direction.
>
> Note that t + d - d is in general not equal to t.

I'm not sure there's a guarantee that t + n day + m second may not be equal to 
t + m second + n day, either. This is possibly also something that we can look 
at what existing implementations do, though I'm concerned that the choice of 
"fold" rather than "isdst" may come back to bite us here [C actually uses a 
three-state isdst input for mktime which performs these operations]

Also, what about hours? "12 calendar hours" may be 13 or 11 hours depending on 
if a DST transition is included in the given time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

[Random832]

On Tue, Apr 19, 2022, at 07:11, Loris Bennett wrote:
> I now realise that timedelta is not really what I need.  I am interested
> solely in pure periods, i.e. numbers of seconds, that I can convert back
> and forth from a format such as

A timedelta *is* a pure period. A timedelta of one day is 86400 seconds.

The thing you *think* timedelta does [making a day act as 23 or 25 hours across 
daylight saving boundaries etc], that you *don't* want it to do, is something 
it *does not actually do*. I don't know how this can be made more clear to you.

timedelta is what you need. if you think it's not, it's because you're using 
datetime incorrectly.

The real problem is that naive datetime objects [without using either a fixed 
timezone offset like the built-in utc, or a library like pytz] are not fit for 
any purpose.

If you use pytz correctly [which is unfortunately awkward due to leaky 
abstractions and mismatches between the datetime model works and how most 
people expect datetimes with timezones to work], you will indeed get 24 hours 
from timedelta(days=1)

>>> et = pytz.timezone('America/New_York')
>>> et.normalize(et.localize(datetime.datetime(2022,3,12,12,0,0)) + 
>>> datetime.timedelta(days=1))
datetime.datetime(2022, 3, 13, 13, 0, tzinfo=)

you can see here that 2022-03-12T12:00-0500 + timedelta(days=1) correctly 
becomes 2022-03-13T13:00-0400, 24 hours later.

As far as I know, Python doesn't even have a way to represent "1 day" [or 1 
month, 1 year] as a context-dependent-length interval (the thing you think 
timedelta does), at least not within the standard library and the datetime 
model.

>   11-22::44:55
>
> (These are the lengths of time a job has run on an HPC system - leap
> seconds and time zones are of no relevance).
>
> It is obviously fairly easy to rustle up something to do this, but I am
> surprised that this is not baked into Python (such a class also seems to
> be missing from R).  I would have thought that periods crop up all over
> the place and therefore formatting as strings and parsing of string
> would be supported natively by most modern languages.  Apparently not.
>
> Cheers,
>
> Loris
>
> -- 
> This signature is currently under construction.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: use set notation for repr of dict_keys?

[Random832]

On Wed, Feb 24, 2021, at 02:59, Marco Sulla wrote:
> On Wed, 24 Feb 2021 at 06:29, Random832  wrote:
> > I was surprised, though, to find that you can't remove items directly from 
> > the key set, or in general update it in place with &= or -= (these 
> > operators work, but give a new set object).
> 
> This is because they are a view. Changing the key object means you
> will change the underlying dict. Probably not that you want or expect.

Why wouldn't it be what I want or expect? Java allows exactly this [and it's 
the only way provided to, for example, remove all keys matching a predicate in 
a single pass... an operation that Python sets don't support either]

> You can just "cast" them into a "real" set object.
> 
> There was a discussion to implement the whole Set interface for dicts.
> Currently, only `|` is supported.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: use set notation for repr of dict_keys?

[Random832]

On Sat, Feb 20, 2021, at 15:00, dn via Python-list wrote:
> So, the output is not a set (as you say) but nor (as
> apparently-indicated by the square-brackets) is it actually a list!

To be clear, it is an instance of collections.abc.Set, and supports most binary 
operators that sets support.

I was surprised, though, to find that you can't remove items directly from the 
key set, or in general update it in place with &= or -= (these operators work, 
but give a new set object).

AIUI the keys, values, and items collections have always had the ordering 
guarantee that iterating over them while not modifying the underlying 
dictionary will give the same order each time [with respect to each other, and 
possibly also with respect to iterating over the original dictionary to obtain 
the keys]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Response for PING in ircbot.

[Random832]

On Sat, Jan 30, 2021, at 11:50, Bischoop wrote:
> 
> Got problem with responding for Ping, tried so many ways to response
> and always end up with time out or other error. This time:

1. It looks like you're forgetting to send \n\r
2. i'm not sure if the server ping is guaranteed to have : character
3. if it does have : character you need to send everything after it even if it 
includes spaces
4. what happens if the data in recv includes more than one line of data, or 
partial line at the end? this isn't a proper way to handle irc protocol in 
general, let alone the ping command

> ERROR :(Ping timeout: 264 seconds)
> Traceback (most recent call last):
> s.send(bytes('PONG ' + data.split()[1], 'UTF-8'))
> BrokenPipeError: [Errno 32] Broken pipe
> 
> while True:
> time.sleep(2)
> data=s.recv(2040).decode('utf8')
> data = data.strip("\n\r")
> print(data)
> if data.find ("PING :"):
> s.send(bytes('PONG ' + data.split()[1], 'UTF-8'))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 cannot detect the version of compiled sqlite version at some point in runtime.

[Random832]

On Wed, Jan 20, 2021, at 16:45, Random832 wrote:
> On Wed, Jan 20, 2021, at 14:54, panfei wrote:
> > 3. Compile Python 3.9.1
> > C_INCLUDE_PATH=/home/felix/.local/sqlite/sqlite-3.34.0/include/ 
> > CPLUS_INCLUDE_PATH=/home/felix/.local/sqlite/sqlite-3.34.0/include/ 
> > LD_RUN_PATH=/home/felix/.local/sqlite/default/lib ./configure 
> > --prefix=/home/felix/.local/python/python-3.9.1 --enable-optimizations
> > make && make install
> 
> How *exactly* did you compile python? i.e. what specific commands, to 
> make it pick up those include paths? Because from the symptoms you are 
> reporting, it sounds like it was not compiled against the correct 
> version of sqlite.

Oh, sorry, I missed "./configure" on that line.

So, it looks like you had the environment variables set when you ran configure, 
but not make. I don't think this is a common way to set include paths, by the 
way. The usual way is with pkg-config, but I'm not sure how to add your .local 
sqlite directory to it. Does your sqlite installation include a file called 
"sqlite3.pc"? If so, try adding the directory containing it to PKG_CONFIG_PATH 
when running configure.

If not... well, export the environment variables or add them when running make 
and hope for the best
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 cannot detect the version of compiled sqlite version at some point in runtime.

[Random832]

On Wed, Jan 20, 2021, at 14:54, panfei wrote:
> 3. Compile Python 3.9.1
> C_INCLUDE_PATH=/home/felix/.local/sqlite/sqlite-3.34.0/include/ 
> CPLUS_INCLUDE_PATH=/home/felix/.local/sqlite/sqlite-3.34.0/include/ 
> LD_RUN_PATH=/home/felix/.local/sqlite/default/lib ./configure 
> --prefix=/home/felix/.local/python/python-3.9.1 --enable-optimizations
> make && make install

How *exactly* did you compile python? i.e. what specific commands, to make it 
pick up those include paths? Because from the symptoms you are reporting, it 
sounds like it was not compiled against the correct version of sqlite.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Exploring terminfo

[Random832]

On Fri, Jan 15, 2021, at 13:36, Alan Gauld via Python-list wrote:
> That could make a big difference, the putp() function specifically
> states that it writes to stdout.

I think there is a reasonable argument that this is a deficiency of the curses 
module.

I think that the curses module should A) expose a version of tputs that accepts 
a python callback to process each output byte B) expose a version of putp that 
uses python's stdout[.buffer].write rather than C's putchar.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Random832]

On Sat, Oct 31, 2020, at 01:26, Igor Korot wrote:
> This one is for "JAVAsucks" -
> https://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html
> This one is for wxWidgets - https://docs.wxwidgets.org/3.0/overview_sizer.html
> This one is for Qt - https://doc.qt.io/qt-5/layout.html
> This one is for GTK -
> https://developer.gnome.org/gtk3/stable/LayoutContainers.html
> 
> Are you still going to argue "it does not exist"?

Those have nothing to do with the sizing or placement of top-level windows, 
they are for placements of widgets within the top-level window.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Random832]

On Fri, Oct 30, 2020, at 20:18, Igor Korot wrote:
> Hi,
> 
> On Fri, Oct 30, 2020 at 6:59 PM Peter J. Holzer  wrote:
> > So, assuming the user is invoking the application for the first time,
> > how should an application determine how much of the screen it should
> > use? It has to make some choice, and any hard-coded value is almost
> > certainly wrong. So why should an application not use the screen size as
> > one factor?
> 
> It is not up to application.
> It is up to the underlying layout system to decide.

What is a "layout system"? I don't think such a thing exists, in general, for 
positioning top-level windows on major platforms. Each application has to write 
its own, and it is reasonable for the layout system itself [which, as I've 
pointed out, is part of the application - there is no such thing as a system 
service] to need access to this information.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Random832]

On Fri, Oct 30, 2020, at 12:05, Grant Edwards wrote:
> Why do you think that's something your application needs to know?
> 
> I _hate_ applications that think just because they've been started
> they now own the entire computer and everything reachable from it.
> 
> All you need to know is how big your application window is. The user's
> available screen size is none of your business.

The application decides how big the application window is. The user can resize 
it, but there's no reason for the screen size not to be one of the inputs 
considered for the initial choice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why doesn't collections.Counter support a "key" argument in its constructor?

[Random832]

On Fri, Sep 11, 2020, at 12:01, Saurav Chirania wrote:
> I really like that python's sort method accepts a key function as a
> parameter which can be used to specify how elements should be compared.
> 
> Similarly, we could have a "key" argument which specifies how elements
> should be counted. Let's say we have a list of a million students. I would
> like to do something like:
> c = Counter(students, key = lambda student: student.marks)
> 
> which would return a Counter which maps marks to the number of students
> with that marks. Let's say 29 students in the list had scored 100 marks, so
> one entry in the counter would be key=100, val=29.
> 
> So, why doesn't Counter's constructor support this argument? Are there
> other pythonic ways to do this?

I'd like to add to this discussion that a feature like this would not be 
unreasonable to have on all dictionaries, and when I have wanted it in the past 
it has been on WeakKeyDictionary, for which the obvious workaround of making a 
wrapper class that uses the key function for __eq__ and __hash__ isn't usable
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Output showing "None" in Terminal

[Random832]

On Mon, Aug 24, 2020, at 09:12, Py Noob wrote:
> Hi!
> 
> i'm new to python and would like some help with something i was working on
> from a tutorial. I'm using VScode with 3.7.0 version on Windows 7. Below is
> my code and the terminal is showing the word "None" everytime I execute my
> code.

The reason it is displaying None is because print() returns none, and you are 
sending that into input().

Either do:

print("Please enter distance in miles: ")
n = int(input())
# this will wait for input on the next line

or

n = int(input("Please enter distance in miles: "))
# this will wait for input on the same line as the text

The km_mi function doesn't seem to have any purpose and you can delete it and 
the other line further down referencing it. If this is for something like a 
school assignment that requires you to write a km_mi function, it's not clear 
from your code what the requirement is for this function.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Iterators, iterables and special objects

[Random832]

On Fri, Jul 24, 2020, at 14:42, Chris Angelico wrote:
> And then someone will ask why you can't subscript a map object if the
> underlying object could be subscripted, etc, etc, etc. It's not meant
> to be a transparent layer over the object; it's just an iterator -
> basically equivalent to:
> 
> def map(func, *iters):
> try:
> while True:
> yield func(*(next(i) for i in iters))
> except StopIteration:
> pass
> 
> If you want a "MappedList" class, or a "MappedDict" class, or
> whatever, then build it - it isn't hard.

Asking to be able to restart the iteration is hardly the same thing as asking 
to pass through subscripts etc... C#'s Linq functions do fine with restartable 
iterables and hardly ever expose Iterators [well, IEnumerators, as they're 
called] to the user at all. If the original IEnumerable was restartable, so are 
all the intervening steps if you put an arbitrarily long chain of Select, 
Where, etc, on them, since each one restarts the one under it.

Obviously no-one should reasonably expect to be able to pass list subscripts 
through, say, a filter object, but restarting is a perfectly reasonable thing 
to do to *any* transformation of an iterable, whether or not it groups, splits, 
filters, interjects items or anything else you might imagine doing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Iterators, iterables and special objects

[Random832]

On Thu, Jul 23, 2020, at 05:14, Peter Slížik wrote:
> > Works in what way? You can't use it in a 'for' loop if it doesn't
> > define __iter__.
> >
> 
> class Iterable:
> def __iter__(self):
> return Iterator(...)
> 
> class Iterator:
> def __next__(self):
> return 
> 
> # No __iter__ here.
> # I've just forgotten to def it.
> 
> With this setup, using for to iterate over Iterable *will* still work,
> though you cannot use the trick described below.

Sure, but you can't use for to iterate over _Iterator itself_, or do anything 
else useful with it.

>>> class Iterator:
...   def __init__(self): self.done=False
...   def __next__(self):
...if self.done: raise StopIteration
...self.done = True
...return 1
... 
>>> [*Iterator()]
>>> [*map(lambda x:x, Iterator())]
>>> [*filter(lambda x:True, Iterator())]
>>> for x in Iterator(): pass
...
>>> [x for x in Iterator()]
[all of the above have the exact same exception]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'Iterator' object is not iterable
>>> def gen():
...  yield from Iterator()
...
>>> [*gen()]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in gen
TypeError: 'Iterator' object is not iterable
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Iterators, iterables and special objects

[Random832]

On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote:
> The transformers should be once-through iterators because they can be 
> passed once-through interators.  I suppose one could make them iterables 
> and add an attribute 'pristine' set to True in __init__ and False in 
> __iter__, but why have 2 objects instead of 1 when there is not gain in 
> function?

Why not just allow them to be iterated multiple times, and the underlying 
iterator/iterable either handles that or doesn't as the case may be? We don't 
have a hard API distinction between iterables and iterators, all iterators are 
"iterable" in the sense that they have their own __iter__ method that returns 
self.

i.e. the equivalent of

class map:
def __init__(self, func, obj): ...
def __iter__(self): for x in iter(self.obj): yield self.func(x)

That way if it is passed a once-through iterator, it is a once-through iterator 
with a couple extra steps, if passed an iterable it's an iterable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Random832]

On Sat, Jul 4, 2020, at 18:17, Ethan Furman wrote:
> On 07/04/2020 10:32 AM, Random832 wrote:
> 
> > I said obvious because even if it was not obvious from the commit message 
> > itself, it had *already been explained* in the thread on the other mailing 
> > list
> 
> That would require Michael to have been reading the other mailing list 
> to know that.  Just because the information is out there, doesn't mean 
> everybody has seen it.

ok, you know what?

regardless of hairsplitting about how obvious or not it is what she meant, and 
whether or not "it's because of the name White" was a reasonable conclusion to 
jump to, none of that changes that the conclusion was, in fact, incorrect. So 
trying to fight with me for pointing that out and claiming I was offering my 
"opinion" was unreasonable. I was not offering an opinion, I was pointing out a 
factual error, and arguing that the error was reasonable to make rather than 
being obvious doesn't change that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Random832]

On Sat, Jul 4, 2020, at 12:33, o1bigtenor wrote:
> I would point out that even suggesting that the issue be a *obvious 
> factual mistake* only serves to prove that you didn't read the thing 
> and I, at least, wonder why you're offering an opinion on any part of 
> the discussion. 

I said obvious because even if it was not obvious from the commit message 
itself, it had *already been explained* in the thread on the other mailing list 
by the time Michael Torrie posted (July 02 15:14) his assertion of "The fact 
she would conflate an author's name with some kind of race-related thing". I 
even recall raising the question of whether he had in fact read any of that 
discussion. After all, Ethan Furman made the same mistake in his original post, 
and was corrected *very* early on in the discussion, so repeating it several 
days later makes little sense.

*Regardless whether you agree or not* with the premise that "standard english" 
is a subtle means of enforcing white supremacy, the fact that some people do 
believe that is a far more plausible explanation for the statement in the 
commit message than the fact that one of the authors happens to have been named 
"White", and the idea that it was because of the latter only exists in the 
imagination of those determined to assume the worst of the person who wrote the 
commit message.





On Tue, Jun 30, 2020, at 08:44, Ethan Furman wrote:
> On 06/30/2020 05:03 AM, Łukasz Langa wrote:
> > 
> >> On 30 Jun 2020, at 12:44, Ethan Furman  >> > wrote:
> >>
> >> Of course I don't know if Keara or Guido knew any of this, but it 
> >> certainly feels to me that the commit message is ostracizing an entire 
> >> family line because they had the misfortune to have the wrong last name.  
> >> In fact, it seems like Strunk & White is making changes to be inclusive in 
> >> its advice -- exactly what I would have thought we wanted on our side 
> >> ("our side" being the diverse and welcoming side).
> > 
> > In any case, saying that Keara and Guido mistook the family name of one of 
> > the authors for skin color feels derogatory.
> 
> My apologies, that was not my intent.  As I said, I never knew what it 
> was until today (er, yesterday now).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Random832]

On Fri, Jul 3, 2020, at 08:48, Rhodri James wrote:
> As I said in my preamble, it doesn't matter whether you believe that is 
> true or think it's utter bollocks.  I asked the question to get the 
> Steering Council's opinion, not anyone else's.  If you collectively 
> really must rehash the arguments again, please have the decency to do so 
> in a different thread.

The idea that the statement was in any way related to one of the authors being 
named "White" was an *obvious factual mistake* in your post. Regardless of 
anything else, that is *not a matter of opinion*, so saying whose opinion you 
wanted is irrelevant.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Random832]

On Thu, Jul 2, 2020, at 18:29, Michael Torrie wrote:
> Come again?  I can see no other link in the verbage with the "relics of
> white supremacy" that she referred to.  If there are other links, they
> should be included in the commit message.  I agree with Rhodri that an
> explanation would be interesting.  Far be it from me to demand one.  So
> whatever.

It's possible that this wasn't explained clearly enough in the commit message 
itself (though I would argue it was definitely adequately explained in the 
ensuing on-list discussion, and wonder how much of that discussion you've 
actually read), but the point is that the *whole idea* of "standard English" is 
tied to white supremacy, not any particular standard whether via its authors or 
otherwise.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pycharm Won't Do Long Underscore

[Random832]

On Wed, Jun 24, 2020, at 21:38, Grant Edwards wrote:
> On 2020-06-24, Peter J. Holzer  wrote:
> 
> > There is U+FF3F Fullwidth Low Line.
> >
> >> If there were, Python would not know what to do with it
> >
> > You can use it in variable names, but not at the beginning, and it isn't
> > equivalent to two underscores, of course:

It is, in fact, equivalent to a single underscore. This is reasonable, given 
the unicode rules [I assume identifier lookup uses NFKC] and how these 
characters function for East Asian users.

> Ouch.  Anybody caught using that should be fed to a large snake.

Honestly, if I were to suggest any change it'd be to fix it so it's allowed at 
the beginning of an identifier. Let each (human) language's community worry 
about coding conventions for code intended for speakers of that language 
instead of trying to impose things on the world as english-speakers.

>>> a=1
>>> a_b=2
>>> ａ
1
>>> ａ＿ｂ
2
>>> ＿
  File "", line 1
＿
^
SyntaxError: invalid character in identifier
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why does super(bool) give None

[Random832]

On Fri, Apr 24, 2020, at 02:10, Cecil Westerhof wrote:
> issubclass(bool, int) gives True
> but
> super(bool) gives 
> 
> Do I not understand the meaning of super, or is this inconsistent?

I've never heard of a one-argument form for super, but I just tried something 
and now I'm confused about the two-argument form

>>> super(bool, True).__str__()
'True'

I expected '1' - does anyone know why this happens?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What variable type is returned from Open()?

[Random832]

On Wed, Apr 15, 2020, at 12:11, dcwhat...@gmail.com wrote:
> So you're saying this is a type _io.TextIOWrapper?  This type doesn't 
> show up, on the hint listbox (I'm using Wing IDE).  So if I type 
> var_file : _io, it doesn't show anything.

While others have pointed out that you shouldn't need a type hint here at all 
since it can be inferred, the correct type hint to use would be typing.TextIO.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Documentation of __hash__

[Random832]

On Fri, Feb 7, 2020, at 10:14, Richard Damon wrote:
> On 2/6/20 2:13 PM, klau...@gmail.com wrote:
> > The default __eq__ method (object identity) is compatible with all 
> > (reasonable) self-defined __hash__ method.
> >
> > Stefan
> 
> If __eq__ compares just the id, then the only hash you need is the 
> default that is also the id. If you define a separate hash function, 
> which uses some of the 'value' of the object, then presumably you intend 
> for objects where that 'value' matches to be equal, which won't happen 
> with the default __eq__.

I think Stefan's point is that, no matter how questionable the intent may 
sound, any deterministic __hash__ doesn't technically violate the hash/eq 
relationship with the default __eq__, because hash(x) will still be equal to 
hash(x). Only defining __eq__ can create the problem where x == y but hash(x) 
!= hash(y).

The purpose of this rule is to save you from having to override the default 
__hash__ with something that will only raise an exception when you do not 
intend your class to be hashable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clarification on Immutability please

[Random832]

On Wed, Jan 22, 2020, at 02:34, Stephen Tucker wrote:
> Oh dear, I am sorry. I have created quite a storm.
> 
> Moreover, I am sorry because I misremembered what I had typed into Idle. My
> original tuple only had two elements, not three, so the slicing [:2] didn't
> affect the tuple at all - and so the second id() gave the same address as
> the first one.
> 
> So, yes, I am stupid - or just having senior moments (I am 65, after all).
> 
> Stephen.

Regardless, this is interesting because, even though it is not in fact the 
case, this would be a valid optimization for an interpreter to perform, and 
while it's not done, something similar is done when concatenating strings.

>>> s = 'asdfghjklmnop'
>>> id(s); s += 'x'; id(s)
20405128
27766160
>>> id(s); s += 'x'; id(s)
27766160
27766160
# if this is done repeatedly, the two ids will not always be the same, but they 
will be quite a bit more often than not.

The two tuples, if there are  do not exist at the same time, therefore it does 
not violate any constraint if their ids are the same - ids are only required to 
be unique for simultaneously existing objects, not across the lifetime of the 
program.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO

[random832]

random832  added the comment:

That documentation isn't specific to StringIO, and in any case, the limitation 
in question isn't documented. The actual implementation is at 
https://github.com/python/cpython/blob/HEAD/Modules/_io/stringio.c#L484

But if examples would help, they're simple to come up with:

>>> f = io.StringIO('t\xe9st')
>>> f.seek(-1, io.SEEK_END)
Traceback (most recent call last):
  File "", line 1, in 
OSError: Can't do nonzero cur-relative seeks
>>> f.seek(2, io.SEEK_CUR)
Traceback (most recent call last):
  File "", line 1, in 
OSError: Can't do nonzero cur-relative seeks
# demonstration that SEEK_SET works treating all characters as one unit
>>> f.seek(2, io.SEEK_SET)
2
>>> f.read()
'st'

As far as I know this is the case in all currently maintained versions of 
Python 3, since the C-based unicode StringIO implementation was added in 2008.

--

___
Python tracker 
<https://bugs.python.org/issue39365>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO

[random832]

New submission from random832 :

Currently this fails with a (misleading in the case of SEEK_END) "Can't do 
nonzero cur-relative seeks" error, but there's no conceptual reason it 
shouldn't be possible.

The offset should simply be taken as a character offset, without any pretense 
that the "file" represents bytes in some Unicode encoding. This is already done 
for SEEK_START and tell, and has not caused any problems.

--
components: IO
messages: 360158
nosy: random832
priority: normal
severity: normal
status: open
title: Support (SEEK_END/SEEK_CUR) relative seeking in StringIO
type: behavior

___
Python tracker 
<https://bugs.python.org/issue39365>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Extension type inherit from Python int

[Random832]

On Thu, Jan 16, 2020, at 12:33, Mathias Enzensberger via Python-list wrote:
> Has anyone already done something like that? Is there some trick to 
> work around that issue, or is it simply not possible to inherit from 
> PyLongObject?

pure-python types that derive from int place __dict__ at the end of the object, 
I don't know if it's possible for you to do the same with the fields you intend 
to add (for some reason it isn't done with __slots__), but if all else fails 
you could do the same and store whatever data you need in the dict.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why isn't "-std=c99" (and others) not part of python3-config's output?

[Random832]

On Mon, Nov 25, 2019, at 15:13, Musbur wrote:
> 2) How does one activate the necessary CFLAGs for extension building?

the standard level required for building some extension is a property of the 
extension's source code, isn't it? I don't know if including the python headers 
requires -std=c99 or not, but almost certainly they'll work with -std=c11 and 
an extension may well require it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Does the argparse generate a wrong help message?

[Random832]

On Fri, Dec 27, 2019, at 23:08, jf...@ms4.hinet.net wrote:
> > > optional arguments:
> > >   -h, --help   show this help message and exit
> > >   --foo [FOO]  foo help
> > >   --goo GOOgoo help
> > >
> > > D:\Works\Python>py test.py --foo 1 --goo 2
> > > 1 ['2']
>
> So the square bracket means optional, not list? My misunderstanding:-(

To be clear, the brackets in the print output do mean a list, and it is because 
nargs=1 produces a list rather than the default (no nargs) which is to produce 
a single value. This is not normally visible to the end user (it's just a 
difference in how your program consumes the one mandatory argument), so it's 
not reflected in the help output. Square brackets in the help output mean an 
optional argument.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: INHERITANCE in python3

[Random832]

On Wed, Dec 18, 2019, at 23:10, vahid asadi via Python-list wrote:
> HI guys this is my first post on python mailing lists ever and i glad 
> to do this.
> my problem here is why this attribute is not recognize by python and it 
> raise an traceback error that said 'there is no such p.family 
> attribute'. although i use multiple   inheritance with 'super ' it not 
> works. thanks for your help.
> 
> ``` class Username:    def __init__(self,name,*args):        self.name 
> = name
> class Userfamily:    def __init__(self,family,*args):        
> self.family = family
> class Person(Username,Userfamily):    def __init__(self,*args):        
> super().__init__(*args)
> 
> 
> p = Person("v","aaa")print(p.name)print(p.family)```

The Username class also needs to call super(). In general, super() is intended 
to be used with all classes that might be part of a multiple inheritance 
hierarchy, not just the derived one.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: nonlocal fails ?

[Random832]

On Sun, Nov 17, 2019, at 07:26, Richard Damon wrote:
> I am not sure about C#, but in C++, a base language for C#, you can not
> take the address of a variable of reference type, if you do, you get the
> objected referred to, not the reference. References are essentially
> constant pointers, and can not be re-seated to reference another object.

C# is not very closely related to C++, calling it "a base language" would be 
inaccurate IMO. It's much more similar to Java in many ways. In particular, its 
"reference types" have absolutely nothing to do with C++'s references. They're 
much more similar to Java or Python object types. The "ref" references used for 
call-by-reference arguments are much more similar to C++ references [and 
there's no analogous feature in Java], but somewhat more restricted (they can't 
be used as a member of a class, for example)

The ability to make a "ref" reference to a variable of reference type is 
analogous to being able to make a reference to a pointer in C++, even though 
C#/Java/Python object references are not really the same things as pointers due 
to e.g. not having pointer arithmetic, etc. (the C++ .NET compatibility layer 
calls these 'handles', and uses the ^ character for them. The "ref" variables 
themselves use a % character, since they have to be distinct from &-references 
due to their role in the .NET garbage collection system)

> I suppose one way at looking at Python's name binding system (maybe not
> entirely accurate) would be to say that all Python names act like
> references, but that assignment, rather than being applied to the
> referred to object, re-seat the reference to point to the new object. As
> such, you can't get a reference to the name, to let one name re-seat
> where another name refers to.

I guess if anything this discussion has proven to me that C#'s decision to use 
"reference" for two unrelated concepts in fact causes more confusion than I 
thought it would from the perspective of the amount of .NET experience I have. 
However, my point was that the basic idea of pass by reference, even if it 
should be called something else (if implemented in Python it would probably use 
cell objects as "references", with some other kind of wrapper object being 
needed to handle the case of the target not being a local variable) is not 
fundamentally inapplicable to Python just because of the object reference 
model. Call by cell? Call by getter/setter?

There's an old saying that one of the hardest problems in computer science is 
naming things.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: nonlocal fails ?

[Random832]

On Fri, Nov 15, 2019, at 13:41, Dennis Lee Bieber wrote:
>   C# documents those as something visible to the user at the language
> level...
> https://www.infoworld.com/article/3043992/a-deep-dive-value-and-reference-types-in-net.html
> """
> Types in Microsoft .Net can be either value type or reference type.
> """

I was strictly talking about how reference types work (which are just like 
python or Java objects), and how that is completely distinct from the "ref" of 
call-by-reference arguments which are also supported, and that both features 
coexist just fine in the same language. The existence of value types wasn't 
really relevant to my point.

I'm not sure if you were left with the impression that you can't have a "ref" 
argument that points to a variable of reference type (and which does *not* 
point directly to the object), but that is false.

>   Similar to Java.

Well, Java doesn't have user-defined value types, but again, value types are 
beside the point.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: nonlocal fails ?

[Random832]

On Fri, Nov 15, 2019, at 11:47, Richard Damon wrote:
> The issue with calling it a Reference, is that part of the meaning of a
> Reference is that it refers to a Object, and in Python, Names are
> conceptually something very much different than an Object. Yes, in the
> implementation details, a name is basically a dictionary entry, so it
> could be done, the question is should it.

C# has basically the same issue and does fine calling its thing 'ref'. But 
that's not really the point - my point was that the concept of being able to 
have a function change the value of a variable specified by its caller doesn't 
magically cease being applicable just because the value is a "reference" and 
the variable is a "name binding".

[Similarly, the fact that values are "references" to mutable objects doesn't 
mean that python, or Java or C#, isn't call-by-value. The value is the 
"reference" itself, the fact that it can be used to change data that exists 
elsewhere is beside the point.]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: nonlocal fails ?

[Random832]

On Fri, Nov 15, 2019, at 10:48, Richard Damon wrote:
> On 11/15/19 6:56 AM, R.Wieser wrote:
> > There are quite a number of languages where /every/ type of argument 
> > (including values) can be transfered "by reference".  Though some default 
> > to 
> > "by value", where others default to "by reference".
> 
> It seems you are stuck in a programming model different than what Python
> provides, In a very real sense, the terms call "By Reference" and "By
> Value" don't apply to Python. Those concepts presume that a variable
> name represents a bucket of bytes that holds some value, and call by
> value copies those bytes into a new variable for the subroutine, and
> call by Reference creates a pointer value back to original value, and
> all uses of that parameter work indirect that pointer.
> 
> That is NOT how Python works. In Python, in effect, every name in your
> code is just a reference which points to some object (This is called
> binding). Multiple names can point to the same object (or no names, at
> which point the object is subject to being garbage collected). Names
> themselves aren't objects, so you can't really make one name refer to
> another, only to the same object that the other one does. (In actuality,
> these collections of names are implemented basically in a Dictionary, so
> using this sort of implementation details you can sort of get that
> result, but I don't think that is defined to work in the language).

Being abstractly typed objects rather than a bucket of bytes, and having the 
values themselves be a kind of reference or pointer (though to immutable data 
in some important cases), does not in fact change the meaning of the "call by 
reference" concept or its applicability.

It would be entirely reasonable, I think, in the python model, to provide a way 
for making a variable a cell variable, passing the cell object around 
explicitly, and having the called function automatically set/get the value when 
the argument is accessed. I don't think it would solve the OP's problem, since 
his talk about automatically "inheriting" the caller's variable of the same 
name sounds a lot more like dynamic scope than call by reference.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: keying by identity in dict and set

[Random832]

On Sun, Oct 27, 2019, at 03:24, Steve White wrote:
> Yes, there are several options, but they all involve an extra layer
> that detracts between the interface I am building and my user's code.
> In this situation, the objects being used as keys are conceptually the
> unique entities that the user deals with, even if their data is
> non-unique.  And I do not want to subject the user to the un-pythonic
> use of some operator other than '==' to determine their equivalence.

I'm honestly a little bit confused as to what the type of the objects you are 
using which it's reasonable to do this with but doesn't already work that way

> As near as I can tell, returning the id() in __hash__() results in a
> perfect hash key.  I really want to know if that is true.
> Because if it is true, any further layer is simply covering for a
> failing in the documentation.

And if you can override __hash__ you can, obviously, also override __eq__ to do 
whatever you want. You can return id in both. In fact, that is the default 
behavior of objects, assuming your type is not inherited from another type that 
does something different. Regardless, __hash__ and __eq__ should be consistent 
with each other.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: keying by identity in dict and set

[Random832]

On Sat, Oct 19, 2019, at 07:31, Steve White wrote:
> Hi,
> 
> I have an application that would benefit from object instances
> distinguished by identity being used in dict's and set's. To do this,
> the __hash__ method must be overridden, the obvious return value being
> the instance's id.
> 
> This works flawlessly in extensive tests on several platforms, and on
> a couple of different Python versions and implementations.
> 
> The documentation seems to preclude a second requirement, however.
> 
> I also want to use the == operator on these objects to mean a natural
> comparison of values, different from identity, so that two instances
> comparing equivalent does not imply that they are identical.

I'd like to jump in to this thread to note that while this is reasonably easily 
achieved with a custom mapping class that uses a dict along with a wrapper 
class that stores the identity...

I once tried to make a WeakKeyDictionary that was keyed by identity and had no 
end of trouble.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: what's the differences: None and null?

[Random832]

On Fri, Sep 13, 2019, at 21:22, Hongyi Zhao wrote:
> what's the differences: None and null?

null isn't really a concept that exists in Python... while None fills many of 
the same roles that null does in some other languages, it is a proper object, 
with __str__ and __repr__ methods (that return 'None'), __hash__ (that returns 
an arbitrary value), etc.

NULL, the C/C++ null pointer, is used in CPython for things like error returns, 
things like slots or cell variables that are not initialized (as opposed to 
being set to None), etc. This is an implementation detail, and should never 
come up in Python code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: CVE-2019-9636 - Can this be exploit over the wire?

[Random832]

On Wed, Sep 4, 2019, at 13:36, Barry Scott wrote:
> The conclusion I reached is that the CVE only applies to client code 
> that allows a URL in unicode to be entered.
> 
> Have I missed something important in the analysis?

While as I mentioned in my other post I'm not sure if the CVE's analysis of URL 
behavior is correct generally, you have missed the fact that an HTML page can 
provide URLs in unicode, either with the page itself encoded in UTF-8, or with 
whatever characters escaped as XML character references... not only as bytes in 
IDNA or percent-escaped hex. The same principle applies to other formats in 
which URLs might be interchanged as encoded unicode strings, such as JSON. The 
fact that accessing such a URL requires converting the non-ASCII parts to IDNA 
(for the domain part) or percent-escaped hex (for other parts) doesn't limit 
this to user input.

https://example.com@bing.com;>like this
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: CVE-2019-9636 - Can this be exploit over the wire?

[Random832]

On Wed, Sep 4, 2019, at 13:36, Barry Scott wrote:
> I have been looking into CVE-2019-9636 and I'm not sure that
> python code that works in bytes is vulnerable to this.

I'm not convinced that the CVE (or, at least, the description in the bug 
report... it's also unclear to me whether this is an accurate example of the 
CVE) is valid at all. That is, I don't think its suggestion that browsers 
generally use compatibility normalization in decomposing URLs is correct.

I tried the given address "https://example.com\uf...@bing.com; (with actual 
\uff03 character) in Firefox, Chrome, and Edge, and they all accessed bing.com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Plumbing behind super()

[Random832]

On Thu, Jun 27, 2019, at 23:32, adam.pre...@gmail.com wrote:
> On Thursday, June 27, 2019 at 8:30:21 PM UTC-5, DL Neil wrote:
> > I'm mystified by "literally given nothing".
> 
> I'm focusing there particularly on the syntax of writing "super()" 
> without any arguments to it. However, internally it's getting fed stuff.

Any function which is defined inside a class and accesses 'super' is provided a 
'cell variable' (i.e. nonlocal) called __class__, which super inspects on the 
stack to identify the class (along with finding the self argument)

>>> class C:
...  def foo(): super
...
>>> C.foo.__closure__
(,)
>>> C.foo.__code__.co_freevars
('__class__',)

You can also provide this cell manually by defining it as a nested function 
inside another function which has a local variable __class__.

>>> def bar():
...  __class__ = C
...  return lambda self: super()
...
>>> bar()(C())
, >

You can see all this happening in 
https://github.com/python/cpython/blob/3.8/Objects/typeobject.c#L7812
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Implementing C++'s getch() in Python

[Random832]

On Sat, May 25, 2019, at 10:07, binoythomas1...@gmail.com wrote:
> Hi Shakti!
> 
> Thanks for your response. I have tried getpass() but got the following 
> warning:
> 
> Warning (from warnings module):
>   File 
> "C:\Users\Binoy\AppData\Local\Programs\Python\Python37-32\lib\getpass.py", 
> line 100
> return fallback_getpass(prompt, stream)
> GetPassWarning: Can not control echo on the terminal.
> Warning: Password input may be echoed.
> 
> And true enough, the input string is echoed. I saw a video where 
> getpass() worked on Linux. So, probably, its a Windows thing.

getpass works fine on the windows console. Are you running the script in an IDE 
such as IDLE, PyCharm, etc?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36958] IDLE should print exit message or status if one is provided

[Random832]

New submission from Random832 :

IDLE currently just returns to the interactive prompt when a script exits, even 
if SystemExit has arguments. This can be confusing to new users if they are 
using sys.exit to print a message.

--
assignee: terry.reedy
components: IDLE
files: run.py.patch
keywords: patch
messages: 342809
nosy: Random832, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE should print exit message or status if one is provided
versions: Python 3.7
Added file: https://bugs.python.org/file48335/run.py.patch

___
Python tracker 
<https://bugs.python.org/issue36958>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Can't drop files on python scripts in a fresh installation of Windows

[Random832]

Python itself runs fine, but when I try to drop a file on a script it just
doesn't work.

If I try to regsvr32 the shell extension, it says: The module
"c:\windows\pyshellext.amd64.dll" failed to load.

There was no indication of any problem until this. Apparently it is linked
against "VCRUNTIME140.dll", not (or in addition to? peview shows both) the
universal CRT.

Installing the Visual C++ 2015 redistributable resolved it, but there was no
instruction for this.

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

Can't drop files on python scripts in a fresh installation of Windows 10 and Python 3.7

[Random832]

Python itself runs fine, but when I try to drop a file on a script it just 
doesn't work.

If I try to regsvr32 the shell extension, it says: The module 
"c:\windows\pyshellext.amd64.dll" failed to load.

There was no indication of any problem until this. Apparently it is linked 
against "VCRUNTIME140.dll", not (or in addition to? peview shows both) the 
universal CRT.

Installing the Visual C++ 2015 redistributable resolved it, but there was no 
instruction for this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Open (txt) editor and get its content

[Random832]

On Thu, Apr 19, 2018, at 03:39, zljubi...@gmail.com wrote:
> Is there any other option for getting interactive multi line input from user.

If you don't need a full-featured text editor, you could build a simple input 
popup with the Textbox widget in tkinter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help: 64bit python call c and got OSError: exception: access violation writing 0xFFFFFFFF99222A60

[Random832]

On Mon, Jan 22, 2018, at 16:00, Jason Qian via Python-list wrote:
> Hello!
> 
>   I am using ctypes on Windows to interface with a dll  and it works fine
> on Linux and windows 32-bit python.  But, when using 64-bit python, we got
> error "exception: access violation writing 0x99222A60".

You are treating the obj type (myPythonAPI *) as c_int, which is only 32 bits. 
You should be using a pointer type instead (ideally you should be using void * 
and c_void_p, so Python doesn't need the class definition.) Don't forget to set 
lib.loadInstance.restype as well.

> __declspec(dllexport) myPythonAPI* loadInstance(){ return new
> myPythonAPI(); }
> __declspec(dllexport) int createService(myPythonAPI* obj, const char*
> serviceName) { eturn obj->createService(serviceName);

> lib = cdll.LoadLibrary('xxx.dll')
> 
> lib.createService.argtypes=[c_int,ctypes.c_char_p]
> lib.createService.restype=ctypes.c_int
> 
> class myDriver(object):
> def init(self):
> self.obj = lib.loadInstance()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can utf-8 encoded character contain a byte of TAB?

[Random832]

On Mon, Jan 15, 2018, at 09:35, Peter Otten wrote:
> Peng Yu wrote:
> 
> > Can utf-8 encoded character contain a byte of TAB?
> 
> Yes; ascii is a subset of utf8.
> 
> If you want to allow fields containing TABs in a file where TAB is also the 
> field separator you need a convention to escape the TABs occuring in the 
> values. Nothing I see in your post can cope with that, but the csv module 
> can, by quoting field containing the delimiter:

Just to be clear, TAB *only* appears in utf-8 as the encoding for the actual 
TAB character, not as a part of any other character's encoding. The only bytes 
that can appear in the utf-8 encoding of non-ascii characters are starting with 
0xC2 through 0xF4, followed by one or more of 0x80 through 0xBF.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Random832]

On Sun, Jan 7, 2018, at 18:50, Gene Heskett wrote:
> That, now that you mention it, could also effect this as I see it, my 
> default kmail message body font is hack 14 in deference to the age of my 
> eyes.
> 
> My system default font is I believe utf-8. That is not a kmail settable 
> option. But if I uncheck the "use custom fonts", it is still two pair of 
> character outlines. So to what family of fonts do these characters 
> belong?

If it supports truetype fonts (and picking fonts based on what fonts have a 
character available, rather than one font for the whole message), you might try 
the https://www.google.com/get/noto/ family - it has a black-and-white Emoji 
font available (color fonts require special application support, but the black 
and white one is just plain truetype) - of course, that won't help if it's 
limited to 16 bits (the fact that they are *pairs* of boxes unfortunately 
suggests this, but maybe it'll work properly if a font is available).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Random832]

On Sun, Jan 7, 2018, at 17:47, Richard Damon wrote:

> But it also says:
> 
> Content-Transfer-Encoding: 7bit
> 
> Which is incorrect, as the message is actually 8bit encoded (since the 
> Emoji aren't in the first 127 characters, so their UTF-8 encoding isn't 
> 7-bit. Some software might have messed up the message in transit due to 
> that error.

Well, the fact that the emoji survived the round-trip and showed up properly in 
his reply (and yours) led me to rule out the possibility that anything like 
that had happened. Plus, if that had happened, the result wouldn't be boxes, 
but a series of ASCII characters (some of which are control characters, and 
some of which are printable).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Re: has sourceforge exposed the dirty little secret ?

[Random832]

On Sun, Jan 7, 2018, at 17:27, Gene Heskett wrote:
> >
> >  
> >
> But here its broken and I am looking at two pairs of vertical boxes 
> because it is not properly mime'd. If you use chars or gliphs from a 
> non-default charset, it needs to demarcated with a mime-boundary marker 
> followed by the new type definition. Your email/news agent did not do 
> that. 

UTF-8 is the default character set, and anyway his message does have a 
content-type of 'text/plain; charset="utf-8"; Format="flowed"'. Your 
environment not having font support and/or support for non-BMP characters is 
not a deficiency in the message.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: unicode direction control characters

[Random832]

On Tue, Jan 2, 2018, at 10:36, Robin Becker wrote:
> >> u'\u200e28\u200e/\u200e09\u200e/\u200e1962'
>
> I guess I'm really wondering whether the BIDI control characters have any 
> semantic meaning. Most numbers seem to be LTR.
> 
> If I saw u'\u200f12' it seems to imply that the characters should be 
> displayed 
> '21', but I don't know whether the number is 12 or 21.

No, 200F acts as a single R-L character (like an invisible letter), not an 
override for adjacent characters (as 202E would). LRM/RLM basically act like an 
invisible letter of the relevant directionality.

European numerals have "weak" LTR directionality (to allow them to be used as 
part of e.g. a list of numbers in a sentence written in an RTL language), and 
don't affect some punctuation marks the same way as letters. I believe the 
purpose here is to ensure that it displays as 28/09/1962 instead of 1962/09/28 
when the surrounding context is right-to-left. For the slash in particular, 
this was apparently a bug that was fixed in some recent version of unicode 
(this is mentioned briefly in UTR9, look for "solidus"), so earlier 
implementations or non-unicode implementations may not have supported it 
correctly.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to exec a string which has an embedded '\n'?

[Random832]

On Sat, Dec 30, 2017, at 23:57, jf...@ms4.hinet.net wrote:
> I have a multiline string, something like '''...\nf.write('\n')\n...'''
> when pass to exec(), I got
> SyntaxError: EOL while scanning string literal
> 
> How to get rid of it?

Use \\n for this case, since you want the \n to be interpreted by the exec 
parser rather than the newline being part of the string.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is wrong with this regex for matching emails?

[Random832]

On Mon, Dec 18, 2017, at 02:01, Chris Angelico wrote:
> Hmm, is that true? I was under the impression that the quoting rules
> were impossible to match with a regex.  Or maybe it's just that they're
> impossible to match with a *standard* regex, but the extended
> implementations (including Python's, possibly) are able to match them?

What's impossible to match with a regex are the comments permitted by RFC822 
(which are delimited by balanced parentheses - AIUI perl can do it, python 
can't.) Which are, according to my argument, not part of the address.

> Anyhow, it is FAR from simple; and also, for the purpose of "detect
> email addresses in text documents", not desirable. Same as with URL
> detection - it's better to have a handful of weird cases that don't
> autolink correctly than to mis-detect any address that's at the end of
> a sentence, for instance. For that purpose, it's better to ignore the
> RFC and just craft a regex that matches *common* email address
> formats.

Email addresses don't, according to the formal spec, allow a dot at the end of 
the domain part. I was half-seriously proposing that as an extension (since DNS 
names *do*).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: __contains__ classmethod?

[Random832]

On Mon, Dec 18, 2017, at 16:25, Tim Chase wrote:
> My understanding was that "in" makes use of an available __contains__
> but something seems to preventing Python from finding that.
> 
> What's going on here?

Most __ methods have to be an actual method on the class object, which
means you have to use a metaclass.

"one" in X() works, but to get "one" in X to work, you need:

class M(type):
   def __contains__(cls, v):
 return v in cls._ALL

class X(object, metaclass=M):
   ONE = "one"
   TWO = "two"
   _ALL = frozenset(v for k,v in locals().items() if k.isupper())

If you want *both* "one" in X and "one" in X() to work, I think you
pretty much have to define it in both places.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is wrong with this regex for matching emails?

[Random832]

On Sun, Dec 17, 2017, at 10:46, Chris Angelico wrote:
> But if you're trying to *validate* an email address - for instance, if
> you receive a form submission and want to know if there was an email
> address included - then my recommendation is simply DON'T. You can't
> get all the edge cases right; it is actually impossible for a regex to
> perfectly match every valid email address and no invalid addresses.

That's not actually true (the thing that notoriously can't be matched in
a regex, RFC822 "address", is basically most of the syntax of the To:
header - the part that is *the address* as we speak of it normally is
"addr-spec" and is in fact a regular language, though a regex to match
it goes on for a few hundred characters. The formal syntax also has some
surprising corners that might not reflect real-world implementations:
for example, a local-part may not begin or end with a dot or contain two
dots in a row (unless quoted - the suggestion someone else made that a
local-part may contain an @ sign also requires quoting). It's also
unfortunate that a domain-part may not end with the dot, since this
would provide a way to specify TLD- only addresses without allowing the
error of mistakenly leaving the TLD off of an address.

> And that's only counting *syntactically* valid - it doesn't take into
> account the fact that "b...@junk.example.com" is not going to get
> anywhere. So if you're trying to do validation, basically just don't.

The recommendation still stands, of course - this script is probably not
the place to explore these obscure corners. If the email address is
important, you can send a link to it and wait for them to click it to
confirm the email. If it's not, don't bother at all.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: why won't slicing lists raise IndexError?

[Random832]

On Mon, Dec 4, 2017, at 13:54, Jason Maldonis wrote:
> Is there any background on why that doesn't raise an IndexError? Knowing
> that might help me design my extended list class better. For my specific
> use case, it would simplify my code (and prevent `if isinstance(item,
> slice)` checks) if the slicing raised an IndexError in the example I
> gave.

Slicing (of strings, lists, tuples, anyway) never raises an IndexError. If the
start is out of range it will return an empty list. I don't know. As for "why",
 it's just how the operation was designed. Perhaps it was considered that an
exception isn't needed because there's no ambiguity (i.e. there's no other
reason a slice operation can return a list shorter than the length implied by
the slice parameters).

Why would this simplify your code? What are you doing that would benefit from
an IndexError here?

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

Re: Politeness (was: we want python software)

[Random832]

On Wed, Dec 6, 2017, at 11:18, Steve D'Aprano wrote:
> You suggested that if he wasn't familiar with free software, his
> request that people send him a copy of Python wouldn't look so odd.
> Okay, if Python weren't free software, it would be non-free software,
> and you are saying that it wouldn't look so odd for somebody to join a
> mailing list and request a bunch of strangers to gift him a copy of
> non-free software.

The third possibility is that he believes that this list is official
in some corporate sense, that if he asks for the software and it is not
free he will receive a price quote.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: why won't slicing lists raise IndexError?

[Random832]

On Mon, Dec 4, 2017, at 13:54, Jason Maldonis wrote:
> Is there any background on why that doesn't raise an IndexError? Knowing
> that might help me design my extended list class better. For my specific
> use case, it would simplify my code (and prevent `if isinstance(item,
> slice)` checks) if the slicing raised an IndexError in the example I
> gave.

Slicing (of strings, lists, tuples, anyway) never raises an IndexError.
If the start is out of range it will return an empty list. I don't know.
As for "why", it's just how the operation was designed. Perhaps it was
considered that an exception isn't needed because there's no ambiguity
(i.e. there's no other reason a slice operation can return a list
shorter than the length implied by the slice parameters).

Why would this simplify your code? What are you doing that would benefit
from an IndexError here?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

[Random832]

I haven't read over every message in the thread, so sorry if this has
been suggested before, but how about "if not break:" and "if not
except:" as synonyms for the current 'else' clause? They're already
keywords, and this sequence of keywords has no current meaning.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What extended ASCII character set uses 0x9D?

[Random832]

On Fri, Aug 18, 2017, at 03:39, Marko Rauhamaa wrote:
> BTW, I was reading up on the history of ASCII control characters. Quite
> fascinating.
> 
> For example, have you ever wondered why DEL is the odd control character
> out at the code point 127? The reason turns out to be paper punch tape.
> By backstepping and punching a DEL over the previous ASCII character you
> can "rub out" the character.

I assume this is also why teletypes used even parity - so 0xFF can be
used as DEL on characters that had any parity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Thu, Jul 20, 2017, at 01:15, Steven D'Aprano wrote:
> I haven't really been paying attention to Marko's suggestion in detail, 
> but if we're talking about a whole new data type, how about a list of 
> nodes, where each node's data is a decomposed string object guaranteed to 
> be either:

How about each node but the last has a fixed "length" (say, 16
characters), and random access below that size is done by indexing to
the node level and then walking forward.

I've thought about this in the past for encoding strings in UTF-8 with
O(1) random code point access.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Tue, Jul 18, 2017, at 22:49, Steve D'Aprano wrote:
> > What about Emoji?
> > U+1F469 WOMAN is two columns wide on its own.
> > U+1F4BB PERSONAL COMPUTER is two columns wide on its own.
> > U+200D ZERO WIDTH JOINER is zero columns wide on its own.
> 
> 
> What about them? In a monospaced font, they should follow the same rules
> I used
> above: either 0, 1 or 2 column wide.

You snipped the important part - the fact that the whole sequence of
three code points U+1F469 U+200D U+1F4BB is a single grapheme cluster
two columns wide.

You also ignored all of the other examples in my post. Did you even read
anything beyond what you snipped?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Tue, Jul 18, 2017, at 19:21, Gregory Ewing wrote:
> Random832 wrote:
> > What about Emoji?
> > U+1F469 WOMAN is two columns wide on its own.
> > U+1F4BB PERSONAL COMPUTER is two columns wide on its own.
> 
> The term "emoji" is becoming rather strained these days.
> The idea of "woman" and "personal computer" being emotions
> is an interesting one...

Emoji comes from Japanese 絵文字 - 絵(E) picture, 文字(moji) character. It is
not in fact etymologically related to the native English term
"emoticon", which is no longer in common usage.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Tue, Jul 18, 2017, at 10:23, Anders Wegge Keller wrote:
> På Tue, 18 Jul 2017 23:59:33 +1000
> Chris Angelico  skrev:
> > On Tue, Jul 18, 2017 at 11:11 PM, Steve D'Aprano
> >> (I don't think any native English words use a double-V or double-U, but
> >> the possibility exists.)  
>  
> > vacuum.
> 
>  That's latin. 

Define "native" then. My interpretation of "native English words" is
"anything you wouldn't have to put in italics to use in a sentence".
Which would also include "continuum".

As for double-v, a quick search through /usr/share/dict/words reveals
"civvies", "divvy", "revved/revving", "savvy" and "skivvy", and various
conjugations thereof. All following, more or less, the rule of using a
double consonant after a short vowel in contexts where a single
consonant would suggest the preceding vowel was long.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Sun, Jul 16, 2017, at 01:37, Steven D'Aprano wrote:
> In a *well-designed* *bug-free* monospaced font, all code points should 
> be either zero-width or one column wide. Or two columns, if the font 
> supports East Asian fullwidth characters.

What about Emoji?
U+1F469 WOMAN is two columns wide on its own.
U+1F4BB PERSONAL COMPUTER is two columns wide on its own.
U+200D ZERO WIDTH JOINER is zero columns wide on its own.

The sequence U+1F469 U+200D U+1F4BB is the single emoji "Woman
Technologist", which is two columns wide.

Even without ZWJ this comes up - the regional indicator characters are
meant to appear in pairs - signifying a flag, which is two columns wide
- but when they appear in isolation they usually appear as an equally
wide "letter in a box" picture.

The skin tone indicators aren't applied with ZWJ, and are meant to
combine with the preceding character when it is an emoji depicting a
person, but show up as a square swatch of that color in isolation. And
AIUI they don't have a combining class in the unicode data.

Or, consider presentation variation selectors

U+26A1 HIGH VOLTAGE SIGN
U+FE0E VARIATION SELECTOR-15 (text presentation in this context)
U+FE0F VARIATION SELECTOR-16 (emoji presentation in this context)

Some code points are meant to be shown as a text character in some
contexts and an emoji in others. The default presentation (when not
followed by a variation selector) depends on the application. Otherwise,
the Emoji is two columns wide and the text presentation version is
usually one column wide.

The variation selectors themselves are zero columns wide when applied to
any character for which it is not meant to be applied.

(From a font perspective these can be regarded as ligatures, but the
font itself is not responsible for the behavior of a character-cell
terminal emulator)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Fri, Jul 14, 2017, at 04:15, Marko Rauhamaa wrote:
>  Consider, for example, a Python source code
> editor where you want to limit the length of the line based on the
> number of characters more typically than based on the number of pixels.

Even there you need to go based on the width in character cells. Most
characters for East Asian languages occupy two character cells.

It would be nice if there was an easy way to get str.format to use this
width instead of the length in code points for the purpose of padding.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grapheme clusters, a.k.a.real characters

[Random832]

On Fri, Jul 14, 2017, at 08:33, Chris Angelico wrote:
> What do you mean about regular expressions? You can use REs with
> normalized strings. And if you have any valid definition of "real
> character", you can use it equally on an NFC-normalized or
> NFD-normalized string than any other. They're just strings, you know.

I don't understand how normalization is supposed to help with this. It's
not like there aren't valid combinations that do not have a
corresponding single NFC codepoint (to say nothing of the situation with
e.g. Indic languages).

In principle probably a viable solution for regex would be to add
character classes for base and combining characters, and then
"[[:base:]][[:combining:]]*" can be used as a building block if
necessary.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About the implementation of del in Python 3

[Random832]

On Fri, Jul 7, 2017, at 10:41, Nathan Ernst wrote:
> Looks like single expression statements are handled a bit differently
> than
> multiple expression statements:
> 
> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> n = 4000; m = 4000; n is m
> True
> >>> n = 4000
> >>> m = 4000
> >>> n is m
> False

Equal constants are combined (into a single object in the code object's
constant list - the compiler actually uses a dictionary internally) at
compile time, when you execute two separate lines in the interactive
interpreter they are compiled separately.

I would call your first case multiple statements on a line, not multiple
expressions in one statement. But what's important is the separate lines
of the interactive interpreter and therefore separate compile contexts -
if you were to do exec('n=4000\nm=4000') you would get a single object.

With a sufficiently small number (between 0 and 256 inclusive), they are
globally cached and you will get the same object even across separate
compilations, because the compiler gets the same object when it parses
"10" in the first place.

Imagine more or less, this process:

d = {}
a = int("4000")
if a in d: i = d[a]
else: i = d[a] = len(d)
b = int("4000")
if b in d: j =d[b]
else: j = d[b] = len(d)
c = d.keys()
n = c[i]
m = c[j]

When you do it on two separate prompts you get:

d = {}
a = int("4000")
if a in d: i = d[a]
else: i = d[a] = len(d)
c = d.keys()
n = c[i]

d = {}
a = int("4000")
if a in d: i = d[a]
else: i = d[a] = len(d)
c = d.keys()
m = c[i]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: About the implementation of del in Python 3

[Random832]

On Fri, Jul 7, 2017, at 04:12, Gregory Ewing wrote:
> Only if you interpret the word "address" very narrowly.
> 
> By the way, even the low-level notion of "address" that C
> programs deal with is, on most modern hardware, a *virtual*
> address that goes through a level of translation before it
> identifies a physical set of transistors, and that mapping
> can change as stuff gets paged in and out. So it's already
> an abstract concept to some extent.

What's not abstract is that if an object has address X and is N bytes
long, those bytes (and any larger subobjects) occupy a contiguous range
of addresses between X and X+(N-1).

This is not required to be true of Python IDs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Random832]

On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote:
> On 2017-04-20, MRAB  wrote:
> > There _is_ a "universal solution"; it's called a Hollerith constant. :-)
> 
> Wow, I haven't seen one of those in a _long_ time -- probably about 45
> years.  I think the first FORTAN implementation I used was WATFIV,
> which had just introduced the character type. But, books/classes on
> FORTRAN all still covered Hollerith constants.

The IMAP protocol uses a similar kind of construct (the length is
enclosed in braces)

Even ignoring the maintenance difficulty, I don't think it's possible to
syntax highlight something like that on most common editors.

The best solution I can think of is to have a text editor designed to
parse a string literal, spawn a nested editor with the unescaped
contents of that string literal, and then re-escape it back to place in
the code. If we had that, then we wouldn't even need raw strings.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Random832]

On Sun, Mar 19, 2017, at 18:48, Mikhail V wrote:
> Sadly, many people believe that a code editor
> should be monospaced, but generally that does not
> have any sense.

It's also a bit self-reinforcing because there aren't many good coding
fonts that are proportional. And in fact there are issues for coding
usability in proportional fonts that aren't even present for monospaced
fonts. Confusables like lI1| O0 are only the beginning of the story. If
, and ' are only one pixel wide each, it's hard to tell which order they
are in. And in many proportional fonts it is difficult or impossible to
distinguish '' from ". Other issues also exist, such as """ having more
space between the ticks of a single character than between characters,
looking more like '""'. @ and % and sometimes # are too wide and too
short. Minus is too narrow, too thick, and too low owing to its design
as a hyphen (U+2212 is usually nicer, but not used in programming
languages). < and > are wide and low, which works great as relational
operators but makes them visually unpleasant as brackets - and >=
doesn't look nice either. {} are often too tall, too narrow, and a
little bit too curly.

So people try coding in the proportional fonts available on their
systems and rightly note how ugly it is.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's with all the messages from @f38.n261.z1

[Random832]

On Tue, Feb 7, 2017, at 15:08, Michael Torrie wrote:
> Seems like we're getting a bunch of messages on the mailing list that
> appear to be copies of real member posts that are saying they are from
> @f38.n261.z1?  They don't appear to be deliberate impersonations.  Some
> misconfigured server reflecting messages back to the list perhaps?

Looking at it (compared to the original), It has Usenet headers for
comp.lang.python (and a path header indicating an origin at
eternal-september.org), and headers associated with FidoNet and
something called "Prism BBS".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Extended ASCII

[Random832]

On Fri, Jan 13, 2017, at 17:24, D'Arcy Cain wrote:
> I thought I was done with this crap once I moved to 3.x but some 
> Winblows machines are still sending what some circles call "Extended 
> ASCII".  I have a file that I am trying to read and it is barfing on 
> some characters.  For example:
> 
>due to the Qu\xe9bec government
> 
> Obviously should be "due to the Québec government".  I can't figure out 
> what that encoding is or if it is anything that can even be understood 
> outside of M$.  I have tried ascii, cp437, cp858, cp1140, cp1250, 
> latin-1, utf8 and others.  None of them recognize that character.  Can 
> someone tell me what encoding includes that character please.

It's latin-1 (or possibly cp1252 or something else depending on other
characters), your problem is elsewhere.

> Here is the failing code:
> 
> with open(sys.argv[1], encoding="latin-1") as fp:
>for ln in fp:
>  print(ln)
> 
> Traceback (most recent call last):
>File "./load_iff", line 11, in 
>  print(ln)
> UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in 
> position 132: ordinal not in range(128)

Note that this is an encode error - it's converting *from* unicode *to*
bytes, for the print statement.
 
> I don't understand why the error says "ascii" when I told it to use 
> "latin-1".

You set the encoding for the file, not the output. The problem is in
your print statement, and the fact that you probably have your locale
set to "C" or not set up at all instead of e.g. "en_CA.UTF-8".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simulating int arithmetic with wrap-around

[Random832]

On Fri, Dec 30, 2016, at 09:47, Steve D'Aprano wrote:
> Again, assume both operands are in range for an N-bit signed integer.
> What's
> a good way to efficiently, or at least not too inefficiently, do the
> calculations in Python?

I'd do something like:

bit_mask = (1 << bits) - 1 # 0x sign_bit = 1 << (bits - 1) # 0x8000 
sign_ext = ~bit_mask # ...F

def signed(value):
if value & sign_bit:
return value | sign_ext
else:
return value & bit_mask

def unsigned(value):
return value & bit_mask

And also avoid doing it on intermediate steps where it can be shown to not 
affect the result or allow the value to grow too large.

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

Re: Simulating int arithmetic with wrap-around

[Random832]

On Fri, Dec 30, 2016, at 09:47, Steve D'Aprano wrote:
> Again, assume both operands are in range for an N-bit signed integer.
> What's
> a good way to efficiently, or at least not too inefficiently, do the
> calculations in Python?

I'd do something like:

bit_mask = (1 << bits) - 1 # 0x
sign_bit = 1 << (bits - 1) # 0x8000
sign_ext = ~bit_mask # ...F

def signed(value): 
if value & sign_bit:
return value | sign_ext
else:
return value & bit_mask

def unsigned(value):
return value & bit_mask

And also avoid doing it on intermediate steps where it can be shown to
not affect the result or allow the value to grow too large.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: OT - "Soft" ESC key on the new MacBook Pro

[Random832]

On Sun, Dec 18, 2016, at 17:03, Gregory Ewing wrote:
> mm0fmf wrote:
> > +1 for knowing where CTRL should be.
> > Bonus +1 for having used an ASR33.
> 
> And it's quite remarkable that the designers of the ASR33
> knew exactly where it would need to be for Emacs users
> years later! I think Richard Stallman must have a time
> machine as well.

Except for the fact that the actual keyboard that Emacs was originally
developed for [the Knight Keyboard, and the later Symbolics "Space
Cadet" Keyboards] had the control key more or less where it is on modern
PC keyboards [slightly further to the right, so easier to reach with the
thumb of the same-side hand], and the Meta key to its left. To the left
of A was "rub out".

I assume the original Emacs users used proper touch-typing style:
modifier keys with the opposite hand from the letter they were using it
with, rather than trying to contort the same-side hand into hitting both
keys at once. Meanwhile, users of Unix systems were stuck with terminals
like the ADM-3A and VT-100, which, inherited from the ASR-33 but one
must assume the real reason was to save money, only had one control key
and no true meta key (one escape key). I suspect there would have only
been one shift key if they could have got away with it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best attack order for groups of numbers trying to destroy each other, given a victory chance for number to number attack.

[Random832]

On Thu, Dec 15, 2016, at 08:31, Dennis Lee Bieber wrote:
>   As for my posts disappearing: I run with "X-NoArchive" set. I have from
> before Google absorbed DejaNews. Back then, most news-servers expired
> posts
> on some periodic basis (my ISP tended to hold text groups for 30 days or
> so, binaries groups cycled in less than 36 hours). When DejaNews arrived,
> many objected to the non-expiration facet:
> https://en.wikipedia.org/wiki/Google_Groups#Deja_News

As I recall, what most people *actually* said they objected to was the
fact that they profited from showing ads. X-No-Archive was just a
convenient blunt weapon to hit them with.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Running python from pty without prompt

[Random832]

On Tue, Dec 13, 2016, at 19:20, Steve D'Aprano wrote:
> sys.flags.interactive will tell you whether or not your script was
> launched
> with the -i flag.
> 
> hasattr(sys, 'ps1') or hasattr(sys, 'ps2') will tell you if you are
> running
> in the REPL (interactive interpreter). The ps1 and ps2 variables aren't
> defined in non-interactive mode.

There's no way to *tell python to* run in non-interactive mode without
using a file other than the tty as the script. It's not a matter of
finding out from within python whether it's in interactive note, it's a
matter of python finding out whether the user *wants* it to run in
interactive mode.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Running python from pty without prompt

[Random832]

On Tue, Dec 13, 2016, at 19:10, Steve D'Aprano wrote:
> Can you show a simple demonstration of what you are doing?
> 
> I'm having difficulty following this thread because I don't know
> what "script run on a tty" means.

The question is literally about the input/script being the tty and not
redirected from any other file, which causes an interactive prompt in
CPython, but does not do so in some other languages. I don't understand
what part of this you're not getting.

> I thought that with the exception of scripts run from cron, any time you
> run a script *or* in interactive mode, there is an associated tty. Am I
> wrong?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Running python from pty without prompt

[Random832]

On Tue, Dec 13, 2016, at 17:09, Michael Torrie wrote:
> On 12/13/2016 10:48 AM, Random832 wrote:
> > The problem is there's currently no way to differentiate "interactive
> > mode" from "script run on a tty".
> > 
> > You can get similar behavior with python -c "import
> > sys;exec(sys.stdin.read())"
> 
> Are you sure? I can pipe scripts into Python and they run fine and
> Python is not in interactive mode.

Yes, a pipe and a tty are two different things.

> python < script.py
> 
> The behavior the OP is looking for of course is a way of demarcating the
> end of the script and the beginning of data to feed the script.

It's more than just that - with a tty you can call sys.stdin.read()
multiple times, and each time end it with ctrl-d.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Running python from pty without prompt

[Random832]

On Tue, Dec 13, 2016, at 11:01, Michael Torrie wrote:
> On 12/13/2016 05:39 AM, Samuel Williams wrote:
> > Michael, yes.
> > 
> > FYI, I found out why this works. Pressing Ctrl-D flushes the input
> > buffer. If you do this on an empty line, it causes read(...) to return
> > 0 which Ruby considers end of input for the script, but the pipe is
> > not closed.
>
> Currently Python does not appear to support this behavior.  Possibly it
> could be patched to support something similar, though.

The problem is there's currently no way to differentiate "interactive
mode" from "script run on a tty".

You can get similar behavior with python -c "import
sys;exec(sys.stdin.read())"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Splitting text into lines

[Random832]

On Tue, Dec 13, 2016, at 12:25, George Trojan - NOAA Federal wrote:
> >
> > Are repeated newlines/carriage returns significant at all? What about
> > just using re and just replacing any repeated instances of '\r' or '\n'
> > with '\n'? I.e. something like
> >  >>> # the_string is your file all read in
> >  >>> import re
> >  >>> re.sub("[\r\n]+", "\n", the_string)
> > and then continuing as before (i.e. splitting by newlines, etc.)
> > Does that work?
> > Cheers,
> > Thomas
> 
> 
> The '\r\r\n' string is a line separator, though not used consistently in
> US
> meteorological bulletins. I do not want to eliminate "real" empty lines.

I'd do re.sub("\r*\n", "\n", the_string). Any "real" empty lines are
almost certainly going to have two \n characters, regardless of any \r
characters. It looks like what *happens* is that the file, or some part
of the file, had \r\n line endings originally and was "converted" to
turn the \n into \r\n.

> I was hoping there is a way to prevent read() from making hidden changes
> to the file content.

Pass newline='' into open.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote:
> On Thu, 08 Dec 2016 10:37:27 -0500, Random832 <random...@fastmail.com>
> declaimed the following:
> >There are other issues, like needing a way to do Windows' version of
> >wildcard parsing with all its quirks, or at least some of its quirks -
> >"*.*" for all files and "*." for files not containing any dot being the
> >most commonly used in the real world.
> >
>   In the original 8.3 scheme -- no files "contained" a dot

Yes, but they do now, and the compatibility quirks persist. At some
point in the process *?. are translated to other reserved characters <>"
in order to allow the same native functions to perform both the 'quirks
mode' and more rigorous logic.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Wed, Dec 7, 2016, at 22:41, Steven D'Aprano wrote:
> Python's fnmatch lib is a good example. It has, or at least had, no
> support for escaping metacharacters. Anyone relying on Python's fnmatch and 
> glob
> modules alone for globbing will be unable to handle legitimate file names.

That's not true. You can "escape" metacharacters by enclosing them in
square brackets, forming a character class of a single character. I've
done the same in SQL, so it occurred to me immediately. But of course
you have to know you have to do this, and it's not immediately obvious
that it will work for the square bracket characters themselves. Other
implementations of globbing (including native windows) don't do this and
don't even *have* square brackets as metacharacters.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote:
> But, point of fact is that the feature to disable globbing is not often
> needed. Most Unix programs that accept filenames are happy to accept a
> list of filenames. There is not much call for a program to perform it's own
> globbing, like is required in Windows.
> 
> In fact, I can only think of three Unix "commandline" programs that need
> shell globbing disabled:
>   find - which performs it's own filename matching
>   grep - which uses regular expressions to search the contents of files,
>   and
>   sed  - which uses regular expressions to edit the contents of files.
> (I'm sure that there are a few more examples, though).

tar can do its own filename matching in some contexts, to match files
inside the archive for example.

7z does its own filename matching to allow distinguishing "extract from
multiple archives" [x \*.zip] from "extract a list of filenames from a
single archive" [x a.zip b.zip] - a BartC-compliant command line
paradigm if I ever saw one. I suspect it also allows you to match files
inside the archives in the list part.

scp lets you pass glob patterns to be matched on the remote server.
also, quoting for scp is somewhat unpleasant, since metacharacters in
general, not just globs but also $variables, quotes,`commands` etc, are
interpreted by both the local shell and the remote shell. sftp is a
little more sane, but still has remote globs for fetching, and quotes to
escape those globs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Wed, Dec 7, 2016, at 03:50, Peter Otten wrote:
> Is there an equivalent to
> 
> # touch -- -r 
> 
> on Windows?

Doesn't need one - options conventionally start with /, and filenames
can't contain /.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Wed, Dec 7, 2016, at 00:15, Steven D'Aprano wrote:
> and the shell expands the metacharacters ? {...} * [...] regardless of
> how much 
> smarts the command itself has.
> 
> There are thousands of programs I might use, and they may implement who
> knows 
> how many different globbing rules:
> 
> - some might support * and ? but not {...}

Just to point out, brace expansion isn't globbing. The most important
difference is that brace expansion doesn't care what files exist. {a,b}c
becomes "ac bc" regardless of if the files exist. {a,b}* becomes a* b*,
and if no files match one or both of these, it does whatever the shell
does in such cases.

This is why you can do commands like "mv
fix_a_ty{op,po}_in_this_filename"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Thu, Dec 8, 2016, at 01:20, Gregory Ewing wrote:
> BartC wrote:
> > And globbing doesn't take care of all of it: a Linux program still has 
> > to iterate over a loop of filenames. The same as on Windows, except the 
> > latter will need to call a function to deliver the next filename.
> 
> Actually, most of them will require *two* loops, one to
> iterate over a sequence of filespecs, and another for
> the files matching each filespec.

Speaking of which, I think I've advocated before for fileinput to
perform these loops, and for some mechanism for argparse to do it,
etc... seems like it's about that time again.

There are other issues, like needing a way to do Windows' version of
wildcard parsing with all its quirks, or at least some of its quirks -
"*.*" for all files and "*." for files not containing any dot being the
most commonly used in the real world.

> Whereas the unix program only requires one loop.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Tue, Dec 6, 2016, at 02:01, Larry Hudson via Python-list wrote:
> On 12/05/2016 06:51 PM, Nathan Ernst wrote:
> > IIRC, command.com was a relic of Win9x running on top of DOS and was a
> > 16-bit executable, so inherently crippled (and probably never support by
> > the NT kernel). Whereby cmd.exe coexisted but ran in a 32-bit context.
> 
> I know my 79-year-old memory is definitely subject to "senior moments"
> and not too reliable, but 
> IIRC it was Windows prior to 9x (Win 3 and earlier) that were 16 bit and
> ran on top of DOS. 
> Win95 was the first 32 bit version and was independent from DOS.

Yes but there was no* 32-bit windows command interpreter - it ran DOS in
a virtual machine inside it. Windows 3 did the same, actually - the real
architecture of Windows/386 was a 32-bit protected mode host kernel
called VMM32.VXD that ran all of Windows in one virtual machine and each
DOS window in another one, leading to the odd consequence of there being
cooperative multitasking between Windows apps but pre-emptive
multitasking between DOS apps [and between them and Windows].

The fact that Windows was launched at boot by running "win.com" (either
in autoexec.bat or manually at the command line) created a *perception*
that windows ran "on top of DOS", but running it really *replaced* DOS
in memory, putting the CPU into protected mode and everything. The
ability to boot into (or exit to) DOS was because people still did real
work (and games) in DOS and the virtual environment of DOS-on-Windows
didn't perform well enough to be sufficient.

*Well, I vaguely remember a version of cmd.exe that would run on Windows
98 floating around back in the day, but it certainly didn't come with
the OS. It might have been a pirated Windows NT component.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Mon, Dec 5, 2016, at 21:21, Dennis Lee Bieber wrote:
>   They are languages in their own right, with their own rules.
> 
>   The Windows command prompt being one of the weakest -- it doesn't
> support arithmetic and local variables, nor (to my knowledge) looping
> constructs. BAT files are limited to something like 9 parameters (which
> may
> be the only argument for not expanding wildcards at the command line
> level).

There are only nine that you can name explicitly, but there's no
obstacle to handling more with shift or %*. Also, there is a 'for' loop,
though the syntax is somewhat arcane (and you can always loop with
if/goto)

It can do arithmetic with 'set /a', and there is a 'setlocal' command
for local variable scopes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

[Random832]

On Mon, Dec 5, 2016, at 14:48, Michael Torrie wrote:
> Wow. Does that actually work?  And work consistently?  How would it
> handle globs like this:

The rules are simpler than you're probably thinking of. There's actually
no relationship between globs on the left and on the right. Globs on the
left simply select the files to rename as normal, the glob pattern
doesn't inform the renaming operation.

A question mark on the right takes the character from *that character
position* in the original filename. That is, if you have "abc", "rename
ab? ?de" renames it to "ade", not "cde".

A star on the right takes all remaining characters. If you include a
dot, the "name" (everything before the last dot) and "extension" of the
file are considered separate components [so in adddition to rename *.c
*.d, renaming a.* b.* where you have a.py, a.pyc, a.pyo will work].

But if you don't include a dot, for example "rename abcde.fgh xyz*", it
will rename to xyzde.fgh .
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Immutability of Floats, Ints and Strings in Python

[Random832]

On Fri, Nov 25, 2016, at 06:33, Ned Batchelder wrote:
> A Python implementation can choose when to reuse immutable objects and
> when not to.  Reusing a value has a cost, because the values have to
> be kept, and then found again. So the cost is only paid when there's
> a reasonable chance that the values will actually be needed again.
> And that cost has to be weighed against the opposite cost of simply
> making a new object instead.

Of course, there are more complicated costs to consider. For an
implementation where objects do not have a naturally persistent object
identity (such as an immovable address in memory as in cpython) they may
consider it easier to have an "object identity" that consists of the
whole value for immutable types rather than pay whatever costs are
associated with having a unique and unchanging "id" value. It's also not
hard to imagine an implementation that has "references" consisting of a
tagged union and incorporating the value in the "reference" itself (and
therefore the id) for floats and small integer/string values, though I
can't name any implementation (of Python, anyway - it's not uncommon for
Lisp) that does so.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Calling Bash Command From Python

[Random832]

On Mon, Oct 31, 2016, at 10:55, Wildman via Python-list wrote:
> I have code using that approach but I am trying to save myself
> from having to parse the entire shadow file.  Grep will do it
> for me if I can get code right.

Python already has built-in functions to parse the shadow file.

https://docs.python.org/3/library/spwd.html#module-spwd

But you can't use sudo this way if you use that. But why do you want to
use sudo from within the python script instead of just running the
python script with sudo?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why doesn't Python include non-blocking keyboard input function?

[Random832]

On Tue, Oct 25, 2016, at 02:39, Steven D'Aprano wrote:
> Not really. I think that lots of people think they need it, but
> once they write a little utility, they often realise that it's not
> that useful. That's just my opinion, and I'm one of those guys who
> wrote one:
> 
> http://code.activestate.com/recipes/577977-get-single-keypress/?in=user-4172944

Non-blocking (which your example here doesn't even do) isn't the same
thing as character-at-a-time. It doesn't even imply it, technically -
you could want to do other stuff and occasionally check if the user has
entered a line, though *that* is even *more* involved on Windows because
it means you can't do it with msvcrt.kbhit.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Making IDLE3 ignore non-BMP characters instead of throwing an exception?

[Random832]

On Mon, Oct 17, 2016, at 14:20, eryk sun wrote:
> You can patch print() to transcode non-BMP characters as surrogate
> pairs. For example:
> 
> On Windows this should allow printing non-BMP characters such as
> emojis (e.g. U+0001F44C).

I thought there was some reason this wouldn't work with tk, or else
tkinter would do it already?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to refactor nested for loop into smaller for loop assume each of them independent?

[Random832]

On Sat, Oct 8, 2016, at 07:29, Steve D'Aprano wrote:
> The oldest version I have access to is the *extremely* primitive 0.9. Not
> surprisingly, it doesn't have xrange -- but it lacks a lot of things,
> including globals(), map(), named exceptions, "" strings ('' is okay),
> exponentiation, and more.

Really? I'm not sure exactly what you mean by "named exceptions", but
0.9.1 has RuntimeError, EOFError, TypeError, MemoryError, NameError,
SystemError, and KeyboardInterrupt... but exceptions aren't objects,
they're strings.

They're caught by identity, though - "except 'type error'" fails to
catch TypeError, and vice versa.

The most interesting thing that I remember noticing about python 0.9.1
is that == and != don't exist - the equality comparison operators were
<> and a context-sensitive =.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to refactor nested for loop into smaller for loop assume each of them independent?

[Random832]

On Sat, Oct 8, 2016, at 06:12, BartC wrote:
> The OP's code however is a good demonstration of how crazy Python's 
> original for-range loop was: you need to construct a list of N elements 
> just to be able to count to N. How many years was it until xrange was 
> introduced?

Python 1.4 had it, and that's the earliest version of the documentation
that exists on the website.

Python 1.0.1 does include rangeobject, with a timestamp on rangeobject.h
of 1994-01-01.

Python 0.9.1 does not.

So it was added some time between the original alt.sources posting
(February 1991) and version 1.0 (January 1994). And one could argue that
1.0 was the first "real" release of the language.

And of course, you were always free to write:

i = 0
while i < 99:
i = i + 1
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A newbie doubt on methods/functions calling

[Random832]

On Thu, Oct 6, 2016, at 19:27, Loren Wilton wrote:
> So I don't want to WRITE a Python interpreter for the actual mainframe
> environment. I want to use an interpreter for an existing environment
> (Windows) where there are already a lot of existing libraries. But
> since a lot of the data to be analyzed is on the mainframe
> environment, and the results would be wanted there too, I need to
> extend the Python data access to the mainframe environment.

Honestly, the best implementation strategy I can think of is to first
implement a Python interpreter for the actual mainframe environment.
Then invent an RPC layer that can semi-transparently bridge the two for
when you want to call a module that only exists in the Windows
environment (or call _from_ such a module back to an object/module that
only exists in the mainframe environment), whether it's because it
requires a Windows library or because you want the Windows python
interpreter to do the heavy lifting because it's faster.

Do you have C in the mainframe environment?
-- 
https://mail.python.org/mailman/listinfo/python-list